PLANO DE PROJETO DE SOFTWARE

Transcrição

1 UNIVERSIDADE FEDERAL DE SERGIPE PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO ENGENHARIA DE SOFTWARE PLANO DE PROJETO DE SOFTWARE SISTEMA DE CONTROLE DE ESTÁGIO Equipe: José Jorge Barreto Torres Igor Peterson Oliveira Santos Wenderson Campos Pereira São Cristóvão,SE 2014

2 Sumário 1. INTRODUÇÃO Âmbito do Projeto Principais Funções do Produto de Software Requisitos Comportamentais ou de Performance Gestão e Restrições Técnicas ESTIMATIVA DO PROJETO Dados históricos utilizados para as estimativas Técnicas de estimativa e resultados Técnica de estimativa Resultados Recursos do projeto Recursos humanos Recursos de software Recursos de hardware Ferramentas de apoio ANÁLISE E GESTÃO DE RISCOS Riscos do projeto Avaliação Global dos Riscos Tabela de riscos Redução e gestão dos riscos PLANEJAMENTO TEMPORAL Conjunto de Tarefas do Projeto Diagrama de Gantt ORGANIZAÇÃO DO PESSOAL Estrutura da equipe Mecanismos de comunicação Uso do edu- blog como ferramenta de apoio PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE REFERÊNCIAS BIBLIOGRÁFICAS... 16

3 1 1. INTRODUÇÃO Aqui descreve-se o projeto de software começando pelo seu âmbito, seguido das principais funções que o sistema deve prover. Os requisitos de tempo e comportamento da aplicação também são enumerados além de esboçar acerca das restrições técnicas e temporais do projeto Âmbito do Projeto Ao observar a necessidade de várias empresas do ramo educacional, a respeito da gerência e do controle no fornecimento de estagiários às empresas coligadas, assim como as alocações e acompanhamentos desses estagiários, a Lacertae SW decide lançar um produto de controle de estágio que efetua todo cadastro e manutenção dos objetos envolvidos, além de emitir relatórios gerenciais. Os usuários que utilizam o sistema possuem a característica de estarem ligados a departamentos de recursos humanos, gente e carreira ou até centrais de estágio especializadas em empresas do segmento educacional que fornecem estagiários a outras empresas, inclusive como pré-requisito de formação curricular Principais Funções do Produto de Software As principais funções que o sistema deve garantir são: Controle dos estagiários, dos estabelecimentos educacionais e das empresas vinculadas. A capacidade de qualificar os estagiários, de acordo com suas áreas de atuação. O registro de acompanhamento das horas de estágio. O histórico de alocação de vagas dos estagiários nas empresas. Uma empresa pode estar ligada a um ramo de atuação específico e pode possuir vários estabelecimentos que serão os destinos das alocações de vagas. Uma alocação de vaga deve ter o registro temporal de início e fim, bem como informações referentes à quantidade e o valor das horas alocadas Requisitos Comportamentais ou de Performance É solicitado que a interface da aplicação seja de fácil utilização, sem cores chamativas e com suporte a dispositivos móveis. O desempenho deve ser compatível com o de um sistema web comum. Também utilizar recursos interativos na carga de campos do website, a fim de se evitar pageloads excessivos, tornando a experiência do cliente mais agradável e a utilização do canal de comunicação mais leve. Quanto aos requisitos comportamentais, toda aplicação deve estar completa, sem faltar nenhuma funcionalidade - incluindo relatórios - antes de entrar em produção.

4 Gestão e Restrições Técnicas a. Restrições Técnicas No que diz respeito a hardware, a equipe de desenvolvimento pode efetuar os testes de acesso através dos próprios PCs e dispositivos móveis. Em software, torna-se necessária uma IDE Integrated Development Environment e os sistemas de apoio, que são obtidos através da MSDNAA gratuitamente, incluindo o sistema operacional para abrigar a ferramenta. b. Restrições Temporais O prazo para conclusão do projeto poderá afetar a equipe, visto que o mesmo é insuficiente para que seja realizado o desenvolvimento e o conjunto de testes de homologação. Os participantes do projeto estão alocados em outras atividades extracurriculares, o que pode resultar em um desempenho insatisfatório com relação ao empenho dos mesmos no desenvolvimento do projeto como um todo.

5 3 2. ESTIMATIVA DO PROJETO As estimativas são úteis para o acompanhamento geral e detalhado do projeto por todos os membros da equipe. Os cálculos de tempo desprendido em cada fase são levados em consideração para mensurar e provisionar tal alocação Dados históricos utilizados para as estimativas Um sistema semelhante sem utilização de interface web multi-plataforma já foi criado por uma equipe de desenvolvimento um pouco maior que a da Lacertae. Esse projeto levou cerca três meses até ser colocado em produção para o usuário final Técnicas de estimativa e resultados Aqui, descreve-se o método de medição e provisionamento de tempo do projeto através de uma técnica de estimativa comum adotada pela Lacertae SW Técnica de estimativa A técnica de estimativa de tempo eleita pela Lacertae SW é orientada a classes e de fácil utilização, conhecida como métrica de Lorenz & Kidd (Pressman, 2011). Esta métrica envolve as classes-chave do modelo e as classes de suporte que são calculadas através de um multiplicador que varia de acordo com o tipo de interface utilizada no desenvolvimento da aplicação. Os fatores multiplicadores podem ser: a. Interface não gráfica: x2 b. Baseada em texto: x2,25 c. GUI: x2,5 d. GUI complexa: x3 O cálculo das classes de suporte é realizado multiplicando-se a quantidade de classes chaves pelo fator multiplicador correspondente ao tipo de interface adotada. Em seguida é obtido o total de classes somando-se as classes-chave e as classes de suporte para finalmente multiplicar o valor total de classes pelo número médio de unidades de trabalho (dias/pessoa) por classe. A métrica de Lorenz & Kidd sugere um número de 15 a 20 dias / pessoa. Segue a fórmula: [Ch + (Ch x Mu)] x Dp onde, Ch = Quantidade de classes-chave Mu = Fator multiplicador Dp = Número de dias/pessoa (15 a 20)

6 Resultados Pelo fato de existir uma restrição temporal a respeito da alocação dos integrantes do desenvolvimento do produto de software em outros projetos, utiliza-se o fator dias/pessoa em 20. A aplicação, como já mencionado anteriormente, deve possuir interface web com suporte a diversas plataformas, tornando a GUI Graphical User Interface complexa e consequentemente adotando o fator multiplicador em três (Mu=3). São identificadas no projeto, quatro classes-chave (Ch=4). São elas: vaga, estabelecimento educacional, estagiário e alocação. Por fim, o cálculo fica em: [4 + (4 x 3)] x 20 = 320dias/pessoa Já que a equipe é formada de três membros, a quantidade de tempo estimado para o projeto é de 107 dias. Levando em consideração que um mês possui 22 dias úteis, o projeto tem uma previsão de conclusão de quatro meses e meio a cinco meses. Com a informação que o projeto tem uma duração total prevista para 320 dias úteis, dividimos o tempo estimado da forma : Planejamento: 3% = aprox. 9 dias. Requisitos, análise, desenho: 39% = aprox. 125 dias. Geração de código: 20% = 64 dias. Testes: 38% = aprox. 122 dias Recursos do projeto Recursos humanos A equipe de desenvolvimento de software é formada por três profissionais extremamente capacitados em suas áreas: José Jorge Barreto Torres o Gerente de projetos o Certificado Project Management Professional PMP o Engenheiro de Software Igor Peterson Oliveira Santos o Coordenador de desenvolvimento o Microsoft Certified Solutions Developer MCSD o Engenheiro de software Wenderson Campos Pereira o Coordenador de testes o Certificação Brasileira de Teste de Software CBTS o Microsoft Certified Solutions Developer MCSD o Engenheiro de testes e de software

7 Recursos de software Alguns dos softwares envolvidos, desde o desenvolvimento da aplicação até a publicação em um ambiente de produção, são adquiridos através da licença acadêmica MSDNAA e estão descritos a seguir: Visual Studio 2010 Professional: Contém toda suíte de desenvolvimento e testes necessária para o andamento do projeto. Visual Studio 2010 Team Foundation Server: Ambiente de integração do desenvolvimento de software, contendo diversas ferramentas colaborativas, incluindo controle de versão. Windows Server 2008 Enterprise: Sistema operacional que abriga os servidores de desenvolvimento, homologação e produção. Os serviços de apoio como IIS e outras bibliotecas adicionais estão incluídos no S.O. Oracle Database11gR2 Enterprise Edition: Banco de dados para armazenamento dos objetos do sistema, com suporte a recursos de compactação de dados, particionamento de tabelas e backup avançado Recursos de hardware Em uma blade HP, possuímos três servidores virtualizados no VMWare ESX para os ambientes de testes, homologação e produção. A configuração do hardware da blade é: BL 465C Gen (2P), com dois processadores 16-core de 2.4 GHz, 64GB RAM e dois discos SAS de 256GB em RAID Ferramentas de apoio Nas fases de concepção e planejamento do projeto, utilizamos as seguintes ferramentas de modelagem e gerência de projetos: Oracle SQL Developer: utilizada para criar os modelos conceituais e lógicos de banco de dados, além de geração dos objetos físicos. StarUML: Modelagem dos diagramas de classes e casos de uso do sistema. Microsoft Project: Gerência do projeto, alocação de recursos, estimativas de tempo, etc.

8 6 3. ANÁLISE E GESTÃO DE RISCOS Segundo (Pressman,2011) (Sommerville, 2007), o gerenciamento de riscos consiste em prever os riscos que podem afetar o cronograma do projeto ou a qualidade do software que está sendo desenvolvido e tomar providências para evitar riscos que possam vir a acontecer. Um gerenciamento eficiente de riscos torna mais fácil lidar com os problemas e assegurar que eles não conduzam\ a um orçamento inaceitável ou atraso no cronograma. O gerenciamento de riscos é particularmente importante para projetos de software, devido às incertezas inerentes à maioria dos projetos. Eles se originam de requisitos mal definidos, dificuldades na estimativa de prazos e recursos necessários para o desenvolvimento de software, dependência de habilidades individuais e mudanças de requisitos devido às mudanças nas necessidades dos clientes (Sommerville, 2007). Diante disso, as próximas seções apresentam riscos detectados para o projeto do software deste documento, Sistema de Controle de Estágio, assim como o plano de redução, supervisão e gestão de risco (RSGR) Riscos do projeto Risco Projeto Técnico Negócio Comum Especial Retenção de talentos X X Custo associado com atraso na entrega X X X O cliente não tem ideia completa do produto X X Problemas em detectar Requisitos governamentais X X X Garantia de disponibilidade do software X Subestimativas do esforço X X Tabela 1: Identificação dos Riscos do Projeto Avaliação Global dos Riscos Riscos. A seguir estão algumas perguntas e respostas, quanto à avaliação global dos a) O gestor de Software dá suporte ao projeto? Sim. O gestor é fundamental para o andamento do projeto. b) Os clientes estão entusiasmados com o projeto e o produto? Sim. Afinal, eles são os principais beneficiados com os recursos e facilidades que o software propõe. c) Os engenheiros de Software compreenderam bem os requisitos?

9 7 Sim. O processo de análise de requisitos é definido em conjunto com todas as partes envolvidas do software, o que contribui, dessa forma, para um conhecimento geral de como o software deve ser concebido. d) Os clientes estiveram envolvidos na definição de requisitos? Sim. Como foi respondido anteriormente, os clientes e usuários finais estão envolvidos e aptos a ajudar para a criação do software. e) O âmbito do projeto é estável? Até o momento, sim. Mesmo que os requisitos possam ser modificados e riscos possam ocorrer, estamos atentos e preparados para possíveis modificações do projeto. f) Os engenheiros de software possuem as competências requeridas? Sim. Os engenheiros têm experiências no mercado e a soma dessas experiências contribuirá para o bom desenvolvimento do projeto. g) Os requisitos do projeto estão estáveis? Os principais requisitos se encontram estáveis, mas esses e outros podem vir a sofrer modificações a depender de processos futuros no desenvolvimento ou na detecção de novos requisitos fundamentais para o projeto. h) A equipe de desenvolvimento tem experiência na tecnologia que será utilizada? A equipe tem experiência com boa parte das tecnologias adotadas, embora estejam sempre propensos a aprender e agregar conhecimento para o projeto. i) É adequado o número de pessoas da equipe de trabalho? Sim. Afinal, o tamanho do projeto condiz com o prazo estimado para o desenvolvimento do software. Dessa forma, a equipe de trabalho trabalhará focada na qualidade e no prazo do projeto Tabela de riscos Os riscos do projeto são identificados através das seguintes categorias: tamanho do produto, impacto de negócio, cliente, maturidade do software, tecnologia e pessoas. Estes riscos podem ser vistos na Tabela 2, e estão organizados em ordem decrescente de impactos e probabilidades: Risco Categoria Probabilidade Impacto R_01:Garantir a alta disponibilidade Tecnológico 50% Catastrófico R_02:Ausência de equipe de testes Maturidade do dedicada SW 90% Crítico R_03:Número de clientes que utilizam o produto Negócio 70% Crítico R_04:Comportamento duvidoso em Tecnológico 60% Crítico

10 8 sistemas móveis R_05:Problemas de consistência de dados R_06:Garantia da performance em caso de muitos acessos simultâneos R_07:Custo associado com atraso na Tamanho do Produto 60% Crítico Tecnológico 40% Crítico Negócio 40% Crítico entrega R_08:Retenção de talentos Pessoas 40% Crítico R_09:Requisitos governamentais Negócio 20% Crítico R_10:Não acompanhar as fases do projeto R_11:Tem pouco tempo para dedicar no projeto R_12:Não entende os requisitos técnicos R_13:Falta de acompanhamento da qualidade de software por equipe especializada R_14:O cliente não tem ideia completa do produto R_15:Custo associado com produto defeituoso Cliente 90% Moderado Cliente 90% Moderado Cliente 90% Moderado Maturidade do SW 90% Moderado Cliente 80% Moderado Negócio 50% Moderado R_16:Número de usuários do produto Tamanho do Produto 60% Moderado R_17:Reutilização de código de SW Tamanho do Produto 30% Marginal R_18:Condições ruins de ambiente de trabalho Pessoas 20% Marginal R_19:Recrutamento de especialistas com habilidades Pessoas 20% Marginal R_20:Não conhece o processo de E.S. Cliente 90% Desprezível Tabela 2: Riscos do Projeto 3.3. Redução e gestão dos riscos Para a elaboração de um plano de redução, supervisão e gestão de riscos (RSGR), define-se um ponto de corte dos nove primeiros riscos identificados na Tabela 2. Estes são apresentados a seguir. R_01: Garantira alta disponibilidade RISCO: PROB: 50% IMPACTO: Catastrófico Descrição: Garantia que o software esteja sempre disponível. Estratégia de Redução: Monitoramento constante da saúde dos serviços de infraestrutura. Plano de contingência: Adoção de um sistema de Clusters de Alta Disponibilidade. Pessoa responsável: José Jorge Barreto Torres Status: Analisando propostas de fornecedores em (12/04/2014).

11 9 R_02: Ausência de equipe de testes dedicada RISCO: PROB: 90% IMPACTO: Crítico Descrição: Não possui equipe de testes especializada e/ou pessoas alocadas para se dedicar a testes do software. Estratégia de Redução: Dedicar mais horas relativas ao teste de software por parte dos desenvolvedores Plano de contingência: Contratação de testadores certificados. Pessoa responsável: José Jorge Barreto Torres. Status: Efetuando pesquisa de mercado por recursos humanos especializados em (12/04/2014). R_03: Número de clientes que utilizam o produto RISCO: PROB: 70% IMPACTO: Crítico Descrição: Grande quantidade de clientes utilizando o produto ao mesmo tempo. Estratégia de Redução: Efetuar testes de stress para detectar os limites de utilização do produto e realizar tunning dos serviços. Plano de contingência: Adaptar hardware dos servidores quando o tunning não fizer mais diferença no desempenho. Pessoa responsável: José Jorge Barreto Torres Status: Implementando tunning de performance em (12/04/2014). R_04: Comportamento duvidoso em sistemas móveis RISCO: PROB: 60% IMPACTO: Crítico Descrição: Falhas no acesso e uso do software ou dos dados da aplicação móvel. Estratégia de Redução: Monitorar o sistema nos diferentes tipos de Sistemas Operacionais e realizar casos de testes para detectar as diversas falhas que possam surgir. Plano de contingência: Disponibilizar outro sistema, temporariamente, com as funcionalidades principais e mais utilizadas. Pessoa responsável: Wenderson Campos Pereira Status: Analisando as informações de uso do sistema em (15/04/2014). R_05: Problemas de consistência de dados RISCO: PROB: 60% IMPACTO: Crítico Descrição: Problemas de consistência no banco de dados do software. Estratégia de Redução: Monitorar periodicamente a qualidade dos dados que são inseridos no banco de dados. Plano de contingência: Fazer a restauração do banco de dados. Pessoa responsável: Wenderson Campos Pereira Status: Verificando as informações inseridas pelos usuários em (15/04/2014). R_06: Garantia da performance em caso de muitos acessos simultâneos RISCO: PROB: 40% IMPACTO: Crítico Descrição: Garantir o bom desempenho do software quando houver vários acessos simultâneos no software. Estratégia de Redução: Habilitar a compressão GZIP (GNU Zip) para o conteúdo das páginas web do sistema antes de enviar para o usuário. Plano de contingência: Diminuir a quantidade de dados trafegando pelo canal de comunicação com a finalidade de evitar sobrecarga. Pessoa responsável: Wenderson Campos Pereira Status: Avaliando os resultados de resposta das páginas do sistema em (15/04/2014).

12 10 R_07: Custo associado com atraso na entrega RISCO: PROB: 40% IMPACTO: Crítico Descrição: Problemas em adicional de custo do software associado com atraso na entrega do mesmo. Estratégia de Redução: Monitoramento constante do projeto e de suas tarefas. Plano de contingência: Ter parceiros terceirizados para desenvolvimento de parte do projeto. Pessoa responsável: Igor Peterson Oliveira Santos Status: Monitorando projeto em (16/04/2014). R_08: Retenção de talentos RISCO: PROB: 40% IMPACTO: Crítico Descrição: Busca contínua em manter os talentos das diversas áreas do desenvolvimento do software. Estratégia de Redução: Verificar ambiente de trabalho e ofertas de emprego fora da companhia. Plano de contingência: Criar planos de motivação para os funcionários. Pessoa responsável: Igor Peterson Oliveira Santos Status: Desenvolvendo planos de motivação e ambiente de trabalho em (16/04/2014). R_09: Requisitos governamentais RISCO: PROB: 20% IMPACTO: Crítico Descrição: Atividades de estágio não compatíveis com o que é descrito na Lei nº (2008). Estratégia de Redução: Buscar sempre ficar atualizado quanto à lei que regulariza as atividades dos estagiários. Plano de contingência: Alocar e concentrar desenvolvedores para adequar o sistema as mudanças na lei de forma imediata. Pessoa responsável: Igor Peterson Oliveira Santos Status: Colhendo informações sobre a lei no portal do MEC (Ministério da Educação) de forma periódica.

13 11 4. PLANEJAMENTO TEMPORAL Nesta seção descreve-se o conjunto de tarefas do projeto. Após isso, as datas e os responsáveis pela execução dessas tarefas são representados através do Diagrama de Gantt Conjunto de Tarefas do Projeto Na subseção de resultados da estimativa do projeto, estima-se um tempo de 320 dias para o desenvolvimento completo do sistema. Embora esse tempo seja calculado para uma pessoa somente, uma equipe de três compõe o desenvolvimento do projeto. Conclui-se que o tempo previsto para conclusão do sistema é reduzido para, aproximadamente, 107 dias úteis. A divisão de tarefas pela porcentagem é apresentada na Tabela 3. Tarefas Porcentagem do Tempo Planejamento 3% 3 Requisitos, análise, desenho 39% 41 Geração de código 20% 22 Testes 38% 41 Dias úteis de atividade Tabela 3: Divisão das tarefas 4.2. Diagrama de Gantt O Diagrama de Gantt é responsável pela programação de cada atividade. Além disso, as tarefas estão associadas a um ou mais elementos do projeto. Na Figura 1, está a representação do Diagrama de Gantt para o projeto do Sistema de Controle de Estágio. No Diagrama podemos destacar a etapa de Requisitos, Análise e Desenho no qual possui uma duração de 41 dias. Inicialmente, realiza-se o levantamento dos requisitos necessários para o desenvolvimento do sistema, que tem uma duração de 10 dias. Os próximos 5 dias ficam dedicados para a Definição de Casos de Uso dos sistema e para o desenvolvimento do Diagrama de Classes. Após isso, aloca-se um período de 18 dias para o projeto do Banco de Dados para, por fim, realizar e apresentar os Protótipos do Sistema em 8 dias. Na etapa de Construção, estão definidas as quatro classes-chave do projeto, as quais servem de base para mensuração do tempo de duração do projeto. São alocados 22 dias para o desenvolvimento dessas classes. A mesma quantidade de dias está definida para o gerenciamento de controle de versões. Para o período de Testes e Transição do Sistema, há uma dedicação de 41 dias. Neste período a quantidade de dias é maior que o de desenvolvimento, pois trata-se de uma etapa onde é averiguada a qualidade do que foi desenvolvido até o

14 12 momento. Para isso, está definido um período de 22 dias para os Casos de Testes. O processo final do projeto faz parte da implantação do sistema, que é uma parte bem delicada e que merece atenção, que possui duração de 15 dias úteis. Figura 1: Diagrama de Gantt do projeto

15 13 5. ORGANIZAÇÃO DO PESSOAL A equipe realiza um bom trabalho em conjunto do início ao fim do projeto. As delegações das tarefas são tomadas em consenso e a comunicação entre os membros faz com que se organizem a ponto de produzir um projeto com melhor qualidade Estrutura da equipe A equipe é formada por três membros, descritos abaixo com as respectivas funções: Nome Função José Jorge Barreto Torres jorgesamango@gmail.com Engenheiro de Software e Gerente de Projetos Igor Peterson igorpeterson@gmail.com Engenheiro de Software e Analista de Sistemas Wenderson Campos Pereira wendersonse@gmail.com Engenheiro de Software e Analista de Testes Tabela 4: Membros da equipe, contato e suas funções. Segue abaixo a descrição breve de cada função: Engenheiro de Software: Responsável pelo projeto, design da aplicação e implementação do sistema. Gerente de Projetos: Gerenciar e controlar todo o projeto, delegar funções aos membros da equipe com prazos, realizar controle de qualidade e também verificar cada etapa do projeto. Analista de Sistemas: Realiza o levantamento e análise de requisitos do software. Analista de Testes: Responsável pela definição do ambiente de testes e planejamentos e execução dos casos de testes, bem comoo reporte dos erros e defeitos encontrados Mecanismos de comunicação O processo de comunicação do time ocorre através da utilização de ferramentas colaborativas e de comunicação como Skype e Google Drive. Pelo menos duas vezes por semana acompanha-se o andamento do projeto de forma semipresencial, a fim de discuti-lo, solucionar problemas e delegar tarefas.

16 Uso do edu-blog como ferramenta de apoio A ferramenta Edu-blog é fundamental durante todo projeto, pois oferece uma dinâmica entre o professor e os alunos da disciplina. Além disso, através dessa ferramenta é possível organizar todo o conteúdo da disciplina em um só lugar. Tanto o material ofertado pelo professor quanto os links para os blogs de outros alunos com as atividades e projetos de cada grupo estão disponíveis a todos.

17 15 6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE A equipe utiliza os seguintes itens com o intuito de garantir e controlar a qualidade do produto de software: a) Gestão de Projeto de Software Realiza-se um acompanhamento constante das atividades desenvolvidas por parte de todos os envolvidos no projeto. b) Revisões Técnicas Formais - As revisões são executadas por pessoas capacitadas durante todo o ciclo, visando à identificação de erros nas fases iniciais do projeto onde o custo para a manutenção é reduzido. c) Gestão de Configuração do Software - Conjunto de atividades projetadas para controlar inúmeras correções, extensões e adaptações aplicadas durante o ciclo de vida do software de forma a assegurar um processo de desenvolvimento e evolução sistemático e rastreável. d) Métricas de Qualidade - São realizadas medições para verificar o quanto o software atende aos requisitos impostos pelo usuário. e) Análise de Riscos - Identificar, analisar e controlar os riscos, elaborando planos de redução e de contingência. f) Testes Realizar testes dentro de um processo definido, com o objetivo de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Além disso, identificar possíveis erros antes que estes se transformem em defeitos e tornem-se riscos, trazendo prejuízos para a empresa.

18 16 REFERÊNCIAS BIBLIOGRÁFICAS PRESSMAN, Roger S. Engenharia de Software. 7 ed. McGraw-Hill SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-Wesley, 2007.