Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

Transcrição

1 CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS Elicitação Ciclo de Vida Clássico ou Convencional O Modelo Cascata Análise Ana Paula Terra Bacelo Blois Implementação Material Adaptado do Prof. Marcelo Yamaguti Testes Manutenção Ciclo de Vida Clássico ou Convencional Apropriado para sistemas transacionais onde as rotinas e procedimentos a serem automatizados são altamente estruturados. Problemas do ciclo de vida clássico: Os projetos raramente seguem o fluxo seqüencial que o modelo propõe; Dificuldades do cliente em declarar explicitamente todas as suas necessidades; Uma versão do software somente estará pronta ao final do cronograma do projeto; Incremento dos custos de correção na medida em que se avancem as fases. Enfoque Incremental Representa uma variação do ciclo de vida clássico, onde a partir da fase de especificação funcional (projeto lógico) são feitos incrementos sucessivos. Pressupõe que a partir da especificação funcional toda a decomposição do sistema - em termos de subsistemas e módulos - passa a ser conhecida. Processo que propicia ao desenvolvedor criar um modelo do software que será implementado. Os protótipos permitem: que o projetista avalie previamente algumas características particulares do projeto; que o modelo seja testado sem o risco de comprometer todo um projeto; que o usuário tenha condições de melhor entender o produto que esta sendo desenvolvido. O modelo pode assumir uma das três formas: Um protótipo em papel ou visual que retrata a interação homem-máquina; Um protótipo de trabalho que implementa algum subconjunto da função exigida do software desejado; Um programa que executa parte ou toda a função desejada, porém que necessita ser aprimorado para tornar-se operacional. 1

2 Fim Início Engenharia do Produto Coleta e Refinamento dos Requisitos Rápido Problemas da prototipação: Não entendimento pelo cliente de que o protótipo não é um produto acabado; Refinamento do Protótipo Avaliação do Protótipo pelo Cliente Construção do Protótipo Concordância do desenvolvedor com este entendimento. Técnicas de Quarta Geração Definição da Abordagem a ser Utilizada Coleta de Requisitos Estratégia de Implementação usando 4GL Teste Alta Complexidade da Aplicação. Convencional.. Incremental. Incremental. Pacote.. Convencional Baixa Definição de B. Meyer Especificar o documento de requisitos de um software é definir de uma forma completa e não ambígua: as características externas do software oferecidas aos usuários; a forma pela qual o software é integrado no sistema. Definição de A. Davis Durante a fase de requisitos, é necessário analisar, e portanto entender o problema a ser resolvido. Análise do problema é a atividade que inclui o entendimento das necessidades do usuário bem como as limitações impostas na solução. 2

3 ENGENHARIA DE REQUISITOS O PROCESSO DE ELICITAÇÃO Objetivos do Sistema Documentos de Requisito Engenharia de Software Especificação de Software Engenharia de Requisitos Pedaços de Código Entrevista não obtém toda a informação necessária. O engenheiro de requisitos deve se envolver com o ambiente de trabalho do cliente, se misturar com os funcionários, observar, aprender, e questionar, de forma a superar a ignorância do domínio do problema. É preciso entender a razão porque as coisas são feitas da forma que são. GERANDO A ESPECIFICAÇÃO DE REQUISITOS Durante a fase de análise o objetivo é a obtenção de uma especificação que seja consistente e completa. O analista deve: Avaliar o fluxo e o conteúdo da informação; Definir e elaborar todas as definições do software; Entender o comportamento do software no contexto dos eventos que o afetem; Estabelecer as características de interface do software com o usuário; Identificar restrições para o projeto. FASE DE ANÁLISE: GERANDO A Princípios fundamentais dos métodos de análise: [Pressman 95] O domínio de informação de um problema deve ser representado e compreendido; Modelos que descrevem a informação, função e comportamento do sistema devem ser resolvidos; Os modelos (e o problema) devem ser divididos em partições, de maneira que revele os detalhes em forma de camadas (ou hierarquicamente); O processo de análise deve mover-se da informação essencial para os detalhes de implementação. FASE DE PROJETO: GERANDO A ESPECIFICAÇÃO DE PROJETO FASE DE PROJETO: GERANDO A ESPECIFICAÇÃO DE PROJETO pode ser definido como o processo realizado quando tomamos um modelo lógico de um sistema juntamente com um conjunto de objetivos fortemente formulados para aquele sistema, e produzimos a especificação de um sistema físico que atenderá a esses objetivos. O Processo de de Dados; Arquitetural; Procedimental; da Interface. 3

4 ENFOQUES METODOLÓGICOS ABORDAGEM INFORMACIONAL ENFOQUES METODOLÓGICOS ABORDAGEM FUNCIONAL Cliente (1,1) (0,n) (0,n) Contratação Utilização ARQUIVO (0,n) (FONTE) FLUXO DE PROCESSO DADOS (DESTINO) Alocação Recursos Materiais E X Y TRANS- FORMAR X EM Y TRANS- FORMAR Y EM Z Z S (1,n) Recursos Humano ENFOQUES METODOLÓGICOS ABORDAGEM ORIENTADA A OBJETOS DFD MO TÉCNICAS PARA MODELAGEM DE SOFTWARE E-R INTRODUÇÃO: Modelos Objetivos dos modelos Testar uma entidade física antes de lhe dar forma. ex.: modelos de aviões testados em túneis de vento. Comunicação com clientes. ex.: plantas baixas. Visualização. ex.: maquetes. Redução da complexidade. Não há um único modelo "correto" de um situação, apenas modelos adequados e inadequados. A mente humana só consegue tratar um limitado volume de informações a cada momento. Os modelos reduzem a complexidade de um problema dividindo-o em vários problemas menores. INTRODUÇÃO: Modelagem de Software Modelos de componentes de um sistema: Modelo de dados/informações: Armazenamento de informações; Manipulação de dados armazenados; Modelo funcional: Processos (funções). Modelo dinâmico: Tempo; Controle. 4

5 Modelagem de Dados/Informações Modelagem Funcional Obter uma descrição abstrata, independente de implementação em computador, dos dados que serão armazenados na base de dados. Identificar a estrutura e significado dos dados na organização. Modelar os aspectos relacionados à transformação de valores como funções, restrições e dependências funcionais do sistema. Deve permitir descrever o sistema como uma composição de subsistemas interativos que processam dados e informações. Deve descrever o sistema em termos de processos e suas interfaces. Modelagem Dinâmica Também chamada de Modelagem Comportamental. Modelar os aspectos relacionados ao comportamento do sistema, isto é, mostra o que é feito quando. Deve permitir descrever como o sistema reage a eventos de tempo e de controle. Deve descrever o sistema em termos de estados e as transições entre estes estados. Porque modelar o sistema? Aceitação pelo usuário: Ausência de modelo visível ao usuário faz com que ele dê conformidade a soluções incompletas ou mesmo erradas! Falta de interação com o usuário. Ciclo de vida muito comprido: O usuário modifica suas necessidades: o problema muda! As pessoas envolvidas não permanecem até o fim. Porque modelar o sistema? Documentação: Documentos textuais e narrativos cansam e desestimulam. Realizados após o desenvolvimento do sistema: desatualização. Os modelos facilitam a comunicação entre os envolvidos no desenvolvimento do sistema. Indispensável para a manutenção do sistema. Confiabilidade: Testes e depuração de sistemas mal-modelados. 5