.
.
.
.
.
.
.
.
.
.
Engenharia de Software
2. Processos em
Engenharia de Software
2.1. 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);•
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.•
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 ciclode 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.Pas s o 1
Pas s o 2
Pas s o 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.•
Cascata•
Subprocessos executados em estrita seqüência: pontos decontrole 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:Especificação (???)
Produto ???
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.•
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. Ativação Análise de riscos Planejamento da próxima interação Desenvolvimento•
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.•
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. Conceito Inicial Protótipo inicial Protótipos refinados Produto•
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.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.
Requisitos Analise Desenho alto nível Implantação Liberação Avaliação dos usuários Desenho detalhado Resultados•
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.
Tabela 1: Os estágios do PSP
Classificação Nome Elementos novos de processo PSP0 Registro de tempos
Registro de defeitos
Padronização dos tipos de defeitos Processos pessoais
básicos
PSP0.1 Padronização da codificação Medição do tamanho
Proposição de melhorias de processo
PSP1 Estimativas de tamanho Relatórios de testes Processos pessoais com
planejamento
PSP1.1 Planejamento de tarefas
Planejamento de cronogramas
PSP2 Revisões de código Revisões de desenho Processos pessoais com
gestão da qualidade PSP2.1 Modelos de desenho Processos pessoais cíclicos 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.
Documentos dos requisitos. Modelo conceitual.
Planos de recursos, prazos e qualidade.
Registro de tempos. 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. 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. Revisão do desenho de alto nível Verificação da cobertura do desenho. Verificação da máquina de estados. Verificação lógica.
Desenho de alto nível revisto.
Estratégia de
desenvolvimento revista. Estratégia de testes revista.
Verificação da consistência do desenho. Verificação da reutilização. Verificação da estratégia de desenvolvimento Conserto de defeitos. Registro de defeitos de desenho de alto nível. Registro de problemas de desenho de alto nível. Registro de tempos. Desenvolvimen to Desenho do módulo. Revisão do desenho. Codificação. Revisão do código. Compilação. Teste. Reavaliação e reciclagem.
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. Post-mortem Contagem de defeitos injetados
e removidos.
Contagem de tamanhos e 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
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.•
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.•
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.
Tabela 3 - Fases do Processo Unificado
Fase
Descrição
Concepçã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.
Elaboração
Fase na qual o produto é detalhado o suficiente para
permitir um planejamento preciso da fase de
construção.
Construção
Fase na qual é produzida uma versão completamente
operacional do produto.
Transição
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.
Tabela 4 - Fluxos do Processo Unificado
Fluxo
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.
implementação
2.3. Praxis
è Documento do Wilson de Paula . è
