UNIVERSIDADE DE PASSO FUNDO

Transcrição

1 0 UNIVERSIDADE DE PASSO FUNDO Marcelo Teixeira Uma análise do Scrum sob a perspectiva do MPSBR Passo Fundo 2007

2 1 Marcelo Teixeira Uma análise do Scrum sob a perspectiva do MPSBR Monografia apresentada ao curso de Ciência da Computação, do Instituto de Ciências Exatas e Geociências, da Universidade de Passo Fundo, como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação, sob orientação do Prof. Msc. Alexandre Lazaretti Zanatta. Passo Fundo 2007

3 2 Marcelo Teixeira Uma análise do Scrum sob a perspectiva do MPSBR Banca Examinadora: Prof. Alexandre Lazaretti Zanatta UPF Orientador Prof.ª Lis Ângela De Bortoli UPF Examinador Prof. Gilberto Speggiorin Oliveira UPF Examinador Passo Fundo 2007

4 3 Quando me perguntaram em que consistia o meu trabalho, respondi que ajudo pessoas a desenvolver software em 30 dias. E o sujeito olhou para mim e disse: Então, não tenho de esperar 180 dias para ter aquilo que não quero? Sim, exatamente, nós damos-lhe aquilo que não quer em 30 dias. Schwaber, 2002

5 4 RESUMO Este estudo consiste em apresentar as principais características do método ágil Scrum, confrontando-as com os requisitos do modelo MPSBR. Para isso, analisar-se-ão os níveis de maturidade do MPSBR, assim como os resultados esperados para cada processo comparando-os com os princípios defendidos pelas práticas do método ágil Scrum. Nos processos em que os resultados esperados pelo MPSBR não são atendidos pelas práticas do Scrum, buscam-se alternativas em outros métodos ágeis, para seu atendimento. Dessa forma, constata-se que a combinação de práticas de diversos métodos ágeis fornece a possibilidade de atender à maioria dos resultados esperados pelo MPSBR, obtendo assim aderência a este modelo de qualidade. Palavras-chaves: MPSBR, Scrum, FDD e XP.

6 5 LISTA DE FIGURAS Figura 1 - Componentes do MPSBR Figura 2 - Maturidade do MPSBR Figura 3 - Origens do Product Backlog Figura 4 - Exemplo de Product Backlog Figura 5 - Fases do método Scrum Figura 6 - Estrutura de um processo Scrum Figura 7 - Análise entre modelo MPSBR e método Scrum Figura 8 - Aderência do Scrum ao processo de Gerência de Requisitos Figura 9 - Escala de atendimento do Scrum ao processo de Gerência de Requisitos Figura 10 - Aderência do Scrum ao processo de Gerência de Projetos Figura 11 - Escala de atendimento do Scrum ao processo de Gerência de Projetos Figura 12 - Aderência do Scrum ao processo de Gerência de Requisitos Figura 13 - Escala de atendimento do Scrum ao processo de Aquisição Figura 14 - Aderência do Scrum ao processo de Medição Figura 15 - Escala de atendimento do Scrum ao processo de Medição Figura 16 - Aderência do Scrum ao processo de Gerência de Configuração Figura 17 - Escala de atendimento do Scrum ao processo de Gerência de Configuração.. 85 Figura 18 - Aderência do Scrum ao processo de Garantia da Qualidade Figura 19 - Escala de atendimento do Scrum ao processo de Garantia da Qualidade Figura 20 - Aderência do Scrum ao processo de Treinamento Figura 21 - Escala de atendimento do Scrum ao processo de Treinamento Figura 22 - Aderência do Scrum à Avaliação e Melhoria do Processo Organizacional Figura 23 - Escala de atendimento do Scrum à Avaliação e Melhoria do Processo Organizacional

7 6 Figura 24 - Aderência do Scrum às Definições dos Processos Organizacionais Figura 25 - Escala de atendimento do Scrum às Definições dos Processos Organizacionais Figura 26 - Aderência do Scrum às Adaptações para a Gerência do Projeto Figura 27 - Escala de atendimento do Scrum às Adaptações para a Gerência do Projeto. 104 Figura 28 - Aderência do Scrum ao processo de Validação Figura 29 - Escala de atendimento do Scrum ao processo de Validação Figura 30 - Aderência do Scrum ao processo de Verificação Figura 31 - Escala de atendimento do Scrum ao processo de Verificação Figura 32 - Aderência do Scrum ao processo de Soluções Técnicas Figura 33 - Escala de atendimento do Scrum ao processo de Solução Técnica Figura 34 - Aderência do Scrum ao processo de Integração do Produto Figura 35 - Escala de atendimento do Scrum ao processo de Integração do Produto Figura 36 - Aderência do Scrum ao processo de Desenvolvimento de Requisitos Figura 37 - Escala de atendimento do Scrum ao Desenvolvimento de Requisitos Figura 38 - Aderência do Scrum ao processo de Gerência de Riscos Figura 39 - Escala de atendimento do Scrum ao processo de Gerência de Riscos Figura 40 - Aderência do Scrum à Análise de Decisão e Resolução Figura 41 - Escala de atendimento do Scrum à Análise de Decisão e Resolução Figura 42 - Aderência do Scrum à Gerência Quantitativa do Projeto Figura 43 - Escala de atendimento do Scrum à Gerência Quantitativa do Projeto Figura 44 - Aderência do Scrum ao Desempenho do Processo Organizacional Figura 45 - Escala de atendimento do Scrum ao Desempenho do Processo Organizacional Figura 46 - Aderência do Scrum à Análise de Causas e Resolução Figura 47 - Escala de atendimento do Scrum à Análise de Causas e Resolução Figura 48 - Aderência do Scrum à Implantação de Inovações Figura 49 - Escala de atendimento do Scrum à Implantação de Inovações Figura 50 - Atendimento geral do Scrum ao MPSBR Figura 51 - Processos não atendidos pelo Scrum Figura 52 - Proposta para o processo de Aquisição Figura 53 - Proposta para o processo de Treinamento Figura 54 - Proposta para o processo de Gerência de Riscos Figura 55 - Proposta para o processo de Gerência Quantitativa do Projeto

8 7 Figura 56 - Proposta para o processo de Implantação de Inovações na Organização Figura 57 - Aderência das propostas ágeis ao MPSBR Figura 58 - Paralelo entre MPSBR X Scrum e MPSBR X Soluções ágeis

9 8 LISTA DE ABREVIATURAS E SIGLAS BID: Banco Interamericano de Desenvolvimento CMMI: Capability Maturity Model Integration ETM: Equipe Técnica do Modelo FCC: Fórum de Credenciamento e Controle FINEP: Financiadora de estudos e Projetos ISO/IEC: International Standards Organization / International Electrotechnical Commission MA-MPS: Método de avaliação do MPSBR MCT: Ministério da Ciência e Tecnologia MN-MPS: Modelo de negócios do MPSBR MPSBR: Melhoria de Processo de Software Brasileiro MR-MPS: Modelo de Referência do MPSBR NBR: Norma Brasileira SOFTEX: Associação para a Promoção da Excelência do Software Brasileiro

10 9 SUMÁRIO RESUMO... 4 LISTA DE FIGURAS... 5 LISTA DE ABREVIATURAS E SIGLAS... 8 SUMÁRIO... 9 INTRODUÇÃO MPSBR MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO Maturidade Processos SCRUM Definições e funcionalidades Fases dos processos do Scrum Aplicações práticas ANÁLISE DO MODELO MPSBR CONFORME AS PRÁTICAS DO MÉTODO ÁGIL SCRUM Gerência de Requisitos - GRE Gerência de Projetos - GPR Aquisição - AQU Medição - MED Gerência de Configuração - GCO Garantia da Qualidade - GQA Treinamento - TRE Avaliação e Melhoria do Processo Organizacional - AMP Definição do Processo Organizacional - DFP Adaptação do Processo para Gerência do Projeto - APG

11 Validação - VAL Verificação - VER Solução Técnica - STE Integração do Produto - ITP Desenvolvimento de Requisitos - DRE Gerência de Riscos - GRI Análise de Decisão e Resolução - ADR Gerência Quantitativa do Projeto - GQP Desempenho do Processo Organizacional - DEP Análise de Causas e Resolução - ARC Implantação de Inovações na Organização - IIO Considerações finais sobre a aderência do Scrum com o MPSBR PROPOSTAS DE APLICAÇÕES DOS MÉTODOS ÁGEIS PARA ADEQUAÇÃO AO MODELO MPSBR Proposta ao Processo de Aquisição Proposta ao Processo de Treinamento Proposta ao Processo de Gerência de Riscos Proposta ao Processo de Gerência Quantitativa do Projeto Proposta ao Processo de Implantação de Inovações na Organização Considerações finais das propostas CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS

12 11 INTRODUÇÃO Na medida em que os fatores de qualidade passaram a representar um requisito básico para a produção de software e não mais um mero fator de diferencial competitivo, inicia-se uma busca incessante pela adoção de processos de qualidade. Em se tratando diretamente ao processo de software, duas filosofias representam a garantia, ou no mínimo, a fórmula para que se adquira um produto de forma organizada e com qualidade, que são os métodos e os modelos aos quais se baseia a Engenharia de Software. Esses dois fatores são responsáveis pela escalabilidade no processo de desenvolvimento dos produtos, assim como o reconhecimento técnico do teor de qualidade do produto final. Com relação aos métodos de desenvolvimento de software, estes representam a execução ordenada das tarefas de engenharia, e esse fator pode trazer à empresa, uma performance satisfatória em termos de prazo, custos, gerenciamento, etc. Porém, somente desenvolver software de maneira seqüencial, evolutiva e bem disposta, provavelmente não trará resultados muito palpáveis para as empresas, ao passo que todo esforço despendido para estas tarefas, precisam ser avaliados, reconhecidos e aprovados. Esse reconhecimento pode ser dado através dos modelos de qualidade. Os modelos de qualidade referenciam as práticas desenvolvidas e guiadas pelos métodos, fazendo com que a combinação adequada destas, resulte no desenvolvimento de produtos com qualidade. Dentre os modelos existentes, cita-se o CMMI (Capability Maturity Model Integration), que objetiva auxiliar a organização a obter qualidade no desenvolvimento de software, além de reunir boas práticas da engenharia de software baseadas em métricas que propiciam a obtenção escalável de qualidade. No entanto, o excesso de formalidade definido pelo CMMI, pode fazer com que este se torne inviável perante algumas organizações. De posse das definições atuais acerca dos modelos de qualidade, é criado o MPSBR, um modelo brasileiro de melhoria dos processos de

13 12 software, que adota as principais definições sugeridas pelo CMMI, mas que, no entanto, tenta reduzir a sua formalidade exagerada conforme descrito por SOFTEX (2006). Para isso, o MPSBR busca resumir a hierarquia de práticas, ao mesmo tempo em que expande os níveis de maturidade, fazendo assim com que o impacto da implantação deste modelo se torne menos sensível e sua evolução se dê de forma mais pausada, o que para SOFTEX (2006), contribui para sua implantação em empresas de menor porte. Assim, o MPSBR serve ao seu propósito, o qual é inserir práticas que venham a trazer qualidade nos processos de software, principalmente, nas micro, pequenas e médias empresas brasileiras, as quais não dispõe de estrutura nem recursos para inserirem-se no modelo CMMI. No entanto, mesmo com a contenção de diversas atividades formais oriundas do CMMI, o MPSBR ainda é um modelo que exige que suas práticas sejam inseridas em um período de tempo e a um valor muitas vezes indisponíveis pelas empresas para as quais está focado. Dessa forma, a necessidade de resultados rápidos e de maneira confiável nos processos, muitas vezes faz com que as empresas optem pelos chamados métodos ágeis de desenvolvimento de software, representados nesse trabalho pelo Scrum. O Scrum, para Zanatta (2004) é um método ágil que define o desenvolvimento incremental de software. Para o autor, este método é voltado à equipe e proporciona um controle maior dos processos, pelo fato de possuir ciclos curtos de iterações. Também, este método não define técnicas nem ferramentas, mas sim a maneira com que as equipes de desenvolvimento devem se portar perante mudanças constantes nos requisitos do projeto, característica comum encontrada em empresas de pequeno porte. Portanto, define-se o Scrum como sendo adaptável em pequenas empresas, da mesma forma que se afirma ser o MPSBR, voltado ao mesmo perfil organizacional. Então, visto que os cuidados com os métodos utilizados no desenvolvimento de software representam uma etapa importante na tentativa de garantir produtos com qualidade, da mesma forma que as métricas de um modelo de qualidade podem significar o reconhecimento ao sucesso do uso de método de desenvolvimento adequado, percebe-se que se faz necessária uma ação conjunta entre método e modelo. Porém, no caso do perfil das micro, pequenas e médias empresas, resta saber se as técnicas de desenvolvimentos definidas pelo método Scrum, satisfazem as métricas de avaliação do modelo MPSBR, pois mesmo com a aparente compatibilidade, é válido lembrar que trata-se do representante dos métodos tradicionais em contrapartida com o representante dos métodos ágeis de desenvolvimento de software.

14 13 Sendo assim, o objetivo desse trabalho é, inicialmente, realizar uma análise acerca do MPSBR, em seus níveis de maturidade, processos e resultados esperados de cada processo. Também, objetiva-se analisar o método ágil Scrum, seguindo seus conceitos e práticas. Então, pretende-se constatar o nível de aderência entre método e modelo, assim como a possibilidade de aquisição de certificados de qualidade partindo-se do desenvolvimento de software baseado em métodos ágeis. Quanto a organização do presente trabalho, este é composto por 4 (quatro) capítulos organizados da seguinte forma: O primeiro capítulo apresenta o modelo de qualidade MPSBR, de forma a expor suas características e contribuições para a evolução dos processos de qualidade. Neste capítulo são identificados os processos, assim como os resultados esperados para cada processo desse modelo; No segundo capítulo, apresenta-se o método ágil Scrum, mostrando suas práticas e analisando o contexto de inserção de cada uma no processo de software; Realiza-se no terceiro capítulo uma análise acerca da aderência das práticas do Scrum quando colocadas em ponderação com as exigências de cada resultado esperado pelos processos do MPSBR. Para esta análise, atribui-se um status alcançado por cada resultado esperado após as comparações com as práticas do Scrum. Esse status oscila entre, Parcialmente e Não ; No quarto capítulo, apresenta-se para os processos do MPSBR com status de Não s, as alternativas em termos de métodos ágeis as quais não foram alcançadas pelo Scrum, mas que podem vir a ser submetidas às práticas de outros métodos ágeis e alcançar compatibilidade. Por fim, apresentam-se as considerações finais, contendo as conclusões do trabalho, dificuldades e problemas encontrados, sugestões para trabalhos futuros e também as referências bibliográficas.

15 14 1. MPSBR MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO Com o desenvolvimento iniciado em 2003 e coordenado pela SOFTEX (Associação para a Promoção da Excelência do Software Brasileiro) em conjunto com alguns colaboradores, dentre eles o MCT (Ministério da Ciência e Tecnologia), FINEP (Financiadora de estudos e Projetos) e BID (Banco Interamericano de Desenvolvimento), o MPSBR (Melhoria de Processo de Software Brasileiro) é um programa de estruturação do processo de desenvolvimento de software com o objetivo de definir um modelo de melhoria e avaliação de processo de software, preferencialmente para as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e a ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software. (WANGENHEIM ; THIRY, 2005, p. 5). Para coordenar o desenvolvimento do programa MPSBR, foram criadas 2 (duas) estruturas operacionais, o FCC (Fórum de Credenciamento e Controle) e a ETM (Equipe Técnica do Modelo), as quais, segundo SOFTEX (2006, p. 4) ancoram o apoio de representantes de Universidades, Instituições Governamentais, Centros de Pesquisas e organizações privadas. Ainda, conforme SOFTEX (2006, p. 4), o FCC, objetiva assegurar que tanto as Instituições Implementadoras como as Avaliadoras, atendam a um processo adequado de credenciamento, obedecendo a princípios éticos e de qualidade préestabelecidos. A ETM, por sua vez, atua sobre os aspectos técnicos do MPSBR como a elaboração e atualização dos Guias (Geral, Aquisição e Avaliação), processos de treinamento, publicações de Relatórios Técnicos, entre outras. A criação do MPSBR se deu, segundo SOFTEX (2006, p. 5), principalmente ao fato de que no Brasil, as empresas ligadas a área de software podem ser divididas em 2 (duas) classes: as grandes exportadoras, as quais são minoria e geralmente já possuem ou

16 15 tem condições de adquirir um modelo de qualidade para seu processo de desenvolvimento, e as micro, pequenas e médias empresas, que formam a grande massa de empresas, e que mantém seu processo de desenvolvimento de software geralmente com poucos recursos e com a necessidade da obtenção de melhorias significativas em um curto espaço de tempo. Assim, O foco principal do MPSBR, embora não exclusivo, está neste segundo grupo de empresas. Busca-se que ele seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Também, espera-se que o MPSBR seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. (SOFTEX, 2006). Tecnicamente, conforme SOFTEX (2006, p. 11), as bases normativas que servem de referência para a elaboração e manutenção deste modelo de melhoria e avaliação do processo de software, foram as normas NBR ISO/IEC e ISO/IEC Portanto, afirma-se estar esse modelo, em total conformidade com essas normas. Este modelo, também cobre o conteúdo do CMMI-SE/SW, através da inclusão de processos e resultados esperados além dos estabelecidos na Norma ISO/IEC SOFTEX (2006, p. 12). O modelo MPSBR é composto por três componentes: O Modelo de Referência (MR-MPS), Método de avaliação (MA-MPS) e Modelo de negócios (MN-MPS). Na figura 1 percebe-se que cada componente do modelo foi descrito através de documentos específicos tais como os respectivos guias.

17 16 Programa MPSBR Modelo de Referência MR - MPS Método de Avaliação MA - MPS Modelo de Negócio MN - MPS Guia Geral Guia de Aquisição Guia de Avaliação Documentos do Programa Fonte: Adaptado de (SOFTEX, 2006, p 12). Figura 1 - Componentes do MPSBR. No Modelo de Referência estão contidos: o guia geral, que descreve o MPSBR em suas definições mais comuns, assim como o detalhamento completo do modelo, estipulando os requisitos organizacionais que devem ser atendidos para estar em conformidade com o modelo, e o guia de aquisição, o qual é voltado ao serviço de aquisição de software, não servindo como requisito do MPSBR, mas como fonte de boas práticas para a aquisição de software e serviços afins. O Método de Avaliação, por sua vez fornece, através do guia de avaliação, pilares para que as instituições avaliadoras apliquem, da melhor forma, os conceitos definidos pelo modelo MPSBR. Já o Modelo de Negócios descreve as regras genéricas para a implantação do MPSBR como um todo. Essas regras abrangem as normas de implementação, certificações de consultores, programas de treinamento, etc. Por razões de fidelidade ao escopo do presente trabalho, não serão abordados temas referentes ao Método de Avaliação (MA-MPS) e ao Modelo de Negócios (MN-MPS), priorizando o Modelo de Referência (MR-MPS), mais especificamente o conteúdo do Guia Geral, no qual estão as definições necessárias para o bom entendimento do modelo MPSBR. O Modelo de Referência MR-MPS, segundo SOFTEX (2006, p. 14), define através das características comuns e do detalhamento do MPSBR, os requisitos organizacionais que devem ser atendidos para estar em conformidade com o referido modelo. Assim, são

18 17 estipulados níveis de maturidade que combinam a proporcionalidade entre os processos 1 e sua capacidade, podendo-se, dessa forma, avaliar e atribuir graus de efetividade na execução dos processos. Porém, as tarefas necessárias para o atendimento a um propósito, não são definidas no modelo MPSBR, ficando esse serviço a cargo dos usuários do modelo. 1.1 Maturidade A escala de maturidade do modelo MPSBR, as quais representam os patamares de evolução dos processos, assim como a capacidade de previsão de desempenho em execuções futuras, são formados, segundo SOFTEX (2006, p. 14), por 7 (sete) níveis: A (Em otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado), G (Parcialmente Gerenciado). Cada nível de maturidade é uma junção entre processos e capacidade dos processos, ou seja, é composto por um conjunto de processos em um determinado nível de capacidade. (WEBBER, apud SANTANA; TIMÓTEO; VASCONCELOS, 2006, p. 6). O início da escala de maturidade se dá no nível G, progredindo até o A. Cada um dos níveis indica um perfil, o qual servirá como base para a concentração dos esforços da organização em busca da melhoria. O progresso e o atendimento do nível de maturidade se obtêm, quando são atendidos todos os resultados e propósito do processo; e os atributos de processo relacionados àquele nível e aos anteriores. (WEBBER, apud SANTANA; TIMÓTEO; VASCONCELOS, 2006, p. 6). A seguir far-se-á um detalhamento de cada um dos níveis de maturidade identificando os processos que o compõe, assim como os resultados esperados de cada processo. 1 A definição de processo, segundo SOFTEX (2006, p. 14), pode ser interpretada como um propósito, acompanhado dos resultados esperados de sua execução. Também, processo pode ser visto como correspondente à área de processo no modelo CMMI.

19 Nível G Parcialmente Gerenciado O nível G de maturidade é, segundo SOFTEX (2006, p. 22), formado pelos processos Gerência de Projeto GPR e Gerência de Requisitos, os quais são individualmente descritos a seguir Gerência de Projeto GPR O propósito do processo Gerência de Projeto é, segundo SOFTEX (2006, p. 22), identificar, estabelecer coordenar e monitorar as atividades, tarefas e recursos envolvidos no projeto de um produto ou serviço. Para isso, Pfleeger (2004, p. 63) propõe um cronograma de projeto, o qual descreve o ciclo de vida do software e enumera as etapas do projeto dividindo cada uma delas em tarefas a serem cumpridas, assim como o tempo gasto em cada uma delas. O gerenciamento de um projeto de software, para Pfleeger (2004, p. 64), pode ser comparado semelhantemente à construção de uma casa, onde o processo inicia-se com duas tarefas bem abrangentes como a preparação do terreno e a construção propriamente dita. Posteriormente essas duas tarefas são divididas em etapas menores, de forma a simplificá-las, dando acabamento na parte externa da casa, com a preparação do jardim, plantio de árvores, pintura, entre outras e providenciando o acabamento interno, com as tarefas de encanamento, mobília e assim, consequentemente. Assim, espera-se uma maior compreensão das tarefas e etapas e também a obtenção de um resultado mais satisfatório em cada uma delas. A autora afirma também que os gerentes mais bem sucedidos em seus projetos e onde os produtos apresentam maior qualidade, são aqueles que adaptam, de maneira mais precisa, as técnicas de gerenciamento de projeto às características específicas dos recursos necessários a este, tanto em termos de processo, quanto de pessoas escolhidas para o projeto. Koscianski e Soares (2006, p. 146) afirmam que para o cumprimento das atividades de gerência, podem ser usadas, inclusive, ferramentas automatizadas como simuladores, gerenciadores, etc. As atividades envolvidas na Gerência de Projeto, segundo Sommerville

20 19 (2003, p. 60), mesmo sendo elaboradas da melhor forma possível, não podem garantir o sucesso do projeto de software, entretanto, um mau gerenciamento geralmente traz a este, conseqüências desastrosas em termos de prazos, custos e falhas, uma vez que a Gerência de Projeto inicia antes do trabalho técnico, prossegue à medida que o software se desenvolve do modelo conceitual para a realidade e encerra somente quando o software se torna obsoleto e é aposentado. (PRESSMAN, 1995, p. 55). Os resultados esperados para o processo GPR, segundo SOFTEX (2006, p. 22) são: GPR 1: O escopo do trabalho para o projeto está definido; GPR 2: O escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados; GPR 3: As fases do ciclo de vida do projeto são definidas; GPR 4: A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se houver necessidade, alguns ajustes são realizados; GPR 5: As tarefas, os recursos e a infra-estrutura necessários para completar o trabalho são planejados; GPR 6: O cronograma e o orçamento do projeto são estabelecidos e mantidos; GPR 7: Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridades de tratamento são determinados e documentados; GPR 8: Os dados relevantes do projeto são identificados, coletados, armazenados e distribuídos. Um mecanismo é estabelecido para acessá-los, incluindo (se pertinente) questões de privacidade e segurança; GPR 9: Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo; GPR 10: O esforço e o custo para os produtos de trabalho e tarefas são estimados baseados em dados históricos ou referências técnicas; GPR 11: O envolvimento dos interessados no projeto é planejado; GPR 12: O planejamento do projeto é revisado com todos os interessados e o compromisso com o mesmo é obtido; GPR 13: O planejamento do projeto é monitorado no que se refere à cronograma, custos, recursos, riscos, envolvimento dos interessados e dados; GPR 14: Revisões são realizadas em marcos do projeto conforme estabelecido no planejamento;

21 20 GPR 15: Registros e análise dos problemas identificados nas monitorações são estabelecidos; GPR 16: Ações corretivas são estabelecidas quando necessário e gerenciadas até a sua conclusão Gerência de Requisitos GRE Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir seus objetivos. (PFLEEGER, 2004, p. 111). Por sua vez, o gerenciamento de requisitos, é o processo de compreender e controlar as mudanças nos requisitos de sistemas. (SOMERVILLE, 2003, p. 118). O propósito do processo Gerência de Requisitos é, segundo SOFTEX (2006, p. 24) fazer um acompanhamento dos requisitos do projeto, identificando suas inconsistências com relação ao plano de trabalho do projeto, uma vez que, para Pfleeger (2004, p. 112), os requisitos precisam ser escritos de forma a estabelecer um consenso entre desenvolvedor e cliente, a respeito das funcionalidades do futuro sistema. Koscianski e Soares (2006, p. 147) citam um fato muito comum no desenvolvimento de software, que são as mutações que acontecem nos requisitos. Essas mutações podem ser causadas por mudanças na tecnologia, legislação, entre outras, porém, o caso mais comum são as mudanças solicitadas pelos próprios usuários do futuro sistema. Assim, as diversas mutações que se sucedem em um projeto de software, não podem ser consideradas como desastrosas, uma vez que sejam bem controladas. Portanto, algumas das características a considerar para que uma especificação de requisitos tenha qualidade são a rastreabilidade, a consistência e a precisão. (SOMMERVILLE apud KOSCIANSKI; SOARES, 2006, p. 147). Para que se tenha noção da relevância de um bom gerenciamento de requisitos, Boehm (apud PFLEEGER 2004, p. 112), apresenta uma escala de custos para a identificação e resolução de um problema relacionado aos requisitos nas diferentes etapas de desenvolvimento do software. Para o autor, um problema não identificado na especificação dos requisitos, e sim na fase de projeto, pode apresentar um custo 5 (cinco) vezes maior. Já, se o mesmo problema for identificado durante a codificação, o custo

22 21 poderá ser 10 (dez) vezes mais alto, durante os testes, 20 (vinte) vezes mais alto, e se for deduzido somente depois de entregue ao cliente, seu custo poderá ser 200 (duzentas) vezes mais elevado. Pelo exposto, percebe-se não ser nenhum exagero nem tampouco perda de tempo, o cumprimento adequado das tarefas de gerenciamento de requisitos, uma vez que sua ineficiência pode causar a inviabilidade do projeto. Os resultados esperados para o processo GRE, segundo SOFTEX (2006, p. 24) são: GRE 1: Uma comunicação contínua com os fornecedores de requisitos é estabelecida; GRE 2: O entendimento dos requisitos é obtido; GRE 3: A aceitação dos requisitos é estabelecida por meio de critérios objetivos; GRE 4: O comprometimento com os requisitos é estabelecido e mantido; GRE 5: A rastreabilidade entre os requisitos, os planos do projeto e os produtos de trabalho é estabelecida e mantida; GRE 6: Inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos são identificadas e corrigidas; GRE 7: Mudanças nos requisitos são gerenciadas ao longo do projeto Nível F Gerenciado O nível F de maturidade é composto, segundo SOFTEX (2006, p. 25), pelos processos do nível G, acrescidos dos processos de Aquisição, Gerência de Configuração, Garantia da Qualidade e Medição, conforme descritos a seguir Aquisição AQU As atividades de aquisição de software, segundo Pressman (1995, p. 160), são definidas pela equivalência do software a ser adquirido com seu custo final. Ou seja, no

23 22 caso de aquisição de um produto de software de baixo custo, provavelmente sejam despendidos menos recursos na sua compra, diante da realização de um processo de avaliação e desenvolvimento. No entanto, no caso de aquisição de produtos de software de valores mais consideráveis, a opção pela compra ou pelo desenvolvimento deve passar, ainda conforme o autor, pela analise das seguintes condições: Data de entrega do produto precedente a data de desenvolvimento interno, o custo de aquisição e customização menor que o custo de desenvolvimento interno, e custo de suporte externo menor que o interno. De acordo com Koscianski e Soares (2006, p. 147), no processo AQU, as necessidades, metas, critérios de aceitação e a estratégia de aquisição dos produtos são definidos e posteriormente é feito um monitoramento para assegurar que as condições préespecificadas, tais como custo e qualidade, sejam cumpridas. Os seguintes resultados, conforme SOFTEX (2006, p. 25), são esperados do processo de Aquisição: AQU 1: As necessidades de aquisição, as metas, os critérios de aceitação do produto e/ou serviço, os tipos e estratégia de aquisição são definidos; AQU 2: Os critérios de seleção do fornecedor são estabelecidos e usados para avaliar os potenciais fornecedores; AQU 3: O fornecedor é selecionado com base na avaliação das propostas e dos critérios estabelecidos; AQU 4: Um acordo que expresse claramente a expectativa, as responsabilidades e as obrigações de ambos (cliente e fornecedor) é estabelecido e negociado entre o cliente e o fornecedor; AQU 5: Um produto e/ou serviço que satisfaz a necessidade expressa pelo cliente é adquirido baseado na análise dos potenciais candidatos; AQU 6: A aquisição é monitorada de forma que as condições especificadas são atendidas, tais como: custo, cronograma e qualidade e, se necessário, ações corretivas são conduzidas; AQU 7: O produto e/ou serviço de software entregue é avaliado em relação ao acordado e os resultados da aceitação são documentados. AQU 8: O produto adquirido (caso pertinente) é incorporado ao projeto.

24 Gerência de Configuração GCO O gerenciamento de configuração é a arte de identificar, organizar e controlar modificações no software que está sendo construído por uma equipe de programação. (BABICH, apud PRESSMAN, 1995, p. 916). Já para Koscianski e Soares (2006, p. 147), o propósito do processo GCO é definir manter a integridade dos artefatos resultantes de um processo e levá-los ao entendimento dos envolvidos no projeto. Sommerville (2003, p. 550), identifica a Gerência de Configuração como responsável pela aplicação de padrões e procedimentos a um produto em desenvolvimento. Dessa forma, evitam-se eventuais conflitos entre diferentes versões de software e abre-se a possibilidade de um controle efetivo das mudanças implementadas em cada versão, assim como a maneira com que elas foram incluídas no software. A Gerência de Configuração ocupa, segundo Sommerville (2003, p. 550), uma posição semelhante a da Gerência de Qualidade, podendo essa tarefa, inclusive, ser coordenada pela mesma pessoa. Assim, depois de o software ser liberado pela equipe de desenvolvimento, este segue para os testes de controle de qualidade e posteriormente para a equipe que gerencia as bases de configurações, ficando estes responsáveis pelas mudanças que venham a ocorrer no software. Também é importante salientar que os motivos que levam um software a existir sob diferentes configurações, podem ser os diferentes computadores, diferentes sistemas operacionais, peculiaridades de diferentes clientes, entre outras. Os seguintes resultados são esperados do processo GCO, conforme SOFTEX (2006, p. 27): GCO 1: Os itens de configuração são identificados; GCO 2: Os itens de configuração gerados pelo projeto são definidos e colocados sob uma linha base; GCO 3: É estabelecido e mantido um Sistema de Gerência de Configuração; GCO 4: As modificações e liberações dos itens de configuração são controladas; GCO 5: As modificações e liberações são disponibilizadas para todos os envolvidos; GCO 6: A situação dos itens de configuração e as solicitações de mudanças são registradas, relatadas e o seu impacto é analisado;

25 24 GCO 7: A completeza e a consistência dos itens de configuração são asseguradas; GCO 8: O armazenamento, o manuseio e a entrega dos produtos de trabalho são controlados; GCO 9: A integridade das linhas bases é estabelecida e mantida, através de auditoria da configuração e de registros da Gerência de Configuração Garantia da Qualidade GQA O propósito do processo GQA é garantir que os produtos de trabalho e a execução dos processos estão em conformidade com os planos e recursos predefinidos. (SOFTEX, 2006, p. 29). Koscianski e Soares (2006. p. 147), ressalta que os produtos precisam passar por uma avaliação antes da entrega aos clientes, para que se identifiquem as não conformidades e para que ações corretivas sejam tomadas e acompanhadas até sua conclusão. Neste sentido, Sommerville (2003, p. 458), afirma que a projeção de qualidade em um produto de software, pode ser comparada a de qualquer outro produto manufaturado como automóveis, eletrodomésticos, computadores, etc, onde não se aceita a entrega com possíveis deficiências. Entretanto, no caso do software, a noção de qualidade é um conceito um pouco mais elaborado, na medida em que as especificações devem ser voltadas às características do produto definidas pelo cliente, e sendo assim, essas definições podem conflitar com as características que também fazem parte dos requisitos dos desenvolvedores, como é o caso dos aspectos de manutenção, questões éticas, legislativas, etc. Aliás, com relação à manutenção, também esta é de difícil mensuração em termos de qualidade, pois cada caso se mostra muito particular ao avaliador. Portanto, embora um produto de software possa atender a sua especificação, os usuários podem não considerá-lo um produto de alta qualidade. (SOMMERVILLE, 2003, p. 458), da mesma forma que um produto considerado de boa qualidade pelos usuários, pode não apresentar a mesma característica ao desenvolvedor. SOFTEX (2006, p. 29) indica os resultados esperados para o processo GQA: GQA 1: A aderência dos produtos aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente;

26 25 GQA 2: A aderência dos processos executados aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente; GQA 3: Os produtos de trabalho são avaliados antes de serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do projeto; GQA 4: Os problemas e as não-conformidades são identificados, registrados e comunicados; GQA 5: Ações corretivas para não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões; GQA 6: O escalonamento das ações corretivas para níveis superiores é realizado, quando necessário, de forma a garantir a solução das mesmas; GQA 7: A aderência ao processo de Garantia da Qualidade e de seus produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente Medição MED Busca-se com o processo de Medição, segundo SOFTEX (2006, p. 30) a coleta e análise dos dados relativos aos produtos desenvolvidos e aos processos implementados na organização. O processo é medido, num esforço para melhorá-lo. O produto é medido, num esforço para aumentar sua qualidade. (PRESSMAN, 1995, p. 56). Trata-se, conforme Sommerville (2003, p. 468), da extração de um valor numérico para alguns atributos de um produto ou de um processo de software, que quando cruzados com outros valores e padrões de ordem gerencial da organização, fornecem a possibilidade de conclusões a respeito de índices de aproveitamento, eficiência e de qualidade. Koscianski e Soares (2006, p. 148), lembram que no processo MED, identifica-se um conjunto de medidas, as quais são documentadas e revisadas e posteriormente define-se o método de medição, assim como as ferramentas usadas para a análise dos dados. Pressman (1995, p. 59), expressa a necessidade da fundamentação métrica na engenharia de software com a seguinte citação:

27 26 Quando se pode medir aquilo sobre o qual se está falando e expressa-lo em números, sabe-se alguma coisa sobre o mesmo; mas quando não se pode medilo, quando não se pode expressa-lo em números, o conhecimento que se tem é de um tipo inadequado e insatisfatório. (KELVIN, apud PRESSMAN, 1995, p. 59). O uso de métricas de software, no entanto, ainda encontra relutância em sua aplicação. Conforme Sommerville (2003, p. 468), as empresas resistem a este método por não visualizarem, de forma clara, os benefícios advindos de processos métricos, o que ocorre devido à precária organização de seus processos de software, os quais, nestes casos, não estão aperfeiçoados de maneira a suportar as medições. Por outro lado, Sommerville (2003, p. 468), cita algumas empresas, as quais considera conceituadas, como Hewlett-Packard, AT&T, entre outras, que fazem o uso de programas de métricas em seus processos de gerenciamento de qualidade. Essas métricas são voltadas especialmente, nestes casos, à coleta de informações relativas a defeitos de programas, processos de verificações e validações. Os resultados esperados para o processo de medição são, segundo SOFTEX (2006, p. 30): MED 1: Objetivos e atividades de medição são estabelecidos a partir das necessidades de informação e objetivos da organização; MED 2: Um conjunto adequado de medidas, orientado pelas necessidades de informação e objetivos de medição, é identificado e/ou desenvolvido, priorizado, documentado, revisado e atualizado; MED 3: As atividades coleta e armazenamento são especificadas, incluindo-se métodos e ferramentas; MED 4: As atividades de análise são especificadas, incluindo-se métodos e ferramentas; MED 5: Os dados requeridos são coletados e analisados; MED 6: Os dados e os resultados são armazenados; MED 7: As informações produzidas são usadas para apoiar decisões e para fornecer uma base objetiva para comunicação aos interessados.

28 Nível E Parcialmente Definido O nível E de maturidade é composto, segundo SOFTEX (2006, p. 32), pelos níveis G e F, com o acréscimo dos processos Adaptação do Processo para a Gerência do Projeto, Avaliação e Melhoria do Processo Organizacional, Definição do processo organizacional e Treinamento, conforme descritos individualmente a seguir Adaptação do Processo para a Gerência do Projeto APG A finalidade do processo APG é, segundo Koscianski e Soares (2006, p. 148), adaptar um conjunto de processos-padrão da organização, a fim de estabelecer e gerenciar os projetos. O processo é estabelecido e gerenciado em cada projeto, baseado na estratégia da organização. SOFTEX (2006, p. 32), estabelece os seguintes resultados esperados para o processo APG: APG 1: Um processo definido para o projeto é estabelecido de acordo com a estratégia para adaptação de processo da organização. ; APG 2: O planejamento e as estimativas das atividades do projeto são feitos baseados no repositório de estimativas e no conjunto de ativos de processos organizacionais; APG 3: O Plano do Projeto e outros planos que afetam o projeto são integrados; APG 4: O projeto é gerenciado utilizando-se o Plano do Projeto, outros planos que afetam o projeto e o processo definido para o projeto; APG 5: Os produtos de trabalho, medições e experiências documentadas contribuem para os ativos de processos organizacionais; APG 6: O envolvimento dos interessados no projeto é gerenciado; APG 7: Dependências críticas são identificadas, negociadas e acompanhadas com os interessados ; APG 8: Questões pertinentes são resolvidas com os interessados.

29 Avaliação e Melhoria do Processo Organizacional - AMP O objetivo do Processo AMP é determinar o quanto os processos-padrão da organização contribuem para alcançar os objetivos do negócio. Koscianski e Soares (2006, p. 149). Essa avaliação permite aplicar programas de melhoria contínua nos processos, com base no conhecimento dos seus pontos fortes e fracos. Segundo SOFTEX (2006, p. 34), os seguintes resultados são esperados do processo AMP: AMP 1: A descrição das necessidades e os objetivos dos processos da organização estão estabelecidos e mantidos; AMP 2: As informações e os dados relacionados ao uso dos processos-padrão para projetos específicos existem e são mantidos em repositório específico; AMP 3: Revisões dos processos-padrão da organização são realizadas em intervalos adequados para assegurar sua adequação e efetividade e manter o entendimento de seus pontos fortes e fracos; AMP 4: Registros precisos das avaliações realizadas são obtidos e mantidos acessíveis; AMP 5: Os objetivos de melhoria são identificados e priorizados e as conseqüentes mudanças nos processos são planejadas e implementadas de forma controlada e com resultados previsíveis; AMP 6: A implantação de ativos do processo organizacional ou de alterações nestes ativos são implementadas de forma controlada na organização; AMP 7: Experiências relacionadas aos processos são incorporadas nos ativos do processo organizacional; AMP 8: Dados técnicos, históricos e resultantes das avaliações são analisados e usados para melhorar os processos, recomendar mudanças nos projetos e determinar necessidades de mudanças tecnológicas.

30 Definição do processo organizacional DFP A finalidade a que se destina o processo DFP, é, segundo SOFTEX (2006, p. 36), estabelecer e manter um conjunto de processos organizacionais, aplicáveis às necessidades de negócio da organização. Koscianski e Soares (2006, p. 148), ressaltam ainda que, além de estabelecer e manter um conjunto de processos-padrão, estes devem ser documentados e definidos para qual dos processos se destinam. Também são detalhadas as atividades de cada processo, assim como os resultados esperados de cada uma. Segundo SOFTEX (2006, p. 36), os seguintes resultados são esperados do processo DFP: DFP 1: Um conjunto de processos-padrão da organização é definido e documentado, juntamente com a indicação da aplicabilidade de cada processo; DFP 2: O conjunto de processos definido é mantido em uma biblioteca de ativos de processos da organização com mecanismos de consulta e recuperação; DFP 3: Tarefas, atividades e produtos de trabalho associados aos processos-padrão são identificados e detalhados, juntamente com as características de desempenho esperadas; DFP 4: As descrições dos modelos de ciclo de vida a serem utilizados nos projetos da organização são estabelecidas e mantidas; DFP 5: São desenvolvidas estratégias para adaptação do processo-padrão de acordo com as necessidades dos projetos; DFP 6: O repositório de medidas da organização é estabelecido e mantido Treinamento TRE O objetivo do processo de Treinamento é, segundo SOFTEX (2006, p. 37), prover o conhecimento sobre o projeto, com um profissional hábil o suficiente para executar suas funções de forma efetiva. Koscianski e Soares (2006, p. 149), destacam que são inúmeras as estratégias que podem ser adotadas para a execução do processo de treinamento, particulares a cada caso.

31 30 Para Pfleeger (2004, p. 367), o processo de treinamento relaciona o modo com que as tarefas estão atualmente sendo executadas com a forma com que estas passarão a ser desenvolvidas a partir da implementação do software ou de suas modificações. Este deveria ser o objetivo claro do treinamento ao usuário, porém, em muitos casos, na medida em que os usuários se concentram em como manipular o software, em vez do assunto em questão, o aprendizado pode diminuir, ao invés de aumentar (OPPENHEIMER, apud PFLEEGER, 2004, p. 369), ou seja, os usuários muitas vezes se preocupam com os fatores estéticos do projeto, muito mais que sua própria funcionalidade. Além do mais, na maioria dos casos, há uma resistência muito grandes por parte dos usuários, que se vêem forçados a interromper suas atividades habituais para sujeitarem-se a um novo aprendizado. Também, ressalta-se que há um treinamento por parte do operador, para que possa desempenhar uma boa assistência aos usuários. Porém, neste caso, há uma distinção com relação ao treinamento do usuário, sendo que o operador procura abordar como o software funciona, enquanto que a preocupação do usuário é saber o que o software faz. Exemplificando, esse caso é semelhante à relação entre um motorista e um mecânico, sendo este o responsável pelo bom funcionamento do carro e, mesmo exercendo este papel vital, o mecânico pode nunca precisar dirigir o carro. Da mesma forma, o operador de um software realiza um trabalho que foge as funções principais do produto, ou seja, ele realiza tarefas suplementares que apóiam as funções principais, como acessos ao sistema, gerenciamento de backup, instalações de novos dispositivos, entre outras, e nem por isso precisa operar a funcionalidade principal do programa. Os seguintes resultados são esperados para o processo TRE: TRE 1: Uma estratégia de treinamento é planejada e implementada como objetivo de atender as necessidades de treinamento dos projetos e da organização; TRE 2: As necessidades de treinamento que são responsabilidade da organização são identificadas; TRE 3: Para garantir que todos os indivíduos tenham o conhecimento e habilidades requeridas para executar suas atividades, é estabelecida uma estratégia para treinamento que contemple mecanismos, materiais e instrutores qualificados; TRE 4: O treinamento é conduzido e registrado; TRE 5: A efetividade do treinamento é avaliada.

32 Nível D Largamente Definido O nível D de maturidade é composto pelos níveis G, F e E, assim como pelos processos Desenvolvimento de Requisitos, Integração do Produto, Solução Técnica, Validação e Verificação, descritos na seqüência do texto. Koscianski e Soares (2006, p. 150), ainda citam Instalação do Produto e Liberação do Produto como processos do nível D de maturidade. Entretanto, não se tratará dos detalhes desses dois processos nesse trabalho pelo fato de os mesmos não estarem presentes no Guia Geral do MPSBR Desenvolvimento de Requisitos DRE Pressman (1995, p. 231), defende a idéia de que os requisitos devem ser estipulados contando-se com a participação ativa, tanto do usuário como do desenvolvedor, formulando, o usuário, conceitos de desempenho e funcionalidade do software, enquanto que o desenvolvedor deve assumir uma postura crítica, interrogativa e solucionadora de possíveis problemas. As tarefas de desenvolvimento de requisitos podem transmitir a idéia de uma tarefa simples de debate entre desenvolvedor e usuário acerca das definições do projeto a ser elaborado, o que, segundo Pressman (1995, p. 232), é um equívoco, uma vez que o conteúdo da comunicação entre as partes é muito elevado, além de estar nestas tarefas a possibilidade da descoberta de ambigüidades e interpretações errôneas nas interações. Uma prova disso pode ser constatada no exemplo citado por Pfleeger (2004, p. 114), onde o usuário expõe um requisito, a saber: As informações sobre a qualidade da água devem estar acessíveis imediatamente. Diante deste requisito, percebe-se que o cliente tem uma noção clara do significado de imediatamente. No entanto, o desenvolvedor precisa questioná-lo até que este exponha a sua intenção, e assim o requisito pode ser reformulado da seguinte forma: Os requisitos sobre a qualidade da água devem estar acessíveis cinco segundos após a solicitação. No intuito de tornar todos os requisitos possíveis de serem testados, Robertson e Robertson (apud PFLEEGER, 2004, p. 114), elaboram as seguintes situações:

33 32 1. Especificar uma descrição quantitativa de cada advérbio e cada adjetivo; 2. Trocar os pronomes pelos nomes específicos das entidades; 3. Garantir que todo nome seja definido em um local exato na documentação. Assim sendo, Koscianski e Soares (2006, p. 149) definem a finalidade do processo DRE como sendo a de estabelecer os requisitos funcionais, os quais remetem às funções do produto de software a ser construído, e os requisitos não-funcionais, os quais se referem às expectativas de qualidade, desempenho, confiabilidade e segurança do produto. SOFTEX (2006, p. 38), aponta os resultados esperados para o processo DRE: DRE 1: As necessidades e expectativas, restrições e requisitos de interface do cliente são identificadas; DRE 2: Um conjunto definido de requisitos funcionais e não-funcionais que descrevem a solução do problema a ser resolvido é estabelecido a partir das necessidades, expectativas, restrições e requisitos do cliente e da interface ; DRE 3: Os requisitos do cliente são refinados, elaborados e alocados para o desenvolvimento dos requisitos do produto e dos componentes do produto; DRE 4: Conceitos operacionais e cenários são desenvolvidos; DRE 5: A definição das funcionalidades requeridas é desenvolvida e mantida; DRE 6: Os requisitos são analisados para assegurar que são necessários e suficientes e para balancear as necessidades dos interessados com as restrições existentes; DRE 7: Os requisitos são validados Integração do Produto ITP O processo ITP visa, segundo SOFTEX (2006, p. 40), reunir os componentes do software de forma a se criar um produto integrado e consistente com o projeto, ou seja, satisfazendo os requisitos funcionais e não-funcionais, de acordo com o esperado. No entanto, alguns cuidados devem ser seguidos para que a integração dos diversos componentes de um produto transcorra de forma satisfatória. Pfleeger (2004, p. 290), menciona que a combinação do software só pode ser executada quando há absoluta certeza de que a funcionalidade dos componentes individuais satisfaz os requisitos do projeto. Assim sendo, diversas estratégias de integração, como top-down, big-bang, sanduíche,