Anda di halaman 1dari 83

FAA FACULDADE ANGLO-AMERICANO

AIRTON BORDIN JUNIOR

IMPLEMENTAO DE UMA SOLUO BASEADA EM SOFTWARE LIVRE PARA A GERNCIA DE REQUISITOS EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ADEQUADO AO NVEL G DE MATURIDADE DO MPS.BR

FOZ DO IGUAU 2011

i AIRTON BORDIN JUNIOR

Implementao de uma soluo baseada em software livre para a gerncia de requisitos em um processo de desenvolvimento de software adequado ao nvel G de maturidade do MPS.BR
Trabalho de concluso de curso apresentado como requisito obrigatrio para a obteno do ttulo de Bacharel em Cincia da Computao da Faculdade Anglo Americano de Foz do Iguau PR. Orientador: Prof. Miguel Diogenes Matrakas Co-orientador: Prof. Alessandra Bussador

FOZ DO IGUAU 2011

ii

Este trabalho reflete a opinio dos autores e no necessariamente da Faculdade AngloAmericano. Autorizamos a difuso deste trabalho.

________________________________ Airton Bordin Junior

iii

Agradeo aos docentes Miguel Diogenes Matrakas e Alessandra Bussador, pelo apoio e ajuda concedidos no andamento desta monografia e pela generosidade em compartilhar seus conhecimentos. Estendo esta gratulao aos demais professores envolvidos que no mediram esforos em ajudar. Agradeo tambm aos familiares e amigos pelo incentivo e fora proporcionados na concluso de mais essa etapa da vida.

O autor

iv

"A teoria tambm se converte em graa material uma vez que se apossa dos homens." (Karl Marx)

RESUMO Este trabalho descreve a implementao de uma soluo baseada em software livre para auxiliar na execuo eficiente do processo de desenvolvimento de software, mais precisamente na rea de gerncia de requisitos. O processo de gerncia de requisitos um dos analisados na certificao em nvel G do MPS.BR, sendo o outro processo o de gerncia de projetos. A soluo implementada busca automatizar a criao e manuteno da matriz de rastreabilidade vertical dos requisitos no processo de desenvolvimento de software, de forma a diminuir a incidncia de erros na criao e manuteno da mesma e aumentar a eficincia do processo como um todo. O sistema tambm auxilia o mapeamento das modificaes dos requisitos com dependncia, e alerta o responsvel pelo projeto sobre as alteraes crticas e possveis problemas consequentes. A ideia dessa soluo partiu de sugestes da equipe de avaliao do MPS.BR na certificao da Prognus Software Livre, empresa do ramo que possibilitou a pratica dessa pesquisa. Essa soluo foi implementada em forma de um plug-in a ser incorporado na ferramenta de gesto de projetos Trac, que utilizada pela empresa para o gerenciamento dos seus projetos. Para verificar a viabilidade e eficincia da implementao, o plug-in foi testado em projetos reais da empresa, a fim de levantar dados para uma anlise sobre a eficincia da extenso. Aps os testes, o plug-in foi disponibilizado para download no site oficial da ferramenta para que possa ser utilizado em outros projetos. Palavras-chave: Gerncia de requisitos, Matriz de rastreabilidade, MPS.BR, Plug-in.

vi SUMRIO

1 INTRODUO ................................................................................................................................ 8 1.1 OBJETIVOS ............................................................................................................................ 11 1.2 JUSTIFICATIVAS ................................................................................................................... 12 1.3 ORGANIZAO DO DOCUMENTO ................................................................................... 13 2 REVISO BIBLIOGRFICA ....................................................................................................... 15 2.1 MPS.BR ................................................................................................................................... 15 2.1.1 Modelo de referncia MPS ................................................................................................... 17 2.2 FERRAMENTA TRAC ........................................................................................................... 21 2.3 SUBVERSION......................................................................................................................... 25 2.4 GERNCIA 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 UTILIZAO DA METODOLOGIA SCRUM NO PROJETO ....................... 45 3.7 BACKLOG DO PROJETO E DEFINIO DAS SPRINTS ................................................... 47 4 MODELAGEM ............................................................................................................................... 50 4.1 ARQUITETURA TRAC .......................................................................................................... 50 4.2 MODELAGEM DO PLUG-IN ................................................................................................ 51 5 IMPLEMENTAO ...................................................................................................................... 61 5.1 INSTALAO E CONFIGURAO DO AMBIENTE ........................................................ 61 5.2 PADRES DE CONTEDO DA PGINA DE DFD ............................................................. 61 5.3 IMPLEMENTAO DA ANLISE DA PGINA DE DFD ................................................. 63 5.4 GERENCIAMENTO DE AVISOS DE ALTERAES EM REQUISITOS .......................... 65 5.5 INSTALAO DO PLUG-IN NO TRAC .............................................................................. 65 5.6 TESTE DO PLUG-IN .............................................................................................................. 67 6 ANLISE DOS RESULTADOS .................................................................................................... 71 6.1 ESCOLHA DOS PROJETOS .................................................................................................. 71 6.2 INSTALAO E UTILIZAO DO PLUG-IN NA PROGNUS .......................................... 72 6.3 ANLISE DOS RESULTADOS ............................................................................................. 75 7 CONCLUSES .............................................................................................................................. 78 REFERNCIAS ................................................................................................................................. 81

vii LISTA DE FIGURAS

FIGURA 1: COMPONENTES DO MODELO MPS ............................................................ 17 FIGURA 2: NVEIS DE MATURIDADE MPS.BR ............................................................... 18 FIGURA 3: RELAO ENTRE OS NVEIS DE MATURIDADE CMMI E MPS.BR ............ 19 FIGURA 4: FORMATAO WIKI DO Trac ........................................................................ 23 FIGURA 5: UTILIZAO DO TRAC EM CONJUNTO COM O SUBVERSION ................. 24 FIGURA 6: EVOLUO DOS REQUISITOS .................................................................... 29 FIGURA 7: ESTGIOS 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 FAMLIA CRYSTAL ....................................................... 45 FIGURA 12: REPRESENTAO 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: PSEUDOCDIGO DA CRIAO DA MATRIZ DE RASTREABILIDADE VERTICAL .................................................................................................... 54 FIGURA 16: DIAGRAMA DE ATIVIDADES DA EDIO DA LISTA DE REQUISITOS ...... 56 FIGURA 17: DIAGRAMA DE CLASSES DO PLUG-IN ...................................................... 57 FIGURA 18: DIAGRAMA DE CLASSES REPRESENTANDO A RELAO ENTRE OS PACOTES ..................................................................................................... 57 FIGURA 19: DIAGRAMA DE SEQUNCIA DA CRIAO DA MATRIZ DE RASTREABILIDADE VERTICAL .................................................................. 58 FIGURA 22: PADRES DE REPRESENTAO DE CONTEDO DA PGINA DE DECLARAO FORMAL DE DEMANDA .................................................... 62 FIGURA 23: AVISO DE ALTERAO DE REQUISITO COM DEPENDNCIA ................. 66 FIGURA 24: TELA DE ADMINISTRAO DE PLUG-INS DO Trac ................................... 67 FIGURA 25: BOTO DE CRIAO DA MATRIZ DE RASTREABILIDADE VERTICAL NA PGINA DE DECLARAO FORMAL DE DEMANDA ................................ 68 FIGURA 26: MATRIZ DE RASTREABILIDADE VERTICAL GERADA PELO PLUG-IN ..... 68

viii FIGURA 27: NOTAO WIKI REPRESENTANDO A MATRIZ DE RASTREABILIDADE VERTICAL DOS REQUISITOS..................................................................... 69 FIGURA 28: MATRIZ REPRESENTADA PELA NOTAO WIKI DO Trac ........................ 70 FIGURA 29: DEPENDNCIA DE REQUISITOS DA PRIMEIRA DEMANDA ..................... 71 FIGURA 30: DEPENDNCIA DE REQUISITOS DA SEGUNDA DEMANDA .................... 72 FIGURA 31: FASE DE EXECUO DEFINIDA NO PROCESSO DE DESENVOLVIMENTO DA PROGNUS SOFTWARE LIVRE ......................... 73 FIGURA 32: MATRIZ DE RASTREABILIDADE EM RELAO FASE DE ESPECIFICAO......................................................................................... 77 FIGURA 33: DIAGRAMA DE TRIPLA RESTRIO .......................................................... 77

ix LISTA DE TABELAS

TABELA 1: NVEIS 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: MTODOS DE ACESSO AO REPOSITRIO SUBVERSION ..................... 244 TABELA 6: PRINCIPAIS COMANDOS SVN ................................................................... 295 TABELA 7: CLASSIFICAO DE REQUISITOS VOLTEIS ......................................... 318 TABELA 8: MATRIZ DE RASTREABILIDADE VERTICAL ............................................. 370 TABELA 9: LETRAS E SEUS SIGNIFICADOS NA METODOLOGIA CRYSTAL ............. 41 TABELA 10: TEMPO DE DURAO DOS PROJETOS EM FUNO DO NMERO DE PESSOAS .................................................................................................. 441 TABELA 11: COMPARAO SEM E COM A UTILIZAO 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 INTRODUO

A exigncia de se produzir software com mais rapidez e eficincia, tanto no cenrio nacional quanto no internacional, faz com que a cada dia a indstria desse segmento disponibilize novos mtodos, ferramentas e modelos de desenvolvimento que auxiliem nessa produo para que sejam atingidos os prazos e nveis de produtividade exigidos. Apesar de toda evoluo, os projetos de software ainda so executados sem padres bem definidos e existe muita incerteza no processo de desenvolvimento. Nesse cenrio, desenvolvimento de software pode ser definido como um projeto. Segundo a definio de (PMI, 2004), projeto um empreendimento planejado, executado e controlado, com incio, meio e fim programado, tendo como objetivo criar um servio ou um produto singular. Segundo (PRESSMAN, 2006), um projeto de software bem sucedido aquele em que feita anlise em alguns parmetros principais, entre eles o escopo do software, os riscos envolvidos, os recursos necessrios, as tarefas a serem realizadas, os indicadores a serem acompanhados, os esforos e custos aplicados e a sistemtica a ser seguida. Essa anlise feita no gerenciamento do projeto, que se inicia antes do trabalho tcnico 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 aplicao de diversas habilidades, tcnicas, 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 (Associao para promoo da excelncia do software brasileiro), uma entidade privada e sem fins lucrativos que visa aumentar a competitividade da indstria brasileira de software no cenrio mundial. O modelo desenvolvido pelo MPS.BR visa a melhoria contnua 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 Ministrio da Cincia e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Servio 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 avaliao de processo de software, visando preferencialmente s micro, pequenas e mdias empresas, de forma a atender s necessidades de negcio das mesmas e ser reconhecido no mbito nacional e internacional. Por visar as micro, pequenas e mdias empresas nacionais, o MPS.BR leva em considerao a realidade brasileira e no cobra royalties das empresas associadas ao sistema, alm disso, tem um baixo custo de implantao. Apesar dessas caractersticas, esse modelo tambm poder ser implantado em uma empresa de grande porte. O MPS.BR dividido em nveis de maturidade, iniciando-se pelo nvel G, definido como parcialmente gerenciado, e evoluindo at o nvel A, em otimizao. Segundo (SOFTEX, 2009), os nveis de maturidade estabelecem patamares de evoluo de processos, caracterizando estgios de melhoria da implementao dos processos do modelo na organizao. Cada um dos nveis tem atribudo um perfil de processos que indicam onde a organizao deve colocar o esforo de melhoria. A diviso em estgios tem o objetivo de possibilitar uma implementao e avaliao adequada realidade das micro, pequenas e mdias empresas e tambm permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos.

1.1 OBJETIVOS

O trabalho tem como objetivo a criao de um plug-in para a ferramenta de gesto 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 certificao MPS.BR nvel G, parcialmente gerenciado. O plug-in auxiliar no gerenciamento de requisitos dos projetos desenvolvidos pela empresa, automatizando a criao e manuteno da matriz de rastreabilidade vertical de requisitos do projeto. Essa matriz armazena os requisitos do projeto e as interdependncias entre os requisitos. A ferramenta tambm dever alertar os usurios do Trac sobre requisitos que apresentem alguma dependncia. Essa representao ser feita atravs da matriz de
1

http://www.prognus.com.br

12 rastreabilidade vertical, gerada na pgina do projeto, em forma de alerta textual para que caso haja algum requisito com dependncia este possa ser modificado pelo analista de sistemas responsvel. A matriz de rastreabilidade vertical dos requisitos do projeto ser criada e apresentada ao usurio do sistema, em geral pelo analista de sistemas responsvel pelo projeto, essa matriz ser apresentada em forma de tabela utilizando a linguagem Wiki do Trac, na pgina do projeto. Detalhes da linguagem Wiki sero apresentados no item 2.2, na pgina 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 licena GPL3.

1.2 JUSTIFICATIVAS

A Prognus Software Livre uma empresa que est h 6 anos no mercado de desenvolvimento de solues baseadas em software livre, situada na cidade de Foz do Iguau, no Parque Tecnolgico Itaipu, atualmente especializada na sute colaborativa Expresso Livre4, uma sute de comunicao que possui diversos mdulos de servios centralizados em uma nica aplicao, como e-mail, agenda, catlogo de endereos, comunicador instantneo, 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 implantao do modelo de melhoria de processos do MPS.BR. Como forma de melhorar suas prticas de desenvolvimento, a empresa decidiu implantar o modelo de melhoria de processo software MPS.BR nvel G, parcialmente gerenciado. Esse nvel abrange as disciplinas de gerncia de projetos e gerncia de requisitos (PMI, 2004).
2

http://trac.edgewall.org General Public License 4 Documentao e download no site http://www.expressolivre.org


3

13 Para se adequar ao MPS.BR, foi necessria a seleo das ferramentas adequadas para a realizao de cada atividade do processo de desenvolvimento definido, que de acordo com as suas polticas, deveria ser de licena livre. O sistema escolhido para se utilizar no gerenciamento do desenvolvimento dos sistemas da empresa foi o Trac, principalmente por oferecer a flexibilidade de personalizao 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 flexvel e com uma API que permite construir plug-ins para tarefas especficas (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. Aps a avaliao para a certificao da empresa, a equipe avaliadora do MPS.BR fez algumas sugestes para que melhorasse ainda mais o processo de desenvolvimento definido pela empresa, principalmente no que se refere gerncia de requisitos. Uma das ideias sugeria a automatizao da criao 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 criao de uma matriz de rastreabilidade de forma manual um trabalho rduo para o analista de sistemas do projeto. Alm disso, a matriz deveria ser criada utilizando a notao Wiki do Trac, o que tornava o processo ainda mais trabalhoso, e suscetvel a erros por parte do analista. Para atender a sugesto da equipe avaliadora do MPS.BR e automatizar a criao da matriz de rastreabilidade vertical dos requisitos do projeto, ser desenvolvido o plug-in para a ferramenta Trac. A utilizao do plug-in ir facilitar a criao da matriz, automatizando o processo, tornando essa tarefa mais rpida e diminuindo a possibilidade de falhas.

1.3 ORGANIZAO DO DOCUMENTO

Este documento apresenta primeiramente o embasamento terico de todo o trabalho no captulo de reviso bibliogrfica. Neste captulo, apresentamos os principais

14 assuntos abordados durante o trabalho: MPS.BR, Trac, Subversion e gerncia de requisitos. Em seguida apresentada a metodologia utilizada no trabalho, bem como as principais metodologias disponveis. Na sequncia so apresentadas as modelagens do sistema, seguido do captulo de implementao do plug-in. Na sequncia apresentado o captulo de aplicao e a anlise dos resultados. Por fim apresentado o captulo de concluso do trabalho, que traz as consideraes finais, os problemas enfrentados e os trabalhos futuros.

15 2 REVISO BIBLIOGRFICA

Neste captulo, apresentam-se os principais conceitos e ferramentas utilizados no desenvolvimento do trabalho. O primeiro item aborda a certificao MPS.BR, seus nveis e pblico alvo. Na sequncia, apresentada a ferramenta Trac, a qual ser integrada a ferramenta desenvolvida nesse trabalho. O item seguinte fala sobre a ferramenta de controle de verso Subversion (SVN) e suas principais caractersticas. Por fim, o foco ser a gerncia de requisitos, um importante tpico da disciplina de Engenharia de Software e essencial para a sequncia 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 Promoo da Excelncia do Software Brasileiro (SOARES et al, 2008). O programa tem o apoio de diversas instituies como MCT (Ministrio de Cincia e Tecnologia), FINEP (Financiadora de Estudos e Projetos), SEBRAE (Servio 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 vivel para que organizaes, incluindo as pequenas e mdias empresas (PMEs), alcancem os benefcios da melhoria de processos e da utilizao de boas prticas da engenharia de software em um intervalo de tempo razovel. Embora o foco da iniciativa seja PMEs, o modelo adequado tambm para apoiar a melhoria de processos em grandes organizaes (KALINOWSKI et al, 2010, p. 4)

Uma das metas do MPS.BR visa definir e aprimorar um modelo de melhorias e avaliao de processo de software, visando preferencialmente as micro, pequenas e mdias empresas, de forma a atender as suas necessidades de negcio e ter reconhecimento nacional e internacionalmente como um modelo aplicvel indstria de software (SOARES et al, 2008). Soares et al (2008) afirma que o modelo MPS.BR serve como um selo que indica

16 o nvel de maturidade da empresa em relao s prticas relacionadas ao desenvolvimento de software. Esse selo possui nveis, e cada nvel tem suas prticas particulares associadas. Portanto, uma empresa que possui a certificao MPS.BR utiliza as boas prticas no processo de desenvolvimento de software e, teoricamente, tem condies 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 atribudas a profissionais de engenharia de software e pesquisadores. A estrutura organizacional se deu da seguinte forma (KALINOWSKI et al, 2010):

Unidade de execuo do programa MPS.BR: responsvel por definir estratgias e gerenciar as atividades do programa. Atualmente, esta equipe tem a coordenao do SOFTEX;

Equipe tcnica do modelo MPS: responsvel pela criao e aprimoramento contnuo do modelo MPS e capacitao de pessoas por meio de cursos, provas e workshops. A equipe coordenada pela Universidade Federal do Rio de Janeiro (UFRJ);

Frum de credenciamento e controle do MPS: responsvel por emitir parecer que subsidie a deciso da SOFTEX sobre o credenciamento de instituies implementadoras (II) e instituies avaliadoras (IA), avaliar e controlar resultados de implementaes MPS e garantir que as organizaes avaliadas pelo modelo MPS realizem suas atividades dentro dos limites ticos e de qualidades esperados. A coordenao desta atividade feita por representantes do governo brasileiro, da academia e da indstria.

Um dos principais requisitos para desenvolver o modelo MPS que este deveria incorporar tanto prticas internacionalmente reconhecidas de implantao e avaliao de processos de software, quanto atender s necessidades da indstria brasileira de software. Pensando nisso, foram utilizadas as normas ISO/IEC 12207 e ISO/IEC 15504 como base tcnica para a definio dos componentes do modelo MPS (KALINOWSKI et al, 2010). Um dos modelos que serviram como base para a criao do MPS.BR foi o CMMI5. Segundo (PRESSMAN, 2006) o CMMI um abrangente metamodelo de processo, criado

Capability Maturity Model Integration. Mais informaes disponveis 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 alcanam diferentes nveis de maturidade de processo. Pensando na importncia do modelo CMMI para as organizaes nacionais que atuam em mercados internacionais, este modelo foi considerado como complemento tcnico para a definio dos processos do MPS. O MPS possui trs componentes principais: Modelo de referncia MPS (MR-MPS), Mtodo de avaliao MPS (MA-MPS) e o Modelo de negcios MPS (MN-MPS). A figura 1 ilustra estes componentes e as suas relaes. Para este trabalho, ser apresentado somente o Modelo de referncia MPS (MRMPS), 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 referncia MPS

De acordo com (SOFTEX, 2009), o modelo de referncia MPS (MR-MPS) contm todos os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o modelo de referncia. Este documento contm as definies dos nveis de maturidade, processos e atributos do processo. Os nveis de maturidade estabelecem patamares de evoluo de processos, e caracterizam estgios de melhoria da implementao de processos na organizao. O

18 nvel de maturidade permite prever o desempenho futuro de uma organizao ao executar um ou mais processos (SOFTEX, 2009). (SOFTEX, 2009) afirma que o modelo de referncia busca atender s necessidades de implantar os princpios de engenharia de software de forma adequada s necessidades de negcio das organizaes e define sete nveis de maturidade de processos.

FIGURA 2 NVEIS DE MATURIDADE MPS.BR


FONTE: SOARES et al, 2008.

A figura 2 ilustra os nveis de maturidade definidos no modelo de referncia do MPS.BR. Segundo (SOARES et al, 2008), a escala de maturidade se inicia no nvel G e progride at o nvel A. Para cada um destes sete nveis de maturidade atribudo um perfil de processos que indica onde a organizao deve colocar o esforo de melhoria. O alcance de determinado nvel de maturidade se obtm quando so atendidos os propsitos e todos os resultados esperados dos respectivos processos e dos atributos daquele nvel. Apesar da diviso em estgios ser baseada nos nveis de maturidade do CMMI, os nveis do MPS.BR tem uma graduao diferente para possibilitar a implementao e avaliao mais adequada s micro, pequenas e mdias empresas. Essa diviso em nveis

19 tambm 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 correspondncia entre os nveis de maturidade do MPS.BR e do CMMI. Essa correspondncia apresentada na figura 3, que ilustra a relao entre os nveis dos dois modelos de melhoria de processo.

FIGURA 3 RELAO ENTRE OS NVEIS DE MATURIDADE CMMI E MPS.BR


FONTE: SOARES et al, 2008.

De acordo com (SOARES et al, 2008), cada nvel 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 institucionalizao com que o processo executado na organizao. medida que a organizao vai evoluindo nos nveis de maturidade do modelo, deve ser atingido um nvel 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 nveis

20 de capacidade de dos processos so 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 so:

AP 1.1 O processo executado; AP 2.1 O processo gerenciado; AP 2.2 Os produtos de trabalho do processo so 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 inovaes; AP 5.2 O processo otimizado continuamente.

Para cada nvel de maturidade, existem os processos e os atributos dos processos que devem ser atendidos. A tabela 1 apresenta a relao entre os nveis de maturidade do MPS.BR e os atributos de processo do nvel (SOFTEX, 2009).

Nvel A B C D E F G Gerncia de projetos.

Processos

Gerncia de riscos, desenvolvimento para reutilizao e gerncia de decises. Verificao, validao, projeto e construo do produto, integrao com o produto e desenvolvimento de requisitos. Gerncia de projetos, gerncia de reutilizao, gerncia de recursos humanos, definio do processo organizacional, avaliao e melhoria do processo organizacional. Medio, garantia de qualidade, gerncia de portflio de projetos, gerncia de configurao, aquisio. Gerncia de projetos e gerncia de requisitos.

Atributos de processos 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 AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1 e AP 2.2 AP 1.1 e AP 2.1

TABELA 1 NVEIS DE MATURIDADE MPS.BR E ATRIBUTOS DE PROCESSO


FONTE: SOFTEX, 2009.

A Prognus Software Livre optou pela certificao MPS.BR em nvel G, que tem como processos a gerncia de projetos e a gerncia de requisitos. Esta ltima sendo o foco principal do nosso trabalho. Apesar de aprovada na certificao de nvel G do MPS.BR, a banca examinadora

21 fez algumas sugestes para a empresa melhorar o gerenciamento dos requisitos dos seus processos. Uma delas a de automatizar a criao e manuteno da matriz de rastreabilidade vertical dos requisitos, que estava sendo feita manualmente pelo analista de sistemas. A automatizao dessa funcionalidade um dos objetivos deste trabalho, e mais detalhes de sua implementao sero apresentados no captulo 5, pgina 56 deste documento.

2.2 FERRAMENTA TRAC

Trac uma ferramenta open source que pode ser utilizada tanto para o desenvolvimento como para manuteno do software, e no apenas para gerenciar o ciclo de vida dos projetos (OLIVEIRA, 2010). A ferramenta desenvolvida na linguagem de programao Python e est disponvel sob a licena 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 Track-Hacks.org Dojo Toolkit Fedora hosted projects JQuery OpenStreetMap.org Pidgin SourceForge.net
FONTE: http://trac.edgewall.org/wiki/TracUsers

Verso do Trac 0.10.6 0.11 0.10.5 0.12 0.11.7 0.11.1 0.11.2.1

TABELA 2 PROJETOS QUE UTILIZAM O TRAC

A tabela 2 apresenta uma relao 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 pgina da ferramenta8.
6

Documentao e download disponvel em http://www.cvstrac.org/index.html/doc/trunk/www/index.html http://www.edgewall.org/ 8 http://trac.edgewall.org/wiki/TracUsers.


7

22 A utilizao do Trac para o gerenciamento dos projetos de desenvolvimento traz diversos benefcios, entre eles (OLIVEIRA, 2010): Melhoria na qualidade do produto e do processo de desenvolvimento; Registro, rastreamento e controle das solicitaes durante seu ciclo de vida do software; Amarrao entre o controle de verso e o controle de mudana, atravs de um utilitrio de changeset, que possibilita a visualizao da diferena entre duas verses de um arquivo; Melhor documentao do projeto atravs de participao da equipe de desenvolvimento.

O Trac disponibiliza diversas funcionalidades para o gerenciamento e controle dos projetos de software. A tabela 3 descreve as principais funes e as suas descries (Oliveira, 2010):

Funcionalidade Controle de tickets

Ferramenta Wiki

Integrao com o Subversion

Acompanhamento projeto

da

evoluo

Descrio A ferramenta Trac comporta o controle de tarefas do projeto, onde possvel criar tarefas de melhoria, correo e implementao em um projeto. A ferramenta Wiki a responsvel pela documentao completa de um projeto, onde os analistas, desenvolvedores, podem criar requisitos do software. A ferramenta Trac funciona como um browser para o Subversion onde o usurio pode navegar entre as pastas dos projetos. do possvel gerar vrios tipos de relatrios referentes ao projeto, possibilitando o acompanhamento da evoluo do projeto.

TABELA 3 FUNCIONALIDADES DA FERRAMENTA TRAC


FONTE: Oliveira, 2010.

Uma das caractersticas mais interessantes do Trac a utilizao de um mecanismo de Wiki para a documentao colaborativa do projeto que est sendo gerenciado. O Wiki um mecanismo que serve para a edio colaborativa do contedo de um documento que fica disponvel para acesso atravs de um navegador Web a qualquer momento. Esse mecanismo tambm possibilita a referncia 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 pgina de declarao formal de demanda (DFD), onde so descritos os requisitos e outras informaes relativas ao projeto. A pgina 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 marcao HTML, o que facilita e encoraja as pessoas a contriburem para o contedo dessas pginas utilizando essa linguagem. importante lembrar que aps a confirmao da edio da pgina em linguagem Wiki, produzido um texto formatado em HTML como sada. A figura 4 apresenta alguns cdigos Wiki bsicos, para dar uma ideia do funcionamento da linguagem.

FIGURA 4 FORMATAO WIKI DO TRAC FONTE: http://trac.edgewall.org/wiki/WikiFormatting A ferramenta Trac pode ser integrada com o Subversion sistema de controle de verso, que ser detalhado no item 2.3 deste documento e funciona como um browser para a ferramenta. Atravs do Trac, possvel manipular as pastas sob controle de verso, visualizar logs de mudana nos arquivos, diferena entre revises, entre outros (OLIVEIRA, 2010). A figura 5 mostra o Trac sendo utilizado em conjunto com a ferramenta de controle de verso Subversion (SVN), que ser mostrada com mais detalhes no item 2.3 descrito na pgina 22 deste documento. Note que possvel visualizar e navegar pelos diretrios sob controle de verso. O Trac controla tambm as revises dos arquivos, e cada commit do SVN pode ser atrelado a um ticket do Trac para facilitar a organizao e a

24 manuteno do cdigo, bem como para rastrear possveis inconsistncias no projeto devido a alteraes equivocadas.

FIGURA 5 UTILIZAO DO TRAC EM CONJUNTO COM O SUBVERSION FONTE: Trac Prognus, 2011, https://dev.prognus.com.br/expresso/browser/expresso/trunk

A partir da verso 0.9 possvel implementar plug-ins para a ferramenta Trac. Esses plug-ins so 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 criao do Trac. O Trac faz a busca por plug-ins no diretrio plugins/ no local da instalao da ferramenta. Esses plug-ins tambm podem ser instalados atravs da interface de administrao fornecida pela ferramenta. Essa tela e a instalao do plug-in sero comentados no item 5.4 que trata especificamente da instalao de plug-ins no Trac. A possibilidade de flexibilidade de personalizao 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 mudanas, como a funcionalidade de tickets que representa uma tarefa do projeto. Na tabela 4, so apresentadas as principais propriedades da ferramenta Trac
9

Linguagem de programao. Mais informaes podem ser encontradas no site oficial da linguagem: http://python.org/

25 (OLIVEIRA, 2010).

Trac Wiki Trac Timeline Trac Browser Trac Changeset Trac Revisionlog Trac Tickets Trac Reports Trac Roadmap
FONTE: Oliveira, 2010.

Contm toda a documentao dos projetos Histrico de desenvolvimento do projeto Cdigo-fonte mostrado em estrutura de pastas do projeto Alteraes do projeto Logs das revises do projeto Representao e distribuio das tarefas Relatrios do projeto Progresso do projeto

TABELA 4 PROPRIEDADES DO TRAC

2.3 SUBVERSION O Subversion um sistema de controle de verso open source. que gerencia arquivos e diretrios e as modificaes realizadas neles ao longo do tempo. Isso permite recuperar uma verso antiga dos dados que esto sob controle de verso bem como examinar o histrico das alteraes dos arquivos e diretrios (SVNBOOK, 2007). O Subversion (SVN) mantido pela Apache Software Foundation10, que permite armazenar documentos efetuando controle de acesso ao repositrio e mantendo um controle de revises desses documentos. Seu desenvolvimento iniciou-se no ano 2000, tendo como objetivo construir um software de controle de verso melhor que a principal opo disponvel 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 esto contidas no Subversion, o que facilita a migrao entre os sistemas. As principais melhorias em relao ao CVS foram o controle de diretrios uma vez que o CVS somente controlava arquivos as operaes atmicas de commit possibilitando que, caso ocorra alguma falha durante o commit, todo o processo seja desfeito, evitando inconsistncias compatibilizao com arquivos binrios e o uso mais eficiente da rede (DIAS, 2011). O repositrio do Subversion pode ser acessado de diferentes modos: desde o disco local at utilizando protocolos de rede. Independente da forma que ser acessado, a localizao desse repositrio sempre representada atravs de uma URL. A tabela 5
10 11

http://www.apache.org/ http://svn.debian.org/ 12 http://websvn.kde.org/

26 apresenta os principais mtodos de acesso ao repositrio Subversion.

Esquema file:/// http:// https:// svn:// svn+ssh://


Fonte: Dias, 2011

Mtodo de acesso Acesso direto ao repositrio por meio de disco local Acesso via protocolo WebDAV atravs do servidor Apache http com segurana SSL Acesso pelo svnserve Acesso pelo svnserve usando tnel SSH

TABELA 5 MTODOS DE ACESSO AO REPOSITRIO SUBVERSION

Os dados que sero mantidos sob controle de verso so armazenados em um repositrio, que acessado atravs de uma URL. Embora existam diversas combinaes possveis de configurao de servidor e plataforma para usar como um repositrio, 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 so mantidos os arquivos no repositrio, identificados por uma URL e os computadores clientes so os usurios que de utilizam os documentos do repositrio. Os documentos so recuperados do repositrio pelos clientes e armazenados localmente, na operao de checkout. Esses documentos ficam sob controle de verso, e suas modificaes so controladas pelo SVN. O cliente pode enviar suas modificaes para o repositrio, utilizando a funo de commit. Como vrios clientes podem estar trabalhando nos mesmos dados ao mesmo tempo, o SVN tem um controle de conflitos, que determina onde uma alterao que causa conflito foi realizada e disponibiliza uma ferramenta de merge, que mescla as alteraes nos arquivos feitas pelos clientes automaticamente. A cada commit gerada uma reviso, que um ponto de referncia na rvore do repositrio. possvel o cliente visualizar o contedo de um documento em qualquer reviso, e pode tambm atualizar seus documentos com as modificaes do repositrio com a funo de update. A qualquer momento, o cliente pode verificar o status de sua cpia de trabalho, com a funo status disponibilizada pelo SVN. Caso os documentos de trabalho estejam desatualizados, o cliente pode utilizar o update para incorporar as modificaes que foram realizadas aps a data do seu checkout do repositrio. Na tabela 6 so apresentados os principais comandos do Subversion (SVNBOOK, 2007).

27

Comando Checkout Status Commit Add Delete Revert

Atalho Co St Ci

Ao Faz um download do repositrio e cria uma cpia de trabalho Mostra alteraes da cpia de trabalho Envia alteraes da cpia de trabalho para o servidor Adiciona novos arquivos ao repositrio Remove arquivos do repositrio Volta arquivo da cpia de trabalho para ultima verso baixada do repositrio Atualiza para ultima verso do repositrio Mostra ajuda

Exemplo svn co https://dev.prognus.com.br/ /expresso/trunk svn status svn ci -m "Informao sobre commit" svn add foo.c svn del foo.c svn revert -R1177 .

Rm

Update Help

Up

svn update svn help

TABELA 6 PRINCIPAIS COMANDOS SVN


Fonte: SVNBOOK, 2007.

2.4 GERNCIA 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 modificaes 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 mudanas 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 comear assim que um esboo da verso do documento de requisitos estiver disponvel. (SOMMERVILLE, 2003, p. 118)

Segundo (VILA E SPNOLA, 2007), o processo de gerncia de requisitos a atividade de administrar os requisitos ao longo do tempo do projeto. De acordo com (SOFTEX, 2009), a gerncia 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. Tambm deve

28 controlar e tratar as mudanas nos requisitos durante o desenvolvimento. A gesto dos requisitos do sistema comea com a identificao 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 esto sempre mudando, pois geralmente so desenvolvidos para lidar com problemas intrincados. E como no pode ser definido inteiramente o problema, seus requisitos so necessariamente incompletos (SOMMERVILLE, 2003). Os requisitos de software focalizam a ateno 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 definio de requisitos do sistema continua sendo desenvolvida, uma melhor compreenso da necessidade dos usurios alcanada, causando modificaes nos requisitos (SOMMERVILLE, 2003). Segundo (FILHO, 2005), no deveria haver a necessidade de alterao nos requisitos ao longo do projeto, caso fosse possvel realizar os fluxos de requisitos e anlises de forma perfeita. Na prtica, essas alteraes ocorrem devido a diversos fatores, que podem ser externos como alteraes na tecnologia, gerenciais e polticas, ou internos, como uma mudana no entendimento do problema por parte dos usurios finais do mesmo ou at mesmo pelos desenvolvedores do sistema. (VILA E SPNOLA, 2007) afirmam que softwares complexos esto sempre sendo modificados. Essas modificaes ocorrem por conta da natureza voltil dos requisitos, que sofrem influncia de diversos fatores, como mudanas externas, erros cometidos no levantamento de requisitos, entre outros. Grandes sistemas so geralmente necessrios para melhorar o status atual. O sistema existente pode ser um sistema manual ou desatualizado. Mesmo que essas dificuldades sejam conhecidas, mostra-se difcil prever que efeitos o sistema que foi aperfeioado ter sobre a organizao, e depois que os usurios finais se familiarizam com o sistema, novos requisitos surgem (SOMMERVILLE, 2003). Isso acontece pelas seguintes razes: Os grandes sistemas geralmente tem uma comunidade diversificada de usurios. Esses diferentes usurios tem diferentes requisitos e prioridades, que podem ser contraditrios. Os requisitos finais do sistema so uma conciliao entre eles e, com a experincia, diversas vezes contatado que o equilbrio do apoio dispendido para diferentes usurios precisa ser modificado;

29 As pessoas que pagam pelo sistema dificilmente so a mesma pessoa que vai utilizar o mesmo. Os clientes do sistema impem os requisitos em funo de restries oramentrias e organizacionais. Esses requisitos podem ser conflitantes com os requisitos dos usurios finais, que realmente fazem uso do sistema; A empresa e o ambiente tcnico se modificam, e isso deve ter impacto no prprio sistema. A prioridade da empresa pode ser modificada, acarrentando consequentes mudanas no suporte necessrio ao sistema, e tambm novas legislaes e regulamentos podem ser criados, o que certamente dever ser implementado pelo sistema. Os requisitos no funcionais so, particularmente, afetados por mudanas na tecnologia de hardware. Ainda de acordo com (SOMMERVILLE, 2003), o gerenciamento de requisitos o processo de compreender e controlar as mudanas 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 esboo da verso do documento de requisitos.

FIGURA 6 EVOLUO DOS REQUISITOS


FONTE: Sommerville, 2003, pag. 119

A figura 6 ilustra a evoluo dos requisitos do sistema com o passar do tempo. Os requisitos iniciais geralmente mudam com o aperfeioamento da compreenso do problema. Levando em considerao uma perspectiva de evoluo, podemos dividir os requisitos em duas classes de requisitos: Requisitos permanentes e requisitos volteis (SOMMERVILLE, 2003). Os requisitos permanentes so os requisitos estveis, que derivam da atividade

30 principal da organizao e que se relacionam diretamente com o domnio do problema. Podemos citar como exemplo um sistema de controle de estoque onde sempre haver requisitos relacionados aos produtos, aos funcionrios da empresa, s vendas, s entradas, entre outros. Segundo (SOMMERVILLE, 2003), esses requisitos podem ser derivados dos modelos de domnio, que mostram as entidades e os relacionamentos que caracterizam um domnio de aplicao. Os requisitos volteis se referem aos requisitos que provavelmente vo ser modificados durante o desenvolvimento do sistema, ou depois que o sistema estiver em operao. Podemos citar como exemplos requisitos resultantes de polticas

governamentais sobre determinada rea. Os requisitos volteis so organizados em quatro classes (SOMMERVILLE 2003 apud HARKER et al 1993), como demonstrado na tabela 7.

Tipos de requisitos
Requisitos mutveis

Descrio
Requisitos que mudam devido a mudana no ambiente no qual o organizao est operando. Por exemplo, em sistemas, o financeiro do tratamento de paciente pode mudar e, assim exigir que informaes de diferentes tratamentos sejam coletadas. Requisitos que surgem medida que a compreenso do sistema pelo cliente progride durante o desenvolvimento do sistema. O processo de projeto pode revelar novos requisitos emergentes. Requisitos que resultam da introduo do sistema de computador. A introduo do sistema de computador pode mudar os processos da organizao e criar novas formas de trabalho que geram nova requisitos de sistema. Requisitos que dependem de sistema ou processos de negcios especficos dentro de uma organizao. medida que eles mudam, os requisitos de compatibilidade do sistema encomendados ou entrega podem tambm evoluir.

Requisitos emergentes

Requisitos conseqncia

Requisitos de compatibilidade

TABELA 7 - CLASSIFICAO DE REQUISITOS VOLTEIS


Fonte: Sommerville, 2003, p. 119

O gerenciamento de alteraes nos requisitos deve ser aplicado a todas as propostas para os requisitos. Deve se utilizar um mtodo formal, com a vantagem de que todas as propostas de mudanas sejam tratadas de modo consistente e feitas de forma controlada. A figura 7 representa os trs principais estgios em um processo de gerenciamento de mudanas.

31

FIGURA 7 ESTGIOS DO PROCESSO DE GERENCIAMENTO DE MUDANAS DE REQUISITOS


FONTE: Sommerville, 2003, pag. 122

No estgio de Anlise do problema e especificao da mudana, o processo se inicia com a identificao do problema com os requisitos, ou algumas vezes com a proposta especfica de mudana. Nessa fase, realizada a anlise do problema ou da proposta de mudana, para verificar se a mesma vlida. Para se analisar o efeito da mudana proposta, utilizam-se informaes sobre o conhecimento geral dos requisitos do sistema. O custo dessa mudana estimado em termos das modificaes do documento de requisitos. Quando essa anlise concluda, a deciso sobre prosseguir ou no com a alterao de requisito ou no tomada. As mudanas ocorrem efetivamente no estgio de implementao de mudanas onde so modificados os documentos de requisitos e quando necessrio o projeto do sistema e a implementao (PRESSMAN, 2006) afirma que existem muitos tipos de tabelas de rastreamento possveis para gerenciar os requisitos do sistema. So elas: rastreamento de caractersticas, que mostra como os requisitos se relacionam s caractersticas importantes do sistema observados pelo cliente; rastreamento de fontes que identifica a fonte de cada requisito; rastreamento de dependncia, que indica como os requisitos esto 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 relaes entre requisitos e outros requisitos entre os requisitos do projeto do sistema. H tambm elos entre os requisitos e as razes bsicas da proposio desses requisitos. Quando so propostas modificaes, preciso verificar o impacto dessas mudanas sobre os outros requisitos e o projeto do sistema. (SOMMERVILLE, 2003, p. 120)

As informaes de rastreabilidade so, com frequncia, representadas por

32 matrizes de rastreabilidade (SOMMERVILLE, 2003). (SOFTEX, 2009) afirma que para apoiar o processo de mudana 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 relao dos componentes entre conjuntos de produtos de trabalho. Por exemplo, cada componente do projeto tem seus artefatos rastreados at chegar ao cdigo que implementa essa funcionalidade. J a rastreabilidade vertical expressa a relao entre as partes do produto de trabalho pertencentes ao mesmo artefato, como por exemplo a interdependncia entre os requisitos do sistema (PFLEEGER, 2004). Segundo (PRESSMAN, 2006), em muitos casos essas tabelas de rastreamento so mantidas como parte do mesmo banco de dados dos requisitos, de modo que ela possa ser pesquisada rapidamente e para que seja possvel entender como a modificao 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

1.3

2.1

2.2

2.3 X

3.1

3.2

X X X X X X X X X

TABELA 8 MATRIZ DE RASTREABILIDADE VERTICAL


Fonte: Sommerville, 2003, p. 120

A tabela 8 ilustra a representao de uma matriz de rastreabilidade vertical que identifica as interdependncias entre os requisitos de um sistema. Como podemos perceber, para sistemas com poucos requisitos a rastreabilidade da interdependncia entre eles pode no ser to necessria. (SOMMERVILLE, 2003) afirma que o apoio de uma ferramenta para o gerenciamento de facilidade de rastreamento permite que sejam descobertos requisitos relacionados. Essa ferramenta tambm pode auxiliar no armazenamento dos requisitos e no gerenciamento das mudanas dos mesmos. Segundo (SOMMERVILLE, 2003):

33

Para sistemas pequenos, pode no ser necessrio utilizar ferramentas especializadas de gerenciamento de requisitos. Esse processo pode ter apoio utilizando os recursos disponveis em processadores de texto, planilhas de clculo e bancos de dados de PCs. Contudo, para sistemas maiores, o apoio de ferramentas mais especializadas necessrio. (SOMMERVILLE, 2003, p. 121)

Tambm para (PRESSMAN, 2006) a gesto formal dos requisitos indicada somente para grandes projetos, geralmente com mais de 100 requisitos identificveis. Para projetos pequenos, essa funo de gerncia de requisitos consideravelmente menos formal. Se a rastreabilidade for um fator de qualidade enfatizado desde o incio do projeto, a documentao se tornar mais clara e consistente, ser obtido um melhor entendimento entre o pessoal de projeto, as entradas no projeto sero mais direcionadas e a manuteno do produto ser menos dependente de especialistas individuais (PFLEEGER 2004 apud LINDVALL e SANDAHL). A importncia de uma ferramenta que auxilie na criao dessa rastreabilidade destacada por (PFLEEGER, 2004) que afirma que alguns de seus trabalhos sobre rastreabilidade exigiram muito esforo, como rastrear itens de dependncia sem o apoio de ferramentas para rastrear links e rastrear modelos que sejam parcialmente inconsistentes ou pouco documentados. O captulo de reviso bibliogrfica apresentou os principais itens que sero abordados durante todo o trabalho. Este captulo serve como embasamento terico de toda a implementao do mesmo, desde a modelagem at a implementao e anlise dos resultados. Primeiramente foi abordado o MPS.BR, melhoria de processo de software, criado para ser implementado por pequenas e mdias empresas no lugar da certificao CMMI. Essa certificao 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 importncia de um captulo explicando seu funcionamento. Em seguida apresentou-se o Subversion, ferramenta de controle de verso e que muitas vezes utilizada junto com o Trac para o gerenciamento de projetos. O item 2.4 explicou a gerncia de requisitos, um dos itens do nvel G do MPS.BR, que abrange tambm a gerncia de projetos.

34 Na gerncia de requisitos, foram tratados os principais conceitos relacionados a requisitos, criando o embasamento terico necessrio para o prosseguimento dos trabalhos. Para iniciar o desenvolvimento dos trabalhos, ficou evidente a necessidade de adoo de uma metodologia de desenvolvimento de software. Devido s caractersticas do trabalho, mostrou-se mais apropriado o estudo das principais metodologias geis disponveis atualmente para, assim, adotar a mais adequada para o desenvolvimento deste trabalho.

35 3 METODOLOGIA

Esse captulo apresenta as principais metodologias de desenvolvimento gil disponveis atualmente. Na sequncia, apresentamos a metodologia escolhida para o desenvolvimento do projeto e suas caractersticas, bem como particularidades e adaptaes 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 burocrticas 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 prtica de projetar o sistema todo para s ento iniciar a implementao obsoleta para o cenrio atual de desenvolvimento. muito difcil prever com antecedncia todos os detalhes de um sistema, devido s condies mutveis de mercado e a frequente evoluo das necessidades dos usurios (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 prprias teorias sobre a maneira de desenvolver software, entraram em acordo e criaram o Manifesto gil para o desenvolvimento de software, contendo quatro princpios:

36 Indivduos e suas interaes acima de procedimentos e ferramentas; O funcionamento do software acima de documentao abrangente; A colaborao dos clientes acima da negociao de contratos; A capacidade de reposta s mudanas acima de um plano pr-estabelecido.

Esse

manifesto

no

descarta

as

ferramentas

documentao

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 utilizao de pequenos e constantes incrementos de software, e para isso, necessita que o feedback do cliente seja feito o mais rpido possvel. Os itens a seguir apresentaro algumas das principais metodologias geis disponveis atualmente, seus mtodos de trabalho e seus princpios e valores. Analisando as principais metodologias geis possvel escolher a metodologia que se adqua 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 criao de sistemas de melhor qualidade, demandando menos tempo e menos recurso financeiro que os habituais mtodos tradicionais. (PRESSMAN, 2006) afirma que as ideias e mtodos de Extreme Programming foram abordados pela primeira vez na dcada de 1980, mas s ganharam notoriedade quando Kent Beck fez uma publicao 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 prticas que ocorrem no contexto de quatro atividades de arcabouo: planejamento, projeto, codificao e teste. (PRESSMAN, 2006). A figura 8 ilustra o processo do mtodo Extreme Programming e apresenta algumas das ideias-chave e tarefas que esto associadas.

37

FIGURA 8 O PROCESSO DE EXTREME PROGRAMMING


FONTE: Pressman, 2006, pag. 64

Na atividade de planejamento inicia-se a criao de um conjunto de histrias que descrevem as caractersticas e funcionalidades requeridas para o software que ser desenvolvido. Cada histria escrita pelo cliente e colocada em um carto de indexao. Este atribui um valor para essa histria com base no valor de negcio global da caracterstica ou da funo. Aps isso, os membros da equipe XP avaliam cada histria e atribuem um custo para a mesma, custo esse medido em semanas de desenvolvimento. Caso essa histria necessite de mais de trs semanas de desenvolvimento, solicitado que o cliente divida-a em partes menores e realizada a atribuio de valor e custo para a histria novamente. Os clientes e a equipe XP trabalham juntos para decidir como agrupar histrias na verso seguinte a ser desenvolvida pela equipe (PRESSMAN, 2006). Uma vez feito o compromisso bsico para a verso, ou seja, as histrias que sero entregues, a equipe XP determina as histrias que sero implementadas em um dos trs modos que seguem: (1)Todas as histrias sero implementadas imediatamente, ou seja, dentro de poucas semanas; (2) as histrias com valor mais alto sero antecipadas; (3) as histrias de maior risco sero antecipadas. (PRESSMAN, 2006) Aps a primeira verso do projeto, tambm chamada de incremento de software,

38 ter sido entregue, a equipe XP calcula a velocidade do projeto, que a quantidade de histrias do cliente implementadas na primeira verso da implementao. Essa velocidade serve tanto para ajudar a estimar as datas de entrega e o cronograma para as prximas verses quanto para determinar se um comprometimento excessivo foi feito para todas as histrias ao longo do projeto. Caso ocorra um comprometimento excessivo, o contedo das verses ser modificado ou as datas de entrega sero alteradas. Durante o desenvolvimento o cliente pode tambm adicionar histrias, mudar o valor de uma histria existente, subdividir histrias 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 princpio KIS (Keep it simple mantenha simplicidade). sempre prefervel um projeto simples em relao a uma representao mais complexa. Caso um problema de projeto difcil seja encontrado como parte de um projeto de uma histria, a metodologia recomenda que seja criado um prottipo operacional daquela parte do projeto, com a inteno de diminuir o risco quando a implementao verdadeira comea e validar as estimativas originais correspondentes histria que contm o problema. Essa etapa de projeto acontece tanto antes quanto depois da fase de codificao do sistema. De fato, a atividade de codificao vai fornecer diretrizes equipe XP sobre como aperfeioar o projeto (PRESSMAN, 2006). Aps a etapa de projeto inicia-se a fase de codificao do projeto. A metodologia recomenda que depois que as histrias forem desenvolvidas e o trabalho preliminar do projeto tenha sido feito, a equipe no avance diretamente para o cdigo, mas sim que crie testes unitrios referentes cada uma das histrias que devem ser includas na verso atual. Com os testes unitrios criados, o desenvolvedor est melhor preparado para focalizar o que precisa ser implementado para passar nesse teste. Uma vez que esse cdigo implementado, o mesmo pode ser submetido para os testes unitrios (PRESSMAN, 2006). Durante essa etapa de codificao aplicado um conceito-chave da metodologia: a programao em pares. O XP recomenda que duas pessoas trabalhem juntas na mesma estao de trabalho para a implementao de uma histria. Isso fornece um mecanismo de soluo de problemas em tempo real, e mantm os desenvolvedores focados no problema em mos, alm de garantir a qualidade do programa em tempo real. Na prtica, as pessoas envolvidas assumem diferentes papis, como por exemplo um dos integrantes poderia pensar em detalhes de cdigo enquanto outro integrante garante que as normas de codificao estejam sendo seguidas (PRESSMAN, 2006).

39 Por fim, existe uma etapa de testes, onde so feitos os testes de integrao e de validao do sistema, uma vez que os testes unitrios so criados na etapa de codificao. medida que os testes unitrios vo sendo organizados, os testes de integrao e validao podem ocorrer diariamente. Isso fornece equipe uma indicao de progresso contnua e pode alertar caso as coisas no estejam correndo como o esperado (PRESSMAN, 2006). O Extreme Programming regido por cinco valores principais, seguidos por princpios bsicos. So eles: Comunicao; Simplicidade; Feedback; Coragem; Respeito.

fato que muitas das ideias que compe o Extreme Programming fazem parte do senso comum, com a diferena que a palavra Extreme significa que essas ideias devem ser levadas realmente ao mximo (PRESSMAN, 2006 apud BECK). Dentre essas ideias encontra-se:

Revisar o cdigo a todo momento (programao em pares); Testar o cdigo o tempo todo (testes de unidade), mesmo os requisitos do cliente (testes funcionais); Melhorar a modelagem do sistema com refatorao de cdigo; Simplificar ao mximo a modelagem do sistema; Definir e melhorar a arquitetura sempre; Integrar e testar vrias vezes por dia; Iteraes com duraes curtas, as mais curtas possveis.

3.3 SCRUM

O Scrum um modelo gil de processo, desenvolvido por Jeff Shutterland 13 e sua

13

http://jeffsutherland.com/

40 equipe no incio da dcada de 1990. Os princpios utilizados em Scrum so consistentes com o manifesto gil, apresentado no item 3.1 (PRESSMAN, 2006). De acordo com (PRESSMAN, 2006), esses princpios so:

Pequenas equipes de trabalho so organizadas de modo a maximizar a comunicao, minimizar a superviso e maximizar o compartilhamento de conhecimento;

O processo precisa ser adaptvel tanto a modificaes tcnicas quanto de negcios, para garantir que o melhor produto possvel 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 parties claras, com baixo acoplamento, ou em pacotes; Testes e documentao constantes so realizados medida que o produto construdo;

A metodologia Scrum divide os projetos em ciclos menores, chamados de Sprints. O trabalho conduzido dentro de um Sprint adaptado ao problema em mos e definido e, frequentemente, modificado em tempo real pela equipe Scrum. A quantidade de Sprints necessrias para uma atividade varia dependendo da complexidade e do tamanho do produto (PRESSMAN, 2006). Os requisitos que sero implementados pela equipe so definidos no Backlog do produto. Os requisitos do Backlog do Produto so priorizados pela equipe, e so definidos quais deles entraro na prxima Sprint do projeto. Os requisitos escolhidos so ento transferidos para o Backlog do Sprint, que nada mais do que os itens que devero ser desenvolvidos nesse ciclo. Segundo (SCHWABER, 2004), o Scrum dividido em trs papis principais: Product Owner (PO), Scrum Master e Time. O Product Owner define as funcionalidades do produto, as datas de lanamento e o contedo e responsvel pelo controle do retorno de investimento (ROI Return Of Investiment). o Product Owner tambm 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 responsvel pelo desenvolvimento das funcionalidades. No Scrum, os Times so auto-organizados e multifuncionais. Todos os membros so

41 coletivamente responsveis pelo sucesso de cada Sprint e do projeto como um todo. A recomendao que um Time no tenha mais que 9 pessoas (SCHWABER, 2004). O Scrum Master responsvel pelo processo de desenvolvimento, treinamento dos envolvidos no projeto e na aplicao dos valores da metodologia Scrum. Ele representa um gerente de projetos, removendo obstculos 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 representao de um esquema bsico de funcionamento da metodologia Scrum. O Backlog do produto contm todos os requisitos do sistema que deve ser desenvolvido. A equipe define a prioridade dos requisitos, e define quais faro parte da prxima Sprint. Com isso, os requisitos so transferidos para o Backlog da Sprint, e so 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 reunio rpida diria a Daily Scrum. Essa reunio feita preferencialmente de p para garantir que no vai levar muito tempo e os participantes respondem trs questes principais: (1) O que voc fez desde a ltima reunio de equipe? (2) Que obstculos voc est

42 encontrando? (3) O que voc planeja realizar at a prxima reunio de equipe? Isso garante que a equipe esteja sempre bem informada sobre o que deve ser feito, bem como o que os outros companheiros esto desenvolvendo e possveis dificuldades e limitaes que esto enfrentando (PRESSMAN, 2006). Ao fim de cada Sprint, a metodologia define uma reunio de retrospectiva, onde cada membro da equipe reflete e discute sobre a Sprint passada, as possveis dificuldades e acertos da equipe e as lies que podem ser usadas para desenvolvimentos futuros.

3.5 CRYSTAL

O Mtodo Crystal uma famlia 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 dcada 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 princpio que pessoas no consideram fcil seguir metodologias disciplinadas e rgidas. Com isso, a ideia de ter um mtodo menos rgido, 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 caractersticas da equipe e seus membros. Fazendo uma comparao com o mtodo gil XP (Extreme Programming), podemos considerar o mtodo Crystal menos produtivo, porm por ser menos rgido e disciplinado, mais desenvolvedores estaro aptos a segu-lo. Uma das caractersticas mais importantes no mtodo Crystal so as revises no final de cada uma das iteraes, 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 famlia de mtodos 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 nmero de participantes na
14

http://www.ibm.com

43 equipe, atribuda uma cor a ela. Alm disso, o membro da famlia 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 mximo de durao do projeto relacionado com cada cor atribuda s equipes (FOWLER, 2003).

C (confort) D (discret) E (essential) L (life)


FONTE: Fowler, 2003.

Perda de dinheiro no substancial, com recuperao confortvel Perda discreta (sutil) de dinheiro. Perda essencial (substancial) de dinheiro. Possvel perda de vidas.

TABELA 9 LETRAS E SEUS SIGNIFICADOS NA METODOLOGIA CRYSTAL

Clear Yellow Orange Red

4 meses No definido 2 anos No definido

TABELA 10 TEMPO DE DURAO DOS PROJETOS EM FUNO DO NMERO 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. Ento, pensando nisso, podemos ter uma combinao de possveis projetos, com tamanhos e complexidades diferentes. Quanto maior o tamanho da equipe, mais complexo e burocrtico fica o gerenciamento da mesma, e quanto mais crtico o projeto maior a necessidade de coordenao e metodologias mais pesadas para o desenvolvimento. Podemos visualizar melhor essas possibilidades na figura 10 que ilustra os possveis tipos de projeto e suas complexidades, fazendo uma relao 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 prticas, que so (PEDROSA, 2006): Staging: Planejamento do prximo incremento do sistema. A equipe seleciona os requisitos que sero implementados nessa iterao e tambm define os prazos para a entrega desses requisitos; Edio e reviso: Construo, demonstrao e reviso dos objetivos do incremento atual do sistema; Monitoramento: O processo monitorado com relao ao progresso e estabilidade da equipe de desenvolvimento. Paralelismo e fluxo: Em Crystal Orange as diferentes equipes podem operar com o mximo paralelismo. Isto possvel atravs do monitoramento da estabilidade e da sincronizao entre as equipes distintas do projeto; Inspees de usurios: Sugeridas duas ou trs inspees feitas por usurios a cada incremento do sistema; Workshops refletivos: Reunies que ocorrem antes e depois de cada iterao com objetivo de analisar o progresso do projeto; Produtos de Trabalho: Sequncia de lanamento, modelos de objetos comuns, manual do usurio, casos de teste e migrao de cdigo;

45 Padres: Padres de notao, convenes de produto, formatao e qualidade usadas durante o projeto que est sendo desenvolvido; Tools: Ferramentas mnimas utilizadas para o desenvolvimento dos projetos, como ferramentas de controle de verso, teste, comunicao, entre outras.

FIGURA 11 CICLO DE VIDA DA FAMLIA CRYSTAL FONTE: Pedrosa, 2006.

A figura 11 ilustra o ciclo de vida da famlia de metodologia Crystal e as relaes entre as prticas da metodologia.

3.6 ESCOLHA E UTILIZAO DA METODOLOGIA SCRUM NO PROJETO

Para este projeto, a metodologia gil escolhida foi a metodologia Scrum, pois aps a anlise das principais metodologias geis disponveis 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 so coletivamente responsveis pelo sucesso de cada Sprint e do projeto como um todo. O prprio conceito de Sprint, a diviso do trabalho em diversas etapas com entregas regulares, a facilidade de adaptao s reunies frequentes e s alteraes do processo e de acompanhamento, que faz com que o Time esteja sempre atualizado sobre o andamento do projeto como um todo. Essas informaes so explicadas mais detalhadamente no item 3.3 deste documento. Um dos itens previstos na metodologia Scrum a existncia de um lder na equipe, uma espcie 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, no foi definido nenhum papel de liderana entre os integrantes, ou seja, no escolhemos um integrante para o papel de Scrum Master, portanto a aplicao dos valores da metodologia Scrum, a remoo de obstculos 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 construo da ferramenta. Devido a impossibilidade de realizar de maneira efetiva a Daily Scrum reunio diria proposta pela metodologia Scrum - as reunies presenciais foram definidas com periodicidade semanal, toda sexta-feira, nas dependncias da Faculdade Anglo Americano. Nessas reunies eram respondidas as trs questes principais definidas pela metodologia para as Daily Scrum: (1) O que voc fez desde a ltima reunio de equipe? (2) Que obstculos voc est encontrando? (3) O que voc planeja realizar at a prxima reunio de equipe? Tambm nessa reunio eram tratadas as dvidas e as adequaes de escopo e prazo para o desenvolvimento do sistema. Reunies de acompanhamento tambm foram definidas, e eram realizadas a cada dois dias atravs de sistema de comunicao instantnea online, utilizando a ferramenta de comunicao gtalk, do Google. Essas reunies aconteciam no incio do dia, onde todos os membros da equipe realizavam o alinhamento das atividades, tambm seguindo as trs questes principais, citado anteriormente. Para o primeiro Sprint do projeto, foram escolhidos para o Sprint Backlog os requisitos relacionados ao estudo da gerncia de requisitos, para que a equipe pudesse ter o embasamento terico necessrio para o incio 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 gerncia de requisitos. Esses documentos e anotaes foram utilizados em todo o projeto, principalmente no item de reviso bibliogrfica. Para a segunda Sprint, os requisitos escolhidos para o Backlog do ciclo tambm eram de pesquisa. O resultado esperado dessa Sprint era a gerao do documento terico 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 documentao que foi utilizada para a criao do item sobre MPS.BR na reviso bibliogrfica do documento. O acompanhamento dos requisitos do sistema, o Backlog do produto, era feito em uma pgina 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 so apresentados os requisitos do trabalho, bem como suas respectivas Sprints.

3.7 BACKLOG DO PROJETO E DEFINIO DAS SPRINTS

Como apresentado no item 3.3, o Backlog do projeto contm os requisitos que devem ser implementados para a finalizao do projeto e o Backlog da Sprint nada mais do que os itens que devero ser desenvolvidos em cada ciclo, ou Sprint. Segundo apresentado no item 2.3 que tratava de gerenciamento de requisitos, os requisitos so primeiramente identificados de modo nico neste caso, por um ID do requisito para que possa facilitar a utilizao desse requisito em tabelas de rastreamento posteriormente no projeto. Note que como se trata de um projeto com poucos requisitos, no foi necessria a aplicao de uma rastreabilidade nesses requisitos. Como citado no item 2.4, para projetos com menos de cem requisitos no indicado uma gesto formal dos mesmos, uma vez que h poucos ganhos nessa gesto formalizada nesse tipo de projeto (PRESSMAN, 2006).

ID requisito R1 R2 R3

Sprint Backlog - Documento de gerncia de requisitos Requisito Tempo Levantar literatura sobre o assunto 3 dias Estudar os documentos levantados 6 dias Gerar documento de gerncia de requisitos 6 dias

48
Sprint Backlog - Documento MPS.BR Requisito Levantar literatura sobre o assunto 3 dias Estudar os documentos levantados 6 dias Gerar documento sobre MPS.BR 6 dias Sprint Backlog - Documento Trac e Subversion Requisito Levantar literatura sobre o assunto 3 dias Estudar os documentos levantados 6 dias Gerar documento sobre Trac e Subversion 6 dias Sprint Backlog Modelagem do plug-in Requisito Levantar materiais modelagem UML 2 dias Estudo principais diagramas UML 6 dias Criar principais diagramas do plug-in 7 dias

ID requisito R4 R5 R6

Tempo

ID requisito R7 R8 R9

Tempo

ID requisito R10 R11 R12

Tempo

ID requisito R13 R14 R15

Sprint Backlog Ambiente de teste e desenvolvimento Requisito Tempo Pesquisar requisitos e dependncias 3 dias Instalao do Sistema operacional e programas 6 dias Teste do ambiente de desenvolvimento 6 dias Sprint Backlog Implementao plug-in Requisito Materiais linguagem python e plug-ins Trac 2 dias Estudo da linguagem python 4 dias Estudo API plug-ins Trac 6 dias Implementao plug-in 4 dias Teste e correes do plug-in 4 dias Sprint Backlog Aplicao e anlise do plug-in Requisito Instalao plug-in Prognus 2 dias Aplicao em projetos reais 10 dias Documento de anlise dos resultados 3 dias

ID requisito R16 R17 R18 R19 R20

Tempo

ID requisito R21 R22 R23

Tempo

ID requisito R24 R25

Sprint Backlog Concluses do trabalho Requisito Tempo Gerar documento de concluses 10 dias Trabalhos futuros 5 dias

Buscando padronizar o tempo de cada Sprint, foi levado em considerao uma mdia de 15 dias para cada ciclo. Alguns ciclos demandaram mais tempo, devido a complexidade dos requisitos contidos no Backlog da Sprint. Por deciso de projeto, cada requisito era desenvolvido por todos os integrantes do grupo, e no havia separao 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 execuo de cada requisito era feita na reunio de incio de cada Sprint. Cada um dos integrantes da equipe apresentava a quantidade de dias que imaginava ser necessrio para concluir a atividade e com isso era feita uma mdia das estimativas dadas pelos membros. Quando havia uma diferena muito grande entre as estimativas, o requisito era analisado para tentar identificar o motivo da diferena entre os entendimentos e a previso de trmino da tarefa.

50 4 MODELAGEM

Esse captulo 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 necessrios 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 deveramos desenvolver, e que serviriam de auxlio e base para a tarefa de implementao. Os diagramas foram criados utilizando o software Astah Community, disponvel para download gratuitamente no site da ferramenta16.

4.1 ARQUITETURA Trac

A partir da verso 0.9, o Trac permite que sejam desenvolvidos plug-ins para estender algumas outras funcionalidades, a fim de tornar o sistema mais flexvel permitindo a customizao de tarefas. Para isso, a ferramenta disponibiliza uma API para as extenses sejam desenvolvidas. Esses plug-ins devem ser implementados em forma de componentes, que so objetos que provm algum tipo de servio no contexto da aplicao. Em momento algum existir mais que uma instncia de cada componente, pois seguem o padro de projeto Singleton (EDGEWALL, 2011). Os componentes na verdade representam subsistemas funcionais, e podem implementar pontos de extenso para que sirvam de interface para outros plug-ins. Um mesmo componente pode estender vrios outros componentes e ainda assim oferecer seus prprios pontos de extenso. As funcionalidades do Trac so definidas pelos componentes individuais, e o kernel do componente responsvel em ligar os diferentes subsistemas, sem necessariamente conhecerem uns aos outros, funcionalidade conhecida como Magic Glue. A figura 12 ilustra a representao da arquitetura de componentes do Trac.
15

Unified Modeling Language (Linguagem de modelagem unificada). Documentao disponvel em http://www.uml.org/ 16 http://astah.net/.

51

FIGURA 12 REPRESENTAO 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 pginas Wiki. Para a manipulao desses componentes, o Trac disponibiliza algumas classes interfaces que devem ser implementadas pelos plug-ins. Neste trabalho, devido necessidade de manipulao das pginas wiki do Trac, as interfaces utilizadas foram a IWikiChangeListener, servindo como uma interface de ponto de extenso para os componentes que seriam processados durante a criao, edio ou deleo de uma pgina wiki e a IWikiPageManipulator que usada nos ps-processamento e prprocessamento das pginas wiki. A representao da implementao dessas interfaces detalhada no prximo item que trata da modelagem do plug-in.

4.2 MODELAGEM DO PLUG-IN

Para obter uma viso macro do sistema, o primeiro diagrama que foi desenvolvido foi o Diagrama de Caso de Uso. Nesse Diagrama, so apresentadas as funcionalidades do sistema do ponto de vista do usurio, e sua interao 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 responsvel pela anlise e parsing da pgina de declarao formal de demanda (DFD), bem como do gerenciamento dos avisos de dependncia de requisitos. Sempre que o caso de uso Gerar matriz for acionado pelo analista de sistemas, ser executado o caso de uso Analisar Pgina de declarao formal de demanda. Essa representao vista na figura 6 atravs do esteretipo include que liga os dois casos de uso. O plug-in tambm responsvel pela execuo do caso de uso Gerenciar avisos de dependncia, gerenciando as dependncias de requisitos e os avisos quando houver mudanas nos mesmos, como edio ou excluso. Esses avisos sero destinados ao analista de sistemas para que o mesmo tenha conhecimento de que os requisitos que est modificando apresentam alguma dependncia. No caso de edio de requisitos na pgina de declarao formal de demanda, a matriz de rastreabilidade criada novamente, levando em considerao a nova listagem de requisitos. Em seguida, o foco da anlise e modelagem se deu na implementao da

53 funcionalidade de parser, parte principal da nossa ferramenta. Para representar o fluxo da soluo da implementao, 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 visualizao e entendimento dos fluxos principais do sistema, auxiliando na implementao dos mesmos. Algumas das funcionalidades do sistema, como a criao e configurao da matriz de rastreabilidade, eram complexas, por isso mostrou-se necessrio a criao de diagramas que representassem o fluxo de processamento dessas partes em especfico.

54 Novamente, o diagrama escolhido para iniciar a representao 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 pseudocdigo referente criao e configurao da matriz de rastreabilidade vertical dos requisitos. O cdigo demonstra as repeties e as verificaes necessrias para a criao da matriz de rastreabilidade vertical. Detalhes do desenvolvimento dessas funcionalidades so demonstradas no captulo 5.3 que trata da implementao do parser.

FIGURA 15 PSEUDOCDIGO DA CRIAO DA MATRIZ DE RASTREABILIDADE VERTICAL Esse procedimento de criao da matriz de rastreabilidade disparado tambm no momento em que uma pgina de declarao formal de demanda atualizada. Ou seja, no momento da atualizao das informaes de uma DFD, a matriz de rastreabilidade recriada. Quando o usurio entre em modo de edio no Trac mas no efetua nenhuma mudana, a prpria ferramenta identifica esse comportamento e no faz uma requisio para salvar a pgina 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 dependncia. Para que o fluxo da soluo pudesse ser melhor visualizado e para facilitar a posterior implementao, foi criado um diagrama de atividades desse processamento. Esse diagrama est representado pela figura 16, que demonstra as atividades necessrias para o desenvolvimento dessa funcionalidade. Dando sequncia s atividades de modelagem do plug-in, percebeu-se a necessidade da criao das classes que so necessrias para o funcionamento da ferramenta. Para manipular e identificar alteraes nos componentes do Trac, a ferramenta disponibiliza algumas interfaces que devem ser implementadas pelos plug-ins. Neste trabalho, tornou-se necessrio a manipulao das pginas Wiki do Trac. Por isso, as interfaces utilizadas foram a IWikiChangeListener, servindo como uma interface de ponto de extenso para os componentes que seriam processados durante a criao, edio ou deleo de uma pgina Wiki e a IWikiPageManipulator que usada nos psprocessamento e pr-processamento das pginas wiki. Para utilizar essas interfaces, basta que a classe da ferramenta que far uso das mesmas implementem os mtodos existentes. Na figura 17 possvel perceber as duas interfaces implementadas pelo plug-in e seus mtodos. Neste trabalho, no foi necessrio utilizar todos os mtodos das interfaces implementadas, portanto os mtodos que no seriam utilizados tinham no corpo apenas a palavra-chave pass. A classe principal ParseWiki implementa as duas interfaces disponibilizadas pelo Trac para a manipulao de pginas Wiki. Essa classe realiza toda a verificao por padres na pgina de declarao formal de demanda, cria a matriz e gerencia os avisos de alterao nos requisitos com dependncia. Para seguir com a modelagem e mapear a sequncia das operaes do sistema, foi criado o diagrama de sequncia da atividade de criao da matriz de rastreabilidade. possvel observar que o analista de sistemas interage com a interface de criao da matriz, que no caso desse trabalho representado por um boto no final da pgina de declarao formal de demanda (DFD). O processamento segue por sua vez passando pela biblioteca BeautifulSoup, que faz a normalizao da pgina, e logo em seguida volta para o plug-in, que a anlise da pgina de DFD e a criao da matriz de rastreabilidade na pgina. Esse diagrama apresentado na figura 19.

56

FIGURA 16 DIAGRAMA DE ATIVIDADES DA EDIO DA LISTA DE REQUISITOS

57

FIGURA 17 DIAGRAMA DE CLASSES DO PLUG-IN

FIGURA 18 DIAGRAMA DE CLASSES REPRESENTANDO A RELAO ENTRE OS PACOTES Para o funcionamento do plug-in foi necessrio a utilizao de uma biblioteca externa, a BeautifulSoup. Essa biblioteca funciona como um normalizador do contedo HTML de uma pgina, transformando-a em uma rvore para que seja possvel manipular a pgina atravs de objetos DOM (Documment object model). Essa dependncia apresentada na figura 18, onde existe a relao entre o pacote principal da

58 implementao e a biblioteca externa BeautifulSoup.

FIGURA 19 DIAGRAMA DE SEQUNCIA DA CRIAO DA MATRIZ DE RASTREABILIDADE VERTICAL A biblioteca BeautifulSoup funciona como um parser de HTML/XML para Python que pode transformar at mesmo marcao invlida em uma rvore analtica. Ela prov um modo idiomtico de navegar, procurar e modificar a rvore de elemento, facilitando o processo de manipulao das pginas Web como objetos DOM, que fornece uma maneira padronizada de acesso aos elementos da pgina, permitindo trabalhar com cada um desses elementos separadamente. O plug-in tambm deve gerenciar as alteraes nos requisitos com

interdependncias. A figura 20 ilustra o diagrama de sequncia que representa a anlise da pgina de DFD, em busca dos requisitos alterados. O sistema verifica se nas alteraes existem itens com dependncias e caso essas dependncias sejam encontradas enviado um alerta para a tela, informando o usurio. A anlise da pgina de declarao formal de demanda feita atravs do mtodo ParseWiki. Esse mtodo recebe como entrada uma pgina normalizada, e realiza a

59 anlise conforme mostra a figura 14. Um diagrama de sequncia foi criado para representar as operaes que sero realizadas para a implementao dessa funcionalidade. Esse diagrama pode ser visualizado na figura 21.

FIGURA 20 DIAGRAMA DE SEQUNCIA DA FUNCIONALIDADE DE ALERTA PARA ALTERAO DE REQUISITOS COM DEPENDNCIA Neste captulo, as modelagens de sistema necessrias para a implementao do plug-in foram apresentadas. Esses diagramas servem como base para a fase de implementao, que ser detalhada no prximo captulo, facilitando a visualizao da soluo que deve ser implementada.

60

FIGURA 21 DIAGRAMA DE SEQUNCIA DA FUNCIONALIDADE DE ANLISE DA PGINA DE DFD

61 5 IMPLEMENTAO

Nesse

captulo

apresentaremos

implementao

do

plug-in

suas

funcionalidades, bem como as ferramentas utilizadas e detalhes de algoritmos e estruturas de dados usados na sua implementao.

5.1 INSTALAO E CONFIGURAO DO AMBIENTE

Para o desenvolvimento do plug-in, foi necessrio a instalao e configurao de um ambiente, com as ferramentas que seriam usadas no trabalho. O sistema operacional escolhido foi a distribuio GNU/Linux Ubuntu17, verso 11.04, instalado em uma mquina virtual com 1GB de memria RAM e 10GB de HD. A escolha desta distribuio deu-se devido sua estabilidade e por disponibilizar diversas bibliotecas e softwares utilitrios por padro em sua instalao. Aps a instalao do sistema operacional, foi feito o download do Trac e do servidor Web Apache que seria usado para o gerenciamento do acesso as pginas do sistema. Essa instalao foi feita utilizando a ferramenta apt-get18, disponibilizada pela distribuio Ubuntu e por todas as distribuies baseadas em Debian.

5.2 PADRES DE CONTEDO DA PGINA DE DECLARAO FORMAL DE DEMANDA

Como descrito no captulo 2.2, pgina 18, para cada projeto criado uma pgina de declarao formal de demanda (DFD). O preenchimento dessa pgina segue alguns padres, que so essenciais para o funcionamento correto do plug-in. Uma maneira de identificar uma pgina de declarao formal de demanda atravs do seu ttulo. O padro determina que todas as pginas de DFD tenham como primeira frase a palavra Declarao Formal de Demanda. Essa padronizao importante para diferenciar a pgina de DFD de outras pginas Wiki genricas, uma vez que para o Trac no h distino entre as pginas.
17 18

Disponvel para download em http://www.ubuntu.com Documentao disponvel em http://www.apt-get.org/

62 Na pgina de DFD so listados os requisitos de um projeto e suas interdependncias. Essa listagem tambm padronizada. Os requisitos so representados em uma lista, sempre iniciando pela letra R. As dependncias so representadas pelo identificador do requisito dependente entre colchetes. A figura 22 ilustra essas padronizaes.

FIGURA 22 PADRES DE REPRESENTAO DE CONTEDO DA PGINA DE DECLARAO FORMAL DE DEMANDA

No exemplo da figura 22, o requisito 1 (R01) tem dependncia com o requisito 2 (R02), e por isso deve ser criada uma relao de dependncia entre eles. Este padro foi definido de acordo com uma sugesto da equipe de avaliao do MPS.BR, para facilitar a visualizao e organizao dos requisitos e as dependncias entre eles.

63 5.3 IMPLEMENTAO DA ANLISE DA PGINA DE DECLARAO FORMAL DE DEMANDA

A maneira como feita a criao da matriz de rastreabilidade vertical dos requisitos atualmente torna o trabalho do analista de sistemas muito penoso, pois a mesma construda manualmente, utilizando os recursos Wiki do Trac. Isso aumenta a possibilidade de falhas durante a criao e manuteno da matriz, principalmente em projetos com muitos requisitos. Uma das funcionalidades do plug-in a anlise da pgina de DFD buscando por padres de definies de requisitos e possveis dependncias. Essa anlise deve identificar a pgina de declarao formal de demanda, que contm as definies dos requisitos e suas dependncias. Aps analisar a pgina e identificar os requisitos, a ferramenta cria uma rea no final pgina, onde ser construda a matriz de rastreabilidade vertical dos requisitos. Para a representao visual dessa matriz de rastreabilidade vertical utiliza-se a linguagem Wiki do Trac. Essas atividades de anlise da pgina de DFD e da criao da matriz podem ser visualizadas na figura 14 do item 4.2, que trata da modelagem do plug-in e representa o fluxo de aes que ser realizado pela ferramenta. No momento de criao de uma pgina Wiki, o plug-in disparado e verifica se a pgina se trata de uma DFD. Isso acontece pois a extenso implementa o mtodo wiki_page_added da interface IWikiChangeListener, que chamado sempre que uma pgina Wiki criada. Por isso o processamento de anlise e criao da matriz centralizado nesse mtodo. Ao ser disparado, o plug-in requisita a pgina de declarao formal de demanda para o servidor Web atravs de sua URL. Aps requisitar a pgina, o sistema obtm o contedo da pgina solicitada, formatada na linguagem HTML. Para facilitar a manipulao das pginas, feita a normalizao das mesmas para que sejam manipuladas via DOM (Document Object Model Modelo de documento de objeto em portugus). Para fazer a normalizao, foi utilizada a biblioteca BeautifulSoup19. Essa biblioteca funciona como um parser de HTML/XML para Python que pode transformar at mesmo marcao invlida em uma rvore analtica. Ela prov um modo idiomtico de navegar, procurar e modificar a rvore de elemento, facilitando o processo de manipulao das pginas Web como objetos DOM, que fornece uma maneira
19

Disponvel para download em http://www.crummy.com/software/BeautifulSoup/download

64 padronizada de acesso aos elementos da pgina, permitindo trabalhar com cada um desses elementos separadamente. Aps a normalizao da pgina, feita a busca pelos requisitos no contedo da mesma. Os requisitos so descritos sempre em lista, representado pela tag HTML <li>, por isso basta utilizar o mtodo findAll da biblioteca BeautifulSoup, passando como parmetro o elemento que deseja buscar no nosso caso <li> - e ento retornado uma estrutura de Array com os elementos encontrados na pgina. Note que em alguns casos, podem existir trechos representados com a tag <li> e que no representam uma descrio de um requisito. Para que sejam retornados somente os elementos que representam requisitos do sistema, realizada uma verificao extra, atravs de uma expresso regular que identifica se o elemento inicia com a letra R, seguida de uma segunda letra e um nmero. Esse padro utilizado para representar um requisito do sistema, como apresentado no item 5.2 deste documento. Com o Array com os elementos da pgina que representam os requisitos, iniciase um lao que itera sobre esses elementos. Nessa repetio, feita a anlise dos requisitos e suas respectivas dependncias, representadas pelo identificador do requisito dependente entre colchetes. Essas dependncias so armazenadas em uma estrutura auxiliar, que ser utilizada para a criao 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 nmero de requisitos do sistema. Sabendo disso, para criar a matriz, realizado um outro lao que far a iterao para a montagem da matriz. Nessa repetio feita uma verificao na estrutura auxiliar que armazena as dependncias entre os requisitos, para que seja preenchida a coluna que representa a relao entre os mesmos. A matriz de rastreabilidade vertical de requisitos simtrica, ou seja, toda vez que uma coluna i,j for marcada a clula j,i tambm dever ser marcada. Para incorporar a matriz de rastreabilidade vertical dos requisitos em uma pgina do Trac, nesse caso em uma pgina de declarao formal de demanda, essa matriz deve estar representada na linguagem Wiki da ferramenta. Devido a isso, o plug-in gera o cdigo referente matriz na notao Wiki, e incorpora este artefato no final pgina de declarao formal de demanda. criada tambm uma matriz auxiliar para visualizao utilizando marcao HTML, lanando mo das tags <tr> e <td> que representam, respectivamente, linhas e colunas de uma matriz. Portanto, na prtica so geradas duas matrizes de rastreabilidade vertical dos

65 requisitos: uma em notao HTML, em uma pgina distinta da DFD e uma em notao Wiki, incorporada na pgina de DFD.

5.4 GERENCIAMENTO DE AVISOS DE ALTERAES EM REQUISITOS

Uma das funcionalidades do plug-in o de gerenciamento as alteraes nos requisitos do projeto, com a criao de um mecanismo para informar sobre uma alterao 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 usurio do Trac, para informar algo importante. Essa mensagem desaparece logo que a pgina recarregada. Para verificar se algum requisito com dependncia foi alterado, necessrio comparar as duas verses do documento: (1) a verso modificada e (2) a verso original. Com as duas verses do documento, realizada uma verificao das diferenas entre elas, e o resultado dessa diferena analisado, buscando pelo padro que corresponde a uma dependncia entre requisitos (identificador de um requisito entre colchetes). Caso esse padro seja encontrado, a mensagem apresentada para o analista de sistemas, para que este possa tomar as providncias necessrias. Um exemplo da mensagem de alterao de requisitos ilustrada na figura 23. A mensagem de aviso mostrada no topo da tela de declarao formal de demanda, com fundo amarelo e com a palavra Warning em negrito. Caso somente requisitos sem dependncia sejam alterados, essa mensagem no apresentada, e o salvamento da pgina de declarao formal de demanda realizado da forma padro. A mensagem apresentada no contm caracteres acentuados devido a um problema da ferramenta Trac no momento de compilao do template com a mensagem de warning.

5.5 INSTALAO 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 pgina de administrao do Trac, que prov uma interface de instalao e integrao de plug-ins. Para instalar uma extenso, deve ser carregado o arquivo de cdigo-fonte do plug-in, escrito em Python (com extenso .py), e o Trac faz o carregamento do arquivo na pasta de plug-ins do sistema. Aps o carregamento da extenso a pgina de administrao de plug-ins recarregada e na listagem j consta a nova funcionalidade incorporada ao Trac. Ainda nessa interface, possvel habilitar e desabilitar as extenses instaladas no sistema.

FIGURA 23 AVISO DE ALTERAO DE REQUISITO COM DEPENDNCIA A figura 24 ilustra a tela de administrao da ferramenta Trac. Nessa tela, possvel administrar as principais funcionalidades do sistema, entre elas a instalao e o gerenciamento de plug-ins. Na tela, os plug-ins instalados so listados, e existe a possibilidade de instalar mais extenses. Para isso, basta fazer o upload do arquivo fonte do plug-in e acionar o boto instalar. Na instalao do plug-in h uma verificao em relao sintaxe do cdigo que est sendo enviado. Caso existam erros, o mesmo no adicionado lista de plug-ins na tela de administrao. Para obter detalhes do erro, o usurio pode verificar o arquivo de log do sistema, que por padro localizado em /tmp/trac.log.

67 Caso ocorram erros em tempo de execuo, apresentado uma mensagem informando sobre o mesmo.

FIGURA 24 TELA DE ADMINISTRAO DE PLUG-INS DO Trac

5.6 TESTE DO PLUG-IN

Aps realizar a instalao 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 pginas de Declarao Formal de Demanda, semelhantes s utilizadas na Prognus. As duas pginas foram sendo editadas ao decorrer dos testes, com requisitos sendo adicionados, editados e excludos. A figura 25 ilustra a interface de utilizao do plug-in pelo analista de sistemas. No final da listagem de requisitos na pgina de Declarao formal de demanda, possvel acionar o boto Criar matriz de rastreabilidade. Esse boto quem vai disparar o evento para que o plug-in faa a anlise dos requisitos da pgina e crie a matriz.

68

FIGURA 25 BOTO DE CRIAO DA MATRIZ DE RASTREABILIDADE VERTICAL NA PGINA DE DECLARAO FORMAL DE DEMANDA

FIGURA 26 MATRIZ DE RASTREABILIDADE VERTICAL GERADA PELO PLUGIN Aps a criao da pgina de Declarao 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 dependncias representadas na diagonal principal da matriz de rastreabilidade representam a dependncia do requisito com ele mesmo, por isso ela no considerada em nossa contagem. Como apresentado no item 5.3, o plug-in tambm gera a notao Wiki da matriz

69 de rastreabilidade vertical dos requisitos. Esse cdigo pode ser incorporado na pgina da demanda (DFD) pelo analista de sistemas, bastando incorporar o cdigo gerado pgina de DFD.

FIGURA 27 NOTAO WIKI REPRESENTANDO A MATRIZ DE RASTREABILIDADE VERTICAL DOS REQUISITOS A figura 27 ilustra um exemplo de notao Wiki gerada pelo plug-in. Ao incorporar esse cdigo Wiki gerado pela extenso na pgina da DFD, o analista de sistemas adiciona o artefato nessa mesma pgina, facilitando a visualizao e manuteno da mesma. A figura 28 mostra a matriz de rastreabilidade de requisitos representada na DFD, aps o analista de sistemas incorporar o cdigo Wiki na pgina e salvar a mesma. Neste captulo foram apresentados a implementao do plug-in, bem como os testes realizados no ambiente de desenvolvimento. No prximo captulo apresentaremos a aplicao da ferramenta no ambiente da empresa, bem como a anlise dos resultados desses testes. Essa anlise servir como base para as concluses do trabalho, onde ser verificado se os objetivos do trabalho foram atingidos de maneira satisfatria.

70

FIGURA 28 MATRIZ REPRESENTADA PELA NOTAO WIKI DO Trac

71 6 ANLISE DOS RESULTADOS

Nesse captulo ser abordada a aplicao da ferramenta desenvolvida na Prognus Software Livre. Os testes foram realizados em dois projetos de 10 (dez) dias de durao, com quantidades de requisitos semelhantes outros projetos desenvolvidos anteriormente pela empresa. Aps os resultados dos testes, ser feito o levantamento e anlise dos resultados, bem como possveis consideraes sobre a utilizao do plug-in.

6.1 ESCOLHA DOS PROJETOS

Para que fosse possvel analisar e comparar os resultados com projetos anteriores, foram escolhidas demandas de escopo semelhantes outras j

implementadas anteriormente pela Prognus. Para essa anlise e levantamento de dados, utilizou-se o plug-in em dois projetos da empresa, com durao mdia de 10 dias cada. O plug-in foi instalado no Trac da empresa para que fosse utilizado nos projetos. A instalao da ferramenta foi feita atravs do mdulo de administrao do Trac, como foi feito no ambiente de implementao, demonstrado no item 5.5, pgina 61. Para tornar o teste mais completo, foram simuladas mudanas em requisitos com dependncias, para testar e analisar a eficincia do plug-in na anlise e no mapeamento dessas dependncias. O primeiro projeto escolhido para a anlise do plug-in era composto por 89 requisitos funcionais, com 7 dependncias entre os mesmos. A figura 29 mostra um exemplo de dependncia de requisitos para essa primeira demanda.

FIGURA 29 DEPENDNCIA DE REQUISITOS DA PRIMEIRA DEMANDA


FONTE: https://dev.prognus.com.br/processo/wiki/Processo/Principal

O segundo projeto era composto por 96 requisitos e possua 13 dependncias

72 entre eles. possvel visualizar um exemplo de dependncia desta demanda na figura 30.

FIGURA 30 DEPENDNCIA 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 possvel fazer uma comparao com esses projetos, facilitando a anlise da eficincia da soluo. De acordo com o processo de desenvolvimento definido na empresa, a fase de especificao da demanda, onde o processo de criao da matriz de rastreabilidade vertical est includo, demanda 60% da fase de execuo do projeto, sendo utilizado 30% para implementao e os 10% restantes para testes. A figura 31 ilustra a fase de execuo do processo de desenvolvimento da Prognus Software Livre. Essa fase divida em 3 subfases: Especificao,

Desenvolvimento e Teste. A criao da matriz de rastreabilidade vertical dos requisitos feita na tarefa de especificao, que demanda o maior tempo da fase de execuo do projeto.

6.2 INSTALAO E UTILIZAO DO PLUG-IN NA PROGNUS

Aps a finalizao da implementao do plug-in, a extenso foi instalada no Trac no ambiente de desenvolvimento da Prognus Software Livre. A instalao ocorreu sem contratempos, utilizando a interface de administrao 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 apresentao, que explicava o funcionamento da ferramenta.

73

FIGURA 31 FASE DE EXECUO DEFINIDA NO PROCESSO DE DESENVOLVIMENTO DA PROGNUS SOFTWARE LIVRE


FONTE: https://dev.prognus.com.br/processo/wiki/Processo/Principal

Foi decidido que a utilizao do plug-in para testes seria feita da seguinte forma: aps a extenso ser instalada no ambiente de desenvolvimento da empresa, o analista de sistemas responsvel por uma demanda iria preencher a pgina de declarao formal de demanda normalmente e seria analisado o resultado do processamento do plug-in aps a pgina ser salva. Devido caracterstica automtica da extenso, o tempo de adaptao ao seu uso muito curto. Como apresentado no item 6.1, para que fosse feita a comparao com outros projetos semelhantes da empresa, foram escolhidos duas demandas. O levantamento das horas gastas na construo da matriz de rastreabilidade vertical dos requisitos de cada uma das demandas foi feito atravs do ticket registrado para essa atividade no Trac. O foco da anlise foi o tempo gasto somente na matriz de requisitos. Essa deciso foi tomada para que no haja inconsistncias nas anlises e comparaes, consequentes de possveis atrasos em outras fases do projeto. A primeira demanda implementada pela empresa sem o plug-in e que foi utilizada como exemplo para comparao era composta por 66 requisitos, e a atividade de criao e configurao 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 necessrio para a montagem da matriz de

74 rastreabilidade vertical. Nesse mesmo ticket havia mais 4 horas de trabalho referente s manutenes na matriz de rastreabilidade vertical, como remoo e edio de requisitos e correo de inconsistncias. Haviam sido registradas 9 mudanas 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 construo da matriz registrava 7 horas de trabalho. Para outras atividades haviam mais 2 horas e 30 minutos contabilizados, com 5 mudanas de requisitos registradas no ticket, totalizando 9 horas e 30 minutos de trabalho, somente relacionado matriz de rastreabilidade. Com esses dados, possvel notar que a tarefa de criao e manuteno da matriz de rastreabilidade vertical de requisitos das demandas requer um tempo considervel 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 dependncias entre eles. O ticket referente criao da demanda contava 45 minutos para a tarefa de criao da matriz de rastreabilidade dos requisitos. Apesar de automatizada, essa tarefa teve um tempo de durao um pouco elevado pois era a primeira vez que estava sendo utilizada pelos analistas de sistema da empresa. Tambm, aps a montagem, os analistas verificaram se a matriz havia sido montada de maneira correta. Durante a fase de

especificao, houve 5 mudanas de requisitos, uma delas em um requisito com dependncia. Essas atividades de manuteno contabilizaram 1 hora no ticket da atividade no Trac. No total foram gastos 1 hora e 45 minutos na criao e manuteno 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 dependncias entre eles. Para a criao da matriz foram contabilizados 35 minutos. Durante seu desenvolvimento houve 4 mudanas nos requisitos, e nenhum requisito dependente sendo afetado. Para as atividades de manuteno foram contabilizados 45 minutos, totalizando 1 hora e 15 minutos para toda a tarefa relacionada matriz de rastreabilidade.

75 6.3 ANLISE DOS RESULTADOS

Aps os testes do plug-in em projetos reais da empresa, foi realizado o levantamento dos dados referentes utilizao. Para fim de comparao, foram escolhidos outros 2 projetos implementados anteriormente pela empresa, e que tinham uma quantidade de requisitos semelhantes.

Demanda Demanda sem plug-in 1 Demanda sem plug-in 2 Demanda com plug-in 1 Demanda com plug-in 2

Requisitos 66 71 89 96

Mudanas 9 5 7 13

Tempo 10 horas e 20 minutos 9 horas e 30 minutos 1 hora e 45 minutos 1 hora e 15 minutos

TABELA 11 COMPARAO DE DEMANDAS SEM E COM A UTILIZAO DO PLUG-IN

Na tabela 11 possvel observar a quantidade de tempo necessria para a criao e manuteno da matriz para cada demanda e a diferena de durao dessa tarefa em projetos que no utilizaram o plug-in e demandas que utilizaram a extenso. Em mdia, os trabalhos relacionados a essa atividade ficaram 9 vezes mais rpidos, fazendo com que o projeto como um todo fosse desenvolvido mais rapidamente. necessrio tambm considerar a taxa de falhas durante a criao e edio da matriz. Essa atividade quando realizada manualmente tem uma possibilidade de erro considervel devido a necessidade de manipular grandes quantidades de dados e tambm da forma como construda a matriz, utilizando linguagem Wiki. Durante os testes com o plug-in no foram encontradas falhas na criao e na manuteno da matriz, ou seja, sempre que a pgina de declarao formal de demanda estava formatada corretamente seguindo o padro esperado, a ferramenta funcionou a contento. Levando em considerao os projetos que foram utilizados para teste e com base no processo de desenvolvimento da Prognus, apresentado na figura 27, possvel quantificar a melhora da utilizao da soluo no processo da empresa. Os projetos testados tinham em mdia durao 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 80 horas Especificao (60%) 48 horas Desenvolvimento (30%) 24 horas Testes (10%) 8 horas

TABELA 12 QUANTIDADE DE HORAS POR ATIVIDADE DO PROCESSO

Analisando os dados dos testes do plug-in, apresentados na tabela 11, foi possvel perceber que as tarefas relacionadas matriz de rastreabilidade vertical dos requisitos levavam em mdia 10 horas para serem concludas. Com a utilizao da ferramenta desenvolvida, esse tempo mdio caiu para 1 hora e 30 minutos, uma reduo de 85% no tempo gasto para essa atividade. Considerando somente a fase de especificao da demanda, em um projeto de 80 horas, so alocados 48 horas para essa atividade. Dessas, em mdia 10 horas eram utilizadas para a manipulao da matriz de rastreabilidade, ou seja, 20% de toda a fase de especificao. Com a reduo de tempo decorrente da utilizao do plug-in, utilizando 1 hora e 30 minutos em mdia nas tarefas relacionadas matriz. Dessa forma, possvel concluir que a matriz de rastreabilidade utiliza somente 3% da quantidade de horas alocadas para a fase de especificao da demanda. Analisando os dados apresentados na tabela 13, percebe-se que a economia de tempo decorrente da utilizao do plug-in possibilita uma readequao do processo de desenvolvimento da Prognus. No caso dos projetos testados, houve uma economia de 8 horas e 30 minutos na fase de especificao da demanda, decorrente da criao e manuteno da matriz de rastreabilidade que foi feita mais de 6 vezes mais rpida. Essa tarefa, que antes demandava 20% de toda a fase de especificao, agora necessita em mdia de 3% para ser implementada, diminuindo o tempo da fase e, consequentemente, de todo o projeto.
Fase de especificao da demanda matriz de rastreabilidade vertical dos requisitos Projeto sem a utilizao 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 ESPECIFICAO DA DEMANDA. A relao do tempo gasto nas tarefas relacionadas matriz de rastreabilidade na fase de especificao da demanda ilustrada na figura 32.

77

FIGURA 32 MATRIZ DE RASTREABILIDADE EM RELAO FASE DE ESPECIFICAO

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 diminuio do tempo de desenvolvimento de um projeto, temos como impacto direto a diminuio de seu preo final, uma vez que de acordo com o diagrama de tripla restrio, escopo, prazo e custo esto intrinsecamente relacionados em um projeto, e uma alterao 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 restrio ao atendimento das necessidades dos interessados no projeto: Escopo, prazo e custo. Um grande esforo em planejamento necessrio para minimizar a ocorrncia de eventos incertos que podem causar grande impacto nesses 3 itens mencionados, e isso pode refletir tambm nos recursos humanos.

FIGURA 33 DIAGRAMA DE TRIPLA RESTRIO


FONTE: Moreira, 2007

78 7 CONCLUSES

Aps implementao e utilizao do plug-in foi possvel verificar que os objetivos declarados no captulo de introduo deste documento foram atingidos. Um dos objetivos definidos no item 1.1 tratava da funcionalidade de automatizao da criao e manuteno da matriz de rastreabilidade vertical de requisitos, para auxiliar no gerenciamento de requisitos dos projetos desenvolvidos pela Prognus Software Livre. Esse objetivo foi implementado atravs do processamento da pgina de declarao formal de demanda, analisando os padres estabelecidos para descrio de dependncia de requisitos, e que j so utilizados pela empresa. Com o resultado da anlise da pgina, a linguagem Wiki do Trac utilizada para gerar visualmente a matriz de rastreabilidade de forma a ser representada no Trac. Outro objetivo do trabalho, tambm afirmado no item 1.1, foi que a ferramenta deve alertar os usurios do Trac sobre requisitos que apresentem alguma dependncia. Isso feito utilizando uma mensagem de warning disponibilizada para uso pelo Trac. Todas as vezes que uma pgina de declarao formal de demanda atualizada, realizada a verificao, informando o analista de sistemas caso algum requisito com dependncia for modificado. Com o resultado das anlises e comparaes da utilizao do plug-in nos projetos da Prognus Software Livre, conclumos que houve um ganho significativo no tempo utilizado na fase de especificao da demanda, mais especificamente na criao e manuteno da matriz de rastreabilidade de requisitos, foco do trabalho. Mesmo com apenas dois testes realizados, foi possvel notar uma diminuio de mais de 6 vezes no tempo da criao da matriz com a utilizao do plug-in em relao aos projetos semelhantes que no utilizaram a extenso. A tarefa de criar e manter a matriz de rastreabilidade considerada uma das mais importantes etapas da especificao das demandas, pois d uma viso geral do projeto, identificando possveis problemas. Essa atividade tambm uma das mais trabalhosas dessa etapa, pois era realizada manualmente pelo analista de sistemas, o que aumentava tambm a possibilidade de falhas na criao e manuteno da mesma. Esse aumento de eficincia na fase de especificao da demanda tornou essa fase do processo de desenvolvimento mais rpida, facilitando o trabalho do analista de sistemas da demanda. A possibilidade de adequao e diminuio da fase de execuo do processo,

79 diminuindo o tempo de entrega dos projetos se transformam em vantagem competitiva para a empresa. Como foi afirmado no captulo 1 de introduo, o mercado exige que cada vez mais os projetos sejam implementados mais rapidamente e com maior eficincia. Com isso, as empresas que lanarem mo de mtodos que auxiliem as fases do projeto para torna-las mais rpidas e eficientes consequentemente tero ganhos reais com esse auxlio. A utilizao do plug-in tambm atende sugesto da equipe de avaliao do MPS.BR, para que a criao da matriz de rastreabilidade seja automatizada. Isso faz com que a empresa esteja cada vez mais aderente ao nvel G do MPS.BR, principalmente no que diz respeito disciplina de gerncia de requisitos, tornando o processo mais eficiente. A utilizao do plug-in pelos analistas de sistemas que participaram dos testes ocorreu sem maiores problemas, e a curva de adaptao com a extenso foi muito pequena. Apesar de fazer um trabalho complexo e importante, sua utilizao muito simples e automatizada, bastando que o usurio da ferramenta acione o boto para a criao da matriz de rastreabilidade dos requisitos. A aceitao do plug-in na empresa utilizada como teste da ferramenta, bem como a provvel continuidade do uso da extenso em outros projetos demonstra que os resultados da utilizao da ferramenta agregou valor ao processo de desenvolvimento da empresa, auxiliando uma fase importante do ciclo de especificao das demandas para implementar. Durante a utilizao foi possvel tambm notar possveis adequaes que podem melhorar ainda mais a usabilidade e eficincia no gerenciamento de requisitos de uma demanda e podem ser implementadas em trabalhos futuros. Uma das melhorias possveis, sugeridas pelos analistas de sistemas que utilizaram o plug-in, foi a possibilidade de criar uma dependncia entre requisitos atravs da matriz de rastreabilidade de requisitos. Isso poderia ser feito tornando possvel que cada clula da matriz de rastreabilidade fosse editvel. Uma vez que isso fosse possvel, o analista de sistemas poderia, na prpria matriz de rastreabilidade, criar uma dependncia entre dois requisitos, sem a necessidade de editar os requisitos da pgina de declarao formal de demanda. Uma melhoria interessante remete escolha dos requisitos que faro 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 possvel selecionar os requisitos que faro parte da matriz, principalmente quando a demanda possuir muitos requisitos. Com isso, seria possvel at

80 mesmo a criao de mais de uma matriz, separada por grupos de requisitos de uma mesma demanda. Como implementao futura foi levantada a possibilidade de tornar o padro de listagem e dependncia de requisitos configurvel, para que cada usurio utilize a extenso da maneira que julgar melhor, sem a necessidade de se adequar ao padro 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 codificao dos caracteres das mensagens apresentadas pela ferramenta. Quando o alerta de alterao de requisito com dependncia era escrito com caracteres acentuados com, por exemplo, a palavra alterao, ocorria um erro na compilao do template do Trac. Por isso, a mensagem apresentada no pode conter acentos. Problemas com requisitos escritos fora do formato tambm aconteceram durante os testes do plug-in. Para que a ferramenta funcione adequadamente, necessrio que o analista de sistemas preencha de forma correta a pgina de declarao formal de demanda (DFD), seguindo os padres de descrio de requisitos e dependncias descritos no item 5.2 deste documento. Caso o preenchimento da pgina de DFD seja feito fora do padro, o sistema ter seu funcionamento prejudicado, pois no encontrar os padres pr-estabelecidos e as dependncias e requisitos que estiverem fora do padro no sero identificadas.

81 REFERNCIAS

PRESSMAN, R. S. Engenharia de Software. 6. ed. Rio de Janeiro: Mc Graw Hill, 2006. PFLEEGER, S. L. Engenharia de Software: Teoria e prtica. 2. ed. So Paulo: Prentice Hall, 2004. SOMMERVILLE, I. Engenharia de Software. 6. ed. So Paulo: Addison Wesley, 2003. FILHO, W. P. Engenharia de Software: Fundamentos, mtodos e padres. 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 experincia de implementao nvel G em uma empresa de software livre. In: Simpsio Brasileiro de Qualidade de Software, 10, 2011, Curitiba. VIANA, Leonardo. M.; DESCHAMPS, Alexandro. XP Extreme Programming. Disponvel em: <http://www.apicesoft.com/common/articles/Apice> Acesso em: 21 de Ago. 2011. OLIVEIRA, T. M. Gerenciamento de projetos atravs do Project Locker (Trac e Subversion). 2010. 42f. Trabalho de concluso de curso (Bacharelado em Cincia da Computao) Universidade Estadual de Maring, Paran. VILA, A. L.; SPNOLA, R. O. Introduo Engenharia de Requisitos. Revista Engenharia de Software, So Paulo, v. 1, n. 1, p. 46-51, 2007. ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWAFRE BRASILEIRO, SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro. So Paulo, 2009. FOWLER, M. The New Methodology. Disponvel 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 Adoo de Boas Prticas de Engenharia de Software pela Indstria 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 alcanados e lies aprendidas (2004-2008). CLEI 2008 (XXXIV Conf. Latinoamericana de Informtica), 8 a 12 de Setembro, Santa F, Argentina. PEDROSA, A.E, UESONO, G.M. Metodologias de Desenvolvimento de Sistemas-

82 Universidade Federal de So Carlos 2006. Disponvel 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. Viso Geral do Projeto MPS.br - Faculdade de Cincias da Computao de Cataguases 2008. Disponvel em <http://pt.scribd.com/doc/44966729/Artigo-MPSbr> Acesso: 20 de out. 2011. CASTRO, V. A. Desenvolvimento gil com Programao Extrema. 2007. 122f. Trabalho de concluso de curso (Bacharelado em Cincia da Computao) Universidade Federal de Sergipe, Sergipe. DIAS, Andr Felipe. Controle de Mudana com Trac. Disponvel em: <http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/trac.php> Acesso em: 25 set. 2011. EDGEWALL, Trac Open Source Project. http://trac.edgewall.org/> Acesso em: 11 set. 2011. Disponvel em: <http://www.

MOREIRA, O. C. Modelos para gesto de projetos na Engenharia de Software. 2007. 32f. Tese (Especializao em Engenharia de Projetos de Software) Universidade do Sul de Santa Catarina, Santa Catarina.