Processo de Software Prof. Dr. rer. nat. Daniel D. Abdala ►METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS Prof. Dr. rer. nat. Daniel D. Abdala e-mail: abdala@das.ufsc.br
Objetivos Introduzir os principais processos de software; Discutir as vantagens e desvantagens de cada um dos processos;
Plano Modelos de Processos de Software; Modelo em Cascata Prototipação Modelo Iterativo Modelo em Espiral Métodos Ágeis Desenvolvimento Dirigido por Modelos
Processo de Software Um conjunto estruturado de atividades que são necessárias para se desenvolver um sistema de software Especificação; Projeto; Implementação; Validação; Evolução. Um modelo de processo de software é uma representação abstrata de um processo. Ele apresenta uma descrição do processo a partir de uma dada perspectiva
Modelo em Cascata Definição de Requisitos Projeto do Software Implementação e Teste de Unidades Integração e teste do Sistema Implantação e Manutenção
Fases do Modelo em Cascata Definição dos Requisitos e Análise do Problema Projeto do Software Implementação e Teste de Unidades Integração e Teste do Sistema Operação e Manutenção A principal desvantagem do modelo em cascata é a dificuldade em se acomodar mudanças uma vez que o processo se iniciou. Uma fase deve terminar antes que a fase seguinte possa se iniciar
Problemas do Modelo em Cascata Difícil atender a mudança de requisitos dos usuários Apropriado apenas quando os requisitos são claros desde o início do projeto Poucos sistemas possuem requisitos estáveis O modelo em cascata é principalmente usado em processos de engenharia onde o sistema é desenvolvido em diversas localidades (modularização) Ainda assim, cerca de 40% de todos os projetos utilizam este modelo!
Modelo de Prototipação Descrição em Alto Nível Especificação Desenvolvimento Validação Versão Inicial Versão Intermediária Versão Final
Observações sobre Prototipação Desenvolvimento Exploratório O objetivo é trabalhar com os clientes (stackholders) para criar iterativamente um sistema final a partir de uma especificação inicial. Deve-se iniciar o processo com um conjunto de requisitos muito bem entendidos e novas características são adicionadas a medida que vão sendo propostas pelo usuário Protótipo Descartável Tem como objetivo o entendimento dos requisitos do sistema
Observações sobre Prototipação Problemas Falta de visibilidade; Sistemas possuem geralmente uma estrutura pobre; Habilidades especiais (i.e. Em linguagens de prototipação rápida) podem ser necessárias. Aplicabilidade Em projetos de pequenos e de médio tamanho; Em partes de sistemas mais complexos(i.e. As interfaces do usuário); Em programas de curto ciclo de vida.
Modelo de Desenvolvimento Incremental Definição de requisitos iniciais Atribuição de requisitos à iterações Projeto da arquitetura do sistema Desenvolvimento do incremento do sistema Validação do Incremento Integração do Incremento Validação do Sistema Sistema Final
Vantagens do Modelo Incremental Uma parte usável do sistema é entregue ao cliente a cada iteração (incremento); Incrementos iniciais podem ser usados como protótipos para clarificação de requisitos; Baixo risco de falha geral do projeto; Os sub-sistemas de mais alta prioridade tendem a passar por testes mais intensos.
Modelo Espiral
Modelo Espiral O Processo é representado por meio de uma espiral ao invés de uma sequência de atividades com retro-alimentação; Não existem fases fixas tal como especificação ou projeto – loops na espiral são escolhidos dependendo do que é requerido; Riscos são avaliados explicitamentee resolvidos durante todo o processo;
Secções do Modelo Espiral Definição dos objetivos Especificação dos objetivos para a fase corrente são identificados; Avaliação e redução de riscos Riscos são avaliados e atividades são especificadas para reduzir os riscos chave; Desenvolvimento e validação Um modelo de desenvolvimento é escolhido para o projeto que pode ser qualquer dos modelos vistos anteriormente Planejamento O projeto é revisto e a próxima fase da espiral é planejada
Métodos Ágeis Baseado modelo interativo, porém mais “leve” e centrado no ponto de vista das pessoas envolvidas Cada fase demora dias e não semanas Envolvidos ficam presentes numa mesma sala Enfatizam trabalho no software como uma medida primária de progresso Utiliza feedback ao invés de planejamento como mecanismo primário de controle Disponibilização regular de versões do software
Métodos Ágeis - Exemplos Extreme Programming (XP) Fases pequenas e rápidas (alguns dias) Testes são automatizados: metas p/ desenvolvimento Programação feita em duplas Projeto e arquitetura surgem por refactoring SCRUM Usado no gerenciamento de projetos de software Ciclos formados por várias interações (sprint) Breves reuniões diárias (daily scrum) SCRUM é um termo usado no jogo de Rúgbi, que significa quando os jogadores se amontoam
Métodos Ágeis - Aplicabilidade Mais adequados quando os requisitos estão emergindo e mudando rapidamente Mais adequados para projetos com pequenos times, em torno de 20 pessoas Não são aplicáveis em sistemas críticos
Desenv. Dirigido por Modelos Definir visões abstratas para o projeto até chegar no código Modelos são refinados através de transformações sucessivas (Greenfield and Short 2003)
Desenv. Dirigido por Modelos Modelo Específico de Domínio (modelos em XML) MetaCASE DSLTools Modelo WEB JSP+Spring+Hibe Modelo Desktop Swing + Spring Modelo Celular MIDP + Burlap Código WEB JSP+Spring+Hibe Código Desktop Swing + Spring Código Celular MIDP + Burlap Plataforma (WEB + Desktop + Celular)
Pontos Chave Processos de Software são conjuntos de atividades envolvidas na criação de um software; Modelos de processo de software são representações abstratas destes processos; As atividades comuns a todos os modelos são: especificação, projeto, implementação, validação e evolução; Modelos gerais de processo descrevem a organização do processo de software. Exemplos incluem o modelo em cascata, prototipagem, iterativo, modelos ágeis e baseado em componentes;
Referências R. S. Pressman, Engenharia de Software, McGraw Hill, 6a Ed., 2002. Chap. 3. I. Sommerville. Software Engineering. 7th Ed. Addison-Wesley, 2004. Chap. 4.