Definições e ciclo de vida

Transcrição

1 Definições e ciclo de vida

2 A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software. É a aplicação sistemática de conhecimentos científicos na criação e construção de soluções com um bom custo benefício para resolução de problemas práticos da sociedade.

3 Abrange um conjunto de três elementos fundamentais: Métodos, Ferramentas e Procedimentos Métodos: proporcionam os detalhes de como fazer para construir o software.

4 Planejamento e estimativa de projeto Análise de requisitos de software e de sistemas Projeto da estrutura de dados Codificação Teste Manutenção

5 Ferramentas: dão suporte automatizado aos métodos. existem atualmente ferramentas para sustentar cada um dos métodos quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering

6 Procedimentos: constituem o elo de ligação entre os métodos e as ferramentas; sequência em que os métodos serão aplicados produtos que se exige que sejam entregues controles que ajudam assegurar a qualidade e coordenar as alterações marcos de referência que possibilitam administrar o progresso do software.

7 O processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido: 1. DEFINIÇÃO, 2. DESENVOLVIMENTO e 3. MANUTENÇÃO.

8 Software é: (1) Instruções (programas) de computador que, quando executadas, produzem a função e o desempenho desejados; + (2) estruturas de dados que possibilitam que os programas manipulem adequadamente a informação; + (3) documentos que descrevem a operação e o uso dos programas. Roger Pressman

9 Um conjunto de instruções que quando executadas produzem a função e o desempenho desejados, estruturas de dados que permitam que as informações relativas aos problema a resolver sejam manipulados adequadamente e a documentação necessária para uma melhor operação e entendimento. Não consiste apenas em um programa de computador, mas também todos os dados de documentação e configuração selecionados Conjunto de programas Arquivos de configuração Documentação do sistema Documentação para o usuário Site contendo informações e atualizações do sistema

10 O Software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico: Custos são concentrados no trabalho de engenharia. Projetos não podem ser geridos como projetos de manufatura. Fábrica de Software!

11 Software não desgasta! Software não é sensível aos problemas ambientais que fazem com que o hardware se desgaste. Ver curvas de falha, páginas 14 e 15 do Pressman. Toda falha indica erro de projeto ou implementação: manutenção do SW é mais complicada que a do HW.

12 A maioria dos softwares é feita sob medida e não montada a partir de componentes existentes.!= Hardware. Situação esta mudando: Orientação a objetos. Reusabilidade é o Santo Graal (diminui custos e melhora projetos).

13 Construção Definição o que Desenvolvimento 1. Análise de Sistema 2. Planejamento do Projeto 3. Análise de Requisitos como 1. Projeto de Software 2. Codificação 3. Teste SOFTWARE PRODUTO Atividades de Apoio 1. Revisões 2. Documentação 3. Controle de Mudanças Operação Manutenção mudanças 1. Entender 2. Modificar 3. Revalidar

14 Alguns ciclos de vida mais conhecidos são: Ciclo de Vida Clássico (Cascata) Prototipação Modelo Espiral Desenvolvimento Iterativo Evolutivo

15 natureza do projeto e da aplicação métodos e ferramentas a serem usados ou disponíveis controles e produtos que precisam ser entregues prazos e recursos disponíveis

16 modelo mais antigo e o mais amplamente usado da engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática, sequencial ao desenvolvimento de software

17 Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

18 Definição: o que será desenvolvido. Análise do sistema : define o papel de cada elemento num sistema baseado em computador, atribuindo, em última análise, o papel que o software desempenhará. Planejamento do projeto de software : assim que o escopo do software é estabelecido, os riscos são analisados, os recursos são alocados, os custos são estimados e as tarefas e a programação de trabalho, definidas. 18

19 Definição: o que será desenvolvido. Análise de requisitos : o escopo definido para o software proporciona uma direção, mas uma definição detalhada do domínio da informação e da função do software é necessária antes que o trabalho se inicie. 19

20 Desenvolvimento: como será desenvolvido. Projeto de software : traduz os requisitos do software num conjunto de representações que descrevem a estrutura de dados, a arquitetura, o procedimento algorítmico e as características de interfaces. Codificação : as representações do projeto devem ser convertidas numa linguagem artificial que resulte em instruções que possam ser executadas pelo computador. A etapa de codificação realiza essa conversão. Realização de testes do software : logo que é implementado numa forma executável por máquina, o software deve ser testado para que se possa descobrir defeitos de função, lógica e implementação. 20

21 Manutenção: mudanças que estão associadas à: CORRECÃO DE ERROS, ADAPTAÇÕES e AMPLIAÇÕES. EVOLUTIVAS Três tipos de mudanças são encontradas durante a fase de manutenção: 21

22 Correção: mesmo com as melhores atividades de garantia da qualidade, é possível que o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir defeitos. Adaptação: com o passar de tempo, o ambiente original para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa resulta em modificações no software a fim de acomodar mudanças em seu ambiente. Melhoramento funcional: à medida que o software é usado, o cliente/usuário reconhecerá funções adicionais que oferecerão benefícios, estendendo o software para além de suas exigências funcionais originais. 22

23 Atividades de proteção : complementam as fases e passos descritos na visão genérica da Engenharia de Software. Revisões : são feitas para garantir que a qualidade seja mantida à medida que cada etapa é concluída. Documentação : desenvolvida e controlada para garantir que informações completas sobre o sistema e o software estejam disponíveis para uso posterior. Controle das mudanças : é instituído de forma que elas possam ser aprovadas e acompanhadas. 23

24 projetos reais raramente seguem o fluxo seqüencial que o modelo propõe logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural o cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento

25 Embora o Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software

26 processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software. apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.

27 fim construção produto início refinamento protótipo obtenção dos requisitos avaliação protótipo projeto rápido construção protótipo Obtenção dos Requisitos: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais Projeto Rápido: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída)

28 fim construção produto início refinamento protótipo obtenção dos requisitos avaliação protótipo projeto rápido construção protótipo Construção Protótipo: implementação do projeto rápido Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo

29 fim construção produto início refinamento protótipo obtenção dos requisitos avaliação protótipo projeto rápido construção protótipo Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iteração que pode conduzir a 1a. atividade até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito.

30 fim construção produto início obtenção dos requisitos projeto rápido Construção Produto: identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade. refinamento protótipo avaliação protótipo construção protótipo

31 cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo. Não aceita bem a idéia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final.

32 desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final.

33 Exercício de prototipação Grupo de até 4 alunos Construir um protótipo para um dos temas a seguir: Software de locação Locação de filmes por um determinado cliente Devolução dos filmes locados Efetuar pagamento dos filmes locados utilizando cartão crédito Emitir relação de filmes locados no mês, agrupadas por gênero do filmes. Indicador subtotais de locações (quantidade e valor financeiro arrecadado) por filme e por gênero. Software de controle acadêmico Emissão das disciplinas cursadas pelo aluno com suas respectivas notas, carga horária, frequências e situação (aprovado ou reprovado) Matrícula on-line do aluno

34 Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente A chave é definir-se as regras do jogo logo no começo O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos

35 Por quê? O primeiro design muito provavelmente será deficiente com respeito aos requisitos principais do projeto nem todos os requisitos são claramente identificáveis a princípio, e aqueles que são podem as vezes ser ambíguos ou simplesmente inconsistentes requisitos podem mudar ou ficar obsoletos clientes podem mudar de opinião mercado competitivo pode exigir mudanças A descoberta tardia de defeitos no design resultarão em aumentos de custos ou cancelamento do projeto O tempo e o dinheiro gastos na correção de um design defeituoso não são recuperáveis!

36 O modelo espiral acopla a natureza iterativa da prototipação com os aspectos controlados e sistemáticos do modelo cascata O modelo espiral é dividido em uma série de atividades de trabalho ou regiões de tarefa Existem tipicamente de 3 a 6 regiões de tarefa 36

37 Adiciona um novo elemento: a Análise de Risco Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos Exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso O modelo é relativamente novo e não tem sido amplamente usado O paradigma do modelo espiral para a engenharia de software é a abordagem mais realística para o desenvolvimento de sistemas e de software de grande escala 37

38 Planejamento Análise de Riscos Comunicação com Cliente Engenharia Avaliação do Cliente Construção e Liberação 38

39 Risco Especificação de Requisitos Análise Design Implementação Teste Tempo

40 Aplicação da Cascata Iterativamente ao Sistema R R R R I1 I2 I3 I4 A A A A D D D D I I I I T T T T Primeiras iterações carregam os maiores riscos Cada iteração gera uma versão executável com algum incremento ao sistema Cada iteração inclui integração e testes tempo

41 Risco Iterativo Cascata Iteração Iteração Iteração Iteração Iteração Iteração Iteração Iteração Tempo

42 SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-Wesley, PRESSMAN, R. S. Engenharia de Software: Uma abordagem Profissional. 7ª ed. Porto Alegre: AMGH, 2011.