Modelos de Ciclo de Vida de Software

Transcrição

1 Análise 1 Modelos de Ciclo de Vida de Software Um ciclo de vida do software é um período aproximado do desenvolvimento de software, com capacidade de entrega específica e marcos dentro de cada fase. Um modelo de ciclo de vida do software e uma abstração do processo de desenvolvimento do software, que é conveniente usar para fins de planejamento. O modelo de cascata foi o primeiro modelo de ciclo de vida de software a ser largamente utilizado. Em seguida, destaca alternativa de modelos de ciclo de vida de software que tem sido desenvolvido para superar algumas das limitações do modelo de cascata. Esses são modelo de ciclo de vida prototipação descartável, modelo de ciclo de vida de desenvolvimento incremental (também referido como prototipação evolucionária), o modelo espiral, e o Processo de Desenvolvimento de Software Unificado. Modelo de ciclo de vida em cascata Software tipicamente costa 80% do total do orçamento de um projeto, enquanto que nos primeiros dias do desenvolvimento de software, o hardware foi, de longe, o maior custo do projeto. O termos engenharia de software foi cunhado para ser referir ao gerenciamento e métodos técnicos, procedimentos, e requisitos de ferramentas para efetivamente desenvolver sistema de software em larga escala. Com a aplicação do conceito de engenharia de software, muitos sistemas de software tem sido desenvolvido em larga escala usando um ciclo de vida do software. O primeiro modelo de ciclo de vida do software largamente utilizado, frequentemente se refere como modelo em cascata. É geralmente considerado o ciclo de vida do software convencional ou clássico. O modelo em cascata é um modelo de processo idealizado no qual cada fase é completada antes que a próxima fase seja iniciada, e um projeto muda de uma fase para outra sem interação ou sobreposição.

2 2 Modelos de Ciclo de Vida do Software Limitações do modelo em cascata Na prática alguma sobreposição é frequentemente necessária entre fases sucessivas do ciclo de vida, bem como alguma interação entre fases quando erros são detectados. Além disso, para alguns projetos de desenvolvimento de software, o modelo em cascata apresenta os seguintes problemas significantes: Requisitos de software, um fator chave em qualquer projeto de desenvolvimento de software, não são devidamente testados até um sistema estar funcionando está disponível para demonstrar para o usuário final. De fato, vários estudos tem mostrado que erros nas especificações de requisitos são frequentemente as últimas a serem detectadas (frequentemente não até o sistema ou teste de aceitação) e o mais custoso para corrigir. Um sistema funcionando torna-se disponível somente apenas no final do ciclo de vida. Assim, o projeto principal ou problemas de desempenho podem passar despercebidos até o sistema estar quase operacional, momento em que é normalmente tarde demais para tomar uma ação efetiva. Protótipagem throwaway Prototipos throwaway podem ser usados para ajudas a esclarecer requisitos de usuários. Essa abordagem é particularmente útil para receber feedback da interface com o usuário e pode ser usada para sistemas que tem uma interface complexa com o usuário. O protótipo throwaway pode ser desenvolvido depois de uma especificação preliminar de requisitos. Dando aos usuários a capacidade de exercitar o protótipo, um valioso feedback pode ser obtido que é por outro lado frequentemente difícil de conseguir. Baseado nesse feedback, uma especificação de requisitos revisada pode ser preparada. Subsequente procede o desenvolvimento, seguindo o ciclo de vida de software convencional. O protótipo throwaway, particularmente da interface do usuário, tem sido mostrado para ser uma solução efetiva para o problema de especificação de requisitos para sistema de informação interativa.

3 Análise 3 O maior problema ajudou superar as barreiras de comunicações que existiam entre os usuários e os desenvolvedores. Protótipos throwaway podem também ser usados para prototipação experimental de projeto. Isso pode ser usado para determinar se certo algoritmo está logicamente correto ou determinar se eles encontrarem seus objetivos de desempenho. Prototipação evolutiva por desenvolvimento incremental A abordagem da prototipação evolutiva é um formulário de desenvolvimento incremental no qual o protótipo envolve através de vários sistemas operacionais intermediários no sistema de entrega. Essa abordagem pode ajudar em determinar se o sistema encontra seus objetivos de execução e nos componentes de testes críticos do projeto. Também reduz o risco de desenvolvimento por espalhar a implementação ao longo de um período mais longo. Casos de uso e cenário baseado em diagramas de comunicação podem ser usados para auxiliar na seleção de subconjuntos do sistema para cada incremento.

4 4 Modelos de Ciclo de Vida do Software Um objetivo da abordagem da prototipação evolutiva é ter um subconjunto de sistemas trabalhando antes, que é então gradualmente construído. É vantajoso se a primeira versão incremental do sistema de testes através de um caminho completo o sistema de entrada externa para saída externa. Combinando prototipação throwaway e desenvolvimento incremental Com a abordagem do modelo de ciclo de vida de desenvolvimento incremental, um sistema funcionando na forma de um protótipo evolutivo está significativamente disponível antes que com o convencional ciclo de vida em cascata. Não obstante, cuidado muito maior deve ser tomado no desenvolvimento desta espécie de protótipo do que com um protótipo throwaway porque forma a base do produto pronto; assim, a qualidade de software tem que ser construída dentro do sistema do início e não pode ser como um pensamento futuro. Em particular, a arquitetura de software precisa ser projetada cuidadosamente e todas interfaces especificadas. O ciclo de vida em cascata convencional é significativamente impactado pela introdução da prototipação throwaway ou desenvolvimento incremental. Também é possível combinar as duas abordagens. Um exercício de prototipação throwaway é realizado para esclarecer os requisitos. Depois que os requisitos são entendidos e uma especificação é desenvolvida,

5 Análise 5 um ciclo de vida de desenvolvimento incremental é obtido, mais mudanças nos requisitos podem ser necessárias devido às alterações no ambiente do usuário. Modelo espiral O modelo espiral é um modelo de processo de risco dirigido originalmente dirigido por Boehm (1988) para chamar a atenção para problemas conhecidos com modelos de processos anteriores do ciclo de vida do software em particular, o modelo em cascata. O modelo espiral é planejado para abranger outros modelos de ciclo de vida, assim como o modelo em cascata, o modelo de desenvolvimento incremental, e o modelo de prototipação throwaway. No modelo espiral, a coordenada radial representa custo, e a coordenada angular representa progresso na realização de um ciclo do modelo. O modelo espiral consiste nos seguintes quatro quadrantes: 1. Define objetivos, alternas, e restrições. Planejamento detalhado para este ciclo: identifica objetivos e abordagens alternativas para alcançá-los. 2. Análise de riscos. Avaliação detalhada de atuais riscos do projeto; planejar atividades para serem executadas para aliviar esses riscos. 3. Desenvolve o produto. Trabalha no desenvolvimento do produto, assim como análise de requisitos, projeto ou codificação. 4. Planeja o próximo ciclo. Avalia o progresso feito nesse ciclo e começa a planejar o próximo ciclo. Cada ciclo do modelo espiral interage através desses quadrantes, embora o número de ciclos é específico do projeto. As descrições das atividades em cada quadrante são planejadas para ser geral o suficiente que elas possam ser incluídas em qualquer ciclo. O objetivo da modelo espiral é ser dirigido pelo risco, então os riscos em dado ciclo são determinados pelo quadrante de análise de riscos. Para gerenciar esses riscos, como prototipação de requisitos se a análise de risco indica que os requisitos de software não são claramente entendidos. Esses riscos específicos do projeto são

6 6 Modelos de Ciclo de Vida do Software denominados motoristas do processo. Para qualquer motorista do processo, um ou mais atividades específicas do projeto precisam ser realizadas para gerenciar o risco. Processo unificado de desenvolvimento de software O processo unificado de desenvolvimento de software, é um processo de software de caso de uso dirigido que utiliza a notação UML. O USDP PUDS consiste é também conhecido como o Processo Unificado Racional (RUP). USDP/RUP é um processo popular para desenvolvimento de software baseado em UML. O USDP consiste em cinco fluxos de trabalho do núcleo e quatro fases e é interativo. Um artefato é definido como uma peça de informação que é produzida, modificada, ou usada por um processo. Um fluxo é definido como uma sequência de atividades que produz um resultado de valor observável. Uma fase é definida como o tempo entre dois marcos maiores durante a qual um bem definido conjunto de objetivos é encontrado, artefatos são completados e decisões sobre se muda para a próxima fase são feitas. Há normalmente mais que uma iteração (repetição) na fase; assim, uma iteração de fase na USDP corresponde a um ciclo no modelo espiral. Cada ciclo passa por todas as quatro fases e endereços do desenvolvimento de um núcleo do fluxo de trabalho. Os fluxos e produtos de cada fluxo são: 1. Requisitos. O produto do fluxo dos requisitos é o modelo do caso de uso. 2. Analise. O produto do fluxo das análises é o modelo de análise. 3. Projeto. Os produtos do fluxo de projeto são o modelo desenhado e o modelo desenvolvido. 4. Implementação. O produto do fluxo da implementação é o modelo de implementação.

7 Análise 7 5. Teste. O produto do fluxo de teste é o modelo de teste. Como o modelo espiral, o USDP é um processo de risco dirigido. As fases do ciclo de vida do USDP são: 1. Início. Durante a fase inicial, a ideia de semente é desenvolvida para um nível suficiente para justificar entrar na fase de elaboração. 2. Elaboração. Durante a fase de elaboração, a arquitetura de software é definida. 3. Construção. Durante a fase de construção, o software é construído para o ponto em que esteja pronto para lançamento à comunidade de usuários. 4. Transição. Durante a fase d transição, o software é entregue à comunidade de usuários. Atividades do ciclo de vida do software Seja qual for o ciclo de vida de software adotado, as atividades de engenharia de software brevemente descreveu a seguir o que precisará para ser executado. Análise de requisitos e especificação Nessa fase, os requisitos dos usuários são identificados e analisados. Os requisitos do sistema a ser desenvolvido são especificados na Especificação de Requisitos do Software (ERS). A ERS é uma especificação externa do software. Seu objetivo é fornecer uma descrição completa de qual é o comportamento externo do sistema sem descrever como o sistema funcionará internamente. Com alguns sistemas, por exemplo sistemas embutidos, na qual o software é parte de uma sistema maior de hardware/software, é provável que uma análise de requisitos do sistema e a fase de especificação anteceda as análises de requisitos e especificação do software. Com essa abordagem, requisitos funcionais do sistema são distribuídas para software e hardware antes de começar a análise de requisitos de software. Projeto de arquitetura Uma arquitetura de software separa a estrutura global do sistema, em termos de componentes e suas interconexões, dos detalhes internos dos componentes individuais. A ênfase nos componentes e suas interconexões refere-se algumas vezes como programação em larga escala, e projeto detalhado dos componentes individuais se refere como programação em curta escala. Durante essa fase, o sistema é estruturado dentro dos seus componentes constituídos e as interfaces entre esses componentes são definidas. Projeto detalhado Durante a fase de projeto detalhado, os detalhes dos algoritmos de cada componente do sistema são definidos. Isso é frequentemente alcançado pelo uso de uma notação Linguagem de Projeto de Programa, também chamado como Português Estruturado ou pseudocódigo. As estruturas de dados interna também são projetadas. Codificação Durante a fase de codificação, cada componente é codificado na linguagem de programação selecionada para o projeto. Normalmente um conjunto de código e documentações padrão é aderido.

8 8 Modelos de Ciclo de Vida do Software Testando o software Por causa da dificuldade de detecção de erros e então localizar e corrigir os erros detectados, sistemas de software são normalmente testados em vários estágios. Teste individual e integrado são abordagens de teste caixa branca, requer conhecimento do interior do software; teste do sistema é uma abordagem caixa preta baseada nas especificações de requisitos de software, sem conhecimento do interior do software. Teste de unidade No teste de unidade, um componente individual é testado antes que seja associado com outros componentes. Abordagens de testes de unidade utilizam critérios de cobertura de teste. Frequentemente usado o critério de cobertura de teste são cobertura de declaração e cobertura de ramo. Cobertura de declaração requer que cada declaração seja executada pelo menos uma vez. Cobertura de ramo requer que cada resultado possível de cada ramo seja teste pelo menos uma vez. Teste integrado Teste de sistemas é o processo de testar hardware e sistema de software integrado para verificar que o sistema encontrou seus requisitos especificados. O sistema como um todo ou subsistemas principais são testados para determinar conformidade com as especificações de requisitos. Para alcançar maior objetividade, é preferível ter realizado o teste do sistema por uma equipe de teste independente. Durante o teste do sistema, várias características do sistema de software precisam ser testadas. Esses incluem: Teste funcional. Para determinar que o sistema executa as funções descritas nas especificações de requisitos. Teste de carga. Para determinar se o sistema pode manipular a grande e variada carga de trabalho que é esperado manipular quando estiver operando. Teste de desempenho. Para testar que o sistema corresponde às suas exigências de tempo de resposta. Teste de aceitação A organização do usuário ou seu representante normalmente executam o teste de aceitação, tipicamente na instalação do usuário, antes da aceitação do sistema. A maioria das questões relacionadas ao teste do sistema também aplica o teste de aceitação. Exercícios 1. O que é um ciclo de vida do software? a) A vida do software. b) Uma abordagem cíclica do desenvolvimento de software. c) A vida do desenvolvimento de software em ciclos. d) Uma abordagem em fases do ciclo de desenvolvimento de software. 2. Qual é o modelo do ciclo de vida em cascata? a) Software desenvolvido sob uma cachoeira. b) Um modelo de processo no qual cada fase é completada antes que a próxima fase seja iniciada. c) Um modelo de processo na qual as fases são sobrepostas. d) Um modelo de processo no qual as fases são cíclicas. 3. Quais das seguintes opções é uma limitação do modelo do ciclo de vida em cascata?

9 Análise 9 a) O software é desenvolvido em fases. b) Cada fase é completada antes que a próxima fase seja iniciada. c) O desenvolvimento de software é cíclico. d) Os requisitos de software não são corretamente testados até o sistema de trabalho estar disponível. 4. Quais das seguintes abordagens podem superar as limitações na questão anterior? a) Desenvolvimento do software em fases. b) Prototipação throwaway. c) Prototipação evolucionário. d) Desenvolvimento incremental. 5. O que é a prototipação evolucionária? a) Desenvolvimento do software em fases. b) Prototipação throwaway. c) Desenvolvimento dirigido por risco. d) Desenvolvimento incremental. 6. Qual a ênfase da abordagem do modelo espiral? a) Desenvolvimento do software em fases. b) Prototipação throwaway. c) Desenvolvimento dirigido por risco. d) Desenvolvimento incremental. 7. O que é teste de caixa-branca? a) Teste de unidade. b) Teste de integração. c) Teste com conhecimento do interior do sistema. d) Teste sem conhecimento do interior do sistema. 8. O que é teste de caixa-preta? a) Teste do sistema. b) Teste de integração. c) Teste com conhecimento do interior do sistema. d) Teste sem conhecimento do interior do software. Bibliografia Software modeling and design: UML, use cases, patterns, and software architectures Hassan Gomma USA: Cambridge University Press, 2011 Software development and professional practice John Dooley USA: Apress, 2011