implementação de uma solução baseada em software livre para a gerência de requisitos em um...
DESCRIPTION
Este trabalho descreve a implementação de uma solução baseada em software livre para auxiliar na execução eficiente do processo de desenvolvimento de software, mais preci-samente na área de gerência de requisitos. O processo de gerência de requisitos é um dos analisados na certificação em nível G do MPS.BR, sendo o outro processo o de ge-rência de projetos. A solução implementada busca automatizar a criação e manutenção da matriz de rastreabilidade vertical dos requisitos no processo de desenvolvimento de software, de forma a diminuir a incidência de erros na criação e manutenção da mesma e aumentar a eficiência do processo como um todo. O sistema também auxilia o mapea-mento das modificações dos requisitos com dependência, e alerta o responsável pelo projeto sobre as alterações críticas e possíveis problemas consequentes. A ideia dessa solução partiu de sugestões da equipe de avaliação do MPS.BR na certificação da Prognus Software Livre, empresa do ramo que possibilitou a pratica dessa pesquisa. Essa solução foi implementada em forma de um plug-in a ser incorporado na ferramenta de gestão de projetos Trac, que é utilizada pela empresa para o gerenciamento dos seus projetos. Para verificar a viabilidade e eficiência da implementação, o plug-in foi testado em projetos reais da empresa, a fim de levantar dados para uma análise sobre a eficiência da extensão. Após os testes, o plug-in foi disponibilizado para download no site oficial da ferramenta para que possa ser utilizado em outros projetos.TRANSCRIPT
FAA – FACULDADE ANGLO-AMERICANO
AIRTON BORDIN JUNIOR
IMPLEMENTAÇÃO DE UMA SOLUÇÃO BASEADA EM SOFTWARE LIVRE PARA A GERÊNCIA DE REQUISITOS EM UM PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE ADEQUADO AO NÍVEL G DE MATURIDADE DO MPS.BR
FOZ DO IGUAÇU
2011
i
AIRTON BORDIN JUNIOR
Implementação de uma solução baseada em software livre para a gerência de requisitos em um processo de desenvolvimento de software adequado ao
nível G de maturidade do MPS.BR
FOZ DO IGUAÇU 2011
Trabalho de conclusão de curso apresentado como requisito obrigatório para a obtenção do título de Bacharel em Ciência da Computação da Faculdade Anglo Americano de Foz do Iguaçu –PR. Orientador: Prof. Miguel Diogenes Matrakas Co-orientador: Prof. Alessandra Bussador
ii
________________________________
Airton Bordin Junior
Este trabalho reflete a opinião dos autores e não
necessariamente à da Faculdade Anglo-
Americano. Autorizamos a difusão deste
trabalho.
iii
O autor
Agradeço aos docentes Miguel Diogenes Matra-kas e Alessandra Bussador, pelo apoio e ajuda concedidos no andamento desta monografia e pela generosidade em compartilhar seus conhe-cimentos. Estendo esta gratulação aos demais professores envolvidos que não mediram esfor-ços em ajudar. Agradeço também aos familiares e amigos pelo incentivo e força proporcionados na conclusão de mais essa etapa da vida.
iv
"A teoria também se converte em graça material uma vez que se apossa dos homens." (Karl Marx)
v
RESUMO
Este trabalho descreve a implementação de uma solução baseada em software livre para auxiliar na execução eficiente do processo de desenvolvimento de software, mais preci-samente na área de gerência de requisitos. O processo de gerência de requisitos é um dos analisados na certificação em nível G do MPS.BR, sendo o outro processo o de ge-rência de projetos. A solução implementada busca automatizar a criação e manutenção da matriz de rastreabilidade vertical dos requisitos no processo de desenvolvimento de software, de forma a diminuir a incidência de erros na criação e manutenção da mesma e aumentar a eficiência do processo como um todo. O sistema também auxilia o mapea-mento das modificações dos requisitos com dependência, e alerta o responsável pelo pro-jeto sobre as alterações críticas e possíveis problemas consequentes. A ideia dessa solu-ção partiu de sugestões da equipe de avaliação do MPS.BR na certificação da Prognus Software Livre, empresa do ramo que possibilitou a pratica dessa pesquisa. Essa solução foi implementada em forma de um plug-in a ser incorporado na ferramenta de gestão de projetos Trac, que é utilizada pela empresa para o gerenciamento dos seus projetos. Para verificar a viabilidade e eficiência da implementação, o plug-in foi testado em projetos re-ais da empresa, a fim de levantar dados para uma análise sobre a eficiência da extensão. Após os testes, o plug-in foi disponibilizado para download no site oficial da ferramenta para que possa ser utilizado em outros projetos.
Palavras-chave: Gerência de requisitos, Matriz de rastreabilidade, MPS.BR, Plug-in.
vi
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................................ 8
1.1 OBJETIVOS ............................................................................................................................ 11
1.2 JUSTIFICATIVAS ................................................................................................................... 12
1.3 ORGANIZAÇÃO DO DOCUMENTO ................................................................................... 13
2 REVISÃO BIBLIOGRÁFICA ....................................................................................................... 15
2.1 MPS.BR ................................................................................................................................... 15
2.1.1 Modelo de referência MPS ................................................................................................... 17
2.2 FERRAMENTA TRAC ........................................................................................................... 21
2.3 SUBVERSION......................................................................................................................... 25
2.4 GERÊNCIA DE REQUISITOS ............................................................................................... 27
3 METODOLOGIA ........................................................................................................................... 35
3.1 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO ....................................................... 35
3.2 EXTREME PROGRAMMING (XP)....................................................................................... 36
3.3 SCRUM .................................................................................................................................... 39
3.5 CRYSTAL ................................................................................................................................ 42
3.6 ESCOLHA E UTILIZAÇÃO DA METODOLOGIA SCRUM NO PROJETO ....................... 45
3.7 BACKLOG DO PROJETO E DEFINIÇÃO DAS SPRINTS ................................................... 47
4 MODELAGEM ............................................................................................................................... 50
4.1 ARQUITETURA TRAC .......................................................................................................... 50
4.2 MODELAGEM DO PLUG-IN ................................................................................................ 51
5 IMPLEMENTAÇÃO ...................................................................................................................... 61
5.1 INSTALAÇÃO E CONFIGURAÇÃO DO AMBIENTE ........................................................ 61
5.2 PADRÕES DE CONTEÚDO DA PÁGINA DE DFD ............................................................. 61
5.3 IMPLEMENTAÇÃO DA ANÁLISE DA PÁGINA DE DFD ................................................. 63
5.4 GERENCIAMENTO DE AVISOS DE ALTERAÇÕES EM REQUISITOS .......................... 65
5.5 INSTALAÇÃO DO PLUG-IN NO TRAC .............................................................................. 65
5.6 TESTE DO PLUG-IN .............................................................................................................. 67
6 ANÁLISE DOS RESULTADOS .................................................................................................... 71
6.1 ESCOLHA DOS PROJETOS .................................................................................................. 71
6.2 INSTALAÇÃO E UTILIZAÇÃO DO PLUG-IN NA PROGNUS .......................................... 72
6.3 ANÁLISE DOS RESULTADOS ............................................................................................. 75
7 CONCLUSÕES .............................................................................................................................. 78
REFERÊNCIAS ................................................................................................................................. 81
vii
LISTA DE FIGURAS
FIGURA 1: COMPONENTES DO MODELO MPS ............................................................ 17
FIGURA 2: NÍVEIS DE MATURIDADE MPS.BR ............................................................... 18
FIGURA 3: RELAÇÃO ENTRE OS NÍVEIS DE MATURIDADE CMMI E MPS.BR ............ 19
FIGURA 4: FORMATAÇÃO WIKI DO Trac ........................................................................ 23
FIGURA 5: UTILIZAÇÃO DO TRAC EM CONJUNTO COM O SUBVERSION ................. 24
FIGURA 6: EVOLUÇÃO DOS REQUISITOS .................................................................... 29
FIGURA 7: ESTÁGIOS DO PROCESSO DE GERENCIAMENTO DE REQUISITOS ....... 31
FIGURA 8: O PROCESSO DE EXTREME PROGRAMMING .......................................... 37
FIGURA 9: FLUXO DE PROCESSO SCRUM .................................................................. 41
FIGURA 10: ESQUEMA RELACIONANDO A COMPLEXIDADE DO PROJETO COM O
TAMANHO DA EQUIPE E A CRITICALIDADE DO SISTEMA ...................... 44
FIGURA 11: CICLO DE VIDA DA FAMÍLIA CRYSTAL ....................................................... 45
FIGURA 12: REPRESENTAÇÃO DA ARQUITETURA DE COMPONENTES DO TRAC .. 51
FIGURA 13: DIAGRAMA DE CASO DE USO DO PLUG-IN.............................................. 52
FIGURA 14: DIAGRAMA DE ATIVIDADES DO PLUG-IN .................................................. 53
FIGURA 15: PSEUDOCÓDIGO DA CRIAÇÃO DA MATRIZ DE RASTREABILIDADE
VERTICAL .................................................................................................... 54
FIGURA 16: DIAGRAMA DE ATIVIDADES DA EDIÇÃO DA LISTA DE REQUISITOS ...... 56
FIGURA 17: DIAGRAMA DE CLASSES DO PLUG-IN ...................................................... 57
FIGURA 18: DIAGRAMA DE CLASSES REPRESENTANDO A RELAÇÃO ENTRE OS
PACOTES ..................................................................................................... 57
FIGURA 19: DIAGRAMA DE SEQUÊNCIA DA CRIAÇÃO DA MATRIZ DE
RASTREABILIDADE VERTICAL .................................................................. 58
FIGURA 22: PADRÕES DE REPRESENTAÇÃO DE CONTEÚDO DA PÁGINA DE
DECLARAÇÃO FORMAL DE DEMANDA .................................................... 62
FIGURA 23: AVISO DE ALTERAÇÃO DE REQUISITO COM DEPENDÊNCIA ................. 66
FIGURA 24: TELA DE ADMINISTRAÇÃO DE PLUG-INS DO Trac ................................... 67
FIGURA 25: BOTÃO DE CRIAÇÃO DA MATRIZ DE RASTREABILIDADE VERTICAL NA
PÁGINA DE DECLARAÇÃO FORMAL DE DEMANDA ................................ 68
FIGURA 26: MATRIZ DE RASTREABILIDADE VERTICAL GERADA PELO PLUG-IN ..... 68
viii
FIGURA 27: NOTAÇÃO WIKI REPRESENTANDO A MATRIZ DE RASTREABILIDADE
VERTICAL DOS REQUISITOS ..................................................................... 69
FIGURA 28: MATRIZ REPRESENTADA PELA NOTAÇÃO WIKI DO Trac ........................ 70
FIGURA 29: DEPENDÊNCIA DE REQUISITOS DA PRIMEIRA DEMANDA ..................... 71
FIGURA 30: DEPENDÊNCIA DE REQUISITOS DA SEGUNDA DEMANDA .................... 72
FIGURA 31: FASE DE EXECUÇÃO DEFINIDA NO PROCESSO DE
DESENVOLVIMENTO DA PROGNUS SOFTWARE LIVRE ......................... 73
FIGURA 32: MATRIZ DE RASTREABILIDADE EM RELAÇÃO À FASE DE
ESPECIFICAÇÃO ......................................................................................... 77
FIGURA 33: DIAGRAMA DE TRIPLA RESTRIÇÃO .......................................................... 77
ix
LISTA DE TABELAS
TABELA 1: NÍVEIS DE MATURIDADE MPS.BR E ATRIBUTOS DE PROCESSO ......... 178
TABELA 2: PROJETOS QUE UTILIZAM O TRAC .......................................................... 189
TABELA 3: FUNCIONALIDADES DA FERRAMENTA TRAC ............................................ 20
TABELA 4: PROPRIEDADES DO TRAC ........................................................................ 233
TABELA 5: MÉTODOS DE ACESSO AO REPOSITÓRIO SUBVERSION ..................... 244
TABELA 6: PRINCIPAIS COMANDOS SVN ................................................................... 295
TABELA 7: CLASSIFICAÇÃO DE REQUISITOS VOLÁTEIS ......................................... 318
TABELA 8: MATRIZ DE RASTREABILIDADE VERTICAL ............................................. 370
TABELA 9: LETRAS E SEUS SIGNIFICADOS NA METODOLOGIA CRYSTAL ............. 41
TABELA 10: TEMPO DE DURAÇÃO DOS PROJETOS EM FUNÇÃO DO NÚMERO DE
PESSOAS .................................................................................................. 441
TABELA 11: COMPARAÇÃO SEM E COM A UTILIZAÇÃO DO PLUG-IN ........................ 73
TABELA 12: QUANTIDADE DE HORAS POR ATIVIDADE DO PROCESSO ................... 74
TABELA 13: TEMPO GASTO COM A MATRIZ DE RASTREABILIDADE ......................... 74
1 INTRODUÇÃO
A exigência de se produzir software com mais rapidez e eficiência, tanto no
cenário nacional quanto no internacional, faz com que a cada dia a indústria desse
segmento disponibilize novos métodos, ferramentas e modelos de desenvolvimento que
auxiliem nessa produção para que sejam atingidos os prazos e níveis de produtividade
exigidos. Apesar de toda evolução, os projetos de software ainda são executados sem
padrões bem definidos e existe muita incerteza no processo de desenvolvimento.
Nesse cenário, desenvolvimento de software pode ser definido como um projeto.
Segundo a definição de (PMI, 2004), projeto é um empreendimento planejado, executado
e controlado, com início, meio e fim programado, tendo como objetivo criar um serviço ou
um produto singular.
Segundo (PRESSMAN, 2006), um projeto de software bem sucedido é aquele em
que é feita análise em alguns parâmetros principais, entre eles o escopo do software, os
riscos envolvidos, os recursos necessários, as tarefas a serem realizadas, os indicadores
a serem acompanhados, os esforços e custos aplicados e a sistemática a ser seguida.
Essa análise é feita no gerenciamento do projeto, que se inicia antes do trabalho técnico e
prossegue à medida que o software vai sendo desenvolvido. Por isso, o gerenciamento de
projetos é fundamental no sucesso do desenvolvimento de um software.
De acordo com (PMI, 2004), podemos definir gerenciamento de projetos como a
aplicação de diversas habilidades, técnicas, ferramentas e conhecimento às atividades do
projeto, com a finalidade de atender aos requisitos das partes interessadas no projeto.
Da necessidade de melhorias no processo de software nacional, surgiu o
MPS.BR, melhoria de processo de software brasileiro, criado pela SOFTEX (Associação
para promoção da excelência do software brasileiro), uma entidade privada e sem fins
lucrativos que visa aumentar a competitividade da indústria brasileira de software no
cenário mundial. O modelo desenvolvido pelo MPS.BR visa a melhoria contínua dos
processos de software nas empresas e com compatibilidade com as principais normas de
qualidade internacionais, como a ISO/IEC 15504 e a ISO/IEC 12207. O MPS.BR conta
com o apoio do Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e
Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE)
11
e Banco Interamericano de Desenvolvimento (BID). Uma das metas do programa é definir
e aprimorar um modelo de melhoria e avaliação de processo de software, visando
preferencialmente às micro, pequenas e médias empresas, de forma a atender às
necessidades de negócio das mesmas e ser reconhecido no âmbito nacional e
internacional.
Por visar as micro, pequenas e médias empresas nacionais, o MPS.BR leva em
consideração a realidade brasileira e não cobra royalties das empresas associadas ao
sistema, além disso, tem um baixo custo de implantação. Apesar dessas características,
esse modelo também poder ser implantado em uma empresa de grande porte.
O MPS.BR é dividido em níveis de maturidade, iniciando-se pelo nível G, definido
como parcialmente gerenciado, e evoluindo até o nível A, em otimização. Segundo
(SOFTEX, 2009), os níveis de maturidade estabelecem patamares de evolução de
processos, caracterizando estágios de melhoria da implementação dos processos do
modelo na organização. Cada um dos níveis tem atribuído um perfil de processos que
indicam onde a organização deve colocar o esforço de melhoria. A divisão em estágios
tem o objetivo de possibilitar uma implementação e avaliação adequada à realidade das
micro, pequenas e médias empresas e também permite uma visibilidade dos resultados
de melhoria de processos em prazos mais curtos.
1.1 OBJETIVOS
O trabalho tem como objetivo a criação de um plug-in para a ferramenta de
gestão de projetos Trac, que auxilie no gerenciamento de requisitos de um projeto. A
ferramenta Trac é utilizada pela Prognus Software Livre1 para o gerenciamento dos
projetos da empresa, e serviu como base de gerenciamento de projeto e gerenciamento
de requisitos para a certificação MPS.BR nível G, parcialmente gerenciado.
O plug-in auxiliará no gerenciamento de requisitos dos projetos desenvolvidos
pela empresa, automatizando a criação e manutenção da matriz de rastreabilidade
vertical de requisitos do projeto. Essa matriz armazena os requisitos do projeto e as
interdependências entre os requisitos.
A ferramenta também deverá alertar os usuários do Trac sobre requisitos que
apresentem alguma dependência. Essa representação será feita através da matriz de
1 http://www.prognus.com.br
12
rastreabilidade vertical, gerada na página do projeto, em forma de alerta textual para que
caso haja algum requisito com dependência este possa ser modificado pelo analista de
sistemas responsável.
A matriz de rastreabilidade vertical dos requisitos do projeto será criada e
apresentada ao usuário do sistema, em geral pelo analista de sistemas responsável pelo
projeto, essa matriz será apresentada em forma de tabela utilizando a linguagem Wiki do
Trac, na página do projeto. Detalhes da linguagem Wiki serão apresentados no item 2.2,
na página 18 deste documento.
O plug-in será incorporado à ferramenta Trac para ser utilizado em todos os
projetos desenvolvidos pela empresa, e será disponibilizado para download no site oficial
da ferramenta Trac2 sob licença GPL3.
1.2 JUSTIFICATIVAS
A Prognus Software Livre é uma empresa que está há 6 anos no mercado de
desenvolvimento de soluções baseadas em software livre, situada na cidade de Foz do
Iguaçu, no Parque Tecnológico Itaipu, atualmente especializada na suíte colaborativa
Expresso Livre4, uma suíte de comunicação que possui diversos módulos de serviços
centralizados em uma única aplicação, como e-mail, agenda, catálogo de endereços,
comunicador instantâneo, entre outros.
Para garantir a qualidade dos produtos gerados pela empresa, tanto para a
comunidade de software livre quanto para a carta de clientes, a empresa passou a se
preocupar em definir um processo de desenvolvimento de software tendo como base um
modelo de melhoria do processo (BETTIO et al, 2011).
Com isso, a empresa decidiu ingressar em um grupo de empresas coordenadas
pelo Centro Internacional de Tecnologia de Software (CITS) para a implantação do
modelo de melhoria de processos do MPS.BR.
Como forma de melhorar suas práticas de desenvolvimento, a empresa decidiu
implantar o modelo de melhoria de processo software MPS.BR nível G, parcialmente
gerenciado. Esse nível abrange as disciplinas de gerência de projetos e gerência de
requisitos (PMI, 2004).
2 http://trac.edgewall.org 3 General Public License
4 Documentação e download no site http://www.expressolivre.org
13
Para se adequar ao MPS.BR, foi necessária a seleção das ferramentas
adequadas para a realização de cada atividade do processo de desenvolvimento definido,
que de acordo com as suas políticas, deveria ser de licença livre. O sistema escolhido
para se utilizar no gerenciamento do desenvolvimento dos sistemas da empresa foi o
Trac, principalmente “por oferecer a flexibilidade de personalização por meio de plug-ins e
componentes que podem ser adicionados conforme necessidade” (BETTIO et al. apud
Trac 2011).
O Trac é um sistema Web que gerencia o desenvolvimento de sistemas,
altamente flexível e com uma API que permite construir plug-ins para tarefas específicas
(OLIVEIRA, 2010). A ferramenta será detalhada no item 2.2 deste documento.
Todo o processo de desenvolvimento da empresa foi adequado e incorporado ao
Trac, de modo que todas as fases de trabalho fossem gerenciadas e documentadas na
ferramenta.
Após a avaliação para a certificação da empresa, a equipe avaliadora do MPS.BR
fez algumas sugestões para que melhorasse ainda mais o processo de desenvolvimento
definido pela empresa, principalmente no que se refere à gerência de requisitos. Uma das
ideias sugeria a automatização da criação do artefato matriz de rastreabilidade vertical
dos requisitos, que era feita manualmente e que demandava muito tempo do processo.
Na maioria dos projetos, a quantidade de requisitos era grande, frequentemente maior
que 100, o que tornava a criação de uma matriz de rastreabilidade de forma manual um
trabalho árduo para o analista de sistemas do projeto. Além disso, a matriz deveria ser
criada utilizando a notação Wiki do Trac, o que tornava o processo ainda mais trabalhoso,
e suscetível a erros por parte do analista.
Para atender a sugestão da equipe avaliadora do MPS.BR e automatizar a
criação da matriz de rastreabilidade vertical dos requisitos do projeto, será desenvolvido o
plug-in para a ferramenta Trac. A utilização do plug-in irá facilitar a criação da matriz,
automatizando o processo, tornando essa tarefa mais rápida e diminuindo a possibilidade
de falhas.
1.3 ORGANIZAÇÃO DO DOCUMENTO
Este documento apresenta primeiramente o embasamento teórico de todo o
trabalho no capítulo de revisão bibliográfica. Neste capítulo, apresentamos os principais
14
assuntos abordados durante o trabalho: MPS.BR, Trac, Subversion e gerência de
requisitos. Em seguida é apresentada a metodologia utilizada no trabalho, bem como as
principais metodologias disponíveis. Na sequência são apresentadas as modelagens do
sistema, seguido do capítulo de implementação do plug-in. Na sequência é apresentado o
capítulo de aplicação e a análise dos resultados. Por fim é apresentado o capítulo de
conclusão do trabalho, que traz as considerações finais, os problemas enfrentados e os
trabalhos futuros.
15
2 REVISÃO BIBLIOGRÁFICA
Neste capítulo, apresentam-se os principais conceitos e ferramentas utilizados no
desenvolvimento do trabalho. O primeiro item aborda a certificação MPS.BR, seus níveis
e público alvo. Na sequência, é apresentada a ferramenta Trac, a qual será integrada a
ferramenta desenvolvida nesse trabalho. O item seguinte fala sobre a ferramenta de
controle de versão Subversion (SVN) e suas principais características. Por fim, o foco
será a gerência de requisitos, um importante tópico da disciplina de Engenharia de
Software e essencial para a sequência dos trabalhos.
2.1 MPS.BR
O MPS.BR é um programa para a melhoria de software brasileiro, criado em
dezembro de 2003 e coordenado pelo SOFTEX, Sociedade para Promoção da Excelência
do Software Brasileiro (SOARES et al, 2008).
O programa tem o apoio de diversas instituições como MCT (Ministério de Ciência
e Tecnologia), FINEP (Financiadora de Estudos e Projetos), SEBRAE (Serviço de Apoio
às Micro e Pequenas Empresas), BID (Banco Interamericano de Desenvolvimento), entre
outros (KALINOWSKI et al, 2010).
O principal objetivo do MPS.BR é:
estabelecer um caminho economicamente viável para que organizações, incluindo
as pequenas e médias empresas (PMEs), alcancem os benefícios da melhoria de
processos e da utilização de boas práticas da engenharia de software em um
intervalo de tempo razoável. Embora o foco da iniciativa seja PMEs, o modelo é
adequado também para apoiar a melhoria de processos em grandes organizações
(KALINOWSKI et al, 2010, p. 4)
Uma das metas do MPS.BR visa definir e aprimorar um modelo de melhorias e
avaliação de processo de software, visando preferencialmente as micro, pequenas e
médias empresas, de forma a atender as suas necessidades de negócio e ter
reconhecimento nacional e internacionalmente como um modelo aplicável à indústria de
software (SOARES et al, 2008).
Soares et al (2008) afirma que o modelo MPS.BR serve como um selo que indica
16
o nível de maturidade da empresa em relação às práticas relacionadas ao
desenvolvimento de software. Esse selo possui níveis, e cada nível tem suas práticas
particulares associadas. Portanto, uma empresa que possui a certificação MPS.BR utiliza
as boas práticas no processo de desenvolvimento de software e, teoricamente, tem
condições suficientes para produzir e desenvolver software dentro do prazo e custo
estimado sem prejudicar a qualidade do mesmo.
Para gerenciar o programa, foi definida uma estrutura organizacional, e
responsabilidades foram atribuídas a profissionais de engenharia de software e
pesquisadores. A estrutura organizacional se deu da seguinte forma (KALINOWSKI et al,
2010):
Unidade de execução do programa MPS.BR: É responsável por definir estratégias
e gerenciar as atividades do programa. Atualmente, esta equipe tem a coordena-
ção do SOFTEX;
Equipe técnica do modelo MPS: responsável pela criação e aprimoramento contí-
nuo do modelo MPS e capacitação de pessoas por meio de cursos, provas e
workshops. A equipe é coordenada pela Universidade Federal do Rio de Janeiro
(UFRJ);
Fórum de credenciamento e controle do MPS: É responsável por emitir parecer
que subsidie a decisão da SOFTEX sobre o credenciamento de instituições im-
plementadoras (II) e instituições avaliadoras (IA), avaliar e controlar resultados de
implementações MPS e garantir que as organizações avaliadas pelo modelo MPS
realizem suas atividades dentro dos limites éticos e de qualidades esperados. A
coordenação desta atividade é feita por representantes do governo brasileiro, da
academia e da indústria.
Um dos principais requisitos para desenvolver o modelo MPS é que este deveria
incorporar tanto práticas internacionalmente reconhecidas de implantação e avaliação de
processos de software, quanto atender às necessidades da indústria brasileira de
software. Pensando nisso, foram utilizadas as normas ISO/IEC 12207 e ISO/IEC 15504
como base técnica para a definição dos componentes do modelo MPS (KALINOWSKI et
al, 2010).
Um dos modelos que serviram como base para a criação do MPS.BR foi o CMMI5.
Segundo (PRESSMAN, 2006) o CMMI é um abrangente metamodelo de processo, criado
5 Capability Maturity Model Integration. Mais informações disponíveis em http://www.sei.cmu.edu/cmmi/
17
pelo SEI (Software Engineering Institute), e baseado em um conjunto de capacidades de
engenharia de software que devem estar presentes à medida que as empresas alcançam
diferentes níveis de maturidade de processo.
Pensando na importância do modelo CMMI para as organizações nacionais que
atuam em mercados internacionais, este modelo foi considerado como complemento
técnico para a definição dos processos do MPS. O MPS possui três componentes
principais: Modelo de referência MPS (MR-MPS), Método de avaliação MPS (MA-MPS) e
o Modelo de negócios MPS (MN-MPS). A figura 1 ilustra estes componentes e as suas
relações.
Para este trabalho, será apresentado somente o Modelo de referência MPS (MR-
MPS), que contempla os processos de engenharia de software e que faz parte do escopo
do trabalho.
FIGURA 1 – COMPONENTES DO MODELO MPS FONTE: SOFTEX, 2009.
2.1.1 Modelo de referência MPS
De acordo com (SOFTEX, 2009), o modelo de referência MPS (MR-MPS) contém
todos os requisitos que os processos das unidades organizacionais devem atender para
estar em conformidade com o modelo de referência. Este documento contém as
definições dos níveis de maturidade, processos e atributos do processo.
Os níveis de maturidade estabelecem patamares de evolução de processos, e
caracterizam estágios de melhoria da implementação de processos na organização. O
18
nível de maturidade permite prever o desempenho futuro de uma organização ao executar
um ou mais processos (SOFTEX, 2009).
(SOFTEX, 2009) afirma que o modelo de referência busca atender às
necessidades de implantar os princípios de engenharia de software de forma adequada
às necessidades de negócio das organizações e define sete níveis de maturidade de
processos.
FIGURA 2 – NÍVEIS DE MATURIDADE MPS.BR FONTE: SOARES et al, 2008.
A figura 2 ilustra os níveis de maturidade definidos no modelo de referência do
MPS.BR. Segundo (SOARES et al, 2008), a escala de maturidade se inicia no nível G e
progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um
perfil de processos que indica onde a organização deve colocar o esforço de melhoria. O
alcance de determinado nível de maturidade se obtém quando são atendidos os
propósitos e todos os resultados esperados dos respectivos processos e dos atributos
daquele nível.
Apesar da divisão em estágios ser baseada nos níveis de maturidade do CMMI,
os níveis do MPS.BR tem uma graduação diferente para possibilitar a implementação e
avaliação mais adequada às micro, pequenas e médias empresas. Essa divisão em níveis
19
também possibilita a visibilidade dos resultados de melhoria de processos em prazos mais
curtos (SOARES et al, 2008).
(SOFTEX, 2009) afirma que pode ser feita uma correspondência entre os níveis
de maturidade do MPS.BR e do CMMI. Essa correspondência é apresentada na figura 3,
que ilustra a relação entre os níveis dos dois modelos de melhoria de processo.
FIGURA 3 – RELAÇÃO ENTRE OS NÍVEIS DE MATURIDADE CMMI E MPS.BR FONTE: SOARES et al, 2008.
De acordo com (SOARES et al, 2008), cada nível de maturidade possui suas
áreas de processo. A capacidade do processo é representada por um conjunto de
atributos de processo descrito em termos de resultados esperados. A capacidade do
processo expressa o grau de refinamento e institucionalização com que o processo é
executado na organização. À medida que a organização vai evoluindo nos níveis de
maturidade do modelo, deve ser atingido um nível maior de capacidade para
desempenhar o processo.
(SOFTEX, 2009) afirma que o atendimento aos atributos do processo (AP) se dá
pelo atendimento aos resultados esperados dos atributos do processo (RAP). Ou seja,
para cada atributo do processo existem alguns resultados esperados. Os diferentes níveis
20
de capacidade de dos processos são descritos por nove atributos de processo. O alcance
de cada atributo de processo é avaliado utilizando alguns resultados esperados de
atributos de processo.
De acordo com (SOFTEX, 2009), os atributos de processos são:
AP 1.1 – O processo é executado;
AP 2.1 – O processo é gerenciado;
AP 2.2 – Os produtos de trabalho do processo são gerenciados;
AP 3.1 – O processo é definido;
AP 3.2 – O processo está implementado;
AP 4.1 – O processo é medido;
AP 4.2 – O processo é controlado;
AP 5.1 – O processo é objeto de melhorias e inovações;
AP 5.2 – O processo é otimizado continuamente.
Para cada nível de maturidade, existem os processos e os atributos dos
processos que devem ser atendidos. A tabela 1 apresenta a relação entre os níveis de
maturidade do MPS.BR e os atributos de processo do nível (SOFTEX, 2009).
Nível Processos Atributos de processos
A AP 1.1, AP 2.1, AP 2.2, AP
3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2
B Gerência de projetos. AP 1.1, AP 2.1, AP 2.2, AP
3.1, AP 3.2, AP 4.1 e AP 4.2
C Gerência de riscos, desenvolvimento para reutilização e gerência de decisões.
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
D Verificação, validação, projeto e construção do produto, integração com o produto e desenvolvimento de requisitos.
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
E Gerência de projetos, gerência de reutilização, gerência de recursos humanos, definição do processo organizacional, avaliação e melhoria do processo organizacional.
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
F Medição, garantia de qualidade, gerência de portfólio de projetos, gerência de configuração, aquisição.
AP 1.1, AP 2.1 e AP 2.2
G Gerência de projetos e gerência de requisitos. AP 1.1 e AP 2.1
TABELA 1 – NÍVEIS DE MATURIDADE MPS.BR E ATRIBUTOS DE PROCESSO FONTE: SOFTEX, 2009.
A Prognus Software Livre optou pela certificação MPS.BR em nível G, que tem
como processos a gerência de projetos e a gerência de requisitos. Esta última sendo o
foco principal do nosso trabalho.
Apesar de aprovada na certificação de nível G do MPS.BR, a banca examinadora
21
fez algumas sugestões para a empresa melhorar o gerenciamento dos requisitos dos
seus processos. Uma delas é a de automatizar a criação e manutenção da matriz de
rastreabilidade vertical dos requisitos, que estava sendo feita manualmente pelo analista
de sistemas. A automatização dessa funcionalidade é um dos objetivos deste trabalho, e
mais detalhes de sua implementação serão apresentados no capítulo 5, página 56 deste
documento.
2.2 FERRAMENTA TRAC
Trac é uma ferramenta open source que pode ser utilizada tanto para o
desenvolvimento como para manutenção do software, e não apenas para gerenciar o
ciclo de vida dos projetos (OLIVEIRA, 2010).
A ferramenta é desenvolvida na linguagem de programação Python e está
disponível sob a licença GPL (General Public License) desde 2005.
O projeto iniciou-se em 2003, inspirado na ferramenta CVSTrac6. É mantido pela
empresa Edgewall Software7 e por colaboradores da comunidade. Nos últimos anos, o
Trac vem ganhando popularidade e vem sendo usado por diversas empresas para
gerenciar seus projetos. (DIAS, 2011)
Projeto Versão do Trac
Track-Hacks.org 0.10.6 Dojo Toolkit 0.11 Fedora hosted projects 0.10.5 JQuery 0.12 OpenStreetMap.org 0.11.7 Pidgin 0.11.1 SourceForge.net 0.11.2.1
TABELA 2 – PROJETOS QUE UTILIZAM O TRAC FONTE: http://trac.edgewall.org/wiki/TracUsers
A tabela 2 apresenta uma relação de projetos que utilizam a ferramenta Trac para
gerenciá-los. A lista completa, com aproximadamente 450 projetos que fazem uso do Trac
pode ser encontrada na página da ferramenta8.
6 Documentação e download disponível em http://www.cvstrac.org/index.html/doc/trunk/www/index.html
7 http://www.edgewall.org/
8 http://trac.edgewall.org/wiki/TracUsers.
22
A utilização do Trac para o gerenciamento dos projetos de desenvolvimento traz
diversos benefícios, entre eles (OLIVEIRA, 2010):
Melhoria na qualidade do produto e do processo de desenvolvimento;
Registro, rastreamento e controle das solicitações durante seu ciclo de vida do
software;
Amarração entre o controle de versão e o controle de mudança, através de um
utilitário de changeset, que possibilita a visualização da diferença entre duas
versões de um arquivo;
Melhor documentação do projeto através de participação da equipe de
desenvolvimento.
O Trac disponibiliza diversas funcionalidades para o gerenciamento e controle dos
projetos de software. A tabela 3 descreve as principais funções e as suas descrições
(Oliveira, 2010):
Funcionalidade Descrição
Controle de tickets A ferramenta Trac comporta o controle de tarefas do projeto, onde é possível criar tarefas de melhoria, correção e implementação em um projeto.
Ferramenta Wiki A ferramenta Wiki é a responsável pela documentação completa de um projeto, onde os analistas, desenvolvedores, podem criar requisitos do software.
Integração com o Subversion A ferramenta Trac funciona como um browser para o Subversion onde o usuário pode navegar entre as pastas dos projetos.
Acompanhamento da evolução do projeto
É possível gerar vários tipos de relatórios referentes ao projeto, possibilitando o acompanhamento da evolução do projeto.
TABELA 3 – FUNCIONALIDADES DA FERRAMENTA TRAC FONTE: Oliveira, 2010.
Uma das características mais interessantes do Trac é a utilização de um
mecanismo de Wiki para a documentação colaborativa do projeto que está sendo
gerenciado. O Wiki é um mecanismo que serve para a edição colaborativa do conteúdo
de um documento que fica disponível para acesso através de um navegador Web a
qualquer momento. Esse mecanismo também possibilita a referência cruzada entre todos
os elementos mantidos pelo Trac em um projeto, ou entre projetos distintos (DIAS, 2011).
Na Prognus Software Livre, para cada projeto existe uma página de declaração
formal de demanda (DFD), onde são descritos os requisitos e outras informações relativas
ao projeto. A página é criada utilizando a linguagem Wiki disponibilizada pela ferramenta
23
Trac.
O texto Wiki possui uma sintaxe um pouco diferente e mais simples que a
linguagem de marcação HTML, o que facilita e encoraja as pessoas a contribuírem para o
conteúdo dessas páginas utilizando essa linguagem. É importante lembrar que após a
confirmação da edição da página em linguagem Wiki, é produzido um texto formatado em
HTML como saída. A figura 4 apresenta alguns códigos Wiki básicos, para dar uma ideia
do funcionamento da linguagem.
FIGURA 4 – FORMATAÇÃO WIKI DO TRAC FONTE: http://trac.edgewall.org/wiki/WikiFormatting
A ferramenta Trac pode ser integrada com o Subversion – sistema de controle de
versão, que será detalhado no item 2.3 deste documento – e funciona como um browser
para a ferramenta. Através do Trac, é possível manipular as pastas sob controle de
versão, visualizar logs de mudança nos arquivos, diferença entre revisões, entre outros
(OLIVEIRA, 2010).
A figura 5 mostra o Trac sendo utilizado em conjunto com a ferramenta de
controle de versão Subversion (SVN), que será mostrada com mais detalhes no item 2.3
descrito na página 22 deste documento. Note que é possível visualizar e navegar pelos
diretórios sob controle de versão. O Trac controla também as revisões dos arquivos, e
cada commit do SVN pode ser atrelado a um ticket do Trac para facilitar a organização e a
24
manutenção do código, bem como para rastrear possíveis inconsistências no projeto
devido a alterações equivocadas.
FIGURA 5 – UTILIZAÇÃO DO TRAC EM CONJUNTO COM O SUBVERSION FONTE: Trac Prognus, 2011, https://dev.prognus.com.br/expresso/browser/expresso/trunk
A partir da versão 0.9 é possível implementar plug-ins para a ferramenta Trac.
Esses plug-ins são baseados na arquitetura de componentes, que será apresentada em
detalhes no item 4.1 que trata da arquitetura do Trac (EDGEWALL, 2011).
Os plug-ins desenvolvidos para a ferramenta devem ser escritos na linguagem
Python9, a mesma utilizada para a criação do Trac. O Trac faz a busca por plug-ins no
diretório plugins/ no local da instalação da ferramenta. Esses plug-ins também podem ser
instalados através da interface de administração fornecida pela ferramenta. Essa tela e a
instalação do plug-in serão comentados no item 5.4 que trata especificamente da
instalação de plug-ins no Trac.
A possibilidade de flexibilidade de personalização por meio de plug-ins e
componentes que podem ser adicionados conforme a necessidade foi um dos principais
motivos da escolha da ferramenta Trac pela Prognus para o gerenciamento dos projetos
da empresa (BETTIO et al, 2011).
O Trac disponibiliza diversos componentes para o gerenciamento dos projetos de
software e suas mudanças, como a funcionalidade de tickets que representa uma tarefa
do projeto. Na tabela 4, são apresentadas as principais propriedades da ferramenta Trac
9 Linguagem de programação. Mais informações podem ser encontradas no site oficial da linguagem:
http://python.org/
25
(OLIVEIRA, 2010).
Trac Wiki Contém toda a documentação dos projetos
Trac Timeline Histórico de desenvolvimento do projeto Trac Browser Código-fonte mostrado em estrutura de pastas do projeto Trac Changeset Alterações do projeto Trac Revisionlog Logs das revisões do projeto Trac Tickets Representação e distribuição das tarefas Trac Reports Relatórios do projeto Trac Roadmap Progresso do projeto
TABELA 4 – PROPRIEDADES DO TRAC FONTE: Oliveira, 2010.
2.3 SUBVERSION
O Subversion é um sistema de controle de versão open source. que gerencia
arquivos e diretórios e as modificações realizadas neles ao longo do tempo. Isso permite
recuperar uma versão antiga dos dados que estão sob controle de versão bem como
examinar o histórico das alterações dos arquivos e diretórios (SVNBOOK, 2007).
O Subversion (SVN) é mantido pela Apache Software Foundation10, que permite
armazenar documentos efetuando controle de acesso ao repositório e mantendo um
controle de revisões desses documentos. Seu desenvolvimento iniciou-se no ano 2000,
tendo como objetivo construir um software de controle de versão melhor que a principal
opção disponível na época, o CVS, que era considerado limitado. Desde que foi
desenvolvido, diversos projetos migraram do CVS para o Subversion, como por exemplo
o projeto Debian11 e o projeto KDE12 (DIAS, 2011).
De modo geral, a maior parte das funcionalidades do CVS estão contidas no
Subversion, o que facilita a migração entre os sistemas. As principais melhorias em
relação ao CVS foram o controle de diretórios – uma vez que o CVS somente controlava
arquivos – as operações atômicas de commit – possibilitando que, caso ocorra alguma
falha durante o commit, todo o processo seja desfeito, evitando inconsistências -
compatibilização com arquivos binários e o uso mais eficiente da rede (DIAS, 2011).
O repositório do Subversion pode ser acessado de diferentes modos: desde o
disco local até utilizando protocolos de rede. Independente da forma que será acessado, a
localização desse repositório sempre é representada através de uma URL. A tabela 5
10
http://www.apache.org/ 11
http://svn.debian.org/ 12
http://websvn.kde.org/
26
apresenta os principais métodos de acesso ao repositório Subversion.
Esquema Método de acesso
file:/// Acesso direto ao repositório por meio de disco local http:// Acesso via protocolo WebDAV através do servidor Apache https:// http com segurança SSL svn:// Acesso pelo svnserve svn+ssh:// Acesso pelo svnserve usando túnel SSH
TABELA 5 – MÉTODOS DE ACESSO AO REPOSITÓRIO SUBVERSION Fonte: Dias, 2011
Os dados que serão mantidos sob controle de versão são armazenados em um
repositório, que é acessado através de uma URL. Embora existam diversas combinações
possíveis de configuração de servidor e plataforma para usar como um repositório, a mais
comum é utilizar o servidor Apache rodando em plataforma GNU/Linux (DIAS, 2011).
O Subversion trabalha utilizando a uma arquitetura cliente-servidor. No servidor
são mantidos os arquivos no repositório, identificados por uma URL e os computadores
clientes são os usuários que de utilizam os documentos do repositório.
Os documentos são recuperados do repositório pelos clientes e armazenados
localmente, na operação de checkout. Esses documentos ficam sob controle de versão, e
suas modificações são controladas pelo SVN. O cliente pode enviar suas modificações
para o repositório, utilizando a função de commit. Como vários clientes podem estar
trabalhando nos mesmos dados ao mesmo tempo, o SVN tem um controle de conflitos,
que determina onde uma alteração que causa conflito foi realizada e disponibiliza uma
ferramenta de merge, que mescla as alterações nos arquivos feitas pelos clientes
automaticamente. A cada commit é gerada uma revisão, que é um ponto de referência na
árvore do repositório. É possível o cliente visualizar o conteúdo de um documento em
qualquer revisão, e pode também atualizar seus documentos com as modificações do
repositório com a função de update. A qualquer momento, o cliente pode verificar o status
de sua cópia de trabalho, com a função status disponibilizada pelo SVN. Caso os
documentos de trabalho estejam desatualizados, o cliente pode utilizar o update para
incorporar as modificações que foram realizadas após a data do seu checkout do
repositório. Na tabela 6 são apresentados os principais comandos do Subversion
(SVNBOOK, 2007).
27
Comando Atalho Ação Exemplo
Checkout Co Faz um download do repositório e cria uma cópia de trabalho
svn co https://dev.prognus.com.br/ /expresso/trunk
Status St Mostra alterações da cópia de trabalho
svn status
Commit Ci Envia alterações da cópia de trabalho para o servidor
svn ci -m "Informação sobre commit"
Add Adiciona novos arquivos ao repositório
svn add foo.c
Delete Rm Remove arquivos do repositório svn del foo.c
Revert Volta arquivo da cópia de trabalho para ultima versão baixada do repositório
svn revert -R1177 .
Update Up Atualiza para ultima versão do repositório
svn update
Help Mostra ajuda svn help
TABELA 6 – PRINCIPAIS COMANDOS SVN Fonte: SVNBOOK, 2007.
2.4 GERÊNCIA DE REQUISITOS
(PRESSMAN, 2006) define o gerenciamento de requisitos como um conjunto de
atividades que ajudam a equipe do projeto a identificar, controlar e rastrear requisitos e
modificações em requisitos em qualquer parte do desenvolvimento à medida que o projeto
continua acontecendo.
Quanto ao gerenciamento de requisitos, podemos citar:
O gerenciamento de requisitos é o processo de compreender e controlar as
mudanças nos requisitos de sistemas. O processo de gerenciamento de requisitos
é realizado em conjunto com outros processos da engenharia de requisitos, e o
gerenciamento ativo dos requisitos deve começar assim que um esboço da versão
do documento de requisitos estiver disponível. (SOMMERVILLE, 2003, p. 118)
Segundo (ÁVILA E SPÍNOLA, 2007), o processo de gerência de requisitos é a
atividade de administrar os requisitos ao longo do tempo do projeto.
De acordo com (SOFTEX, 2009), a gerência de requisitos envolve identificar os
requisitos do produto e dos componentes do projeto, assim como estabelecer e manter
um acordo entre o cliente e a equipe do projeto sobre os requisitos. Também deve
28
controlar e tratar as mudanças nos requisitos durante o desenvolvimento.
A gestão dos requisitos do sistema começa com a identificação dos mesmos.
Cada requisito recebe um identificador, que segue representando os requisitos nos
artefatos seguintes (PRESSMAN, 2006).
Um dos maiores problemas no gerenciamento de requisitos é que os requisitos
para sistemas de software estão sempre mudando, pois geralmente são desenvolvidos
para lidar com problemas “intrincados”. E como não pode ser definido inteiramente o
problema, seus requisitos são necessariamente incompletos (SOMMERVILLE, 2003).
Os requisitos de software focalizam a atenção nos recursos do software, nos
objetivos da empresa para a qual está sendo desenvolvido o sistema e em outros
aspectos e sistemas da empresa. Enquanto essa definição de requisitos do sistema
continua sendo desenvolvida, uma melhor compreensão da necessidade dos usuários é
alcançada, causando modificações nos requisitos (SOMMERVILLE, 2003).
Segundo (FILHO, 2005), não deveria haver a necessidade de alteração nos
requisitos ao longo do projeto, caso fosse possível realizar os fluxos de requisitos e
análises de forma perfeita. Na prática, essas alterações ocorrem devido a diversos
fatores, que podem ser externos como alterações na tecnologia, gerenciais e políticas, ou
internos, como uma mudança no entendimento do problema por parte dos usuários finais
do mesmo ou até mesmo pelos desenvolvedores do sistema.
(ÁVILA E SPÍNOLA, 2007) afirmam que softwares complexos estão sempre sendo
modificados. Essas modificações ocorrem por conta da natureza volátil dos requisitos,
que sofrem influência de diversos fatores, como mudanças externas, erros cometidos no
levantamento de requisitos, entre outros.
Grandes sistemas são geralmente necessários para melhorar o status atual. O
sistema existente pode ser um sistema manual ou desatualizado. Mesmo que essas
dificuldades sejam conhecidas, mostra-se difícil prever que efeitos o sistema que foi
aperfeiçoado terá sobre a organização, e depois que os usuários finais se familiarizam
com o sistema, novos requisitos surgem (SOMMERVILLE, 2003). Isso acontece pelas
seguintes razões:
Os grandes sistemas geralmente tem uma comunidade diversificada de usuários.
Esses diferentes usuários tem diferentes requisitos e prioridades, que podem ser
contraditórios. Os requisitos finais do sistema são uma conciliação entre eles e,
com a experiência, diversas vezes é contatado que o equilíbrio do apoio dispendi-
do para diferentes usuários precisa ser modificado;
29
As pessoas que pagam pelo sistema dificilmente são a mesma pessoa que vai uti-
lizar o mesmo. Os clientes do sistema impõem os requisitos em função de restri-
ções orçamentárias e organizacionais. Esses requisitos podem ser conflitantes
com os requisitos dos usuários finais, que realmente fazem uso do sistema;
A empresa e o ambiente técnico se modificam, e isso deve ter impacto no próprio
sistema. A prioridade da empresa pode ser modificada, acarrentando consequen-
tes mudanças no suporte necessário ao sistema, e também novas legislações e
regulamentos podem ser criados, o que certamente deverá ser implementado pe-
lo sistema. Os requisitos não funcionais são, particularmente, afetados por mu-
danças na tecnologia de hardware.
Ainda de acordo com (SOMMERVILLE, 2003), o gerenciamento de requisitos é o
processo de compreender e controlar as mudanças em requisitos de sistemas. O
processo de gerenciamento de requisitos é realizado junto com outros processos da
engenharia de requisitos como o levantamento inicial dos requisitos e o esboço da versão
do documento de requisitos.
FIGURA 6 – EVOLUÇÃO DOS REQUISITOS FONTE: Sommerville, 2003, pag. 119
A figura 6 ilustra a evolução dos requisitos do sistema com o passar do tempo. Os
requisitos iniciais geralmente mudam com o aperfeiçoamento da compreensão do
problema.
Levando em consideração uma perspectiva de evolução, podemos dividir os
requisitos em duas classes de requisitos: Requisitos permanentes e requisitos voláteis
(SOMMERVILLE, 2003).
Os requisitos permanentes são os requisitos estáveis, que derivam da atividade
30
principal da organização e que se relacionam diretamente com o domínio do problema.
Podemos citar como exemplo um sistema de controle de estoque onde sempre haverá
requisitos relacionados aos produtos, aos funcionários da empresa, às vendas, às
entradas, entre outros. Segundo (SOMMERVILLE, 2003), esses requisitos podem ser
derivados dos modelos de domínio, que mostram as entidades e os relacionamentos que
caracterizam um domínio de aplicação.
Os requisitos voláteis se referem aos requisitos que provavelmente vão ser
modificados durante o desenvolvimento do sistema, ou depois que o sistema estiver em
operação. Podemos citar como exemplos requisitos resultantes de políticas
governamentais sobre determinada área.
Os requisitos voláteis são organizados em quatro classes (SOMMERVILLE 2003
apud HARKER et al 1993), como demonstrado na tabela 7.
Tipos de requisitos Descrição
Requisitos mutáveis Requisitos que mudam devido a mudança no ambiente no qual o organização está operando. Por exemplo, em sistemas, o financeiro do tratamento de paciente pode mudar e, assim exigir que informações de diferentes tratamentos sejam coletadas.
Requisitos emergentes Requisitos que surgem à medida que a compreensão do sistema pelo cliente progride durante o desenvolvimento do sistema. O processo de projeto pode revelar novos requisitos emergentes.
Requisitos conseqüência Requisitos que resultam da introdução do sistema de computador. A introdução do sistema de computador pode mudar os processos da organização e criar novas formas de trabalho que geram nova requisitos de sistema.
Requisitos de compatibilidade
Requisitos que dependem de sistema ou processos de negócios específicos dentro de uma organização. À medida que eles mudam, os requisitos de compatibilidade do sistema encomendados ou entrega podem também evoluir.
TABELA 7 - CLASSIFICAÇÃO DE REQUISITOS VOLÁTEIS Fonte: Sommerville, 2003, p. 119
O gerenciamento de alterações nos requisitos deve ser aplicado a todas as
propostas para os requisitos. Deve se utilizar um método formal, com a vantagem de que
todas as propostas de mudanças sejam tratadas de modo consistente e feitas de forma
controlada.
A figura 7 representa os três principais estágios em um processo de
gerenciamento de mudanças.
31
FIGURA 7 – ESTÁGIOS DO PROCESSO DE GERENCIAMENTO DE MUDANÇAS DE REQUISITOS FONTE: Sommerville, 2003, pag. 122
No estágio de Análise do problema e especificação da mudança, o processo se
inicia com a identificação do problema com os requisitos, ou algumas vezes com a
proposta específica de mudança. Nessa fase, é realizada a análise do problema ou da
proposta de mudança, para verificar se a mesma é válida.
Para se analisar o efeito da mudança proposta, utilizam-se informações sobre o
conhecimento geral dos requisitos do sistema. O custo dessa mudança é estimado em
termos das modificações do documento de requisitos. Quando essa análise é concluída, a
decisão sobre prosseguir ou não com a alteração de requisito ou não é tomada.
As mudanças ocorrem efetivamente no estágio de implementação de mudanças
onde são modificados os documentos de requisitos e quando necessário o projeto do
sistema e a implementação
(PRESSMAN, 2006) afirma que existem muitos tipos de tabelas de rastreamento
possíveis para gerenciar os requisitos do sistema. São elas: rastreamento de
características, que mostra como os requisitos se relacionam às características
importantes do sistema observados pelo cliente; rastreamento de fontes que identifica a
fonte de cada requisito; rastreamento de dependência, que indica como os requisitos
estão relacionados uns aos outros, e que é o foco principal deste trabalho; rastreamento
de subsistemas, que caracteriza os requisitos pelos subsistemas que eles governam e
rastreamento de interface, que mostra como os requisitos se relacionam com as
interfaces internas e externas do sistema.
Existem muitas relações entre requisitos e outros requisitos entre os requisitos do
projeto do sistema. Há também elos entre os requisitos e as razões básicas da
proposição desses requisitos. Quando são propostas modificações, é preciso
verificar o impacto dessas mudanças sobre os outros requisitos e o projeto do
sistema. (SOMMERVILLE, 2003, p. 120)
As informações de rastreabilidade são, com frequência, representadas por
32
matrizes de rastreabilidade (SOMMERVILLE, 2003).
(SOFTEX, 2009) afirma que para apoiar o processo de mudança de requisito é
fundamental definir e manter a rastreabilidade dos requisitos. A rastreabilidade entre os
requisitos do produto de trabalho pode ser feita na forma de rastreabilidade vertical e
rastreabilidade horizontal.
A rastreabilidade horizontal aborda a relação dos componentes entre conjuntos de
produtos de trabalho. Por exemplo, cada componente do projeto tem seus artefatos
rastreados até chegar ao código que implementa essa funcionalidade. Já a rastreabilidade
vertical expressa a relação entre as partes do produto de trabalho pertencentes ao
mesmo artefato, como por exemplo a interdependência entre os requisitos do sistema
(PFLEEGER, 2004).
Segundo (PRESSMAN, 2006), em muitos casos essas tabelas de rastreamento
são mantidas como parte do mesmo banco de dados dos requisitos, de modo que ela
possa ser pesquisada rapidamente e para que seja possível entender como a modificação
em um requisito afetará diferentes requisitos do sistema.
ID de Requisitos 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 X 1.2 X X 1.3 X 2.1 X X 2.2 X 2.3 X X 3.1 X X 3.2 X
TABELA 8 – MATRIZ DE RASTREABILIDADE VERTICAL Fonte: Sommerville, 2003, p. 120
A tabela 8 ilustra a representação de uma matriz de rastreabilidade vertical que
identifica as interdependências entre os requisitos de um sistema. Como podemos
perceber, para sistemas com poucos requisitos a rastreabilidade da interdependência
entre eles pode não ser tão necessária.
(SOMMERVILLE, 2003) afirma que o apoio de uma ferramenta para o
gerenciamento de facilidade de rastreamento permite que sejam descobertos requisitos
relacionados. Essa ferramenta também pode auxiliar no armazenamento dos requisitos e
no gerenciamento das mudanças dos mesmos.
Segundo (SOMMERVILLE, 2003):
33
Para sistemas pequenos, pode não ser necessário utilizar ferramentas
especializadas de gerenciamento de requisitos. Esse processo pode ter apoio
utilizando os recursos disponíveis em processadores de texto, planilhas de cálculo
e bancos de dados de PCs. Contudo, para sistemas maiores, o apoio de
ferramentas mais especializadas é necessário. (SOMMERVILLE, 2003, p. 121)
Também para (PRESSMAN, 2006) a gestão formal dos requisitos é indicada
somente para grandes projetos, geralmente com mais de 100 requisitos identificáveis.
Para projetos pequenos, essa função de gerência de requisitos é consideravelmente
menos formal.
Se a rastreabilidade for um fator de qualidade enfatizado desde o início do
projeto, a documentação se tornará mais clara e consistente, será obtido um melhor
entendimento entre o pessoal de projeto, as entradas no projeto serão mais direcionadas
e a manutenção do produto será menos dependente de especialistas individuais
(PFLEEGER 2004 apud LINDVALL e SANDAHL).
A importância de uma ferramenta que auxilie na criação dessa rastreabilidade é
destacada por (PFLEEGER, 2004) que afirma que alguns de seus trabalhos sobre
rastreabilidade exigiram muito esforço, como rastrear itens de dependência sem o apoio
de ferramentas para rastrear links e rastrear modelos que sejam parcialmente
inconsistentes ou pouco documentados.
O capítulo de revisão bibliográfica apresentou os principais itens que serão
abordados durante todo o trabalho. Este capítulo serve como embasamento teórico de
toda a implementação do mesmo, desde a modelagem até a implementação e análise dos
resultados.
Primeiramente foi abordado o MPS.BR, melhoria de processo de software, criado
para ser implementado por pequenas e médias empresas no lugar da certificação CMMI.
Essa certificação foi a escolhida pela Prognus Software Livre para garantir a melhoria nos
seus processo de desenvolvimento.
O item 2.2 apresentou a ferramenta Trac, que é utilizada para auxiliar o
gerenciamento de projetos. O desenvolvimento do plug-in será voltado para esta
ferramenta, por isso a importância de um capítulo explicando seu funcionamento.
Em seguida apresentou-se o Subversion, ferramenta de controle de versão e que
muitas vezes é utilizada junto com o Trac para o gerenciamento de projetos.
O item 2.4 explicou a gerência de requisitos, um dos itens do nível G do MPS.BR,
que abrange também a gerência de projetos.
34
Na gerência de requisitos, foram tratados os principais conceitos relacionados a
requisitos, criando o embasamento teórico necessário para o prosseguimento dos
trabalhos.
Para iniciar o desenvolvimento dos trabalhos, ficou evidente a necessidade de
adoção de uma metodologia de desenvolvimento de software. Devido às características
do trabalho, mostrou-se mais apropriado o estudo das principais metodologias ágeis
disponíveis atualmente para, assim, adotar a mais adequada para o desenvolvimento
deste trabalho.
35
3 METODOLOGIA
Esse capítulo apresenta as principais metodologias de desenvolvimento ágil
disponíveis atualmente. Na sequência, apresentamos a metodologia escolhida para o
desenvolvimento do projeto e suas características, bem como particularidades e
adaptações ao modelo escolhido.
3.1 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO
As metodologias ágeis de desenvolvimento de software foram criadas em
contrapartida das metodologias tradicionais de desenvolvimento, que geralmente eram
muito burocráticas e algumas vezes prejudicavam e atrasavam o desenvolvimento do
software.
Segundo (VIANA E DESCHAMPS, 2007), as metodologias de desenvolvimento
tradicionais foram se tornando obsoletas, pois foram criadas em um contexto muito
diferente do atual.
A prática de projetar o sistema todo para só então iniciar a implementação é
obsoleta para o cenário atual de desenvolvimento. É muito difícil prever com antecedência
todos os detalhes de um sistema, devido às condições mutáveis de mercado e a
frequente evolução das necessidades dos usuários (PRESSMAN, 2006).
Pensando nisso, profissionais de Engenharia de software se reuniram no ano de
2001 e criaram um novo conceito no desenvolvimento de software, denominado
Desenvolvimento Ágil.
Segundo (CASTRO, 2007), o desenvolvimento ágil é uma nova metodologia de
desenvolvimento criada por profissionais renomados, que só conseguiram maximizar os
resultados pensando e trabalhando de forma diferente das descritas normalmente nos
livros.
Ainda de acordo com (CASTRO, 2007), mesmo que cada um dos profissionais
tivesse suas próprias teorias sobre a maneira de desenvolver software, entraram em
acordo e criaram o Manifesto Ágil para o desenvolvimento de software, contendo quatro
princípios:
36
Indivíduos e suas interações acima de procedimentos e ferramentas;
O funcionamento do software acima de documentação abrangente;
A colaboração dos clientes acima da negociação de contratos;
A capacidade de reposta às mudanças acima de um plano pré-estabelecido.
Esse manifesto não descarta as ferramentas e documentação no
desenvolvimento do sistema, somente deixa essas etapas em segundo plano e foca no
que acreditam ser as principais etapas do desenvolvimento de software.
De acordo com (PRESSMAN, 2006) o desenvolvimento ágil de software demanda
a utilização de pequenos e constantes incrementos de software, e para isso, necessita
que o feedback do cliente seja feito o mais rápido possível.
Os itens a seguir apresentarão algumas das principais metodologias ágeis
disponíveis atualmente, seus métodos de trabalho e seus princípios e valores. Analisando
as principais metodologias ágeis é possível escolher a metodologia que se adéqua melhor
ao trabalho desenvolvido.
3.2 EXTREME PROGRAMMING (XP)
O Extreme Programming (XP) é uma metodologia de desenvolvimento ágil, criada
nos Estados Unidos no final dos anos 80. Tem como objetivo auxiliar na criação de
sistemas de melhor qualidade, demandando menos tempo e menos recurso financeiro
que os habituais métodos tradicionais.
(PRESSMAN, 2006) afirma que as ideias e métodos de Extreme Programming
foram abordados pela primeira vez na década de 1980, mas só ganharam notoriedade
quando Kent Beck fez uma publicação sobre a metodologia, em (BECK, 1999).
O XP utiliza uma abordagem orientada a objetos como seu paradigma de
desenvolvimento predileto. Inclui um conjunto de regras e práticas que ocorrem no
contexto de quatro atividades de arcabouço: planejamento, projeto, codificação e teste.
(PRESSMAN, 2006). A figura 8 ilustra o processo do método Extreme Programming e
apresenta algumas das ideias-chave e tarefas que estão associadas.
37
FIGURA 8 – O PROCESSO DE EXTREME PROGRAMMING FONTE: Pressman, 2006, pag. 64
Na atividade de planejamento inicia-se a criação de um conjunto de histórias que
descrevem as características e funcionalidades requeridas para o software que será
desenvolvido. Cada história é escrita pelo cliente e colocada em um cartão de indexação.
Este atribui um valor para essa história com base no valor de negócio global da
característica ou da função. Após isso, os membros da equipe XP avaliam cada história e
atribuem um custo para a mesma, custo esse medido em semanas de desenvolvimento.
Caso essa história necessite de mais de três semanas de desenvolvimento, é solicitado
que o cliente divida-a em partes menores e é realizada a atribuição de valor e custo para
a história novamente. Os clientes e a equipe XP trabalham juntos para decidir como
agrupar histórias na versão seguinte a ser desenvolvida pela equipe (PRESSMAN, 2006).
Uma vez feito o compromisso básico para a versão, ou seja, as histórias que
serão entregues, a equipe XP determina as histórias que serão implementadas em um
dos três modos que seguem: (1)Todas as histórias serão implementadas imediatamente,
ou seja, dentro de poucas semanas; (2) as histórias com valor mais alto serão
antecipadas; (3) as histórias de maior risco serão antecipadas. (PRESSMAN, 2006)
Após a primeira versão do projeto, também chamada de incremento de software,
38
ter sido entregue, a equipe XP calcula a velocidade do projeto, que é a quantidade de
histórias do cliente implementadas na primeira versão da implementação. Essa
velocidade serve tanto para ajudar a estimar as datas de entrega e o cronograma para as
próximas versões quanto para determinar se um comprometimento excessivo foi feito
para todas as histórias ao longo do projeto. Caso ocorra um comprometimento excessivo,
o conteúdo das versões será modificado ou as datas de entrega serão alteradas. Durante
o desenvolvimento o cliente pode também adicionar histórias, mudar o valor de uma
história existente, subdividir histórias e até mesmo eliminá-las. (PRESSMAN, 2006).
De acordo com (PRESSMAN, 2006), a atividade que segue a fase de
planejamento é a atividade de projeto. Nessa fase, o Extreme Programming segue o
princípio KIS (Keep it simple – mantenha simplicidade). É sempre preferível um projeto
simples em relação a uma representação mais complexa. Caso um problema de projeto
difícil seja encontrado como parte de um projeto de uma história, a metodologia
recomenda que seja criado um protótipo operacional daquela parte do projeto, com a
intenção de diminuir o risco quando a implementação verdadeira começa e validar as
estimativas originais correspondentes à história que contém o problema.
Essa etapa de projeto acontece tanto antes quanto depois da fase de codificação
do sistema. De fato, a atividade de codificação vai fornecer diretrizes à equipe XP sobre
como aperfeiçoar o projeto (PRESSMAN, 2006).
Após a etapa de projeto inicia-se a fase de codificação do projeto. A metodologia
recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar do
projeto tenha sido feito, a equipe não avance diretamente para o código, mas sim que crie
testes unitários referentes à cada uma das histórias que devem ser incluídas na versão
atual. Com os testes unitários criados, o desenvolvedor está melhor preparado para
focalizar o que precisa ser implementado para passar nesse teste. Uma vez que esse
código é implementado, o mesmo pode ser submetido para os testes unitários
(PRESSMAN, 2006).
Durante essa etapa de codificação é aplicado um conceito-chave da metodologia:
a programação em pares. O XP recomenda que duas pessoas trabalhem juntas na
mesma estação de trabalho para a implementação de uma história. Isso fornece um
mecanismo de solução de problemas em tempo real, e mantém os desenvolvedores
focados no problema em mãos, além de garantir a qualidade do programa em tempo real.
Na prática, as pessoas envolvidas assumem diferentes papéis, como por exemplo um dos
integrantes poderia pensar em detalhes de código enquanto outro integrante garante que
as normas de codificação estejam sendo seguidas (PRESSMAN, 2006).
39
Por fim, existe uma etapa de testes, onde são feitos os testes de integração e de
validação do sistema, uma vez que os testes unitários são criados na etapa de
codificação. À medida que os testes unitários vão sendo organizados, os testes de
integração e validação podem ocorrer diariamente. Isso fornece à equipe uma indicação
de progresso contínua e pode alertar caso as coisas não estejam correndo como o
esperado (PRESSMAN, 2006).
O Extreme Programming é regido por cinco valores principais, seguidos por
princípios básicos. São eles:
Comunicação;
Simplicidade;
Feedback;
Coragem;
Respeito.
É fato que muitas das ideias que compõe o Extreme Programming fazem parte do
senso comum, com a diferença que a palavra Extreme significa que essas ideias devem
ser levadas realmente ao máximo (PRESSMAN, 2006 apud BECK). Dentre essas ideias
encontra-se:
Revisar o código a todo momento (programação em pares);
Testar o código o tempo todo (testes de unidade), mesmo os requisitos do cliente
(testes funcionais);
Melhorar a modelagem do sistema com refatoração de código;
Simplificar ao máximo a modelagem do sistema;
Definir e melhorar a arquitetura sempre;
Integrar e testar várias vezes por dia;
Iterações com durações curtas, as mais curtas possíveis.
3.3 SCRUM
O Scrum é um modelo ágil de processo, desenvolvido por Jeff Shutterland13 e sua
13
http://jeffsutherland.com/
40
equipe no início da década de 1990. Os princípios utilizados em Scrum são consistentes
com o manifesto ágil, apresentado no item 3.1 (PRESSMAN, 2006).
De acordo com (PRESSMAN, 2006), esses princípios são:
Pequenas equipes de trabalho são organizadas de modo a maximizar a
comunicação, minimizar a supervisão e maximizar o compartilhamento de
conhecimento;
O processo precisa ser adaptável tanto a modificações técnicas quanto de
negócios, para garantir que o melhor produto possível seja produzido;
O processo produz frequentes incrementos de software que podem ser
inspecionados, ajustados, testados, documentados e expandidos;
O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições
claras, com baixo acoplamento, ou em pacotes;
Testes e documentação constantes são realizados à medida que o produto é
construído;
A metodologia Scrum divide os projetos em ciclos menores, chamados de Sprints.
O trabalho conduzido dentro de um Sprint é adaptado ao problema em mãos e é definido
e, frequentemente, modificado em tempo real pela equipe Scrum. A quantidade de Sprints
necessárias para uma atividade varia dependendo da complexidade e do tamanho do
produto (PRESSMAN, 2006).
Os requisitos que serão implementados pela equipe são definidos no Backlog do
produto. Os requisitos do Backlog do Produto são priorizados pela equipe, e são definidos
quais deles entrarão na próxima Sprint do projeto. Os requisitos escolhidos são então
transferidos para o Backlog do Sprint, que nada mais é do que os itens que deverão ser
desenvolvidos nesse ciclo.
Segundo (SCHWABER, 2004), o Scrum é dividido em três papéis principais:
Product Owner (PO), Scrum Master e Time.
O Product Owner define as funcionalidades do produto, as datas de lançamento e
o conteúdo e é responsável pelo controle do retorno de investimento (ROI – Return Of
Investiment). É o Product Owner também quem prioriza funcionalidades de acordo com o
valor do requisito, aceita ou rejeita o resultado dos trabalhos desenvolvidos pelo Time
(SCHWABER, 2004).
O Time é a equipe responsável pelo desenvolvimento das funcionalidades. No
Scrum, os Times são auto-organizados e multifuncionais. Todos os membros são
41
coletivamente responsáveis pelo sucesso de cada Sprint e do projeto como um todo. A
recomendação é que um Time não tenha mais que 9 pessoas (SCHWABER, 2004).
O Scrum Master é responsável pelo processo de desenvolvimento, treinamento
dos envolvidos no projeto e na aplicação dos valores da metodologia Scrum. Ele
representa um gerente de projetos, removendo obstáculos e garantindo a plena
funcionalidade e produtividade da equipe (SCHWABER, 2004).
FIGURA 9 – FLUXO DE PROCESSO SCRUM FONTE: Pressman, 2006, pag. 70
Na figura 9 temos a representação de um esquema básico de funcionamento da
metodologia Scrum. O Backlog do produto contém todos os requisitos do sistema que
deve ser desenvolvido. A equipe define a prioridade dos requisitos, e define quais farão
parte da próxima Sprint. Com isso, os requisitos são transferidos para o Backlog da
Sprint, e são desenvolvidos durante o tempo definido para o ciclo, que é geralmente de 30
dias, mas pode variar de acordo com o projeto e a equipe. Por fim, temos o resultado da
Sprint, que é considerado um incremento do software.
Para o acompanhamento do projeto, a metodologia define uma reunião rápida
diária – a Daily Scrum. Essa reunião é feita preferencialmente de pé – para garantir que
não vai levar muito tempo – e os participantes respondem três questões principais: (1) O
que você fez desde a última reunião de equipe? (2) Que obstáculos você está
42
encontrando? (3) O que você planeja realizar até a próxima reunião de equipe? Isso
garante que a equipe esteja sempre bem informada sobre o que deve ser feito, bem como
o que os outros companheiros estão desenvolvendo e possíveis dificuldades e limitações
que estão enfrentando (PRESSMAN, 2006).
Ao fim de cada Sprint, a metodologia define uma reunião de retrospectiva, onde
cada membro da equipe reflete e discute sobre a Sprint passada, as possíveis
dificuldades e acertos da equipe e as lições que podem ser usadas para
desenvolvimentos futuros.
3.5 CRYSTAL
O Método Crystal é uma família de metodologias, com diversos modelos de
processo que se adapta a diversos tipos de equipes de desenvolvimento e às
particularidades encontradas em cada projeto único. Foi criada por Alistair Cockburn,
contratado pela IBM14 na década de 1990 somente para escrever sobre metodologias de
desenvolvimento de software. Este usa uma abordagem diferente da maioria dos
estudiosos da área. Ele parte do princípio que pessoas não consideram fácil seguir
metodologias disciplinadas e rígidas. Com isso, a ideia é de ter um método menos rígido,
onde as pessoas possam se sentir mais a vontade e mesmo assim ao final ser bem
sucedido, é adotada na metodologia. O foco principal é o talento e habilidades pessoais,
moldando o processo de acordo com as características da equipe e seus membros.
Fazendo uma comparação com o método ágil XP (Extreme Programming),
podemos considerar o método Crystal menos produtivo, porém por ser menos rígido e
disciplinado, mais desenvolvedores estarão aptos a seguí-lo. Uma das características
mais importantes no método Crystal são as revisões no final de cada uma das iterações,
fazendo com que na maioria das vezes o processo seja melhorado, dando ênfase no
monitoramento e no ajuste do processo à medida que o mesmo vai sendo desenvolvido.
Cockburn acredita que o desenvolvimento iterativo existe para que problemas possam ser
detectados o quanto antes, habilitando as pessoas a corrigí-los (FOWLER, 2003).
Na família de métodos Crystal, pela sua versatilidade, podemos ter equipes de
desenvolvimento pequenas (de até 6 desenvolvedores) até equipes maiores e mais
complexas (até 100 desenvolvedores). Dependendo do número de participantes na
14
http://www.ibm.com
43
equipe, é atribuída uma cor a ela. Além disso, o membro da família Crystal recebe uma
letra que significa o risco do projeto (o que será perdido caso ocorra falhas no sistema
que está sendo desenvolvido). Na tabela 9 mostramos as letras e os significados de cada
uma, e na tabela 10 apresentamos o tempo máximo de duração do projeto relacionado
com cada cor atribuída às equipes (FOWLER, 2003).
C (confort) Perda de dinheiro não substancial, com recuperação confortável
D (discret) Perda discreta (sutil) de dinheiro. E (essential) Perda essencial (substancial) de dinheiro. L (life) Possível perda de vidas.
TABELA 9 – LETRAS E SEUS SIGNIFICADOS NA METODOLOGIA CRYSTAL FONTE: Fowler, 2003.
Clear 4 meses
Yellow Não definido Orange 2 anos Red Não definido
TABELA 10 – TEMPO DE DURAÇÃO DOS PROJETOS EM FUNÇÃO DO NÚMERO DE PESSOAS FONTE: Fowler, 2003.
Como apresentado na tabela 9 e na tabela 10, cada equipe recebe uma cor e
uma letra, dependendo do tamanho e da criticalidade do projeto respectivamente. Então,
pensando nisso, podemos ter uma combinação de possíveis projetos, com tamanhos e
complexidades diferentes. Quanto maior o tamanho da equipe, mais complexo e
burocrático fica o gerenciamento da mesma, e quanto mais crítico o projeto maior é a
necessidade de coordenação e metodologias mais pesadas para o desenvolvimento.
Podemos visualizar melhor essas possibilidades na figura 10 que ilustra os possíveis tipos
de projeto e suas complexidades, fazendo uma relação entre o tamanho da equipe e a
criticalidade.
44
FIGURA 10 – ESQUEMA RELACIONANDO A COMPLEXIDADE DO PROJETO COM O TAMANHO DA EQUIPE E A CRITICALIDADE DO SISTEMA
FONTE: Pedrosa, 2006.
A metodologia Crystal segue um ciclo de vida, baseado em algumas práticas, que são (PEDROSA, 2006):
Staging: Planejamento do próximo incremento do sistema. A equipe seleciona os
requisitos que serão implementados nessa iteração e também define os prazos
para a entrega desses requisitos;
Edição e revisão: Construção, demonstração e revisão dos objetivos do
incremento atual do sistema;
Monitoramento: O processo é monitorado com relação ao progresso e
estabilidade da equipe de desenvolvimento.
Paralelismo e fluxo: Em Crystal Orange as diferentes equipes podem operar com
o máximo paralelismo. Isto é possível através do monitoramento da estabilidade e
da sincronização entre as equipes distintas do projeto;
Inspeções de usuários: Sugeridas duas ou três inspeções feitas por usuários a
cada incremento do sistema;
Workshops refletivos: Reuniões que ocorrem antes e depois de cada iteração com
objetivo de analisar o progresso do projeto;
Produtos de Trabalho: Sequência de lançamento, modelos de objetos comuns,
manual do usuário, casos de teste e migração de código;
45
Padrões: Padrões de notação, convenções de produto, formatação e qualidade
usadas durante o projeto que está sendo desenvolvido;
Tools: Ferramentas mínimas utilizadas para o desenvolvimento dos projetos,
como ferramentas de controle de versão, teste, comunicação, entre outras.
FIGURA 11 – CICLO DE VIDA DA FAMÍLIA CRYSTAL FONTE: Pedrosa, 2006.
A figura 11 ilustra o ciclo de vida da família de metodologia Crystal e as relações
entre as práticas da metodologia.
3.6 ESCOLHA E UTILIZAÇÃO DA METODOLOGIA SCRUM NO PROJETO
Para este projeto, a metodologia ágil escolhida foi a metodologia Scrum, pois
após a análise das principais metodologias ágeis disponíveis no mercado percebeu-se
que era a metodologia que mais se adequava a este trabalho. Os principais itens que
valeram para a escolha do Scrum foram os conceitos de Times auto-organizados e
46
multifuncionais, onde todos os membros são coletivamente responsáveis pelo sucesso de
cada Sprint e do projeto como um todo. O próprio conceito de Sprint, a divisão do trabalho
em diversas etapas com entregas regulares, a facilidade de adaptação às reuniões
frequentes e às alterações do processo e de acompanhamento, que faz com que o Time
esteja sempre atualizado sobre o andamento do projeto como um todo. Essas
informações são explicadas mais detalhadamente no item 3.3 deste documento.
Um dos itens previstos na metodologia Scrum é a existência de um líder na
equipe, uma espécie de gerente de projetos, conhecido como Scrum Master. Neste
trabalho, devido a homogeneidade da equipe e devido a maioria das atividades serem
realizadas sem a equipe reunida no mesmo local, não foi definido nenhum papel de
liderança entre os integrantes, ou seja, não escolhemos um integrante para o papel de
Scrum Master, portanto a aplicação dos valores da metodologia Scrum, a remoção de
obstáculos e a garantia de funcionalidade e produtividade da equipe, papel do Scrum
Master, era feita por todos os integrantes.
Primeiramente, foi definido o Backlog do projeto, com os requisitos que deveriam
ser implementados para a construção da ferramenta.
Devido a impossibilidade de realizar de maneira efetiva a Daily Scrum – reunião
diária proposta pela metodologia Scrum - as reuniões presenciais foram definidas com
periodicidade semanal, toda sexta-feira, nas dependências da Faculdade Anglo
Americano. Nessas reuniões eram respondidas as três questões principais definidas pela
metodologia para as Daily Scrum: (1) O que você fez desde a última reunião de equipe?
(2) Que obstáculos você está encontrando? (3) O que você planeja realizar até a próxima
reunião de equipe? Também nessa reunião eram tratadas as dúvidas e as adequações de
escopo e prazo para o desenvolvimento do sistema.
Reuniões de acompanhamento também foram definidas, e eram realizadas a
cada dois dias através de sistema de comunicação instantânea online, utilizando a
ferramenta de comunicação gtalk, do Google. Essas reuniões aconteciam no início do dia,
onde todos os membros da equipe realizavam o alinhamento das atividades, também
seguindo as três questões principais, citado anteriormente.
Para o primeiro Sprint do projeto, foram escolhidos para o Sprint Backlog os
requisitos relacionados ao estudo da gerência de requisitos, para que a equipe pudesse
ter o embasamento teórico necessário para o início dos trabalhos e, consequentemente,
facilitar o trabalho de desenvolvimento do plug-in. Para essa Sprint, foi definido um prazo
de 15 dias.
Desse primeiro ciclo de trabalho, foram obtidos documentos produzidos pela
47
equipe que tratavam da gerência de requisitos. Esses documentos e anotações foram
utilizados em todo o projeto, principalmente no item de revisão bibliográfica.
Para a segunda Sprint, os requisitos escolhidos para o Backlog do ciclo também
eram de pesquisa. O resultado esperado dessa Sprint era a geração do documento
teórico sobre o MPS.BR. Para que o tempo de cada Sprint fosse padronizado foi definido
15 dias para a entrega dos resultados das atividades.
Dessa segunda Sprint, resultou a documentação que foi utilizada para a criação
do item sobre MPS.BR na revisão bibliográfica do documento.
O acompanhamento dos requisitos do sistema, o Backlog do produto, era feito em
uma página Web compartilhada, onde todos os integrantes tinham acesso. Nesse
documento era realizado o controle dos requisitos que já haviam sido implementados,
bem como dos itens que estavam sendo implementados na Sprint em andamento.
No item 3.7 são apresentados os requisitos do trabalho, bem como suas
respectivas Sprints.
3.7 BACKLOG DO PROJETO E DEFINIÇÃO DAS SPRINTS
Como apresentado no item 3.3, o Backlog do projeto contém os requisitos que
devem ser implementados para a finalização do projeto e o Backlog da Sprint nada mais é
do que os itens que deverão ser desenvolvidos em cada ciclo, ou Sprint.
Segundo apresentado no item 2.3 que tratava de gerenciamento de requisitos, os
requisitos são primeiramente identificados de modo único – neste caso, por um ID do
requisito – para que possa facilitar a utilização desse requisito em tabelas de
rastreamento posteriormente no projeto. Note que como se trata de um projeto com
poucos requisitos, não foi necessária a aplicação de uma rastreabilidade nesses
requisitos. Como citado no item 2.4, para projetos com menos de cem requisitos não é
indicado uma gestão formal dos mesmos, uma vez que há poucos ganhos nessa gestão
formalizada nesse tipo de projeto (PRESSMAN, 2006).
Sprint Backlog - Documento de gerência de requisitos
ID requisito Requisito Tempo R1 Levantar literatura sobre o assunto 3 dias R2 Estudar os documentos levantados 6 dias R3 Gerar documento de gerência de requisitos 6 dias
48
Sprint Backlog - Documento MPS.BR
ID requisito Requisito Tempo R4 Levantar literatura sobre o assunto 3 dias R5 Estudar os documentos levantados 6 dias R6 Gerar documento sobre MPS.BR 6 dias
Sprint Backlog - Documento Trac e Subversion
ID requisito Requisito Tempo R7 Levantar literatura sobre o assunto 3 dias R8 Estudar os documentos levantados 6 dias R9 Gerar documento sobre Trac e Subversion 6 dias
Sprint Backlog – Modelagem do plug-in
ID requisito Requisito Tempo R10 Levantar materiais modelagem UML 2 dias R11 Estudo principais diagramas UML 6 dias R12 Criar principais diagramas do plug-in 7 dias
Sprint Backlog – Ambiente de teste e desenvolvimento
ID requisito Requisito Tempo R13 Pesquisar requisitos e dependências 3 dias R14 Instalação do Sistema operacional e programas 6 dias R15 Teste do ambiente de desenvolvimento 6 dias
Sprint Backlog – Implementação plug-in
ID requisito Requisito Tempo R16 Materiais linguagem python e plug-ins Trac 2 dias R17 Estudo da linguagem python 4 dias R18 Estudo API plug-ins Trac 6 dias R19 Implementação plug-in 4 dias R20 Teste e correções do plug-in 4 dias
Sprint Backlog – Aplicação e análise do plug-in
ID requisito Requisito Tempo R21 Instalação plug-in Prognus 2 dias R22 Aplicação em projetos reais 10 dias R23 Documento de análise dos resultados 3 dias
Sprint Backlog – Conclusões do trabalho
ID requisito Requisito Tempo R24 Gerar documento de conclusões 10 dias R25 Trabalhos futuros 5 dias
Buscando padronizar o tempo de cada Sprint, foi levado em consideração uma
média de 15 dias para cada ciclo. Alguns ciclos demandaram mais tempo, devido a
complexidade dos requisitos contidos no Backlog da Sprint. Por decisão de projeto, cada
requisito era desenvolvido por todos os integrantes do grupo, e não havia separação das
atividades para cada membro. Os resultados dos trabalhos em cada requisito eram
compartilhados e com isso era gerado o artefato referente ao requisito executado.
49
A estimativa de prazo de execução de cada requisito era feita na reunião de início
de cada Sprint. Cada um dos integrantes da equipe apresentava a quantidade de dias que
imaginava ser necessário para concluir a atividade e com isso era feita uma média das
estimativas dadas pelos membros. Quando havia uma diferença muito grande entre as
estimativas, o requisito era analisado para tentar identificar o motivo da diferença entre os
entendimentos e a previsão de término da tarefa.
50
4 MODELAGEM
Esse capítulo explica a modelagem do plug-in que será implementado, bem como
a arquitetura do sistema Trac, ao qual o plug-in será incorporado, e os componentes
necessários para que a ferramenta funcione a contento.
Uma das principais Sprints do projeto tinha como Backlog da Sprint requisitos que
tratavam da modelagem do sistema a ser implementado. A partir dos requisitos do
sistema, utilizamos os diagramas da UML15 para representar as funcionalidades que
deveríamos desenvolver, e que serviriam de auxílio e base para a tarefa de
implementação. Os diagramas foram criados utilizando o software Astah Community,
disponível para download gratuitamente no site da ferramenta16.
4.1 ARQUITETURA Trac
A partir da versão 0.9, o Trac permite que sejam desenvolvidos plug-ins para
estender algumas outras funcionalidades, a fim de tornar o sistema mais flexível
permitindo a customização de tarefas.
Para isso, a ferramenta disponibiliza uma API para as extensões sejam
desenvolvidas. Esses plug-ins devem ser implementados em forma de componentes, que
são objetos que provêm algum tipo de serviço no contexto da aplicação. Em momento
algum existirá mais que uma instância de cada componente, pois seguem o padrão de
projeto Singleton (EDGEWALL, 2011).
Os componentes na verdade representam subsistemas funcionais, e podem
implementar pontos de extensão para que sirvam de interface para outros plug-ins. Um
mesmo componente pode estender vários outros componentes e ainda assim oferecer
seus próprios pontos de extensão.
As funcionalidades do Trac são definidas pelos componentes individuais, e o
kernel do componente é responsável em ligar os diferentes subsistemas, sem
necessariamente conhecerem uns aos outros, funcionalidade conhecida como Magic
Glue. A figura 12 ilustra a representação da arquitetura de componentes do Trac.
15
Unified Modeling Language (Linguagem de modelagem unificada). Documentação disponível em http://www.uml.org/ 16
http://astah.net/.
51
FIGURA 12 – REPRESENTAÇÃO DA ARQUITETURA DE COMPONENTES DO TRAC FONTE: http://trac.edgewall.org
Para que seja criado um componente da arquitetura do Trac, devem ser usadas
algumas classes que representem os componentes do sistema, como os tickets e as
páginas Wiki.
Para a manipulação desses componentes, o Trac disponibiliza algumas classes
interfaces que devem ser implementadas pelos plug-ins. Neste trabalho, devido à
necessidade de manipulação das páginas wiki do Trac, as interfaces utilizadas foram a
IWikiChangeListener, servindo como uma interface de ponto de extensão para os
componentes que seriam processados durante a criação, edição ou deleção de uma
página wiki e a IWikiPageManipulator que é usada nos pós-processamento e pré-
processamento das páginas wiki. A representação da implementação dessas interfaces é
detalhada no próximo item que trata da modelagem do plug-in.
4.2 MODELAGEM DO PLUG-IN
Para obter uma visão macro do sistema, o primeiro diagrama que foi desenvolvido
foi o Diagrama de Caso de Uso. Nesse Diagrama, são apresentadas as funcionalidades
do sistema do ponto de vista do usuário, e sua interação com outras entidades, chamadas
de atores. Esse diagrama é apresentado na figura 13, e tem como atores do sistema o
analista de sistemas e o plug-in em si.
52
FIGURA 13 – DIAGRAMA DE CASO DE USO DO PLUG-IN
Como podemos visualizar no diagrama de casos de uso representado na figura
13, o analista de sistemas pode somente gerar e editar a matriz de rastreabilidade dos
requisitos. Já o plug-in é responsável pela análise e parsing da página de declaração
formal de demanda (DFD), bem como do gerenciamento dos avisos de dependência de
requisitos.
Sempre que o caso de uso “Gerar matriz” for acionado pelo analista de sistemas,
será executado o caso de uso “Analisar Página de declaração formal de demanda”. Essa
representação é vista na figura 6 através do estereótipo include que liga os dois casos de
uso.
O plug-in também é responsável pela execução do caso de uso “Gerenciar avisos
de dependência”, gerenciando as dependências de requisitos e os avisos quando houver
mudanças nos mesmos, como edição ou exclusão. Esses avisos serão destinados ao
analista de sistemas para que o mesmo tenha conhecimento de que os requisitos que
está modificando apresentam alguma dependência. No caso de edição de requisitos na
página de declaração formal de demanda, a matriz de rastreabilidade é criada novamente,
levando em consideração a nova listagem de requisitos.
Em seguida, o foco da análise e modelagem se deu na implementação da
53
funcionalidade de parser, parte principal da nossa ferramenta. Para representar o fluxo da
solução da implementação, utilizou-se o diagrama de atividade da UML.
FIGURA 14 – DIAGRAMA DE ATIVIDADES DO PLUG-IN
O diagrama de atividades apresentado na figura 14 possibilita a visualização e
entendimento dos fluxos principais do sistema, auxiliando na implementação dos
mesmos.
Algumas das funcionalidades do sistema, como a criação e configuração da
matriz de rastreabilidade, eram complexas, por isso mostrou-se necessário a criação de
diagramas que representassem o fluxo de processamento dessas partes em específico.
54
Novamente, o diagrama escolhido para iniciar a representação dessas funcionalidades foi
o diagrama de atividades, pois consegue representar com clareza os passos que devem
ser realizados para que o problema seja resolvido.
Na figura 15, é apresentado um pseudocódigo referente à criação e configuração
da matriz de rastreabilidade vertical dos requisitos. O código demonstra as repetições e
as verificações necessárias para a criação da matriz de rastreabilidade vertical. Detalhes
do desenvolvimento dessas funcionalidades são demonstradas no capítulo 5.3 que trata
da implementação do parser.
FIGURA 15 – PSEUDOCÓDIGO DA CRIAÇÃO DA MATRIZ DE RASTREABILIDA-DE VERTICAL
Esse procedimento de criação da matriz de rastreabilidade é disparado também
no momento em que uma página de declaração formal de demanda é atualizada. Ou seja,
no momento da atualização das informações de uma DFD, a matriz de rastreabilidade é
recriada. Quando o usuário entre em modo de edição no Trac mas não efetua nenhuma
mudança, a própria ferramenta identifica esse comportamento e não faz uma requisição
para salvar a página novamente.
55
Um dos requisitos do plug-in define que a ferramenta deve avisar para o analista
de sistemas quando um requisito que está sendo editado tiver alguma dependência. Para
que o fluxo da solução pudesse ser melhor visualizado e para facilitar a posterior
implementação, foi criado um diagrama de atividades desse processamento. Esse
diagrama está representado pela figura 16, que demonstra as atividades necessárias para
o desenvolvimento dessa funcionalidade.
Dando sequência às atividades de modelagem do plug-in, percebeu-se a
necessidade da criação das classes que são necessárias para o funcionamento da
ferramenta.
Para manipular e identificar alterações nos componentes do Trac, a ferramenta
disponibiliza algumas interfaces que devem ser implementadas pelos plug-ins. Neste
trabalho, tornou-se necessário a manipulação das páginas Wiki do Trac. Por isso, as
interfaces utilizadas foram a IWikiChangeListener, servindo como uma interface de ponto
de extensão para os componentes que seriam processados durante a criação, edição ou
deleção de uma página Wiki e a IWikiPageManipulator que é usada nos pós-
processamento e pré-processamento das páginas wiki.
Para utilizar essas interfaces, basta que a classe da ferramenta que fará uso das
mesmas implementem os métodos existentes. Na figura 17 é possível perceber as duas
interfaces implementadas pelo plug-in e seus métodos. Neste trabalho, não foi necessário
utilizar todos os métodos das interfaces implementadas, portanto os métodos que não
seriam utilizados tinham no corpo apenas a palavra-chave pass.
A classe principal ParseWiki implementa as duas interfaces disponibilizadas pelo
Trac para a manipulação de páginas Wiki. Essa classe realiza toda a verificação por
padrões na página de declaração formal de demanda, cria a matriz e gerencia os avisos
de alteração nos requisitos com dependência.
Para seguir com a modelagem e mapear a sequência das operações do sistema,
foi criado o diagrama de sequência da atividade de criação da matriz de rastreabilidade. É
possível observar que o analista de sistemas interage com a interface de criação da
matriz, que no caso desse trabalho é representado por um botão no final da página de
declaração formal de demanda (DFD). O processamento segue por sua vez passando
pela biblioteca BeautifulSoup, que faz a normalização da página, e logo em seguida volta
para o plug-in, que a análise da página de DFD e a criação da matriz de rastreabilidade
na página. Esse diagrama é apresentado na figura 19.
56
FIGURA 16 – DIAGRAMA DE ATIVIDADES DA EDIÇÃO DA LISTA DE REQUISI-TOS
57
FIGURA 17 – DIAGRAMA DE CLASSES DO PLUG-IN
FIGURA 18 – DIAGRAMA DE CLASSES REPRESENTANDO A RELAÇÃO ENTRE OS PACOTES
Para o funcionamento do plug-in foi necessário a utilização de uma biblioteca
externa, a BeautifulSoup. Essa biblioteca funciona como um normalizador do conteúdo
HTML de uma página, transformando-a em uma árvore para que seja possível manipular
a página através de objetos DOM (Documment object model). Essa dependência é
apresentada na figura 18, onde existe a relação entre o pacote principal da
58
implementação e a biblioteca externa BeautifulSoup.
FIGURA 19 – DIAGRAMA DE SEQUÊNCIA DA CRIAÇÃO DA MATRIZ DE RAS-TREABILIDADE VERTICAL
A biblioteca BeautifulSoup funciona como um parser de HTML/XML para Python
que pode transformar até mesmo marcação inválida em uma árvore analítica. Ela provê
um modo idiomático de navegar, procurar e modificar a árvore de elemento, facilitando o
processo de manipulação das páginas Web como objetos DOM, que fornece uma
maneira padronizada de acesso aos elementos da página, permitindo trabalhar com cada
um desses elementos separadamente.
O plug-in também deve gerenciar as alterações nos requisitos com
interdependências. A figura 20 ilustra o diagrama de sequência que representa a análise
da página de DFD, em busca dos requisitos alterados. O sistema verifica se nas
alterações existem itens com dependências e caso essas dependências sejam
encontradas é enviado um alerta para a tela, informando o usuário.
A análise da página de declaração formal de demanda é feita através do método
ParseWiki. Esse método recebe como entrada uma página normalizada, e realiza a
59
análise conforme mostra a figura 14. Um diagrama de sequência foi criado para
representar as operações que serão realizadas para a implementação dessa
funcionalidade. Esse diagrama pode ser visualizado na figura 21.
FIGURA 20 – DIAGRAMA DE SEQUÊNCIA DA FUNCIONALIDADE DE ALERTA PARA ALTERAÇÃO DE REQUISITOS COM DEPENDÊNCIA
Neste capítulo, as modelagens de sistema necessárias para a implementação do
plug-in foram apresentadas. Esses diagramas servem como base para a fase de
implementação, que será detalhada no próximo capítulo, facilitando a visualização da
solução que deve ser implementada.
60
FIGURA 21 – DIAGRAMA DE SEQUÊNCIA DA FUNCIONALIDADE DE ANÁLISE DA PÁGINA DE DFD
61
5 IMPLEMENTAÇÃO
Nesse capítulo apresentaremos a implementação do plug-in e suas
funcionalidades, bem como as ferramentas utilizadas e detalhes de algoritmos e
estruturas de dados usados na sua implementação.
5.1 INSTALAÇÃO E CONFIGURAÇÃO DO AMBIENTE
Para o desenvolvimento do plug-in, foi necessário a instalação e configuração de
um ambiente, com as ferramentas que seriam usadas no trabalho. O sistema operacional
escolhido foi a distribuição GNU/Linux Ubuntu17, versão 11.04, instalado em uma máquina
virtual com 1GB de memória RAM e 10GB de HD. A escolha desta distribuição deu-se
devido à sua estabilidade e por disponibilizar diversas bibliotecas e softwares utilitários
por padrão em sua instalação.
Após a instalação do sistema operacional, foi feito o download do Trac e do
servidor Web Apache que seria usado para o gerenciamento do acesso as páginas do
sistema. Essa instalação foi feita utilizando a ferramenta apt-get18, disponibilizada pela
distribuição Ubuntu e por todas as distribuições baseadas em Debian.
5.2 PADRÕES DE CONTEÚDO DA PÁGINA DE DECLARAÇÃO FORMAL DE DEMANDA
Como descrito no capítulo 2.2, página 18, para cada projeto é criado uma página
de declaração formal de demanda (DFD). O preenchimento dessa página segue alguns
padrões, que são essenciais para o funcionamento correto do plug-in.
Uma maneira de identificar uma página de declaração formal de demanda é
através do seu título. O padrão determina que todas as páginas de DFD tenham como
primeira frase a palavra “Declaração Formal de Demanda”. Essa padronização é
importante para diferenciar a página de DFD de outras páginas Wiki genéricas, uma vez
que para o Trac não há distinção entre as páginas.
17
Disponível para download em http://www.ubuntu.com 18
Documentação disponível em http://www.apt-get.org/
62
Na página de DFD são listados os requisitos de um projeto e suas
interdependências. Essa listagem também é padronizada. Os requisitos são
representados em uma lista, sempre iniciando pela letra “R”. As dependências são
representadas pelo identificador do requisito dependente entre colchetes. A figura 22
ilustra essas padronizações.
FIGURA 22 – PADRÕES DE REPRESENTAÇÃO DE CONTEÚDO DA PÁGINA DE DECLARAÇÃO FORMAL DE DEMANDA
No exemplo da figura 22, o requisito 1 (R01) tem dependência com o requisito 2
(R02), e por isso deve ser criada uma relação de dependência entre eles. Este padrão foi
definido de acordo com uma sugestão da equipe de avaliação do MPS.BR, para facilitar a
visualização e organização dos requisitos e as dependências entre eles.
63
5.3 IMPLEMENTAÇÃO DA ANÁLISE DA PÁGINA DE DECLARAÇÃO FORMAL DE DEMANDA
A maneira como é feita a criação da matriz de rastreabilidade vertical dos
requisitos atualmente torna o trabalho do analista de sistemas muito penoso, pois a
mesma é construída manualmente, utilizando os recursos Wiki do Trac. Isso aumenta a
possibilidade de falhas durante a criação e manutenção da matriz, principalmente em
projetos com muitos requisitos.
Uma das funcionalidades do plug-in é a análise da página de DFD buscando por
padrões de definições de requisitos e possíveis dependências. Essa análise deve
identificar a página de declaração formal de demanda, que contém as definições dos
requisitos e suas dependências. Após analisar a página e identificar os requisitos, a
ferramenta cria uma área no final página, onde será construída a matriz de rastreabilidade
vertical dos requisitos. Para a representação visual dessa matriz de rastreabilidade
vertical utiliza-se a linguagem Wiki do Trac. Essas atividades de análise da página de
DFD e da criação da matriz podem ser visualizadas na figura 14 do item 4.2, que trata da
modelagem do plug-in e representa o fluxo de ações que será realizado pela ferramenta.
No momento de criação de uma página Wiki, o plug-in é disparado e verifica se a
página se trata de uma DFD. Isso acontece pois a extensão implementa o método
wiki_page_added da interface IWikiChangeListener, que é chamado sempre que uma
página Wiki é criada. Por isso o processamento de análise e criação da matriz é
centralizado nesse método.
Ao ser disparado, o plug-in requisita a página de declaração formal de demanda
para o servidor Web através de sua URL. Após requisitar a página, o sistema obtém o
conteúdo da página solicitada, formatada na linguagem HTML.
Para facilitar a manipulação das páginas, é feita a normalização das mesmas para
que sejam manipuladas via DOM (Document Object Model – Modelo de documento de
objeto em português).
Para fazer a normalização, foi utilizada a biblioteca BeautifulSoup19. Essa
biblioteca funciona como um parser de HTML/XML para Python que pode transformar até
mesmo marcação inválida em uma árvore analítica. Ela provê um modo idiomático de
navegar, procurar e modificar a árvore de elemento, facilitando o processo de
manipulação das páginas Web como objetos DOM, que fornece uma maneira
19
Disponível para download em http://www.crummy.com/software/BeautifulSoup/download
64
padronizada de acesso aos elementos da página, permitindo trabalhar com cada um
desses elementos separadamente.
Após a normalização da página, é feita a busca pelos requisitos no conteúdo da
mesma. Os requisitos são descritos sempre em lista, representado pela tag HTML <li>,
por isso basta utilizar o método findAll da biblioteca BeautifulSoup, passando como
parâmetro o elemento que deseja buscar – no nosso caso <li> - e então é retornado uma
estrutura de Array com os elementos encontrados na página. Note que em alguns casos,
podem existir trechos representados com a tag <li> e que não representam uma descrição
de um requisito. Para que sejam retornados somente os elementos que representam
requisitos do sistema, é realizada uma verificação extra, através de uma expressão
regular que identifica se o elemento inicia com a letra R, seguida de uma segunda letra e
um número. Esse padrão é utilizado para representar um requisito do sistema, como
apresentado no item 5.2 deste documento.
Com o Array com os elementos da página que representam os requisitos, inicia-
se um laço que itera sobre esses elementos. Nessa repetição, é feita a análise dos
requisitos e suas respectivas dependências, representadas pelo identificador do requisito
dependente entre colchetes. Essas dependências são armazenadas em uma estrutura
auxiliar, que será utilizada para a criação e preenchimento da matriz de rastreabilidade
vertical dos requisitos.
Como apresentado na tabela 8, uma matriz de rastreabilidade vertical é uma
matriz quadrada, de NxN, onde N é o número de requisitos do sistema. Sabendo disso,
para criar a matriz, é realizado um outro laço que fará a iteração para a montagem da
matriz. Nessa repetição é feita uma verificação na estrutura auxiliar que armazena as
dependências entre os requisitos, para que seja preenchida a coluna que representa a
relação entre os mesmos. A matriz de rastreabilidade vertical de requisitos é simétrica, ou
seja, toda vez que uma coluna i,j for marcada a célula j,i também deverá ser marcada.
Para incorporar a matriz de rastreabilidade vertical dos requisitos em uma página
do Trac, nesse caso em uma página de declaração formal de demanda, essa matriz deve
estar representada na linguagem Wiki da ferramenta. Devido a isso, o plug-in gera o
código referente à matriz na notação Wiki, e incorpora este artefato no final página de
declaração formal de demanda.
É criada também uma matriz auxiliar para visualização utilizando marcação
HTML, lançando mão das tags <tr> e <td> que representam, respectivamente, linhas e
colunas de uma matriz.
Portanto, na prática são geradas duas matrizes de rastreabilidade vertical dos
65
requisitos: uma em notação HTML, em uma página distinta da DFD e uma em notação
Wiki, incorporada na página de DFD.
5.4 GERENCIAMENTO DE AVISOS DE ALTERAÇÕES EM REQUISITOS
Uma das funcionalidades do plug-in é o de gerenciamento as alterações nos
requisitos do projeto, com a criação de um mecanismo para informar sobre uma alteração
que pode causar impacto no projeto. Para isso, utilizou-se a funcionalidade de warning
disponibilizada pela ferramenta Trac. Essa funcionalidade permite que seja apresentada
uma mensagem de alerta para o usuário do Trac, para informar algo importante. Essa
mensagem desaparece logo que a página é recarregada.
Para verificar se algum requisito com dependência foi alterado, é necessário
comparar as duas versões do documento: (1) a versão modificada e (2) a versão original.
Com as duas versões do documento, é realizada uma verificação das diferenças
entre elas, e o resultado dessa diferença é analisado, buscando pelo padrão que
corresponde a uma dependência entre requisitos (identificador de um requisito entre
colchetes). Caso esse padrão seja encontrado, a mensagem é apresentada para o
analista de sistemas, para que este possa tomar as providências necessárias.
Um exemplo da mensagem de alteração de requisitos é ilustrada na figura 23. A
mensagem de aviso é mostrada no topo da tela de declaração formal de demanda, com
fundo amarelo e com a palavra “Warning” em negrito.
Caso somente requisitos sem dependência sejam alterados, essa mensagem não
é apresentada, e o salvamento da página de declaração formal de demanda é realizado
da forma padrão.
A mensagem apresentada não contém caracteres acentuados devido a um
problema da ferramenta Trac no momento de compilação do template com a mensagem
de warning.
5.5 INSTALAÇÃO DO PLUG-IN NO TRAC
Para que o plug-in seja efetivamente integrado ao Trac, ele deve ser instalado na
66
ferramenta. Para isso, pode ser utilizada a página de administração do Trac, que provê
uma interface de instalação e integração de plug-ins. Para instalar uma extensão, deve
ser carregado o arquivo de código-fonte do plug-in, escrito em Python (com extensão .py),
e o Trac faz o carregamento do arquivo na pasta de plug-ins do sistema. Após o
carregamento da extensão a página de administração de plug-ins é recarregada e na
listagem já consta a nova funcionalidade incorporada ao Trac. Ainda nessa interface, é
possível habilitar e desabilitar as extensões instaladas no sistema.
FIGURA 23 – AVISO DE ALTERAÇÃO DE REQUISITO COM DEPENDÊNCIA
A figura 24 ilustra a tela de administração da ferramenta Trac. Nessa tela, é
possível administrar as principais funcionalidades do sistema, entre elas é a instalação e o
gerenciamento de plug-ins. Na tela, os plug-ins instalados são listados, e existe a
possibilidade de instalar mais extensões. Para isso, basta fazer o upload do arquivo fonte
do plug-in e acionar o botão instalar.
Na instalação do plug-in há uma verificação em relação à sintaxe do código que
está sendo enviado. Caso existam erros, o mesmo não é adicionado à lista de plug-ins na
tela de administração. Para obter detalhes do erro, o usuário pode verificar o arquivo de
log do sistema, que por padrão é localizado em /tmp/trac.log.
67
Caso ocorram erros em tempo de execução, é apresentado uma mensagem
informando
sobre o mesmo.
FIGURA 24 – TELA DE ADMINISTRAÇÃO DE PLUG-INS DO Trac
5.6 TESTE DO PLUG-IN
Após realizar a instalação do plug-in no Trac do ambiente de desenvolvimento
deste trabalho, testes foram realizados para verificar se os requisitos do trabalho haviam
sido atendidos.
Para realizar os testes foram criadas duas páginas de Declaração Formal de
Demanda, semelhantes às utilizadas na Prognus. As duas páginas foram sendo editadas
ao decorrer dos testes, com requisitos sendo adicionados, editados e excluídos.
A figura 25 ilustra a interface de utilização do plug-in pelo analista de sistemas. No
final da listagem de requisitos na página de Declaração formal de demanda, é possível
acionar o botão Criar matriz de rastreabilidade. Esse botão é quem vai disparar o evento
para que o plug-in faça a análise dos requisitos da página e crie a matriz.
68
FIGURA 25 – BOTÃO DE CRIAÇÃO DA MATRIZ DE RASTREABILIDADE VERTI-CAL NA PÁGINA DE DECLARAÇÃO FORMAL DE DEMANDA
FIGURA 26 – MATRIZ DE RASTREABILIDADE VERTICAL GERADA PELO PLUG-IN
Após a criação da página de Declaração Formal de Demanda para os testes,
foram adicionados alguns requisitos e gerado a matriz de rastreabilidade vertical dos
requisitos. A figura 26 apresenta uma matriz de rastreabilidade gerada em linguagem
HTML a partir de uma demanda. As dependências representadas na diagonal principal da
matriz de rastreabilidade representam a dependência do requisito com ele mesmo, por
isso ela não é considerada em nossa contagem.
Como apresentado no item 5.3, o plug-in também gera a notação Wiki da matriz
69
de rastreabilidade vertical dos requisitos. Esse código pode ser incorporado na página da
demanda (DFD) pelo analista de sistemas, bastando incorporar o código gerado à página
de DFD.
FIGURA 27 – NOTAÇÃO WIKI REPRESENTANDO A MATRIZ DE RASTREABILI-DADE VERTICAL DOS REQUISITOS
A figura 27 ilustra um exemplo de notação Wiki gerada pelo plug-in. Ao incorporar
esse código Wiki gerado pela extensão na página da DFD, o analista de sistemas
adiciona o artefato nessa mesma página, facilitando a visualização e manutenção da
mesma.
A figura 28 mostra a matriz de rastreabilidade de requisitos representada na DFD,
após o analista de sistemas incorporar o código Wiki na página e salvar a mesma.
Neste capítulo foram apresentados a implementação do plug-in, bem como os
testes realizados no ambiente de desenvolvimento. No próximo capítulo apresentaremos
a aplicação da ferramenta no ambiente da empresa, bem como a análise dos resultados
desses testes. Essa análise servirá como base para as conclusões do trabalho, onde será
verificado se os objetivos do trabalho foram atingidos de maneira satisfatória.
70
FIGURA 28 – MATRIZ REPRESENTADA PELA NOTAÇÃO WIKI DO Trac
71
6 ANÁLISE DOS RESULTADOS
Nesse capítulo será abordada a aplicação da ferramenta desenvolvida na
Prognus Software Livre. Os testes foram realizados em dois projetos de 10 (dez) dias de
duração, com quantidades de requisitos semelhantes à outros projetos desenvolvidos
anteriormente pela empresa. Após os resultados dos testes, será feito o levantamento e
análise dos resultados, bem como possíveis considerações sobre a utilização do plug-in.
6.1 ESCOLHA DOS PROJETOS
Para que fosse possível analisar e comparar os resultados com projetos
anteriores, foram escolhidas demandas de escopo semelhantes à outras já
implementadas anteriormente pela Prognus. Para essa análise e levantamento de dados,
utilizou-se o plug-in em dois projetos da empresa, com duração média de 10 dias cada.
O plug-in foi instalado no Trac da empresa para que fosse utilizado nos projetos. A
instalação da ferramenta foi feita através do módulo de administração do Trac, como foi
feito no ambiente de implementação, demonstrado no item 5.5, página 61.
Para tornar o teste mais completo, foram simuladas mudanças em requisitos com
dependências, para testar e analisar a eficiência do plug-in na análise e no mapeamento
dessas dependências.
O primeiro projeto escolhido para a análise do plug-in era composto por 89
requisitos funcionais, com 7 dependências entre os mesmos. A figura 29 mostra um
exemplo de dependência de requisitos para essa primeira demanda.
FIGURA 29 – DEPENDÊNCIA DE REQUISITOS DA PRIMEIRA DEMANDA FONTE: https://dev.prognus.com.br/processo/wiki/Processo/Principal
O segundo projeto era composto por 96 requisitos e possuía 13 dependências
72
entre eles. É possível visualizar um exemplo de dependência desta demanda na figura 30.
FIGURA 30 – DEPENDÊNCIA DE REQUISITOS DA SEGUNDA DEMANDA FONTE: https://dev.prognus.com.br/processo/wiki/Processo/Principal
A escolha dessas demandas se deu pelo fato de serem semelhantes à outras já
implementadas pela empresa anteriormente. Isso torna possível fazer uma comparação
com esses projetos, facilitando a análise da eficiência da solução.
De acordo com o processo de desenvolvimento definido na empresa, a fase de
especificação da demanda, onde o processo de criação da matriz de rastreabilidade
vertical está incluído, demanda 60% da fase de execução do projeto, sendo utilizado 30%
para implementação e os 10% restantes para testes.
A figura 31 ilustra a fase de execução do processo de desenvolvimento da
Prognus Software Livre. Essa fase é divida em 3 subfases: Especificação,
Desenvolvimento e Teste. A criação da matriz de rastreabilidade vertical dos requisitos é
feita na tarefa de especificação, que demanda o maior tempo da fase de execução do
projeto.
6.2 INSTALAÇÃO E UTILIZAÇÃO DO PLUG-IN NA PROGNUS
Após a finalização da implementação do plug-in, a extensão foi instalada no Trac
no ambiente de desenvolvimento da Prognus Software Livre. A instalação ocorreu sem
contratempos, utilizando a interface de administração da ferramenta, como foi feito no
ambiente destinado para o desenvolvimento deste trabalho.
A forma de funcionamento do plug-in foi apresentado para os analistas de sistema
que iriam desenvolver as demandas nas quais seria testada a ferramenta na forma de
uma apresentação, que explicava o funcionamento da ferramenta.
73
FIGURA 31 – FASE DE EXECUÇÃO DEFINIDA NO PROCESSO DE DESENVOL-VIMENTO DA PROGNUS SOFTWARE LIVRE FONTE: https://dev.prognus.com.br/processo/wiki/Processo/Principal
Foi decidido que a utilização do plug-in para testes seria feita da seguinte forma:
após a extensão ser instalada no ambiente de desenvolvimento da empresa, o analista de
sistemas responsável por uma demanda iria preencher a página de declaração formal de
demanda normalmente e seria analisado o resultado do processamento do plug-in após a
página ser salva. Devido à característica automática da extensão, o tempo de adaptação
ao seu uso é muito curto.
Como apresentado no item 6.1, para que fosse feita a comparação com outros
projetos semelhantes da empresa, foram escolhidos duas demandas. O levantamento das
horas gastas na construção da matriz de rastreabilidade vertical dos requisitos de cada
uma das demandas foi feito através do ticket registrado para essa atividade no Trac. O
foco da análise foi o tempo gasto somente na matriz de requisitos. Essa decisão foi
tomada para que não haja inconsistências nas análises e comparações, consequentes de
possíveis atrasos em outras fases do projeto.
A primeira demanda implementada pela empresa sem o plug-in e que foi utilizada
como exemplo para comparação era composta por 66 requisitos, e a atividade de criação
e configuração da matriz de rastreabilidade vertical de requisitos dessa demanda
constava 6 horas e 20 minutos registradas no ticket do Trac. Ou seja, mais que 75% de
um dia de trabalho de 8 horas foi necessário para a montagem da matriz de
74
rastreabilidade vertical. Nesse mesmo ticket havia mais 4 horas de trabalho referente às
manutenções na matriz de rastreabilidade vertical, como remoção e edição de requisitos e
correção de inconsistências. Haviam sido registradas 9 mudanças de requisitos para essa
demanda. No total, a atividade relacionada a matriz de requisitos da primeira demanda
tem 10 horas e 20 minutos de registro no sistema.
A segunda demanda contava com 71 requisitos, e o ticket relacionado à atividade
de construção da matriz registrava 7 horas de trabalho. Para outras atividades haviam
mais 2 horas e 30 minutos contabilizados, com 5 mudanças de requisitos registradas no
ticket, totalizando 9 horas e 30 minutos de trabalho, somente relacionado à matriz de
rastreabilidade.
Com esses dados, é possível notar que a tarefa de criação e manutenção da
matriz de rastreabilidade vertical de requisitos das demandas requer um tempo
considerável do analista de sistemas, o que faz com que o projeto tenha um tempo maior,
e consequentemente aumente seu custo.
Como discutido no item 6.1, a primeira demanda selecionada para o teste
utilizando o plug-in era composta por 89 requisitos, com 7 dependências entre eles. O
ticket referente à criação da demanda contava 45 minutos para a tarefa de criação da
matriz de rastreabilidade dos requisitos. Apesar de automatizada, essa tarefa teve um
tempo de duração um pouco elevado pois era a primeira vez que estava sendo utilizada
pelos analistas de sistema da empresa. Também, após a montagem, os analistas
verificaram se a matriz havia sido montada de maneira correta. Durante a fase de
especificação, houve 5 mudanças de requisitos, uma delas em um requisito com
dependência. Essas atividades de manutenção contabilizaram 1 hora no ticket da
atividade no Trac. No total foram gastos 1 hora e 45 minutos na criação e manutenção da
matriz.
Em paralelo a primeira demanda, o plug-in foi utilizado em um segundo projeto.
Como descrito no item 6.1, esse projeto era composto por 96 requisitos, com 13
dependências entre eles. Para a criação da matriz foram contabilizados 35 minutos.
Durante seu desenvolvimento houve 4 mudanças nos requisitos, e nenhum requisito
dependente sendo afetado. Para as atividades de manutenção foram contabilizados 45
minutos, totalizando 1 hora e 15 minutos para toda a tarefa relacionada à matriz de
rastreabilidade.
75
6.3 ANÁLISE DOS RESULTADOS
Após os testes do plug-in em projetos reais da empresa, foi realizado o
levantamento dos dados referentes à utilização. Para fim de comparação, foram
escolhidos outros 2 projetos implementados anteriormente pela empresa, e que tinham
uma quantidade de requisitos semelhantes.
Demanda Requisitos Mudanças Tempo
Demanda sem plug-in 1 66 9 10 horas e 20 minutos Demanda sem plug-in 2 71 5 9 horas e 30 minutos Demanda com plug-in 1 89 7 1 hora e 45 minutos Demanda com plug-in 2 96 13 1 hora e 15 minutos
TABELA 11 – COMPARAÇÃO DE DEMANDAS SEM E COM A UTILIZAÇÃO DO PLUG-IN
Na tabela 11 é possível observar a quantidade de tempo necessária para a
criação e manutenção da matriz para cada demanda e a diferença de duração dessa
tarefa em projetos que não utilizaram o plug-in e demandas que utilizaram a extensão.
Em média, os trabalhos relacionados a essa atividade ficaram 9 vezes mais rápidos,
fazendo com que o projeto como um todo fosse desenvolvido mais rapidamente. É
necessário também considerar a taxa de falhas durante a criação e edição da matriz.
Essa atividade quando realizada manualmente tem uma possibilidade de erro
considerável devido a necessidade de manipular grandes quantidades de dados e
também da forma como é construída a matriz, utilizando linguagem Wiki. Durante os
testes com o plug-in não foram encontradas falhas na criação e na manutenção da matriz,
ou seja, sempre que a página de declaração formal de demanda estava formatada
corretamente seguindo o padrão esperado, a ferramenta funcionou a contento.
Levando em consideração os projetos que foram utilizados para teste e com base
no processo de desenvolvimento da Prognus, apresentado na figura 27, é possível
quantificar a melhora da utilização da solução no processo da empresa.
Os projetos testados tinham em média duração de 10 dias, considerando um dia
de trabalho de 8 horas, totalizando 80 horas para a demanda. Tendo como base ainda a
figura 27, podemos ter a quantidade exata de horas reservada para cada atividade no
processo, que pode ser visualizada na tabela 12.
76
Total de horas do projeto
Especificação (60%)
Desenvolvimento (30%)
Testes (10%)
80 horas 48 horas 24 horas 8 horas
TABELA 12 – QUANTIDADE DE HORAS POR ATIVIDADE DO PROCESSO
Analisando os dados dos testes do plug-in, apresentados na tabela 11, foi
possível perceber que as tarefas relacionadas à matriz de rastreabilidade vertical dos
requisitos levavam em média 10 horas para serem concluídas. Com a utilização da
ferramenta desenvolvida, esse tempo médio caiu para 1 hora e 30 minutos, uma redução
de 85% no tempo gasto para essa atividade.
Considerando somente a fase de especificação da demanda, em um projeto de
80 horas, são alocados 48 horas para essa atividade. Dessas, em média 10 horas eram
utilizadas para a manipulação da matriz de rastreabilidade, ou seja, 20% de toda a fase
de especificação. Com a redução de tempo decorrente da utilização do plug-in, utilizando
1 hora e 30 minutos em média nas tarefas relacionadas à matriz. Dessa forma, é possível
concluir que a matriz de rastreabilidade utiliza somente 3% da quantidade de horas
alocadas para a fase de especificação da demanda.
Analisando os dados apresentados na tabela 13, percebe-se que a economia de
tempo decorrente da utilização do plug-in possibilita uma readequação do processo de
desenvolvimento da Prognus. No caso dos projetos testados, houve uma economia de 8
horas e 30 minutos na fase de especificação da demanda, decorrente da criação e
manutenção da matriz de rastreabilidade que foi feita mais de 6 vezes mais rápida. Essa
tarefa, que antes demandava 20% de toda a fase de especificação, agora necessita em
média de 3% para ser implementada, diminuindo o tempo da fase e, consequentemente,
de todo o projeto.
Fase de especificação da demanda – matriz de rastreabilidade vertical dos requisitos
Projeto sem a utilização do plug-in Projeto utilizando o plug-in Tempo Gasto Porcentagem Tempo Gasto Porcentagem
10h 20% 1h30m 3%
TABELA 13 – TEMPO GASTO COM A MATRIZ DE RASTREABILIDADE NA FASE DE ESPECIFICAÇÃO DA DEMANDA.
A relação do tempo gasto nas tarefas relacionadas à matriz de rastreabilidade na
fase de especificação da demanda é ilustrada na figura 32.
77
FIGURA 32 – MATRIZ DE RASTREABILIDADE EM RELAÇÃO À FASE DE ESPE-CIFICAÇÃO
Se considerarmos o caso em que todas as atividades do projeto sejam
desenvolvidas dentro do prazo estipulado, uma demanda semelhante à testada fazendo
uso do plug-in poderia ser estimada em 72 horas.
Com a diminuição do tempo de desenvolvimento de um projeto, temos como
impacto direto a diminuição de seu preço final, uma vez que de acordo com o diagrama
de tripla restrição, escopo, prazo e custo estão intrinsecamente relacionados em um
projeto, e uma alteração em qualquer um desses itens faz com que os outros dois sejam
alterados. Esse diagrama é ilustrado na figura 33 deste documento.
Como afirma (MOREIRA, 2007), os gerentes de projeto frequentemente se
deparam com a tripla restrição ao atendimento das necessidades dos interessados no
projeto: Escopo, prazo e custo. Um grande esforço em planejamento é necessário para
minimizar a ocorrência de eventos incertos que podem causar grande impacto nesses 3
itens mencionados, e isso pode refletir também nos recursos humanos.
FIGURA 33 – DIAGRAMA DE TRIPLA RESTRIÇÃO FONTE: Moreira, 2007
78
7 CONCLUSÕES
Após implementação e utilização do plug-in foi possível verificar que os objetivos
declarados no capítulo de introdução deste documento foram atingidos.
Um dos objetivos definidos no item 1.1 tratava da funcionalidade de
automatização da criação e manutenção da matriz de rastreabilidade vertical de
requisitos, para auxiliar no gerenciamento de requisitos dos projetos desenvolvidos pela
Prognus Software Livre. Esse objetivo foi implementado através do processamento da
página de declaração formal de demanda, analisando os padrões estabelecidos para
descrição de dependência de requisitos, e que já são utilizados pela empresa. Com o
resultado da análise da página, a linguagem Wiki do Trac é utilizada para gerar
visualmente a matriz de rastreabilidade de forma a ser representada no Trac.
Outro objetivo do trabalho, também afirmado no item 1.1, foi que a ferramenta
deve alertar os usuários do Trac sobre requisitos que apresentem alguma dependência.
Isso é feito utilizando uma mensagem de warning disponibilizada para uso pelo Trac.
Todas as vezes que uma página de declaração formal de demanda é atualizada, é
realizada a verificação, informando o analista de sistemas caso algum requisito com
dependência for modificado.
Com o resultado das análises e comparações da utilização do plug-in nos projetos
da Prognus Software Livre, concluímos que houve um ganho significativo no tempo
utilizado na fase de especificação da demanda, mais especificamente na criação e
manutenção da matriz de rastreabilidade de requisitos, foco do trabalho. Mesmo com
apenas dois testes realizados, foi possível notar uma diminuição de mais de 6 vezes no
tempo da criação da matriz com a utilização do plug-in em relação aos projetos
semelhantes que não utilizaram a extensão.
A tarefa de criar e manter a matriz de rastreabilidade é considerada uma das mais
importantes etapas da especificação das demandas, pois dá uma visão geral do projeto,
identificando possíveis problemas. Essa atividade também é uma das mais trabalhosas
dessa etapa, pois era realizada manualmente pelo analista de sistemas, o que aumentava
também a possibilidade de falhas na criação e manutenção da mesma.
Esse aumento de eficiência na fase de especificação da demanda tornou essa
fase do processo de desenvolvimento mais rápida, facilitando o trabalho do analista de
sistemas da demanda.
A possibilidade de adequação e diminuição da fase de execução do processo,
79
diminuindo o tempo de entrega dos projetos se transformam em vantagem competitiva
para a empresa. Como foi afirmado no capítulo 1 de introdução, o mercado exige que
cada vez mais os projetos sejam implementados mais rapidamente e com maior
eficiência. Com isso, as empresas que lançarem mão de métodos que auxiliem as fases
do projeto para torna-las mais rápidas e eficientes consequentemente terão ganhos reais
com esse auxílio.
A utilização do plug-in também atende à sugestão da equipe de avaliação do
MPS.BR, para que a criação da matriz de rastreabilidade seja automatizada. Isso faz com
que a empresa esteja cada vez mais aderente ao nível G do MPS.BR, principalmente no
que diz respeito à disciplina de gerência de requisitos, tornando o processo mais eficiente.
A utilização do plug-in pelos analistas de sistemas que participaram dos testes
ocorreu sem maiores problemas, e a curva de adaptação com a extensão foi muito
pequena. Apesar de fazer um trabalho complexo e importante, sua utilização é muito
simples e automatizada, bastando que o usuário da ferramenta acione o botão para a
criação da matriz de rastreabilidade dos requisitos.
A aceitação do plug-in na empresa utilizada como teste da ferramenta, bem como
a provável continuidade do uso da extensão em outros projetos demonstra que os
resultados da utilização da ferramenta agregou valor ao processo de desenvolvimento da
empresa, auxiliando uma fase importante do ciclo de especificação das demandas para
implementar.
Durante a utilização foi possível também notar possíveis adequações que podem
melhorar ainda mais a usabilidade e eficiência no gerenciamento de requisitos de uma
demanda e podem ser implementadas em trabalhos futuros.
Uma das melhorias possíveis, sugeridas pelos analistas de sistemas que
utilizaram o plug-in, foi a possibilidade de criar uma dependência entre requisitos através
da matriz de rastreabilidade de requisitos. Isso poderia ser feito tornando possível que
cada célula da matriz de rastreabilidade fosse editável. Uma vez que isso fosse possível,
o analista de sistemas poderia, na própria matriz de rastreabilidade, criar uma
dependência entre dois requisitos, sem a necessidade de editar os requisitos da página
de declaração formal de demanda.
Uma melhoria interessante remete à escolha dos requisitos que farão parte da
matriz de rastreabilidade dos requisitos. Atualmente, todos os requisitos de uma demanda
fazem parte automaticamente da matriz de rastreabilidade, mas mostrou-se interessante
durante os testes que fosse possível selecionar os requisitos que farão parte da matriz,
principalmente quando a demanda possuir muitos requisitos. Com isso, seria possível até
80
mesmo a criação de mais de uma matriz, separada por grupos de requisitos de uma
mesma demanda.
Como implementação futura foi levantada a possibilidade de tornar o padrão de
listagem e dependência de requisitos configurável, para que cada usuário utilize a
extensão da maneira que julgar melhor, sem a necessidade de se adequar ao padrão
utilizado no plug-in e que está fortemente ligado com o utilizado na Prognus.
Durante a fase de desenvolvimento e testes do plug-in ocorreram alguns
problemas. Um deles foi de codificação dos caracteres das mensagens apresentadas pela
ferramenta. Quando o alerta de alteração de requisito com dependência era escrito com
caracteres acentuados com, por exemplo, a palavra “alteração”, ocorria um erro na
compilação do template do Trac. Por isso, a mensagem apresentada não pode conter
acentos.
Problemas com requisitos escritos fora do formato também aconteceram durante
os testes do plug-in. Para que a ferramenta funcione adequadamente, é necessário que o
analista de sistemas preencha de forma correta a página de declaração formal de
demanda (DFD), seguindo os padrões de descrição de requisitos e dependências
descritos no item 5.2 deste documento. Caso o preenchimento da página de DFD seja
feito fora do padrão, o sistema terá seu funcionamento prejudicado, pois não encontrará
os padrões pré-estabelecidos e as dependências e requisitos que estiverem fora do
padrão não serão identificadas.
81
REFERÊNCIAS
PRESSMAN, R. S. Engenharia de Software. 6. ed. Rio de Janeiro: Mc Graw Hill, 2006. PFLEEGER, S. L. Engenharia de Software: Teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004. SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003. FILHO, W. P. Engenharia de Software: Fundamentos, métodos e padrões. 2. ed. Rio de Janeiro: LTC, 2005.
SCHWABER, K. et al. Agile Project Management with Scrum. 1. ed. Microsoft Press, 2004.
PROJECT MANAGEMENT INSTITUTE, PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos: Guia PMBOK. Pennsylvania, 2004. BETTIO, K.; VALASKI, J.; GOMES, D. L.; MATIAS, E.; REINEHR, S.; MALUCELLI, A. Uma experiência de implementação nível G em uma empresa de software livre. In: Simpósio Brasileiro de Qualidade de Software, 10, 2011, Curitiba. VIANA, Leonardo. M.; DESCHAMPS, Alexandro. XP – Extreme Programming. Disponível em: <http://www.apicesoft.com/common/articles/Apice> Acesso em: 21 de Ago. 2011. OLIVEIRA, T. M. Gerenciamento de projetos através do Project Locker (Trac e Subversion). 2010. 42f. Trabalho de conclusão de curso (Bacharelado em Ciência da Computação) Universidade Estadual de Maringá, Paraná. ÁVILA, A. L.; SPÍNOLA, R. O. Introdução à Engenharia de Requisitos. Revista Engenharia de Software, São Paulo, v. 1, n. 1, p. 46-51, 2007. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWAFRE BRASILEIRO, SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro. São Paulo, 2009.
FOWLER, M. The New Methodology. Disponível em <http://www.martinfowler.com/articles/newMethodology.html>, Acesso em 17 out. 2011. KALINOWSKI, M.; Santos, G.; REINEHR, S.; MONTONI, M.; ROCHA, A. R.; WebER, K.C.; TRAVASSOS, G. H. MPS.BR: Promovendo a Adoção de Boas Práticas de Engenharia de Software pela Indústria Brasileira. In: Congreso Iberoamericano en "Software Engineering" (CIBSE), 2010, Cuenca. XIII Congreso Iberoamericano en "Software Engineering", 2010. WEBER, K. C.; MONTONI, M.; ROCHA, A.R.C.; SANTOS, G.; BARBIERI, C., ANTONIONI, J.A. (2008). “MPS.BR – Melhoria de Processo do Software Brasileiro: resultados alcançados e lições aprendidas (2004-2008)”. CLEI 2008 (XXXIV Conf. Latinoamericana de Informática), 8 a 12 de Setembro, Santa Fé, Argentina. PEDROSA, A.E, UESONO, G.M. Metodologias de Desenvolvimento de Sistemas-
82
Universidade Federal de São Carlos 2006. Disponível em: <http://www.dc.ufscar.br/~rosangel/mds/Seminarios/MetodosAgeis.pdf> Acesso em: 23 de out. 2011. SOARES, C., TEIXEIRA, C. M., MOREIRA, D. G., COSTA, J. S. S., COSTA, M. V. S., MENEGUITE, R. L. Visão Geral do Projeto MPS.br - Faculdade de Ciências da Computação de Cataguases 2008. Disponível em <http://pt.scribd.com/doc/44966729/Artigo-MPSbr> Acesso: 20 de out. 2011.
CASTRO, V. A. Desenvolvimento Ágil com Programação Extrema. 2007. 122f. Trabalho de conclusão de curso (Bacharelado em Ciência da Computação) Universidade Federal de Sergipe, Sergipe.
DIAS, André Felipe. Controle de Mudança com Trac. Disponível em: <http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/trac.php> Acesso em: 25 set. 2011. EDGEWALL, Trac Open Source Project. Disponível em: <http://www. http://trac.edgewall.org/> Acesso em: 11 set. 2011. MOREIRA, O. C. Modelos para gestão de projetos na Engenharia de Software. 2007. 32f. Tese (Especialização em Engenharia de Projetos de Software) Universidade do Sul de Santa Catarina, Santa Catarina.