Processos de Desenvolvimento de Software Professora: Aline Vasconcelos Cefet Campos aline.vasconcelos@terra.com.br

Problemas Recorrentes: Estimativas de prazo e custo são freqüentemente imprecisas. Baixa Produtividade no desenvolvimento e alto custo. Baixa qualidade do software produzido. Custos em manutenção de software acabam superando custos em desenvolvimento. Manutenção de software é ameaçada por projetos ruins e falta de controle e gerência adequados.

Processo: Um processo de desenvolvimento de software, em geral, define: Um ciclo de vida para o software, com atividades de desenvolvimento, e um paradigma. Os métodos que serão utilizados ao longo do desenvolvimento. As ferramentas que suportam estes métodos. Quem participa (papéis) e quando. Sub-produtos (ou artefatos) a serem produzidos como saída de cada atividade. Entradas e recursos consumidos por cada atividade. Restrições impostas.

Processo: 3 Fases Genéricas Definição: identificação do “que”! O que o software deve fazer???? Que informação deve ser processada e gerada???? Quais são as restrições do projeto???? O desempenho é crítico??? ETAPA 1: ANÁLISE!!!!!!! Foca no Domínio do Problema!!!!!

Processo: 3 Fases Genéricas Desenvolvimento: identificação do “como”! Estruturas de dados/Banco de Dados!! Definição de Arquitetura!!!!!! Módulos de Programas! Definição de Programas/Algoritmos!!!!! Tecnologia!!!! Projeto de Telas!!!!!! Projeto e Realização de Testes!!! ETAPA 2: PROJETO, PROGRAMAÇÃO, TESTES!!!!!!! DOMÍNIO DA SOLUÇÃO!

Processo: 3 Fases Genéricas Suporte: mudanças!!!!! Reaplica os passos das fases de Definição de Desenvolvimento, mas no contexto de um software existente. Tipos de Manutenção: Corretiva: correção de erros encontrados pelo usuário. Adaptativa: modificações no software para se acomodar a mudanças do ambiente. Mudanças do ambiente envolvem os itens: CPU, Sistema Operacional, Regras de Negócio, Paradigma de Desenvolvimento etc. Evolutiva: à medida que o software é usado, o cliente\usuário reconhece funções adicionais que podem ser úteis. Manutenção evolutiva estende o software para além dos seus requisitos funcionais originais. Preventiva: ETAPA 3: Manutenção!!!!!!!

Teste de Unidade e Integração Ciclo de Vida Clássico: (Waterfall Model ou cascata) Análise de Requisitos Projeto de Alto Nível Projeto do Sistema Projeto dos Programas - Projeto de Baixo Nível Codificação Teste de Unidade e Integração Características: Seqüencial Conceitualmente Simples Guiado por documentos Teste de Sistema Teste de Aceitação Entrega e Manutenção

Contribuições x Problemas – Ciclo de Vida Clássico: Define claramente as fases de desenvolvimento de software, permitindo a definição de métodos e atividades em cada fase. Permite a definição dos “workproducts” ou artefatos a serem entregues em cada atividade. Outros modelos representam simplesmente variações do ciclo clássico, incorporando loops e atividades extra. Problemas: projetos de software na prática raramente seguem um fluxo seqüencial; não suporta mudança de requisitos que pode ocorrer ao longo do projeto; cliente acaba esperando muito tempo por algum resultado concreto do trabalho.

Ciclo de Vida Modelo em V Entrega e Manutenção Valida requisitos Análise de Requisitos Teste de Aceitação Teste de Sistema Projeto do Sistema Verifica Projeto Teste de Unidade e Integração Projeto dos Programas Codificação Características: Relaciona Teste à Análise e Projeto. As conexões implicam em retrabalho se problemas são encontrados. O foco reside na atividade e na corretude.

Ciclo de Vida Modelo em V Foco em testes. Casos de Teste vão sendo criados ao longo das atividades de análise e projeto. A ligação existente entre os lados direito e esquerdo do V implica no fato de que se problemas são encontrados durante testes (verificação e validação), então atividades do desenvolvimento podem ser re-executadas fixando erros em requisitos, projeto e código. Adequado para sistemas com alta criticalidade.

Verificação x Validação => Verificação: “Estamos construindo certo o produto?” => Validação: “Estamos construindo o produto certo?” Validação: assegurar que o sistema implementou todos os requisitos. Verificação: assegurar que cada função executa corretamente.

Ciclo de Vida baseado em Prototipação Lista de Revisões Lista de Revisões Lista de Revisões revisa protótipo Revisão de usuário e cliente Protótipo de Requisitos Protótipo do Projeto Protótipo do Sistema Teste Sistema Entregue Requisitos do sistema Características: Reduz os riscos e incertezas do desenvolvimento.

Prototipação: Protótipo: produto parcialmente desenvolvido, permitindo que usuários, clientes e desenvolvedores avaliem aspectos do sistema proposto e decidam se estes estão apropriados ao produto final. Defeitos podem ser detectados mais cedo no desenvolvimento de software. Prototipação Descartável x Evolutiva. Prototipação descartável pode ser útil para elicitação de requisitos.

Ciclo de Vida Baseado em Desenvolvimento por Fases: Incrementos e Iterações Sistema em Desenvolvimento DESENVOLVEDORES Construção da Release 1 Construção da Release 2 Construção da Release 3 Tempo Utiliza Release 1 Utiliza Release 2 Utiliza Release 3 USUÁRIOS Características: Reduz o tempo de entrega, pois permite que o sistema seja entregue em partes. Geralmente há dois sistemas funcionando em paralelo: sistema operacional ou de produção e sistema em desenvolvimento.

Ciclo de Vida Baseado em Desenvolvimento por Fases: Incremental e Iterativo Desenvolvimento Incremental Release 1 Release 2 Release 3 Parte das Funcionalidades Desenvolvimento Iterativo

Desenvolvimento Iterativo e Incremental Desenvolvimento Incremental: o sistema, como definido na especificação de requisitos, é particionado em subsistemas por funcionalidade. Desenvolvimento Iterativo: permite a entrega de um sistema completo no início do processo, e, então, aumenta a funcionalidade de cada subsistema a cada nova versão.

Modelo em Espiral PLANEJAMENTO ANÁLISE DE RISCOS Coleta Inicial dos Requisitos e Planejamento do Projeto Análise dos Riscos baseada nos requisitos iniciais Planejamento Análise de Riscos baseada na reação do cliente Protótipo de Software Inicial Avaliação do Cliente Protótipo de Nível Seguinte Sistema construído pela Engenharia AVALIAÇÃO DO CLIENTE ENGENHARIA

Ciclo de Vida em Espiral: Guiado pelos Riscos. Pode ser usado como um meta-modelo. Ressalta a importância de duas atividades de engenharia de software: Planejamento: determinação dos objetivos, alternativas e restrições. Análise dos Riscos: identificação, análise e monitoramento dos riscos. Abordagem evolucionária ao desenvolvimento de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva.

Ciclo de Vida em Espiral: Pode ser visto como desenvolvimento iterativo, onde, a cada volta na espiral (a cada iteração do desenvolvimento) as atividades do desenvolvimento podem ser re-executadas com maior ou menor intensidade sobre determinados artefatos de software.

RUP: THE RATIONAL UNIFIED PROCESS Processo de engenharia de software, desenvolvido e mantido pela Rational Software Corporation. Muito utilizado pela indústria para desenvolvimento de software utilizando a linguagem de modelagem unificada UML. Pode ser visto como um framework, o qual pode ser adaptado e estendido para atender às necessidades específicas de uma organização.

RUP: THE RATIONAL UNIFIED PROCESS Princípios: Desenvolver software iterativamente; Gerenciar requisitos; Utilizar arquiteturas de software baseadas em componentes; Modelar software visualmente utilizando a UML; Verificar a qualidade do software continuamente; Controlar mudanças no software (gerência de configuração).

Management Environment Analisys and Design RUP: um Processo Iterativo e Incremental Requirements Planejamento Management Environment Analisys and Design Initial Planning Avaliação Implementation Test Each Iteration Results in an executable release. Deployment

Processo – Elementos: Elementos que compõem um modelo de processo [RUP2000]: Workers: the who (trabalhadores/desenvolvedores - pessoas) Activities: the how (atividades) Artifacts: the what (artefatos) Workflows: the when (quando)

WORKERS (pessoas): Define o comportamento e responsabilidades de um indivíduo ou grupo de indivíduos trabalhando juntos como um time. Comportamento = atividades que o desenvolvedor executa Responsabilidades = artefatos que o desenvolvedor deve produzir, modificar ou controlar O termo worker refere-se ao papel desempenhado pelo indivíduo. Exemplos: analista, projetista, projetista de testes, revisor de projeto, gerente de configuração, etc.

Activities (Atividades): Definem o trabalho que deve ser executado pelos desenvolvedores. Unidade de trabalho que um indivíduo em um determinado papel deve executar. Atividades possuem artefatos de entrada e artefatos de saída. Exemplos de atividades: Produzir casos de uso: worker: analista de sistemas; Revisar o projeto: worker: revisor de projeto; Executar teste de desempenho, etc.

Artifacts (Artefatos): Artefato: pedaço de informação que é produzido, modificado ou utilizado por um processo. Artefatos são os produtos (ou sub-produtos) tangíveis ao longo do processo. Exemplos (em diferentes níveis de granularidade): Um modelo:modelo de casos de uso, modelo de classes, etc. Um elemento de modelo: uma classe, um caso de uso, ou um subsistema. Um documento: como um documento de requisitos, lista de itens de riscos, plano de projeto, etc. Casos de Teste, Código fonte, executáveis, etc.

Workflows: Workflow: seqüência de atividades que produz um resultado observável. Workflows definidos no RUP: Core Workflows: Modelagem de Negócio Modelagem e Especificação de Requisitos Análise e Projeto Implementação Teste Entrega Support Workflows: Gerência de Projeto Gerência de Mudanças e Configuração Ambiente

RUP Workflows: O RUP é caracterizado por fases genéricas, cada uma definindo loops (iterações) de trabalho no desenvolvimento. Cada workflow é revisitado, executado novamente a cada iteração de desenvolvimento, com maior ou menor ênfase dependendo do estágio em que se encontra o projeto.