Metodologia FDD aplicada a especificação dos requisitos no processo GRE do nível G de maturidade do modelo MPS.BR

Transcrição

1 Metodologia FDD aplicada a especificação dos requisitos no processo GRE do nível G de maturidade do modelo MPS.BR Bruno Bandeira Fernandes, Gabriela Fachine Brito, Wisley Cristiano de Souza Milhomem, Cristina D Ornellas Filipakis Curso de Sistemas de Informação Centro Universitário Luterano de Palmas (CEULP/ULBRA) Teotônio Segurado 1501 Sul Caixa Postal Palmas TO-Brasil {brunbandeira, gabrielafachine, wisleycristiano, filipakis}@gmail.com Resumo. Este trabalho trata do mapeamento do processo de Gerência de Requisitos do nível G de maturidade do Modelo MPS.BR alinhados a metodologia ágil FDD. O processo de Gerência de Requisitos, do Modelo MPS, foi mapeado com as práticas baseadas no FDD. Nestes casos, algumas ações podem ser tomadas no intuito de adicionar características, que não destituem os conceitos básicos do FDD, mas que satisfaçam os processos do modelo MPS. Neste trabalho são apresentadas sugestões que visam totalmente a satisfação do FDD ao processo de GRE do MPS.BR, sem que haja uma deturpação dos preceitos empregados nas metodologias ágeis. Palavras-chave: MPS.BR, FDD, requisitos, processos. 1. Introdução Cada vez mais as organizações buscam produzir maiores quantidades de produtos e serviços para atender a demanda de seus clientes. Porém, estes clientes estão cada vez mais exigentes, já que o mercado atual possibilita uma grande quantidade de opções de escolha do produto ou serviço desejado devido a concorrência entre as empresas. Para terem um maior destaque em relação aos concorrentes, as organizações devem tentar buscar oferecer aos seus clientes um diferencial. Muitas vezes é necessário mudar toda uma estratégia mantida pela empresa até o momento de percepção da mudança para se manter no mercado e traçar novas metas a serem seguidas por todos aqueles que estão no desenvolvimento do projeto, seja ele de produtos ou serviços. Todo projeto possui suas funcionalidades que são geradas a partir de uma quantidade x de requisitos. Estes requisitos precisam passar por um estudo de viabilidade antes de serem implantados no projeto. Estudo esse que pode minimizar perdas no futuro. Sobre os requisitos, há muitos fatores que influenciam a elaboração dos mesmos, muitas vezes de forma negativa para o andamento do projeto, como por exemplo, o cliente não saber informar corretamente às funcionalidades que deseja para o projeto. Outra questão em destaque é o financeiro, se a realidade do requisito projetado está de acordo com a viabilidade do cliente. Ou seja, a análise e desenvolvimento de requisitos é essencial no desenvolvimento de software. E pelo fato dos problemas não serem de cunho dos desenvolvedores, acaba dificultando o sucesso no final do projeto. XIII Encoinfo Encontro de Computação e Informática do Tocantins 199

2 A necessidade de uma gerência qualificada, que entenda e pratique esse tipo de estudo, faz com que as organizações estejam sempre flexíveis e atentas em relação a qualidade de seus produtos oferecidos e serviços prestados. Para isso foram estabelecidos normas e modelos de qualidade que servem como guias para aumentar, medir e garantir a qualidade de seus softwares. Em 2003 foi lançado no Brasil o modelo de qualidade MPS.BR Melhoria do Processo de Software Brasileiro - que visa atender as empresas de pequeno e médio porte na implantação da Engenharia e garantia da qualidade na produção de Softwares. O MPS.BR é implementado em níveis de maturidade e o nível G é o mais baixo e possui os processos que garantem a gerência dos projetos e a gerência dos requisitos no ciclo de desenvolvimento de software. De acordo com o Guia Geral (2009, p. 25), o propósito do primeiro processo é: Identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou serviço, no contexto dos requisitos e restrições do projeto. Já o propósito do processo Gerência de Requisitos, conforme o Guia Geral (2009, p. 28) é: Gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. As empresas de software devem buscar soluções que mantenha um equilíbrio na hora do desenvolvimento dos projetos, entre as partes mais críticas, que são a modelagem e a programação. Consequentemente, foi visto a necessidade de entregar partes do sistema para os clientes, fazendo com que todos aqueles colaboradores do projeto estejam mais cientes do que está sendo desenvolvido e minimizar alterações no futuro. Dessa forma, foram propostas metodologias ágeis para desenvolvimento de softwares. Dentre elas será utilizado a FDD Feature Driven Development. Uma das características mais peculiares do FDD é a questão de possuir os relatórios de acompanhamento. Em uma linguagem mais simples, é ver o que está acontecendo no desenvolvimento do projeto. Por conta dessa visibilidade que o FDD permite mudanças, sejam elas de aperfeiçoamento de requisitos ou mudanças mais bruscas, como decisões que podem ser consideradas de riscos para o objetivo final do projeto. O presente trabalho pretende abordar como uma organização pode melhorar seus produtos oferecidos e seus serviços prestados, sob o ponto de vista dos requisitos de software, utilizando o modelo MPS.BR juntamente com a metodologia de desenvolvimento ágil FDD. Nesta proposta será focado o processo de Gerência de Requisitos do nível G de maturidade do modelo MPS.BR, relacionados especificamente a requisitos de software, juntamente com a gerência e desenvolvimento de requisitos da metodologia FDD. 2. Requisitos de Software A maior parte dos problemas nos projetos de software se deve a especificação dos requisitos de forma mal elaborada e mudanças constantes nos próprios requisitos sem a revisão ideal dos mesmos (SANTOS, 2009, p.7). E é justamente na elaboração de requisitos que as principais atividades do projeto são formuladas. Neste trabalho, para que se possa compreender o que o modelo MPS.BR e o FDD se assemelham a respeito de requisitos, será feita uma abordagem da área apresentando algumas considerações a respeito. Requisitos são elementos que devem ser analisados antes do desenvolvimento de produtos, já que se trata de objetivos ou restrições que deverão estar contidas no projeto, assim, os requisitos são condições exigidas para se alcançar determinado fim. Na linguagem computacional, os requisitos são itens que indicarão as propriedades do software, sendo estes, descritos de acordo com as especificações dos usuários do 200 XIII Encoinfo Encontro de Computação e Informática do Tocantins

3 sistema, sejam eles clientes comuns ou até mesmo grandes organizações. Diante da importância dessa etapa, a análise de requisitos é umas das fases que mais necessita de atenção no processo de desenvolvimento de software. Embora, mesmo cientes a respeito de sua importância, ainda há uma grande dificuldade em atingir o sucesso nessa tarefa em um projeto de software. Conforme sua importância no cenário de desenvolvimento de software faz-se necessário conhecer algumas das principais definições da engenharia de requisitos, etapa fundamental para o sucesso com o ciclo de vida do software Tipos de requisitos Na literatura computacional, os requisitos são classificados de variadas formas. No entanto, tradicionalmente, os requisitos são divididos em requisitos funcionais e requisitos não-funcionais. Para Sommerville (2003) os requisitos funcionais são declarações detalhadas das funções que o sistema deve executar e como deve ser seu comportamento diante de entradas e situações específicas. Ou seja, os requisitos funcionais são aqueles que descrevem o que o sistema deve realizar. Como exemplo pode ser citado o ato do sistema emitir relatórios gerenciais a partir da solicitação do usuário. Os requisitos não-funcionais são aqueles que buscam a eficiência naquilo que o sistema deve realizar, condiz com as características do software. Eventualmente, a não consideração desse requisito constitui uma das principais razões de insatisfação dos usuários com relação ao software. Como exemplo de requisito não-funcional: O tempo de resposta do sistema não deve ultrapassar dez segundos Coleta e especificação de Requisitos A especificação de requisitos concentra-se na coleta e na organização de todos os requisitos que envolvem o projeto. Quando detalhamos requisitos de forma organizada, buscamos eficiência das propriedades daqueles requisitos quando forem implementados. Ou seja, a especificação de requisitos visa atender a qualidade dos produtos atendendo todas as especificações pré-estabelecidas pelo cliente, de forma mais objetiva e organizada. 3. Metodologia FDD Feature Driven Development (do português, Desenvolvimento Guiado por Funcionalidades) é uma metodologia ágil para gerenciamento e desenvolvimento de software. O FDD é orientado a funcionalidades, e trata-se de um método que tem como objetivo a visibilidade do desenvolvimento do projeto, já que traz consigo relatórios de acompanhamento. Além disso, o FDD possui ferramentas que ajudam na análise de requisitos, como os diagramas de classe, fazendo com que as práticas da Engenharia de Software sejam realizadas de forma satisfatória. A metodologia FDD possui algumas características específicas, o que a faz ser bem reconhecida em desenvolvimento de softwares. O FDD possui relatórios precisos sobre o andamento do projeto e funcionalidades chamadas de features onde o cliente especifica a valorização destas funcionalidades. As features (características), do FDD tratam-se de requisitos funcionais. Tais requisitos surgem nas fases iniciais, onde é XIII Encoinfo Encontro de Computação e Informática do Tocantins 201

4 desenvolvido um modelo abrangente e as listas de funcionalidades são geradas. Os requisitos são detalhados, quando necessário, nas fases seguintes, onde os desenhos são feitos por funcionalidades. Já outros requisitos devem ser desenvolvidos fora das fases do FDD, servindo apenas como matérias primas para as fases em questão. Como se trata de uma metodologia onde a visibilidade é uma de suas vantagens, possui também os guias para medições e resumos de alto nível sobre os negócios que são direcionados aos gerentes e aos clientes. A Figura 1 demonstra uma visão geral sobre a estrutura do FDD de maneira ilustrativa. Figura 16 - Estrutura do FDD (PACHECO, 2009) Conforme Figura 1, o FDD possui duas fases iterativas, a primeira é chamada de Concepção e Planejamento e a segunda é chamada de Construção. Na etapa inicial, ocorre o desenvolvimento de um modelo abrangente (Develop Overall Model), na qual se trata de uma atividade que abrange todo o projeto. Nesta fase, o moderador orienta membros do domínio de negócio e até mesmo os desenvolvedores, para então, o estudo realizado ter um bom encaminhamento. Na etapa seguinte ocorre a fase de construção da lista de funcionalidades (Build Features List) que por meio de um estudo do escopo, se inicia a construção das características principais das áreas e atividades mais importantes para o desenvolvimento do projeto. Ao término desta fase, tem-se o planejamento baseado nas funcionalidades coletadas (Plan by Feature), nesse processo são definidos a forma, quando e como os requisitos serão implementados e, consequentemente, entregues. Na segunda etapa, a de Construção, ocorre os processos de desenho por funcionalidade (Design by Feature), que se iniciam os protótipos das telas, especificação dos diagramas de classes, entre outros. É nessa etapa que as funcionalidades são modeladas, sempre de acordo com a necessidade do produto final, e então é desenvolvido os códigos das funcionalidades já definidas (Build by Feature). 202 XIII Encoinfo Encontro de Computação e Informática do Tocantins

5 4. Melhoria do Processo de Software Brasileiro O MPS.BR é o programa para melhoria do processo de software brasileiro, voltado para micro, pequenas e médias empresas. Foi iniciado em 2003 pela SOFTEX (Associação para Promoção da Excelência do Software Brasileiro) com objetivo de criar um modelo com níveis de maturidade para o cenário das empresas brasileiras. A figura 2 demonstra uma visão geral sobre a estrutura do MPS.BR: Figura 17 - Estrutura do MPS.BR (Guia Geral MPS.BR - SOFTEX, 2009) O MPS.BR é baseado nas normas ISO/IEC e ISO/IEC 15504, além do CMMI para desenvolvimento. Subdivide-se em: Modelo de Referência, Modelo de Avaliação e Modelo de Negócio. O Modelo de Referência determina os requisitos que os processos das empresas devem satisfazer para estar em conformidade com o MPS.BR. É fundamentado nos requisitos de modelos de referência de processo da norma ISO/IEC e é responsável por definir os níveis de maturidade do MPS.BR, onde cada processo tem seu objetivo e os resultados esperados de sua execução. O Modelo de Avaliação determina como o processo e o método de avaliação do MPS.BR deve ocorrer e é formalizado de acordo com a norma ISO/IEC :2003. O Modelo de Negócio define os métodos de trabalho para as Instituições Implementadoras e Instituições Avaliadoras Níveis de Maturidade Cada nível de maturidade possui suas áreas de processo, e o nível de maturidade pode se dar como acrescentado quando os resultados esperados são atendidos. O MPS.BR possui níveis de maturidade, que acaba sendo um diferencial em relação aos demais modelos. São eles: G (Parcialmente Gerenciado), F (Gerenciado), E (Parcialmente Definido), D (Largamente Definido), C (Definido), B (Gerenciado Quantitativamente) e A (Em Otimização). No entanto, por razão de concisão, aqui será omitido os níveis de F a A e será abordado somente o nível G do MPS.BR. O nível G garante os processos de Gerência de Requisitos e Gerência de Projetos e consequentemente, possui atributos que garantem a execução e o gerenciamento dos processos. XIII Encoinfo Encontro de Computação e Informática do Tocantins 203

6 4.2. Processos Processos podem ser um conjunto de métodos, práticas e/ou atividades que são utilizados para desenvolver e manter a relação entre o próprio software com seus produtos. O modelo MPS.BR dividiu seus processos em: Fundamentais, Organizacionais e de Apoio. Os processos fundamentais são aqueles que vão desde o início até a execução do desenvolvimento, ou seja, eles participam de todo o ciclo de vida do software. Os processos Organizacionais são aqueles que atendem as organizações e que buscam melhorar um processo do ciclo de vida do software. Já os processos de Apoio são aqueles que contribuem como o próprio nome já diz, para o sucesso e qualidade do processo de software Processo de Gerência de Requisitos (GRE) O processo Gerência de Requisitos (GRE) consta no nível G do modelo MPS.BR, que é o primeiro nível do modelo e por isso, tem um grande impacto para a organização. O principal objetivo deste processo é o controle da evolução de todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais, não funcionais e os requisitos impostos ao projeto pela organização (SOFTEX, 2009, p.18) Segundo a SOFTEX (2009, p.20) com a implementação do processo GRE, são esperados alguns resultados: GRE 1 - Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores responsáveis de requisitos, utilizando critérios objetivos. É preciso garantir que os requisitos estejam claramente definidos, comprovados através de um documento de requisitos - que pode ter o formato que melhor atender as necessidades da organização. Após a identificação dos requisitos, eles precisam ser avaliados, tanto pela equipe técnica da organização quanto pelo cliente, com base em critérios que garantam que os requisitos propostos atendam às necessidades e expectativas do cliente e dos usuários. Um registro de aceite dos requisitos aprovados, obtido pelos fornecedores de requisitos será um marco do projeto, a partir do qual todas as mudanças nos requisitos deverão ser tratadas no interesse de minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e cronograma. A cada mudança nos requisitos aprovada, deve-se prover uma avaliação e registro de aceite da mudança aprovada. GRE 2 - O comprometimento da equipe técnica com os requisitos aprovados é obtido. Os requisitos aprovados pelos critérios estabelecidos no GRE 1 deverão obter o comprometimento da equipe técnica. Para formalizar que toda a equipe técnica tem conhecimento e aprovam os requisitos, um documento deve ser registrado, por exemplo, uma ata de reunião, ou algum outro mecanismo. A cada mudança registrada nos requisitos, um novo comprometimento da equipe deve ser obtido (SOFTEX, 2009, p.21). GRE 3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. Obter esse resultado significa que é possível rastrear a dependência entre os requisitos e o produto de trabalho, ou seja, quais artefatos são de quais produtos. Desta forma, facilitando a avaliação do impacto das mudanças nos requisitos, por exemplo, nas estimativas, nos produtos ou tarefas do projeto (SOFTEX, 2009, p.21). 204 XIII Encoinfo Encontro de Computação e Informática do Tocantins

7 GRE 4 - Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. O que resulta no estabelecimento de algum mecanismo para identificação de inconsistências entre os requisitos e os demais elementos do projeto. Todas as inconsistências identificadas devem ser registradas e ações corretivas deverão ser tomadas a fim de resolvê-las, sendo que estas ações deverão ser acompanhadas até que as inconsistências sejam resolvidas (SOFTEX, 2009, p.21-22). GRE 5 - Mudanças nos requisitos são gerenciadas ao longo do projeto. Como é raro não haver mudanças nos requisitos ao longo do projeto, espera-se que a organização realize o gerenciamento das mudanças que venham a ocorrer, juntamente com um histórico das decisões tomadas, que deverão ser tomadas com base na análise do impacto na mudança no projeto (SOFTEX, 2009, p.22). Estes são os cinco resultados esperados do propósito do processo de Gerência de Requisitos que atuam na gestão dos requisitos no MPS.BR no nível G de maturidade. Com o entendimento dos resultados esperados dos processos relacionados aos requisitos, é possível propor o mapeamento e alinhamento destes, conforme será apresentado a seguir. 5. Metodologia FDD Aplicada ao Processo de Gerência de Requisitos no nível G de Maturidade do Modelo MPS.BR Para que as empresas de desenvolvimento de software atinjam um nível de maturidade e agilidade desejável, o ideal é que os objetivos e metas da metodologia ágil FDD e do modelo MPS.BR estejam de acordo com o que foi definido no decorrer do processo Mapeamento entre o processo de GRE com FDD Para analisar se as práticas do FDD satisfazem cada um dos resultados esperados do processo de Gerência de Requisitos do nível G de maturidade do processo MPS.BR, foram definidos os critérios Satisfeito - para quando for dado como evidente, Parcialmente Satisfeito - evidenciado em partes e Insatisfeito - quando não há evidência da satisfação da prática FDD em relação aos resultados. Classificação Insatisfeito Parcialmente Satisfeito Satisfeito Critérios Não há evidências da prática na metodologia Há evidências da prática na metodologia, embora a prática não esteja plenamente atendida A prática está totalmente atendida na metodologia Tabela 5 - Critérios de análise do uso conjunto das metodologias Para cada um dos mapeamentos, foi realizada uma análise detalhada dos resultados esperados em relação às práticas encontradas no FDD, classificando cada resultado esperado de acordo com os critérios estabelecidos na tabela 1. A tabela a seguir ilustra a ordem do mapeamento, o processo do MPS.BR e o resultado esperado, a classificação de acordo com os critérios de análise e um resumo das práticas FDD que podem atender tais resultados. XIII Encoinfo Encontro de Computação e Informática do Tocantins 205

8 Tabela 6 - Resumo do Mapeamento entre o processo GRE do MPS.BR e FDD Dos cinco resultados esperados o FDD atende de forma parcialmente satisfatória os resultados GRE 1, GRE 2, GRE 4 e GRE 5. Uma descrição detalhada dos mapeamentos é apresentada a seguir, conforme ilustrado na tabela 2 (SANTOS, 2009, p.34-38): Map 1 - Na etapa Desenvolver um Modelo Abrangente realiza-se com o cliente, um estudo sobre o escopo do sistema e sobre o domínio de negócio, onde é detalhada cada área a ser modelada. A partir disso, é construída a lista de funcionalidades, representando o documento de requisitos. O FDD não evidencia práticas que estabeleçam critérios para a avaliação dos requisitos, mesmo ocorrendo à avaliação. Logo, sem os registros completos no momento onde os requisitos são levados em consideração, o FDD atende parcialmente este resultado. Map 2 - Na etapa Planejar por Funcionalidade é onde acontece a aprovação das funcionalidades e onde é gerado o Plano de Desenvolvimento revisado pelo cliente e pelos membros da equipe. Este plano deverá conter todas as funcionalidades prédefinidas, com datas de início e término. O FDD não possui critérios objetivos para a aprovação das funcionalidades. Dessa forma o FDD atende parcialmente este resultado. 206 XIII Encoinfo Encontro de Computação e Informática do Tocantins

9 Map 3 - O FDD não evidencia práticas que estabeleçam a rastreabilidade de requisitos e não implementa um sistema de acompanhamento de requisitos. Sendo assim, o FDD não satisfaz este resultado. Map 4 - Na etapa Construir por Funcionalidade é onde o cliente realiza os testes para detectar inconsistências em relação ao que ele solicitou que ocorresse nas funcionalidades. Porém o FDD não possui práticas que evidenciam o registro sobre inconsistências detectadas. Sendo assim o FDD atende parcialmente este resultado. Map 5 - No FDD, as alterações dos requisitos podem ocorrer em qualquer etapa do projeto. Neste caso, o Plano de Desenvolvimento é acrescido ou alterado com as novas datas que foram definidas nas mudanças realizadas nos requisitos. O FDD não evidencia o registro das mudanças de requisitos. Por falta desses registros o FDD atende parcialmente este resultado Resultado do mapeamento entre o processo GRE com FDD. O mapeamento do processo GRE e as práticas FDD tiveram por objetivo verificar a compatibilidade entre ambos. Com isso, foi observado que o FDD satisfaz parcialmente alguns dos resultados esperados do processo analisado, conforme a Figura 3. Figura 18 - Resultado do Mapeamento entre o processo GRE com FDD Ao observar os resultados, percebe-se que a metodologia ágil FDD concentra-se na implantação do processo de Gerência de Requisitos (GRE) do nível G de maturidade do MPS.BR, mas que deixa a desejar em algumas atividades para satisfazer totalmente os resultados do MPS.BR. Este é o caso do GR3 observado no Map3: a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. Isto pode ser facilmente resolvido com a geração de um artefato com uma matriz de rastreabilidade. Oliveira (2010, p. 53) especifica que essa matriz deve possuir a identificação dos requisitos e permitir a rastreabilidade bidirecional horizontal e vertical dos mesmos, estabelecendo as dependências entre os requisitos, os produtos de trabalho em um mesmo nível (horizontal) ou em níveis diferentes (vertical). Essa ferramenta torna-se um instrumento importante de controle do projeto, uma vez que, seu objetivo é especificar as funções e funcionalidades do projeto para atender às necessidades dos envolvidos no desenvolvimento do processo. 6. Considerações Finais XIII Encoinfo Encontro de Computação e Informática do Tocantins 207

10 É preciso buscar um equilíbrio entre os modelos de maturidade e as abordagens ágeis para alcançar o sucesso esperado no início do projeto, pois estas ferramentas auxiliam, respectivamente, na previsibilidade, estabilidade, confiabilidade, fazendo com que um controle do andamento do processo seja mais evidenciado e otimiza o desenvolvimento, fazendo com que o produto desenvolvido seja mais adaptável e flexível quando necessário. O trabalho desenvolvido apresentou um mapeamento entre a metodologia ágil FDD e o modelo de qualidade MPS.BR. Foi analisado o processo de Gerência de Requisitos (GRE) do nível G de maturidade juntamente com a metodologia FDD. Através da presente proposta constatou-se que o FDD atende parcialmente de forma satisfatória boa parte dos resultados esperados do processo GRE. Pelos resultados vistos, foi compreendido que o FDD implica em melhorias para o cumprimento dos requisitos do MPS.BR que visa atender as empresas de pequeno e médio porte na garantia da qualidade na produção de Softwares. Pode ser compreendido para estudos posteriores a necessidade de trabalhos que tratem de práticas que aprimorem os resultados que o FDD não atendeu de forma satisfatória. Tem-se como trabalho futuros a verificação sobre o nível de adequação de outras metodologias ágeis aos níveis de maturidade do modelo MPS.BR, o que visa fornecer uma ampla visão destas metodologias para pequenas e médias empresas que pretendam implementar o MPS.BR. 7. Referências Bibliográficas OLIVEIRA, Juliano. Metodologia Scrum aplicada aos processos de gerência e desenvolvimento de requisitos do modelo MPS.BR. Disponível em: < Acesso em 09 de Setembro de PACHECO, Diego. FDD: um método ágil e eficiente Disponível em: < Acesso em 29 set. de PIMENTEL, Manoel. Fluxo de processos da FDD. Disponível em: < Acesso em 27 de Setembro de SANTOS, Claudio Ari Bergossi. Mapeamento dos processos de desenvolvimento ágeis em relação ao Modelo de Melhoria do Processo de Software no Brasil (nível G). Feira de Santana f. Monografia (Trabalho de conclusão de curso em bacharel em Engenharia da Computação ) - Universidade Estadual de Feira de Santana - UEFS, Feira de Santana, SOFTEX. MPS.BR-Guia Geral: ISBN Disponível em:< Acesso em 27 de Setembro de SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. Tradução Maurício de Andrade. São Paulo: Ed. Pearson Addison Wesley, p XIII Encoinfo Encontro de Computação e Informática do Tocantins