Processos e Modelos de Software: Estruturas e Abordagens na Engenharia de Software

Processo do Software Um processo de software é um conjunto de atividades relacionadas que levam à produção de um produto de software Essas atividades podem envolver o desenvolvimento de software a partir do zero em uma linguagem padrão de programação como C ou Java Modelos de Processos de Software O modelo de um processo de software é uma representação simplificada de um processo de software e existem vários modelos de processo de software ou paradigmas de engenharia de software Obs cada uma representa uma tentativa de colocar ordem em uma atividade inerentemente caótica Processo do Software Grupo de atividades coerentes para especificação projeto implementação e teste de sistemas de software Objetivos Introduzir os processos de modelagem de software Descrever alguns modelos de processos e quando eles devem ser usados Descrever em linhas gerais o processo modelo para os requisitos de engenharia de desenvolvimento de softare seu teste e evolução Indroduzir a tecnologia CASE para o auxílio dos processos de software Tópicos cobertos Modelos do processo de software Iteração entre os processos Especificação de software Projeto e implementação de software Validação do software Evolução do software Processos automatizados de desenvolvimento O processo do software Um conjunto estruturado de atividades necessárias para desenvolver um sistema de software Especificação Projeto Validação Evolução Um modelo de processo de software é uma representação abstrata do processo Ela apresenta uma descrição do processo de algumas perspectivas particulares Modelos genéricos de processos de software O modelo cascata waterfall Fases separadas e distintas de especificação e desenvolvimento Desenvolvimento evolucionário ou prototipação Especificação e desenvolvimento são intercalados Modelo de sistema formal Um modelo de sistema matemático é formalmente transformado numa implementação Desenvolvimento baseado em reuso O sistema é construído a partir de componentes existentes Waterfall model Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance Modelo Cascata Sistemático e seqüencial Waterfall model phases Análise de requisitos e definições Projeto do sistema e do software Implementação e teste de unidades Integração e testes do sistema Manutenção e operação Uma deficiência do modelo cascata é a dificuldade em acomodar mudanças depois que o processo se inicia Análise e Engenharia de Sistemas Estabelecer os requisitos básicos para todos os sistemas que envolvem o software como hardware pessoas e bancos de dados Envolve a coleta dos requisitos em nível do sistema com uma pequena quantidade de projeto e análise de alto nível Analise de Requisitos de Sw Concentra a coleta de requisitos no sw Leva à compreensão do domínio da informação a função desempenho e interfaces exigidos Os requisitos para o sistema e para o sw são documentados e revistos com o cliente Projeto Estrutura de dados Arquitetura de sw Detalhes procedimentais Caracterização da interface É avaliado antes de começar a ser implementado Junto com as etapas anteriores tornase parte da documentação do sistema Codificação Projeto traduzido para a linguagem do computador Se o projeto for executado detalhadamente a codificação pode ser executada mecanicamente Testes Concentrase nos aspectos lógicos internos do sw Garante que todas as instruções tenham sido testadas A entrada definida produz os resultados exigidos Garbage in garbage out Manutenção Sw embutido nem sempre tem esta parte Erros encontrados Mudanças no ambiente externo Acréscimos funcionais Desempenho Problemas com a Cascata O mais antigo e amplamente usado Projetos reais raramente seguem o fluxo seqüencial que ele propõe Ocorrem iterações que trazem problemas na aplicação do paradigma É difícil para o cliente declarar todas as exigências explicitamente É difícil acomodar as incertezas naturais que existem no começo de muitos projetos O cliente deve ter paciência Uma versão do sw só estará disponível em um ponto tardio do cronograma Um erro crasso pode ser desastroso Só é apropriado quando os requisitos são bem conhecidos Desenvolvimento evolucionário Desenvolvimento exploratório O objetivo é trabalhar com o cliente e desenvolver um sistema final a partir das especificações iniciais Deve iniciar com requisitos bem compreendidos Jogar fora a prototipação O objetivo é entender os requisitos do sistema Deve iniciar com requisitos pouco compreendidos Desenvolvimento evolucionário Validation Final version Development Intermediate versions Specification Initial version Outline description Concurrent activities Prototipação Coleta e refinamento dos requisitos Avaliação do protótipo pelo cliente Início Desenvolvimento evolucionário Problemas Falta de visibilidade sobre o processo Sistema geralmente pouco estruturado Habilidades especiais ex em linguagens para uma rápida prototipação são requeridas Aplicabilidade Para sistemas interativos pequenos ou médios Para partes de de grandes sistemas ex A interface com o usuário Para sistemas com pouco tempo de vida Modelo de desenvolvimento formal Baseado na transformação de uma especificação matemática através de diferentes representações em um programa executável As transformações preservam a corretude das especificações sendo fácil demonstrar que que o programa segue estas últimas Baseado na abordagem Cleanroom para o desenvolvimento de software Modelo de desenvolvimento formal Requirements definition Formal specification Formal transformation Integration and system testing Transformações formais R2 Formal specification R3 Executable program P2 P3 P4 T1 T2 T3 T4 Proofs of transformation correctness Formal transformations R1 P1 Desenvolvimento formal Problemas São necessárias habilidades especiais e treinamento para aplicar a técnica Dificuldade para formalizar especificamente alguns aspectos do sistema como a interface com o usuário Aplicabilidade Sistemas críticos especialmente aqueles em que uma versão segura deve ser feita antes do sistema entrar em operação Desenvolvimento orientado a reutilização Baseado na sistemática do reuse onde os sistemas são integrados a partir de componentes existentes ou sistemas COTS Commercialoff theshelf Estágios do processo Análise dos componentes Modificação dos requisitos Projeto do sistema com reutilização Desenvolvimento e integração Esta abordagem está se tornando mais importante porém ainda há pouca experiência com ela Reuseoriented development Requirements specification Component analysis Development and integration System design with reuse Requirements modification System validation Processo de iteração Os requisitos do sistema sempre evoluem ao longo do projeto então o processo de iteração dos estágios anteriores é retrabalhado e vira parte do processo para grandes sistemas Iteração pode ser aplicada a qualquer modelo genérico de ciclo de vida Duas abordagens semelhantes Desenvolvimento incremental Desenvolvimento espiral Desenvolvimento incremental Ao invés de entreagar o sistema uma única vez o desenvolvimento e a entrega são partidos em incrementos que fornecem parte das funcionalidades requeridas Os requisitos do usuários são dispostos hierarquicamente e os requisitos de prioridades mais altas são incluídos nas primeiras entregas Quando o desenvolvimento de um incremento é iniciado os requisitos são congelados de forma que os requisitos para incrementos posteriores possam continuar a evoluir Incremental development Validate increment Develop system increment Design system architecture Integrate increment Validate system Define outline requirements Assign requirements to increments System incomplete Final system Vantagens do desenvolvimento incremental Valor ao cliente tende a ser entregue a cada incremento então a funcionalidade dos sistema tende a ser avaliada mais cedo Os primeiros incrementos funcionam como um protótipo para ajudar a esclarecer os requisitos para os próximos incrementos Baixo risco de o projeto falhar completamente As tarefas de mais alta prioridade tendem a receber mais testes Extreme programming XP Nova abordagem de desenvolvimento baseada no desenvolvimento e entrega de pequenos incrementos de funcionalidade Funciona com melhorias contínuas no código envolvimento do usuário no time de desenvolvimento e programação em pares Os testes aparecem antes da codificação Desenvolvimento em espiral O Processo é representado como um espiral ao invés de uma sequência de atividades com voltas para trás Cada volta no espiral representa uma fase no processo Não há fases fixas como especificação ou projeto As voltas no espiral são escolhidas dependendo do que é requisitado Os riscos são explicitamente avaliados e resolvidos durante todo o processo Spiral model of the software process Risk analysis Risk analysis Risk analysis Risk analysis Proto type 1 Prototype 2 Prototype 3 Opera tional protoype Concept of Operation Simulations models benchmarks SW requirements Requirement validation Design VV Product design Detailed design Code Unit test Integration test Acceptance test Service Develop verify nextlevel product Evaluate alternatives identify resolve risks Determine objectives alternatives and constraints Plan next phase Integration and test plan Development plan Requirements plan Lifecycle plan REVIEW Setores do modelo espiral Definição dos objetivos Os objetivos específicos para a fase são identificados Avaliação e redução de riscos Os riscos são avaliados e as atividades organizadas para reduzir os riscos chave Desenvolvimento e validação Um modelo de desenvolvimento para o sistema é escolhido que pode ser qualquer um dos modelos genéricos Planejamento O projeto é revisto e a próxima fase da espiral é planejada