2. Processos em Engenharia de Software

Transcrição

1 Renato Cardoso Mesquita Departamento de Eng. Elétrica da UFMG Engenharia de Software 2. Processos em Engenharia de Software Visão Geral Conceito de processo conjunto de passos parcialmente ordenados: constituídos por atividades, métodos, práticas e transformações: usado para atingir uma meta; meta geralmente associada a um ou mais resultados concretos finais: os produtos da execução do processo. Receita que é seguida por um projeto: não confundir: processo, com o produto e com a execução do processo por um projeto. Um processo é definido quando tem documentação que detalha: o que é feito (produto);

2 Processos em Engenharia de Software 2 quando (passos); por quem (agentes); as coisas que usa (insumos); as coisas que produz (resultados) Podem ser definidos com mais ou menos detalhes, como qualquer receita. Passos podem ser ordenados ou parcialmente ordenados. Pode existir paralelismo entre passos. Passo 2 Passo 1 Passo 4 Passo 3 Processos podem ser definidos para as atividades de: desenvolvimento; manutenção; aquisição; contratação de software. Podem ser definidos subprocessos para cada um destes. Ex: desenvolvimento. determinação dos requisitos; análise; desenho; implementação; testes. Em um processo de desenvolvimento de software, o ponto de partida para a arquitetura de um processo é a escolha de um modelo de ciclo de vida: Codifica-remenda: Partindo apenas de uma especificação (ou nem isso), os desenvolvedores começam imediatamente a codificar, remendando à medida que os erros vão sendo descobertos. Nenhum processo definido é seguido.

3 Processos em Engenharia de Software 3 Infelizmente, é provavelmente o ciclo de vida mais usado. Para alguns desenvolvedores, esse modelo é atraente porque não exige nenhuma sofisticação técnica ou gerencial. Por outro lado, é um modelo de alto risco, impossível de gerir e que não permite assumir compromissos confiáveis. Especificação (???)??? Produto Cascata Subprocessos executados em estrita seqüência: pontos de controle bem definidos. Pontos de controle facilitam muito a gestão dos projetos, o que faz com que esse processo seja, em princípio, confiável e utilizável em projetos de qualquer escala. Por outro lado, se interpretado literalmente, é um processo rígido e burocrático, em que as atividades de requisitos, análise e desenho têm de ser muito bem dominadas, pois não são permitidos erros. O modelo de cascata puro é de baixa visibilidade para o cliente, que só recebe o resultado final do projeto. Requisitos Correções Análise Desenho Implementação Testes Resultados Implantação Tempo Na prática, é sempre necessário permitir que, em fases posteriores, haja revisão e alteração de resultados das fases anteriores. Uma variante que permite superposição entre fases e a realimentação de correções é o modelo sashimi:

4 Processos em Engenharia de Software 4 Correções Requisitos Análise Desenho Implementação Testes Implantação Resultados tempo A superposição das fases torna difícil o gerenciamento de projetos baseados neste ciclo de vida. Um modelo radicalmente diferente é o modelo em espiral. Ativação Análise de riscos Planejamento da próxima interação Desenvolvimento Produto desenvolvido em uma série de iterações; Cada iteração é uma volta na espiral; Produtos construídos em prazos curtos, com novas características e recursos agregados na medida em que a experiência descobre suas necessidades; Manutenções identificam problemas: seus registros fornecem dados para definir os requisitos das próximas liberações Problema: requer gestão muito sofisticada para ser previsível e confiável. Variante do modelo em espiral: Prototipagem evolutiva. A espiral é usada não para desenvolver o produto completo, mas para construir uma série de versões provisórias que são chamadas de protótipos.

5 Processos em Engenharia de Software 5 Os protótipos cobrem cada vez mais requisitos, até que se atinja o produto desejado. A prototipagem evolutiva permite que os requisitos sejam definidos progressivamente, e apresenta alta flexibilidade e visibilidade para os clientes. Entretanto, também requer gestão sofisticada, e o desenho deve ser de excelente qualidade, para que a estrutura do produto não se degenere ao longo dos protótipos. Conceito Inicial Protótipo inicial Protótipos refinados Produto O modelo de Entrega por estágios difere do modelo de cascata pela entrega ao cliente de liberações parciais do produto. Isso aumenta a visibilidade do projeto, o que geralmente é um fator muito importante no relacionamento com o cliente. Apresenta, entretanto, os demais defeitos do modelo em cascata (rígido / burocrático / requisitos, análise e desenho têm de ser muito bem dominadas, pois não são permitidos erros). Uma combinação dos modelos de Cascata e Prototipagem evolutiva forma o modelo de Entrega Evolutiva. Este modelo permite que, em pontos bem definidos, os usuários possam avaliar partes do produto e fornecer realimentação quanto às decisões tomadas. Facilita também o acompanhamento do progresso de cada projeto, tanto por parte de seus gerentes como dos clientes. A principal dificuldade continua ser a realização do Desenho Inicial: ele deve produzir uma arquitetura de produto robusta, que se mantenha íntegra ao longo dos ciclos de liberações parciais.

6 Processos em Engenharia de Software 6 Requisitos Analise Desenho alto nível Desenho detalhado Resultados Avaliação dos usuários Liberação Outros ciclos possíveis: dirigido pelo prazo; requer bom entendimento de requisitos e arquitetura; gestão sofisticada; dirigido por ferramentas; baixa mutabilidade de escala; pode ter altos riscos; confiabilidade depende da ferramenta. comprar em vez de construir. Implantação 2.2. Exemplos de processos Processo pessoal de Software: Para que equipes de desenvolvimento de software consigam trabalhar com processos de desenvolvimento, é necessário que cada membro da equipe siga individualmente estes processos. Watts Humphrey (1995) propôs uma série de processos pessoais: Processo Pessoal de Software ( Personal Software Process ), ou PSP.

7 Processos em Engenharia de Software 7 Processos aprendidos através de uma seqüência de pequenos projetos. Projetos devem ser realizados seguindo rigorosamente os processos, que incluem um conjunto de formulários, scripts e relatórios predefinidos. Individuais, com duração típica de cerca de 10 horas.

8 Processos em Engenharia de Software 8 Tabela 1: Os estágios do PSP Classificação Nome Elementos novos de processo Processos pessoais básicos PSP0 Registro de tempos Registro de defeitos Padronização dos tipos de defeitos PSP0.1 Padronização da codificação Medição do tamanho Processos pessoais com planejamento Processos pessoais com gestão da qualidade PSP1 PSP1.1 PSP2 PSP2.1 Proposição de melhorias de processo Estimativas de tamanho Relatórios de testes Planejamento de tarefas Planejamento de cronogramas Revisões de código Revisões de desenho Modelos de desenho Processos cíclicos pessoais PSP3 Desenvolvimento cíclico Tabela 2: Fases do PSP3 Fase Atividades Resultados Planejamento Especificação dos requisitos. Estimativa de tamanho. Estratégia. Estimativa de recursos. Estimativa de prazos. Estimativa de defeitos. Desenho de alto nível Revisão do desenho de alto nível Especificações externas. Desenho dos módulos. Prototipagem. Estratégia de desenvolvimento. Documentação da estratégia de desenvolvimento. Registro de acompanhamento de problema. Verificação da cobertura do desenho. Verificação da máquina de estados. Verificação lógica. Documentos dos requisitos. Modelo conceitual. Planos de recursos, prazos e qualidade. Registro de tempos. Especificações funcionais. Especificações de estados. Roteiros operacionais. Especificações de reutilização. Estratégia de desenvolvimento. Estratégia de testes. Registro de tempos. Desenho de alto nível revisto. Estratégia de desenvolvimento revista. Estratégia de testes revista.

9 Processos em Engenharia de Software 9 Desenvolvimen to Post-mortem Verificação da consistência do desenho. Verificação da reutilização. Verificação da estratégia de desenvolvimento Conserto de defeitos. Desenho do módulo. Revisão do desenho. Codificação. Revisão do código. Compilação. Teste. Reavaliação e reciclagem. Contagem de defeitos injetados e removidos. Contagem de tamanhos e tempos. Registro de defeitos de desenho de alto nível. Registro de problemas de desenho de alto nível. Registro de tempos. Desenho detalhado dos módulos. Código dos módulos. Registro de defeitos dos módulos. Registro de problemas dos módulos. Relatórios dos testes. Registro de tempos. Resumo do projeto. PSP3 tem um ciclo de vida de entrega em estágios. Não existe um tratamento separado dos requisitos; estes são muito simples em todos os projetos, e as respectivas atividades são consideradas como parte do planejamento. O planejamento inclui a estimativa de tamanhos (medidos em linhas de código, com base em um modelo conceitual orientado a objetos), de esforços (medidos em tempo de desenvolvimento), de cronograma (tempo físico) e de defeitos. O desenho é feito de acordo com padrões rigorosos, que usam conceitos de orientação a objetos, síntese lógica e máquinas seqüenciais, e submetido a uma fase rigorosa de verificação. Com base no desenho, a fase de desenvolvimento é dividida em ciclos; cada ciclo inclui desenho detalhado, codificação, revisão do código, compilação e testes de unidade dos respectivos módulos. Ao final de cada ciclo, o planejamento é reavaliado. O PSP sempre termina com uma fase de post-mortem, na qual é feito um balanço final do projeto. As lições aprendidas são

10 Processos em Engenharia de Software 10 documentadas e analisadas, para melhoria do processo no projeto seguinte. Como seqüência natural do PSP, Humphrey (1999) introduziu o Processo de Software para Equipes ( Team Software Process ), ou TSP. O TSP usa um modelo em espiral. Ao longo de 15 semanas, são executados tipicamente três ciclos de desenvolvimento de um produto. Os participantes da equipe de desenvolvedores são organizados de tal forma que cada desenvolvedor desempenhe um ou dois papéis gerenciais bem definidos, além de dividir a carga de desenvolvimento. Os papéis suportados pelos participantes são os de gerente de desenvolvimento, de planejamento, de qualidade, de processo e de suporte, além do líder da equipe. O planejamento e controle rigoroso de tamanhos, esforços, prazos e defeitos, característico do PSP, continua a ser feito. O TSP enfatiza algumas áreas que correspondem às áreas de nível 2 do CMM: gestão dos requisitos, planejamento e controle de projetos, garantia da qualidade e gestão de configurações que não são tratadas pelo PSP por serem consideradas muito simples no caso de projetos individuais. Fases e Atividades do TSPe (TSP educacional) Lançamento Descrição do curso: visão geral; informação para os alunos; objetivos do produto. Formação dos times: integrantes, metas e reuniões. Primeira reunião do time: requisitos de dados. Ativação dos projetos. Estratégia Visão geral da estratégia de desenvolvimento. Critérios da estratégia de desenvolvimento. Seleção da estratégia de desenvolvimento. Documentação da estratégia de desenvolvimento.

11 Processos em Engenharia de Software 11 Estimativas de tamanho. Definição do processo de controle de mudanças. Planejamento Visão geral do plano de desenvolvimento. Produção do planos de tarefas. Produção do cronograma. Produção dos planos pessoais dos engenheiros Balanceamento de carga dos engenheiros. Produção do plano da qualidade. Requisitos Revisão do processo de requisitos. Revisão das demandas dos usuários. Esclarecimento das demandas dos usuários. Distribuição das tarefas de requisitos. Documentação dos requisitos. Revisão dos requisitos. Colocação dos requisitos na linha de base. Revisão dos requisitos pelos usuários. Desenho Revisão do processo de desenho. Desenho de alto nível. Distribuição das tarefas de desenho. Documentação do desenho. Revisão do desenho. Atualização do desenho, com colocação na linha de base. Implementação Revisão do processo de implementação. Distribuição das tarefas de implementação. Desenho detalhado Inspeção do desenho detalhado. Código. Inspeção do código. Teste de unidades. Revisão da qualidade dos componentes. Liberação dos componentes.

12 Processos em Engenharia de Software 12 Testes Revisão do processo de testes. Planejamento e desenvolvimento dos testes. Construção. Integração. Testes de sistema. Documentação dos testes. Post-mortem Revisão do processo de post-mortem. Revisão dos dados de processo. Avaliação do desempenho dos papéis. Preparação do relatório do ciclo. Revisão dos pares. Booch, Jacobson e Rumbaugh propuseram a UML como uma notação de modelagem orientada em objetos, independente de processos de desenvolvimento. Além disto, propuseram o Processo Unificado ( Unified Process ) (Jacobson e outros, 1999), que utiliza a UML como notação de uma série de modelos que compõem os principais resultados das atividades do processo. O Processo Unificado apresenta as seguintes características centrais: é dirigido por casos de uso; é centrado na arquitetura; é iterativo e incremental. O ciclo de vida de um produto tem um modelo em espiral, onde cada projeto constitui um ciclo, que entrega uma liberação do produto. O Processo Unificado não trata do que acontece entre ciclos. Cada ciclo é dividido nas fases mostradas na Tabela 3.

13 Processos em Engenharia de Software 13 Fase Tabela 3 - Fases do Processo Unificado Descrição Concepção Elaboração Construção Transição Fase na qual se justifica a execução de um projeto de desenvolvimento de software, do ponto de vista do negócio do cliente. Fase na qual o produto é detalhado o suficiente para permitir um planejamento preciso da fase de construção. Fase na qual é produzida uma versão completamente operacional do produto. Fase na qual o produto é colocado à disposição de uma comunidade de usuários. Uma característica importante do Processo Unificado é que as atividades técnicas são divididas em subprocessos chamados de fluxos de trabalho ( workflows ), mostrados na Tabela 4. Cada fluxo de trabalho (que chamaremos simplesmente de fluxo) tem um tema técnico específico, enquanto que as fases constituem divisões gerenciais, caracterizadas por atingirem metas bem definidas. Fluxo Tabela 4 - Fluxos do Processo Unificado Descrição Requisitos Fluxo que visa obter um conjunto de requisitos de um produto, acordado entre cliente e fornecedor. Análise Fluxo cujo objetivo é detalhar, estruturar e validar os requisitos, de forma que estes possam ser usados como base para o planejamento detalhado. Desenho Fluxo cujo objetivo é formular um modelo estrutural do produto, que sirva de base para a implementação Implementação Fluxo cujo objetivo é realizar o desenho em termos de componentes de código. Testes Fluxo cujo objetivo é verificar os resultados da

14 Processos em Engenharia de Software 14 implementação 2.3. Praxis Documento do Wilson de Paula.