Pós Graduação Engenharia de Software

Transcrição

1 Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT

2 Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento de software como uma disciplina de engenharia Ciclo de vida Processos de software Qualidade do processo e implicações Modelos de qualidade de processo (ênfase ISO/IEC e CMMI) Casos e relatos de experiência Avaliação

3 Ciclo de vida de software

4 Ciclo de Vida de Software Definição de Requisitos Análise Projeto Codificação Testes

5 Ciclo de Vida de Software Antes do início da construção de um sistema, deve ser definido como ele será usado, como será sua interação com os usuários e a quais funções ele se destina. Esta visão externa de seu funcionamento pode ser obtida através da Definição de Requisitos.

6 Ciclo de Vida de Software A Análise visa os seguintes objetivos: verificar a qualidade dos requisitos obtidos; descrever estes requisitos o suficiente para que atinjam o nível de detalhe adequado aos desenvolvedores. O Modelo de Análise é a base para o Projeto, mas deve-se evitar a inclusão de detalhes que pertençam ao domínio da solução e não do problema.

7 Ciclo de Vida de Software A Análise geralmente transcorre com a suposição de que há uma tecnologia perfeita disponível; já no Projeto, sabe-se que o sistema será implementado em uma plataforma de hardware, sob um sistema operacional, usando uma linguagem de programação. Em suma, a Análise interessa-se pelo o quê o sistema deve fazer, enquanto o Projeto diz respeito a como os requisitos serão implementados.

8 Ciclo de Vida de Software Na fase de Projeto há a incorporação de requisitos tecnológicos aos componentes modelados na fase de Análise, bem como a definição da plataforma e das ferramentas utilizadas. O Projeto é dependente de aspectos como as características da linguagem de programação utilizada, o modelo de persistência adotado, as características da plataforma de implementação e as características da interface com o usuário.

9 Ciclo de Vida de Software A Codificação deve ser vista como uma extensão ao processo de projetar. Deve ser direta, quase mecânica, uma vez que as decisões difíceis devem ter sido tomadas durante o projeto. A Codificação deve ser uma tradução das decisões de projeto em uma linguagem específica.

10 Ciclo de Vida de Software Teste de software é uma atividade de garantia da qualidade. O principal objetivo é analisar a qualidade do software em execução, verificando se este atende às necessidades do cliente. Os principais tipos de teste são: teste de unidade, teste de integração e teste de sistema.

11 Ciclo de Vida de Software Teste de unidade é o nível mais baixo de teste e é normalmente realizado pelo próprio desenvolvedor. Em sistemas tradicionais, a unidade pode ser considerada uma função, procedimento ou sub- rotina. Fazendo uma analogia com o modelo de objetos, poder-se se-ia considerar uma unidade como sendo um método de uma classe. Muitas vezes, pode ser difícil isolar um método de sua classe e passa a ser necessário considerar a classe como sendo a menor unidade de teste.

12 Ciclo de Vida de Software Quando as unidades tiverem sido certificadas nos testes de unidade, elas devem ser integradas em unidades maiores e finalmente no sistema. O propósito dos testes de integração é testar se as diferentes unidades trabalham corretamente em conjunto. Mesmo que as unidades tenham sido extensivamente testadas, testes de integração são necessários. Quando as unidades são combinadas, novas falhas podem ser detectadas. A combinação de unidades aumenta exponencialmente o número de caminhos possíveis.

13 Ciclo de Vida de Software O Teste de sistema objetiva assegurar que o sistema faz o que o cliente quer que ele faça. O Teste de sistema é executado no ambiente real de funcionamento mas, freqüentemente, é realizado em um ambiente de teste diferente do local em que será instalado.

14 Modelos de ciclo de vida de software

15 Modelos de Ciclo de Vida de Software Define as diferentes fases na existência de um produto de software, além de definir também os princípios e diretrizes que vão guiar a realização destas fases Um modelo de ciclo de vida organiza as macro- atividades básicas, estabelecendo precedência e dependência entre as mesmas. Define a estrutura e a filosofia segundo as quais o processo de software tem que ser executado No desenvolvimento de software, o ponto de partida para a arquitetura de um processo é a escolha de um modelo de ciclo de vida.

16 Modelos de Ciclo de Vida de Software A adoção de um ciclo de vida não é suficiente para guiar e controlar um projeto de software na prática. Outras características devem ser levadas em consideração durante a vida de um produto de software: Organização das atividades do processo Recursos humanos, hardware e software Procedimentos de operação Políticas de desenvolvimento e restrições Tipos de software

17 Modelos de Ciclo de Vida de Software As características básicas comuns a todos os modelos são: Descrever as principais fases do desenvolvimento Definir as principais atividades a serem realizadas durante cada uma das fases Especificar os produtos de cada uma das fases e insumos para o início das fases Fornecer um framework sobre o qual as atividades necessárias podem ser mapeadas

18 Modelos de Ciclo de Vida de Software Principais modelos de ciclo de vida de software: Modelo Cascata Modelo Incremental Modelo Evolutivo Modelo RAD Prototipação Modelo Espiral Modelo de Ciclo de Vida Associado ao RUP

19 Modelo Cascata Modelo mais antigo e o mais amplamente usado na engenharia de software, modelado em função do ciclo da engenharia convencional. Requer uma abordagem sistemática e seqüencial ao desenvolvimento de software Adequado em situações nas quais os requisitos são bem entendidos e o gerente do projeto confia na capacidade da equipe de desenvolver utilizando o processo

20 Modelo Cascata Especificação de Requisitos Análise Projeto Implementação e Teste de Unidade Integração Figura 2 Um típico modelo em cascata. Manutenção

21 Modelo Cascata Vantagens: A fase única de requisitos leva à especificação antes do projeto e ao projeto antes da codificação O uso de revisões ao fim de cada fase permite o envolvimento do usuário O modelo permite que se imponha um controle de configuração Cada passo serve como uma base aprovada e documentada para o passo seguinte

22 Modelo Cascata Desvantagens: O fluxo seqüencial que o modelo propõe geralmente não é seguido em projeto reais Requisitos devem ser estabelecidos de maneira completa correta e clara no início de um projeto Aplicação deve ser entendida pelo desenvolvedor desde o início do projeto Difícil avaliar o progresso verdadeiro do projeto durante as primeiras fases Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento Ao final do projeto, é necessário um grande esforço de integração e testes

23 Modelo Incremental Requisitos são segmentados em uma série incremental de produtos. O processo se repete até que um produto completo seja produzido. A segmentação de requisitos é realizada antes do desenvolvimento da primeira versão. Adotado quando os requisitos são conhecidos no início do desenvolvimento Necessidade de entrega de um produto funcional em pouco tempo A cada incremento é produzida uma versão operacional do software.

24 Modelo Incremental Vantagens: Menor custo e menos tempo são necessários para se entregar a primeira versão Riscos associados ao desenvolvimento de incrementos são menores, devido ao seu tamanho reduzido Número de mudanças nos requisitos pode diminuir devido ao curto tempo de desenvolvimento da primeira versão

25 Modelo Incremental Desvantagens: Se os requisitos não são tão estáveis ou completos quanto se esperava, alguns incrementos podem precisar ser retirados de uso e re-trabalhados O gerenciamento de custo, cronograma e configuração é mais complexo

26 Modelo Evolutivo Versões parciais são desenvolvidas que atendem aos requisitos conhecidos inicialmente A primeira versão é usada para refinar os requisitos para uma segunda versão. A partir do conhecimento sobre os requisitos, obtido com o uso, continua-se o desenvolvimento, evoluindo o produto

27 Modelo Evolutivo Vantagens: Adequado quando os requisitos não podem ser completamente especificados de início O uso do sistema pode aumentar o conhecimento sobre o produto e melhorar os requisitos

28 Modelo Evolutivo Figura 3 Um típico modelo evolutivo.

29 Modelo Evolutivo Desvantagens: Necessária uma forte gerência de custo, cronograma e configuração Usuários podem não entender a natureza da abordagem e se decepcionar quando os resultados são não satisfatórios

30 Modelo RAD O Modelo RAD (Rapid( Application Development) ) é seqüencial linear enfatizando o desenvolvimento rápido A alta velocidade é conseguida através de uma abordagem de construção baseada em várias equipes trabalhando em paralelo quando o produto pode ser dividido em módulos Adequado quando os requisitos são bem definidos, o escopo do sistema é restrito e a aplicação pode ser modularizada

31 Modelo RAD Vantagens: O ciclo de desenvolvimento é extremamente curto Desvantagens: Requer recursos humanos suficientes para criar um número adequado de equipes em projetos grandes e escaláveis Requer um comprometimento entre desenvolvedores e clientes Não é apropriado quando os riscos são grandes Não é apropriado quando o sistema precisar interagir com outros sistemas

32 Prototipação Protótipos podem ser utilizados para explorar requisitos que serão implementados posteriormente em um incremento funcional Protótipos podem ser utilizados para determinar a viabilidade técnica, de custo e de cronograma para o projeto

33 Prototipação Vantagens: Um protótipo deve ser submetido a uma avaliação, geralmente feita pelo cliente O fato de o cliente poder interagir com um protótipo ajuda a cristalizar suas necessidades funcionais e de desempenho Os desenvolvedores podem implementar os requisitos baseado no feedback do usuário

34 Prototipação Desvantagens: Riscos envolvidos no uso da prototipação: Clientes imaginam que a maior parte do trabalho já foi feita Protótipo pode crescer de maneira não planejada, se tornando um incremento funcional Protótipo pode ter um desempenho melhor do que um incremento funcional, pois não implementa toda a funcionalidade, causando frustração aos clientes quando o sistema completo é entregue

35 Modelo Espiral Modelo de ciclo de vida evolutivo que combina a natureza evolutiva da prototipação ao modelo seqüencial linear. O software é desenvolvido em uma série de versões incrementais, cada vez mais completas Cada ciclo da espiral é composto das seguintes fases: Identificar os objetivos da parte do produto que está sendo elaborada, as alternativas de implementação do produto e as restrições impostas pela aplicação das alternativas Avaliar as alternativas, identificando possíveis riscos para o projetop Planejar um protótipo para resolver os riscos Desenvolver o software segundo o modelo cascata ou o modelo iterativo

36 Modelo de Ciclo de Vida Associado ao RUP O RUP (Rational( Unified Process) é um processo de engenharia de software desenvolvido pela Rational Software e possui um framework de processo que pode ser adaptado e estendido O desenvolvimento de software é feito de forma iterativa e as interações são planejadas em número, duração e objetivos Orientado a casos de uso

37 Concepção Modelo de Ciclo de Vida Associado ao RUP Entender os requisitos gerais e determinar o escopo do esforço de d desenvolvimento Elaboração Planejar as atividades e recursos necessários; especificar as características e projeto da arquitetura Construção Construir o produto e evoluir a visão, arquitetura e planos, até que o produto esteja pronto para entrega Transição Garantir que o sistema tem o nível correto de qualidade para atingir os objetivos; realizar correções, treinamento de usuários, ajustes e adição de elementos que estavam faltando. O produto final é produzido e

38 Vantagens: Modelo de Ciclo de Vida Associado ao RUP Permite e encoraja o feedback do usuário, elicitando os requisitos reais do sistema Inconsistências entre requisitos, projeto e implementação podem ser detectados rapidamente Divisão da carga de trabalho por todo o ciclo de vida Compartilhamento de lições aprendidas, melhorando continuamente o processo Evidências concretas do andamento do projeto podem ser oferecidas durante todo o ciclo de vida

39 Exercícios

40 Modelos de Ciclo de Vida Cenário 1 Objetivo: desenvolver um sistema para acompanhamento de cirurgia cardíaca. A organização dispõe de uma quantidade adequada de desenvolvedores experientes no domínio da aplicação. O sistema pode ser modularizado.. Além disso, a organização possui um conjunto de bibliotecas de componentes reutilizáveis. Possibilidades: Cascata, Evolutivo, Espiral, Incremental, Prototipação,, RAD.

41 Modelos de Ciclo de Vida Cenário 1 Objetivo: desenvolver um sistema para acompanhamento de cirurgia cardíaca. A organização dispõe de uma quantidade adequada de desenvolvedores experientes no domínio da aplicação. O sistema pode ser modularizado.. Além disso, a organização possui um conjunto de bibliotecas de componentes reutilizáveis. Resposta: Espiral

42 Modelos de Ciclo de Vida Cenário 2 Objetivo: desenvolver um sistema para uma aplicação de comércio eletrônico. Apesar do cliente ter uma certa urgência em colocar o sistema em operação, os requisitos para o mesmo não se encontram bem definidos. O cliente se comprometeu em acompanhar o desenvolvimento. Porém, este possui dificuldades em expressar os requisitos do sistema. Possibilidades: Cascata, Evolutivo, Espiral, Incremental, Prototipação,, RAD.

43 Modelos de Ciclo de Vida Cenário 2 Objetivo: desenvolver um sistema para uma aplicação de comércio eletrônico. Apesar do cliente ter uma certa urgência em colocar o sistema em operação, os requisitos para o mesmo não se encontram bem definidos. O cliente se comprometeu em acompanhar o desenvolvimento. Porém, este possui dificuldades em expressar os requisitos do sistema. Resposta: Prototipação.

44 Modelos de Ciclo de Vida Cenário 3 Objetivo:desenvolver um sistema de cadastro de usuários de uma biblioteca virtual. Os requisitos para o sistema foram fornecidos pelo usuário de antemão e estão relativamente bem definidos. A organização dispõe de uma quantidade adequada de desenvolvedores experientes no domínio da aplicação. Porém, há uma alta disputa interna entre a equipe de desenvolvimento. Possibilidades: Cascata, Evolutivo, Espiral, Incremental, Prototipação,, RAD.

45 Modelos de Ciclo de Vida Cenário 3 Objetivo:desenvolver um sistema de cadastro de usuários de uma biblioteca virtual. Os requisitos para o sistema foram fornecidos pelo usuário de antemão e estão relativamente bem definidos. A organização dispõe de uma quantidade adequada de desenvolvedores experientes no domínio da aplicação. Porém, há uma alta disputa interna entre a equipe de desenvolvimento. Resposta: Cascata.

46 Modelos de Ciclo de Vida Cenário 4 Objetivo: desenvolver um sistema de controle de estacionamento. O cliente tem uma vaga idéia dos requisitos do sistema. Apesar disso, exige que uma versão operacional esteja em execução num prazo relativamente curto (2 meses). A organização de desenvolvimento dispõe de um conjunto de bibliotecas de componentes reutilizáveis. Entretanto, os desenvolvedores possuem baixa experiência no domínio da aplicação. Possibilidades: Cascata, Evolutivo, Espiral, Incremental, Prototipação,, RAD.

47 Modelos de Ciclo de Vida Cenário 4 Objetivo: desenvolver um sistema de controle de estacionamento. O cliente tem uma vaga idéia dos requisitos do sistema. Apesar disso, exige que uma versão operacional esteja em execução num prazo relativamente curto (2 meses). A organização de desenvolvimento dispõe de um conjunto de bibliotecas de componentes reutilizáveis. Entretanto, os desenvolvedores possuem baixa experiência no domínio da aplicação. Resposta: Evolutivo.

48 Modelos de Ciclo de Vida Necessidade de execução imediata (Evolutivo, Incremental, RAD) Disponibilidade de recursos humanos (RAD) Tecnologia inovadora (Espiral, Evolutiva) Alta disputa interna na equipe de desenvolvimento (-RAD)( Modularidade (RAD, Incremental) Disponibilidades de COTS (RAD, Cascata, Prototipação) Disponibilidade do cliente (Todos, +Evolutivo, +Prototipação+ Prototipação) Desenvolvedores experientes (RAD, Cascata) Baixa experiência no domínio de aplicação (Espiral, Evolutivo) Software crítico (Espiral) Requisitos BEM definidos (Cascata, Incremental) Necessidade de integração com outros sistemas (Espiral, -RAD) Dificuldade do cliente em expressar requisitos (Prototipação( Prototipação, Evolutivo, - Cascata, -RAD, - Incremental)

49 Referências Engenharia de Software,, Roger S. Pressman, Tradução da 5a edição, Mc Graw Hill, mhhe.com/engcs/compsci/pressman/ Engenharia de Software: Teoria e Prática, 2a edição, Shari L. Pfleeger, Prentice Hall, prenhall.com/pfleeger_br Qualidade de Software: Teoria e Prática,, Ana Regina da Rocha e outros autores, Prentice Hall, 2001.

50 Contatos Ana Candida Natali Ana Regina da Rocha