Análise e Gerenciamento de Requisitos com Casos de Uso

Módulo 1Melhores Práticas da

Engenharia de Software

Objetivos

• Lista de sintomas dos problemas encontrados no Desenvolvimento de Software.

• Definição das Seis Melhores Práticas.• Descrição das Atividades para resolver os

problemas da Engenharia de Software para cada Melhor Prática.

• Apresentação do Processo Unificado (UP), dentro do contexto das Seis Melhores Práticas.

Problemas do Desenvolvimento de Software

SINTOMAS:

Necessidades de Negócio e Usuário não atendem. Muitas mudanças de requisitos. Módulos não integram. Difícil de manter. Descoberta tardia das falhas. Baixa qualidade e iteratividade com o usuário. Baixa performance sob condições normais. Esforço não coordenado da equipe. Problemas de build-e-release (construção e lançamento de

versão).

Mapeamento dos Sintomas para causas raiz

Necessidades erradas

Requisitos Mutantes

Módulos isolados

Difícil manter

Tarde demais

Baixa qualidade

Baixa performance

Equipe descoordenada

Problemas de Build-e-release

Requisitos insuficientes

Comunicação Ambígua

Arquiteturas fragmentadas

Complexidade desnecessária

Inconsistências

Testes insuficientes

Avaliação subjetiva

Desenvolvimento em cascata

Mudanças não controladas

Automação Insuficiente

Sintomas Causas Raiz Melhores Práticas

Desenvolver iterativamente

Gerenciar Requisitos

Arquiteturas componentizadas

Modelar Visualmente (UML)

Verificação de Qualidade

Gerenciar Mudanças

Gerenciar Requisitos

Verificação da Qualidade

Gerenciar Mudanças

Gerenciar Requisitos

Verificação da Qualidade

Gerenciar Mudanças

Requisitos insuficientes

Comunicação ambígua

Mudanças não controladas

Requisitos insuficientes

Comunicação ambígua

Mudanças não controladas

Requisitos mutantes

Requisitos mutantes

Melhores PráticasProcesso Prático

Melhores PráticasProcesso Prático

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

Desenvolver Iterativamente

Características do Desenvolvimento em Cascata

• Demora na confirmação e resolução de Riscos.

• Mensura progresso por produto-entregue que são indicadores ruins.

• Demora nas integrações e testes.

• Implantações só no final.• A maioria dos resultados ocorre

em iterações não planejadas.Código e Teste

Design

Integraçãodos Módulos

Teste de Sistema

Processo CascataProcesso Cascata

Análise de Requisitos

Planejamento

Características do Desenvolvimento Iterativo

• Resolve os maiores riscos antes que haja custos elevados.• Facilita maior participação e feedback do usuário.• Faz testes e integração contínua. • Foca em marcos de projeto curtos e objetivos. • Torna possível a entrega parcial de executáveis.

T E M P OT E M P O

Iteração 1 Iteração 2 Iteração 3 P

RD

CI

T

PR

DC

IT

PR

DC

IT

Desenvolvimento Iterativo

Comportamento dos Riscos

TempoTempo

Ris

coR

isco

Risco no Processo Cascata

Risco no Processo Iterativo

Redução de RiscoRedução de Risco

Gerenciar Requisitos

Melhores PráticasProcesso Prático

Melhores PráticasProcesso Prático

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

• Tenha certeza que está resolvendo o problema certo e entregando o sistema certo.

• Para ter uma ação completa:– Entenda o Problema.– Detalhe, organize, e documente os requisitos.– Gerencie mudanças de requisitos do sistema.

Gerenciamento de Requisitos

Use Arquiteturas Componentizadas

Melhores PráticasProcesso Prático

Melhores PráticasProcesso Prático

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas Modelar Visualmente (UML)

Verificar QualidadeGerenciar Mudanças

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas Modelar Visualmente (UML)

Verificar QualidadeGerenciar Mudanças

Arquitetura Robusta Baseada em Componentes

• Robusta– Atende aos requisitos atuais e futuros.– Melhora a extensibilidade da aplicação.– Permite reuso de funcionalidades.– Encapsula funções e dados do sistema.

• Baseado em componentes– Reuso e customização de componentes. – Escolha de componentes comerciais disponíveis.– Integra o sistema existente incrementalmente.

Arquitetura Baseada Em Componentes

• Base para Reuso– Componentes – Bibliotecas de Componentes

• Base para Gerência de Projetos– Planejamento– Otimização de Recursos– Entregas

• Controle Intelectual– Emcapsulamento– Mantém integridade das regras Repositórios

Integração

Escopo deNegócio

Escopo de Aplicação

Arquitetura baseada em componentes

distribuídos em camadas

Modelar Visualmente (UML)

Melhores PráticasProcesso Prático

Melhores PráticasProcesso Prático

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modele Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modele Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

Por que modelar visualmente?• Captura estrutura e comportamento.• Apresenta a colaboração entre os elementos.• Mantém design e implementação consistentes.• Esconde ou expõe detalhes. • Promove a comunicação não ambígua.• Facilita a evolução do conhecimento.

Diagramas Estáticos

Diagramas deAtividade

Modelos

Diagramas de Seqüência

Diagramas de Colaboração

Diagramasde Estado

Diagramas deDeployment

Diagramas de Componente

Diagramas deObjetos

Diagramas de ClassesDiagramas de

Casos de Uso

Diagramas Dinâmicos

UML, uma linguagem padronizada.

Verificar Qualidade Continuamente

Melhores PráticasProcesso Prático

Melhores PráticasProcesso Prático

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

ContinuamenteGerenciar Mudanças

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

ContinuamenteGerenciar Mudanças

Teste das Dimensões de Qualidade

ConfiabilidadeConfiabilidadeTeste a aplicação em Teste a aplicação em sua consistência de sua consistência de comportamento.comportamento.

PerformancePerformanceTeste o tempo de Teste o tempo de

resposta da aplicação resposta da aplicação on-line e com picos on-line e com picos elevados de uso.elevados de uso.

FuncionalidadeFuncionalidadeTeste a aderência Teste a aderência de cada cenário de cada cenário de caso de uso.de caso de uso.

UsabilidadeUsabilidadeTeste a aplicação Teste a aplicação sob a perspectiva sob a perspectiva

de conveniência de de conveniência de uso pelo usuário.uso pelo usuário.

SuportabilidadeSuportabilidadeTeste a capacidade da Teste a capacidade da

aplicação ser mantida aplicação ser mantida em produção.em produção.

Verificação Contínua da Qualidade do SoftwareC

usto

TransiçãoConstruçãoElaboraçãoConcepção

Problemas de Software são de100 a 1000 vezes mais caros

se encontrados e consertados depois de instalados

Custo para consertar Software Custo com a perda de

oportunidades Custo com a perda de clientes

Mo

de

lo U

ML

e A

plic

açã

o T

est

es

Iteração 1Iteração 1

Test Suite 1Test Suite 1

Iteração 2Iteração 2

Test Suite 2Test Suite 2

Iteração 3Iteração 3

Test Suite 3Test Suite 3

Teste cada iteração

Test Suite 4Test Suite 4

Iteração 4Iteração 4

Gerenciar Mudanças

Melhores PráticasProcesso Prático

Melhores PráticasProcesso Prático

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

Desenvolver IterativamenteGerenciar Requisitos

Arquiteturas Componentizadas

Modelar Visualmente (UML)Verificar Qualidade

Gerenciar Mudanças

Requisições de Mudanças vêm de várias fontes durante o ciclo

de vida do sistema.

Gerenciamento das Requisições de Mudanças

Entradas do Help Desk

Entradas dos Desenvolvedores e Testadores

Entradas dos Usuários e Clientes

Marketing

Nova Característica

Novo Requisito

Bug

Processo deAprovação

das Requisiçõesde Mudança

Comitê de Controle

(CCM)

Canal Único de Aprovação

Requisição de Mudança (RM)

Req

Design

Código

Teste

Manut

Weinberg, ‘95

As melhores práticas reforçam umas as outras

Envolvimento dos usuários no desenv. dos requisitos

Melhores PráticasMelhores Práticas

Desenvolver Iterativamente

Gerenciar Requisitos

Utilizar Arquiteturas Componentizadas

Modelar Visualmente (UML)

Verificar Qualidade

Gerenciar Mudanças

Desenvolver Iterativamente

Gerenciar Requisitos

Utilizar Arquiteturas Componentizadas

Modelar Visualmente (UML)

Verificar Qualidade

Gerenciar Mudanças

Validação antecipada das decisões arquiteturais

Ataca complexidade deDesign / Implementação

incrementalmente

Mede qualidade freqüentemente

Desenvolvimento incremental de baselines

Processo Unificado e as Melhores Práticas

• Abordagem Iterativa• Guias para atividades e artefatos• Foco do Processo na Arquitetura• Casos de uso que direcionam o projeto

de arquitetura e a implementação• Modelos que abstraem o sistema

Definição de Processo

O processo define Quem está fazendo O que, Quando, e Como a fim de chegar a um determinado objetivo.

Novo ou alterado

Requisitos

Novo ou alterado

Sistema

Processo de Processo de

RequisitosRequisitos

Concepção Elaboração Construção Transição

Estrutura do Processo – Fases

Tempo

Lidar com riscos relacionados ao negócio.

(notação financeira do projeto)

Lidar com riscos relacionados aos assuntos técnicos do projeto.

Lidar com riscos relacionados a “ter a massa de trabalho pronta”

Lidar com riscos relacionados à logística de entrega da aplicação para o ambiente de produção

Fronteiras (ou Marcos) das Fases

ConcepçãoConcepção ElaboraçãoElaboração ConstruçãoConstrução TransiçãoTransição

Objetivos doCiclo de Vida e Decisão de Viabilidade do Projeto

Ciclo de Vida da ArquiteturaValidada

CapacidadeOperacionalInicial

ReleaseFinal doProduto

Iterações e Fases

Uma iteração é uma seqüência distinta de atividades baseadas em um plano existente e critérios de avaliação, resultando na liberação de um artefato (produto - interno ou externo).

Iteração PreliminarIteração Preliminar IteraçãoIteraçãoArquiteturalArquitetural

Iteração de Iteração de ConstruçãoConstrução

Iteração de Iteração de TransiçãoTransição

IteraçãoIteraçãode Trans.de Trans.

ConcepçãoConcepção ElaboraçãoElaboração ConstruçãoConstrução TransiçãoTransição

Marcos e Objetivos Menores: Releases

Iteração Iteração ArquiteturalArquitetural

Iteração de Iteração de ConstruçãoConstrução

Evolução dos Artefatos Através do Ciclo de Vida

Artefatos do Projeto são produzidos iterativamente.

Colocando tudo junto

Disciplinas agrupam

atividades logicamente.

Em uma iteração, você passa por todas as disciplinas.

Disciplinas produzem modelos

Modelos

Modelo de Caso de Uso de Negócio

Implementado por

Modelo de Objetos de Negócio

Modelo deDesign

Modelo de Implementação

Modelo deCaso de Uso

Realizado por

Automatizado por

Realizado por

Disciplinas ImplementaçãoImplementaçãoAnálise &Análise &DesignDesign

RequisitosRequisitosModelagemModelagemde Negóciode Negócio

Guia das DisciplinasWorkflow da

Modelagem de Negócios

Workflow de Requisitos

Visão Geral dos Conceitos do Processo Unificado

Revisão

• As melhores práticas são guias da Engenharia de Software para atacar as causas dos problemas do Desenvolvimento de Software;

• As melhores práticas reforçam umas as outras;• Um processo guia a equipe de quem, o que,

quando e como fazer as atividades;• Processo Unificado é uma forma de colocar em

ação as Melhores Práticas.