Melhoria de processo de Verificação e Validação segundo os modelos CMMI-DEV, MPS.BR-SW e norma ISO/IEC 15504 Fernanda Thiesen Matos, Alessandra Casses Zoucas Universidade do Vale do Itajaí Gerência de Pesquisa e Pós-Graduação Curso de pósgraduação em Qualidade e engenharia de software {fernandamatos; azoucas} @univali.br Resumo. Este artigo visa apresentar a análise dos processos de verificação e validação, realizada em uma instituição de pesquisa, desenvolvimento e inovação da região da grande Florianópolis, utilizando-se o mapeamento proposto pelo modelo de referência de processo de verificação e validação alinhado ao CMMI, MPS.BR e à norma ISO/IEC 15504. O resultado dessa análise é apresentado e melhorias no processo são propostas para implementação de V&V na instituição. Palavras chave: Verificação, Validação, Melhoria de Processo de Software, Modelo de Referência de Processo Abstract. This article presents the analysis of the processes of verification and validation, performed in a institution dedicated to research, development and innovation of engineering solutions and strategic management of information and knowledge in Florianopolis, using the mapping proposed by the reference model verification and validation process aligned with CMMI, MPS.BR and ISO/IEC 15504. The results of this analysis are presented and process improvements are proposed for the implementation of V&V in the institution. Key Word: Verification, Validation, Software Process Improvement, Process Model Reference
1. INTRODUÇÃO Um dos principais motivos para que empresas e organizações que desenvolvem softwares adotem uma visão de melhoria contínua de seus processos é o fato da qualidade do produto final depender diretamente da qualidade do processo de software adotado. É por esta razão que elas estão procurando investir na melhoria de seus processos de desenvolvimento (KOSCIANSKI, 2007). A melhoria deste processo traz grandes benefícios, aumentando a qualidade de seus produtos e diminuindo os esforços para produzi-los e mantê-los. Porém, a aplicação de um programa de melhoria de processos não é simples, pois não existe um método padronizado para a sua execução e existem diversos padrões, referências e modelos internacionalmente reconhecidos que podem ser aplicados na empresa ou instituição, como por exemplo o Capability Maturity Model for Development (CMMI-DEVI-DEV) (SEI, 2011), o MPS.BR-SW (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2012) e a norma ISO/IEC 15504 (ISO, 2005). De um modo geral, esses modelos apresentam apenas metas ou estruturas necessárias para que um processo de desenvolvimento tenha excelência na qualidade de seus produtos, mas não determinam como implantar as melhorias necessárias no processo de desenvolvimento, devido às características intrínsecas de cada projeto. O CMMI-DEV foi criado no final da década de 1980 pelo SEI (Software Engineering Institute) dos Estados Unidos, para a avaliação da capacidade dos seus fornecedores de software (REZENDE, 2002; KOSCIANSKI, 2007). Já o MPS.BR-SW, foi elaborado por pesquisadores brasileiros em 2003, visando à melhoria dos processos de desenvolvimento de software de empresas de micro, pequeno e médio porte brasileiras (KOSCIANSKI, 2007). E a norma ISO/IEC 15504 possui uma estreita relação com o modelo CMMI, pois apresenta uma estrutura para a realização de avaliações de processos semelhante ao modelo (REZENDE, 2002; KOSCIANSKI, 2007). O objetivo principal desses modelos é que as organizações conheçam e melhorem seus processos de desenvolvimento de software auxiliando na implementação de práticas definidas. Uma parte importante da melhoria de processos é a avaliação de processos. A avaliação sistemática da qualidade de um processo (as atividades realizadas, as ferramentas, procedimentos utilizados e seus produtos resultantes) é essencial para apoiar a implementação de estratégias de melhoria (KOSCIANSKI, 2007). Em Florianópolis há um instituto de pesquisa e desenvolvimento em inovação onde é realizado o desenvolvimento sob medida de softwares para gestão do conhecimento. Apesar
de possuírem um modelo de ciclo de desenvolvimento de software, nem todos os processos relativos à validação e verificação são realizados. Neste sentido, esta pesquisa visa analisar de que forma o núcleo de qualidade desta instituição, que é responsável pelos processos de verificação e validação dentro do processo de desenvolvimento de software utilizado na instituição, consegue realizar as práticas sugeridas para estes processos. Este artigo apresenta uma análise dos processos de verificação e validação utilizados na instituição pesquisada com base na tabulação realizada por Mussio (2011), que analisa os três modelos citados no que tange estes processos especificamente, e propõe melhorias para cada prática analisada. Este artigo apresenta além desta introdução a seção 2 onde é apresentada a metodologia da pesquisa realizada, uma contextualização da instituição pesquisada e o mapeamento do processo de desenvolvimento realizado como subsídio para a análise e identificação dos processos. A seção 3 apresenta a análise individual realizada para cada prática proposta por Mussio (2011) assim como algumas sugestões de melhoria. A seção 4 tece algumas conclusões sobre o assunto. 2. METODOLOGIA Para identificar as atividades dos processos de validação e verificação na instituição analisada, foi realizado primeiramente o levantamento do processo de desenvolvimento atual apontando em quais etapas a instituição realizava alguma prática dos processos de verificação e validação. Este mapeamento foi realizado através de pesquisa documental, entrevista não estruturada com os colaboradores e observação direta. Para registrar este processo, foi utilizada a ferramenta Bizagi. Após a realização do mapeamento do processo de desenvolvimento na instituição, passou-se para a etapa de avaliação utilizando o modelo proposto por Mussio (2011). Este modelo de referência de processo proposto por Mussio visa contemplar paralelamente os modelos CMMI, MPS.BR e a Norma ISO/IEC 15504 permitindo que ao ser implementado em uma empresa esta esteja cumprindo com todas as práticas esperadas por qualquer um destes três modelos. Dessa forma espera-se que a instituição obtenha um conjunto mínimo de práticas que contemplem os processos de verificação e validação dos três modelos simultaneamente. Ao final espera-se que a análise realizada identifique os gaps do processo atual em relação aos modelos de referência propostos e que a partir desse resultado, seja possível apresentar sugestões de melhoria para as práticas que por ventura não estejam sendo efetuadas ou estejam sendo parcialmente executadas.
SOBRE A EMPRESA ALVO DAS MELHORIAS O trabalho de análise dos processos de Validação e Verificação foi realizado em uma organização privada sem fins lucrativos de Florianópolis, que a mais de 18 anos se dedica à pesquisa, ao desenvolvimento e à inovação de soluções em engenharia e gestão estratégica de informação e conhecimento. A empresa possui vários projetos e alguns produtos e nem sempre a metodologia de desenvolvimento aplicada para gerenciá-los é a mesma. Alguns deles utilizam práticas da metodologia Scrum, conforme definido por Schwaber (2004), enquanto outros trabalham com algumas práticas da metodologia RUP (KRUCHTEN, 2003; REZENDE, 2002). A decisão sobre qual metodologia usar é feita com base no tempo de desenvolvimento estipulado, assim como o investimento realizado. Nem sempre as práticas abordadas neste artigo são realizadas justamente por conta desses motivos. SOBRE O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DA INSTITUIÇÃO O processo de desenvolvimento de software começa com uma reunião inicial entre o analista de negócios e o cliente, onde os requisitos do sistema são levantados e registrados em um mapa mental através da ferramenta FreeMind. Após o levantamento inicial, este mapa mental é transformado em um documento de requisitos (elaborado por uma ferramenta de edição de textos) e segue para a revisão pelo núcleo de qualidade. O núcleo de qualidade revisa os requisitos procurando por inconsistências, ambiguidades, requisitos incorretos, ilógicos e omissos. Depois de finalizado, o relatório de revisão dos requisitos submetido no repositório (a ferramenta utilizada é o SVN) é devolvido para o analista de negócios (através de comunicação por e-mail). O analista corrige as revisões, se necessário, e apresenta ao cliente para aprovação dos mesmos. Esta apresentação pode ser tanto pessoalmente, quanto por envio do documento por e-mail ou por correio, conforme acordado com o cliente. Após a aprovação pelo cliente (também realizada pessoalmente, por e-mail ou por correio) o documento com a lista dos requisitos é entregue para o analista de negócios e para o analista de qualidade para elaboração dos casos de uso e roteiro de testes respectivamente. Estes casos de uso são elaborados com o auxílio da ferramenta Enterprise Architect (EA) e os roteiros de testes são elaborados com a ferramenta de mapa mental FreeMind. Os casos de uso elaborados pelo analista de negócio seguem para revisão de formato e de conteúdo pelo analista de qualidade, que assim como feito com os requisitos, elabora um
documento de revisão de casos de uso. Depois de finalizado o documento, o analista de qualidade submete-o no repositório e comunica por e-mail ao analista de negócio que o documento já está disponível para correções. O analista de negócio, de posse do documento revisado, corrige as revisões na ferramenta EA. Após correção, o analista submete o arquivo no repositório para que a equipe de desenvolvimento tenha acesso à especificação e comunica a equipe do projeto, por e-mail, de que a especificação está apta para ser consultada. Este documento é utilizado tanto pelo núcleo de desenvolvimento (para codificação), como pelo núcleo de qualidade (para a elaboração dos casos de teste, que podem ser elaborados tanto na ferramenta EA como em arquivos de texto ou planilhas). O núcleo de desenvolvimento é encarregado de preparar e liberar o ambiente para a execução dos testes. O próximo passo é a execução dos testes pelo núcleo de qualidade. Geralmente quem executa os testes é o analista de qualidade responsável pela elaboração dos casos de teste. Porém, como os recursos do núcleo são compartilhados pelos demais projetos (não são exclusivos), acontece algumas vezes de mais de um analista ou tester trabalhar no mesmo projeto em momentos distintos. Os erros encontrados durante a execução dos casos de teste são registrados na ferramenta Mantis, que gera o relatório de erros. Estes erros são encaminhados para o núcleo de desenvolvimento para a sua resolução através da própria ferramenta, que envia um e-mail para os membros da equipe de desenvolvimento do projeto. À medida que os erros são corrigidos, a equipe de desenvolvimento vai liberando versões para o reteste e à medida que o reteste é executado com sucesso, o responsável pela execução dos testes autoriza ou não a liberação de uma versão para a homologação. Caso autorizado, esta versão é liberada pelo núcleo de desenvolvimento no ambiente de homologação para que o cliente execute o roteiro de testes de aceitação. O cliente recebe o roteiro de testes de aceitação por e-mail ou por correio. Após a execução com sucesso do roteiro de testes de aceitação pelo cliente, o mesmo deve autorizar a liberação de uma versão na produção. A Figura 1 apresenta o processo de desenvolvimento supracitado.
Figura 1: Mapeamento do processo de desenvolvimento de software.
3. ANÁLISE DOS PROCESSOS Com base no trabalho realizado por Mussio (2011), foi realizada uma análise em cima do processo de desenvolvimento de software adotado pela empresa em busca de indícios dos processos de verificação e validação. O resultado dessa análise é apresentado através do mapeamento com base nos critérios descritos na tabela 1: Identificador Significado T Totalmente atendido P Parcialmente atendido N Não atende Tabela 1: Legenda do identificador do processo 3.1 Sobre o processo de validação no processo de desenvolvimento A Tabela 2 apresenta o resultado da análise realizada sobre o processo de validação identificado na empresa. Ao lado do nome de cada prática está o identificador do resultado encontrado, de acordo com os critérios estabelecidos na Tabela 1. PRÁTICA RESULTADO Prática 1: Selecionar produtos para validação P Prática 2: Estabelecer ambiente de validação T Prática 3: Estabelecer procedimentos e critérios de validação P Prática 4: Realizar validação T Prática 5: Analisar resultados de validação N Prática 6: Disponibilização para as partes interessadas T Prática 7: Validação final do produto P Tabela 2: Tabela de validação CMMI-DEV + MPS.BR-SW + ISO15504 (Validação) A seguir será descrito o detalhamento de cada análise, assim como apresentado sugestões de melhorias para cada prática estudada. PRÁTICA 1: SELECIONAR PRODUTOS PARA VALIDAÇÃO (SEI, 2010) P A instituição pesquisada atende parcialmente a prática 1 na medida em que os produtos de trabalho são selecionados para a validação (requisitos, protótipos, manuais de
usuário, produto do desenvolvimento), porém, os métodos, técnicas e critérios para a validação não são claramente definidos. Como sugestão de melhoria, após a seleção dos produtos que serão validados, os métodos de validação para cada produto devem ser claramente definidos e devidamente registrados como produtos de trabalho típicos desta prática. Alguns métodos que podem ser utilizados são discussões com os usuários, apresentação de protótipos e até mesmo demonstrações funcionais. PRÁTICA 2: ESTABELECER AMBIENTE DE VALIDAÇÃO (SEI, 2010) T A prática 2 do processo de validação é totalmente contemplada pela instituição analisada. O ambiente de validação é elaborado de acordo com os requisitos identificados (de hardware, software, arquitetura, banco de dados) para recriar o ambiente do cliente. O produto de trabalho é o próprio ambiente de validação. A elaboração do ambiente de validação é realizada pela equipe de técnicos envolvidos no projeto, com base nos requisitos de hardware e software solicitados pelo cliente. Este ambiente é disponibilizado a partir do momento que a equipe de desenvolvimento libera uma versão para os testes. Em primeira instância, este ambiente é liberado no servidor de testes da empresa e em um segundo momento, após a realização de todos os testes, este ambiente de validação é migrado para o servidor de homologação do cliente. PRÁTICA 3: ESTABELECER PROCEDIMENTOS E CRITÉRIOS DE VALIDAÇÃO (SEI, 2010) - P A prática 3 do processo de validação é atendida parcialmente pela instituição pesquisada. Os critérios de aceitação pelo cliente são estabelecidos baseados nos requisitos iniciais que são revisados para garantir a validação do produto final. A avaliação constante do design do produto é realizada à medida que é evoluída, para garantir a identificação de eventuais problemas, porém, não há registro dos produtos de trabalho. Como sugestão de melhoria, a instituição deve realizar o registro da documentação necessária para o ambiente, cenário operacional, procedimentos, entradas e saídas dos produtos selecionados. PRÁTICA 4: REALIZAR VALIDAÇÃO (SEI, 2010) - T A prática 4 do processo de validação é atendida totalmente pela instituição pesquisada. A validação é executada e os dados resultantes são coletados, assim como os desvios são
documentados. Os produtos de trabalho resultantes são os relatórios de validação, log de execução e demonstrações operacionais. PRÁTICA 5: ANALISAR RESULTADOS DA VALIDAÇÃO (SEI, 2010) - N Apesar de a validação ser totalmente realizada pela prática 4, os resultados dessa validação não são analisados, conforme solicitado pela prática 5 do processo de validação. Os registros dos erros são registrados, porém, não existe uma análise em cima dos dados levantados durante a execução dos testes de validação. Como sugestão de melhoria, deve-se tomar como base os relatórios gerados pela prática 4, comparando os resultados obtidos com os resultados esperados, analisando os dados sobre os defeitos registrados durante a execução da validação. Como produto de trabalho gerado, pode ser elaborado um relatório com o registro das análises para a identificação dos problemas, usando os resultados da validação para comparação de medidas de desempenho de acordo com as necessidades operacionais. PRÁTICA 6: DISPONIBILIZAÇÃO PARA PARTES INTERESSADAS (SOFTEX, 2009) - P A prática 6 é realizada parcialmente à medida que alguns resultados da validação são apresentados para as partes interessadas. Através do ambiente de homologação disponibilizado ao final do projeto, os stakeholders podem verificar se o produto final atende os requisitos solicitados. Alguns stakeholders solicitam, além do ambiente de homologação, toda a documentação técnica gerada durante o desenvolvimento. Este material é disponibilizado pela rede (interna, externa ou nuvem), através de um software de compartilhamento de arquivos ou repositório. Como sugestão de melhoria, os resultados obtidos pela validação devem ser registrados e apresentados para os interessados, possibilitando a verificação dos critérios definidos, se foram atendidos, se a validação foi executada como planejado e se o produto final está apto para o uso pretendido. PRÁTICA 7: VALIDAÇÃO FINAL DO PRODUTO (SOFTEX, 2009) - T A prática 7 é realizada totalmente pela instituição analisada. O produto é entregue para o cliente para a validação final, disponibilizado em ambiente real de uso, geralmente no próprio servidor do cliente, como ambiente para homologação. A equipe técnica do
projeto é encarregada de configurar e disponibilizar este ambiente. Também é entregue ao cliente um roteiro para homologação, onde deverão ser registrados os problemas encontrados neste período, assim como a aceitação do produto que deverá estar pronto para o uso. 3.2 Sobre o processo de verificação no processo de desenvolvimento A Tabela 3 apresenta o resultado da análise realizada sobre o processo de verificação identificado na empresa. Ao lado no nome de cada prática está o identificador do resultado encontrado, de acordo com os critérios estabelecidos na Tabela 1. PRÁTICA RESULTADO Prática 1: Selecionar produtos para verificação P Prática 2: Estabelecer ambiente de verificação T Prática 3: Estabelecer procedimentos e critérios de verificação P Prática 4: Preparar-se e conduzir revisão por pares N Prática 5: Analisar dados de revisão por pares N Prática 6: Realizar verificação P Prática 7: Analisar resultados da verificação N Tabela 3: Tabela da verificação CMMI-DEV + MPS.BR-SW + ISO 15504 (Verificação) PRÁTICA 1: SELECIONAR PRODUTOS PARA VERIFICAÇÃO - P A prática 1 é parcialmente executada na empresa pois alguns produtos de trabalho são selecionados, porém, não são formalmente registrados. O plano de projeto não contempla a especificação desta prática. Como sugestão de melhoria, o processo atual deve começar a registrar os produtos de trabalho selecionados para verificação visando reconhecer, definir e registrar os requisitos a serem satisfeitos por cada produto de trabalho selecionado; identificar, definir e registrar os métodos de verificação para todos os produtos de trabalho selecionados; registrar no plano de projeto a existência dos produtos de trabalho, os requisitos de satisfação dos mesmos, assim como os métodos utilizados para a verificação dos produtos de trabalho. PRÁTICA 2: ESTABELECER AMBIENTE DE VERIFICAÇÃO - T Com relação à prática 2, a empresa atende completamente no sentido em que o ambiente de verificação do produto é estabelecido. O tipo de ambiente requerido depende dos produtos de trabalho e métodos de verificação selecionados. Para confirmar isto, as seguintes
sub-práticas elencadas pelo SEI (2010) são completamente atendidas: os requisitos do ambiente de verificação são identificados; os recursos disponíveis para reuso e modificação são determinados; as ferramentas e os equipamentos necessários são estabelecidos. PRÁTICA 3: ESTABELECER PROCEDIMENTOS E CRITÉRIOS DE VERIFICAÇÃO - P A instituição pesquisada atende parcialmente a prática 3. Não existe um produto de trabalho formalizado especificando quais os procedimentos e critérios de verificação para atender todos os produtos de trabalho que devem ser verificados. Existe apenas um plano de testes que contempla alguns procedimentos para verificação do sistema desenvolvido, porém, não estão ali especificados os critérios de verificação. Os critérios de verificação devem assegurar que os requisitos dos produtos de trabalho estão sendo atendidos. Como sugestão de melhoria, a instituição deve elaborar um conjunto de procedimentos de verificação para os produtos de trabalho; elaborar ou definir critérios (checklists) de verificação para os produtos de trabalho; identificar as tolerâncias permitidas, os resultados esperados e outros critérios que satisfaçam os requisitos. PRÁTICA 4: PREPARAR-SE E CONDUZIR REVISÃO POR PARES - N A instituição não apresenta indícios de realização da prática 4. Como sugestão de melhoria, o processo deve identificar, definir e tornar efetivo os papéis da equipe que participará na revisão de cada produto de trabalho; identificar os revisores-chave que participarão da revisão por pares; elaborar cronograma das revisões; elaborar listas de verificações; definir os critérios de entrada e saída relativos aos produtos de trabalho; definir e estabelecer critérios para solicitação de outra revisão por pares; elaborar material de treinamento de revisão; definir os produtos de trabalho que devem ser revisados; definir o tipo de revisão por pares que será utilizada; determinar os requisitos para a coleta de dados durante a revisão; garantir que os produtos de trabalho satisfaçam os critérios estabelecidos para as revisões; revisar o produto de trabalho antes de iniciar a revisão por pares; identificar, registrar e comunicar os problemas encontrados no produto de trabalho; documentar os resultados da revisão por pares; coletar dados da revisão; garantir que os critérios de saída estabelecidos para a revisão sejam satisfeitos.
PRÁTICA 5: ANALISAR DADOS DE REVISÃO POR PARES - N Assim como a prática 4, a instituição analisada não apresentou artefatos que comprovem a realização da prática 5. Como sugestão de melhoria, o processo deve registrar os dados que tenham relação com a preparação, a condução e a execução da revisão por pares; armazenar dados para consultas e análises futuras; proteger os dados levantados pelas revisões para que não sejam utilizados de forma inadequada; analisar os dados registrados pela revisão por pares. Alguns exemplos de dados que podem ser coletados durante a revisão são: a fase em que o defeito foi introduzido; tempo ou porcentagem de tempo de preparação versus tempo ou porcentagem de tempo esperada; número de defeitos encontrados versus número de defeitos esperado; tipos de defeito detectados, causas dos defeitos; impacto da correção dos defeitos (SEI, 2010, p. 242); entre outros. PRÁTICA 6: REALIZAR VERIFICAÇÃO - P A prática 6 é realizada parcialmente pela instituição analisada. A verificação dos produtos de trabalho selecionados é realizada, porém, não há controle em relação aos requisitos de verificação, pois estes não são formalmente definidos (prática 3). O resultado dessa verificação não é registrado formalmente, mas os itens de ação resultantes dessa verificação são percebidos. Não há indícios de registro dos seguintes produtos de trabalho típicos solicitados pela norma: resultados de verificação, relatórios de verificação, demonstrações e log de procedimentos. Como sugestão de melhoria, o processo pode, a partir do momento em que os requisitos de verificação dos produtos de trabalho são identificados (prática 1), executar as verificações com base nos requisitos; registrar o resultado da verificação; identificar os itens de ação resultantes da verificação; registrar os procedimentos realizados. PRÁTICA 7: ANALISAR RESULTADOS DA VERIFICAÇÃO - N A prática 7 não é realizada pela instituição analisada. Isso ocorre devido a não realização total da prática 3, pois não há registro de requisitos e critérios a serem contemplados pelos produtos de trabalho selecionados para a verificação. Como sugestão de melhoria para esta prática que não é realizada, a partir do momento que a prática 3 citada anteriormente é realizada totalmente, a instituição deve ser capaz de comparar os resultados reais obtidos com os esperados; identificar os produtos de trabalho que não foram completamente atendidos pelos requisitos exigidos; analisar os dados de
verificação resultantes de defeitos encontrados; elaborar relatório com o resultado da análise; utilizar os relatórios como parâmetro para comparação entre medidas e desempenho reais com parâmetros técnicos de desempenho; fornecer informações de como os defeitos podem ser corrigidos e iniciar as ações corretivas. 4. CONCLUSÃO Este artigo teve como objetivo realizar uma descrição do processo de desenvolvimento de software em um instituto de pesquisa e desenvolvimento, analisar os processos de validação e verificação utilizados no ciclo de desenvolvimento de software dessa instituição de acordo com o mapeamento de modelos de referência proposto por Mussio (2011) e apresentar sugestões de melhoria para aquelas práticas que a instituição não contempla ou contempla parcialmente. Com relação ao processo de validação proposto pelo modelo de referência de Mussio (2011), a instituição estudada atende totalmente a quatro práticas, parcialmente a duas e não atende apenas a uma prática. Já sobre o processo de verificação, a instituição atende totalmente a apenas uma prática, parcialmente a três e não atende a três das práticas propostas. Neste sentido, o artigo recomenda um conjunto de melhorias que podem ser implementadas para as práticas que não estão sendo atendidas, assim como para aquelas que estão sendo parcialmente atendidas. Os resultados encontrados serão apresentados à instituição na forma de um workshop e poderá fazer parte do processo de análise para a certificação MPS.Br que hoje a empresa concorre. 5. REFERÊNCIAS KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo: Novatec Editora, 2007. KRUCHTEN, Philippe. Introdução ao RUP Rational Unified Process. Rio de Janeiro: Editora Ciência Moderna, 2003. MUSSIO, Giovani Mombelli. Mapeamento de práticas dos processos de verificação e validação baseado no CMMI, MPS.BR e Norma ISO/IEC 15504. 2011. 119 f. Relatório (Trabalho de conclusão de curso em Ciência da computação) Universidade do Vale do Itajaí, São José, 2011.
REZENDE, Denis Alcides. Engenharia de Software e sistemas de informação. Rio de Janeiro: Brasport, 2002. SCHWABER, Ken. Agile Project Management With Scrum. Primeira Edição. Redmond, Washington, Estados Unidos da América: Microsoft Press, 2004. SEI SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV). Versão 1.3. Pennsylvania. 2010. Disponível em: <http://www.sei.cmu.edu/cmmi>. Acesso em: 08 de novembro de 2012. SOFTEX ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO. MPS.BR Melhoria de Processo do Software Brasileiro: Guia Geral. Versão 1.2. 2007. Disponível em: <http://www.softex.br/mpsbr>. Acesso em: 08 de novembro de 2012. SPARXSYSTEMS: Enterprise Architect. Disponível em: <http://www.sparxsystems.com.au/>. Acesso em: 29 abr. 2013. FREEMIND: Free mind mapping software. Disponível em: <http://freemind.sourceforge.net/wiki/index.php/main_page>. Acesso em: 29 abr. 2013.