Gestão de projetos de Software GTI-16 Aula 2 Processo Unificado.

Gestão de projetosde Software

GTI-16Aula 2

Processo Unificado

Ger. Proj. de Software GTI - 16 2

Processos• Porque não usamos?

– Sentimento de perda de tempo– Falta de informação– Falta de uma política organizacional– Frases-chave:

• “Já está dando certo do jeito que está”• “O usuário quer resultado logo”

• Decidimos usar quando...– Sentimento de “falta de direção”– A manutenção de um sistema está saindo “cara” demais


Modelo cascata• Primeiro processo

– Managing the development of large software systems. W.W.Royce (1970)

– Modelo seqüencial de atividades• Fortemente inspirado dos processos de

engenharia tradicionais– “Engenharia de Computação”– Necessidades Projeto Execução

• Atividades– Análise Projeto Codificação Teste Manutenção


Modelo cascata

• Suposições– Todos os requisitos são previamente conhecidos– Requisitos não mudam– Usuários sabem o que querem e só precisam ver o sistema quando este

estiver concluído– Projetos podem ser feitos de maneira completamente abstrata– Codificação sempre se adequa aos projetos (design)– Manutenção é trivial

• Evolução– Fonte

– Espiral

AnáliseProjeto

Codificação

TestesAnálise

Projeto

Codificação

Testes


Surgiu então o Processo Unificado• O que é o Processo Unificado (UP)?

– Metodologia de desenvolvimento de software iterativo e incremental

– Procura estabelecer práticas que visem garantir a produção de um software de alta qualidade, dentro de um cronograma e orçamento possível.

• Principais práticas– Desenvolver iterativamente– Gerenciar Requisitos– Usar arquiteturas baseada em componentes– Modelar software visualmente– Verificar continuamente a qualidade do software– Controlar mudanças


Visão em espiral do UP


Visão Geral


Conceitos principais• Componentes estáticos

– Disciplinas– Fluxos– Papéis– Atividades– Artefatos

• Componentes dinâmicos– Ciclos– Fases– Iterações– Marcos


Conceitos-chave: Disciplina• Disciplina

– Uma disciplina é um conjunto de atividades relacionadas a uma “área de interesse” importante em todo o projeto.

– O fluxo de trabalho de uma disciplina é uma seqüência semi-ordenada das atividades que são realizadas para alcançar um determinado resultado.

• Tipos– Relacionadas ao desenvolvimento

• Requisitos, análise e Design, implementação, implantação,...

– Relacionadas ao suporte• Ger. de projeto, ger. de configuração e mudança, ambiente,...


Conceitos-Chave: Fluxo de trab.

• Fluxo de Trabalho– Uma simples enumeração de todos os papéis, atividades

e artefatos não constitui um processo; – É necessária uma forma para descrever as seqüências

significativas das atividades que produzem algum resultado importante e para mostrar as interações entre os papéis.

– O fluxo de trabalho é uma seqüência das atividades que produzem um resultado de valor observável.


Conceitos-Chave


Conceitos-Chave: Papel• Define

– Comportamento e as responsabilidades de um indivíduo ou de um conjunto de indivíduos que trabalham juntos como uma equipe

• Papéis não são indivíduos– Descrição do comportamento e das responsabilidades

que eles devem ter.– Mapeamento Indivíduo/Papel é feito pelo Gerente do

Projeto• Exemplos

– Analista de Sistemas, Designer de Negócio, Revisor de Requisitos, Implementador, Arquiteto de Software,…


Conceitos-Chave: Atividade• Uma atividade é uma unidade de trabalho que um

indivíduo, desempenhando o papel descrito, pode ser chamado a realizar.

• Os papéis possuem atividades que definem o trabalho que executam. Uma atividade é algo que um papel faz e produz um resultado significativo no contexto do projeto

• Exemplos– Avaliar viabilidade do conceito arquitetural– Estruturar modelo de implementação


Conceitos-Chave: Artefato• Um artefato é um produto de

trabalho do processo: os papéis usam os artefatos para executar atividades e produzem artefatos ao executarem as atividades

• As atividades possuem artefatos de entrada e saída

• Exemplo

Analista de Sistema/Especificador de

Requisitos

Domínio de Negócio e Especificação de Casos de

uso


Componentes dinâmicos• UP é um processo baseado no modelo espiral

– Projeto dividido em ciclos– Cada ciclo representa uma nova versão do produto– Cada ciclo possui 4 fases consecutivas

• Fases– Iniciação – definição do escopo– Elaboração – análise e projeto– Construção – desenvolvimento e integração– Transição – passagem ao “domínio público”

• O final das fases define os principais marcos do projeto• Cada fase pode ser quebrada em iterações

– Cada iteração resulta em uma nova release


Fase de iniciação• Objetivos

– Definir o caso de negócio do sistema• Critério de sucesso, análise de risco,

planejamento de recursos e de tempo (cronograma)

– Delimitar o escopo do projeto

• Saídas– Documento de visão do projeto– Caso de uso inicial (~ 20%)– Caso de negócio do sistema– Planejamento inicial (custo, cronograma,

processo,...)– Possíveis protótipos (avaliação)


Marco da fase de incepção• O fim da fase é um marco do projeto (milestone),

cujos critérios de avaliação são:– Tomador de decisão (stakeholder) está de acordo com o

escopo e o custo e tempo estimados– Requisitos bem compreendidos (a julgar pelo caso de uso

inicial)– Custos e cronograma correspondem a realidade– Avaliação dos protótipos desenvolvidos

• O projeto pode ser cancelado ou revisto se não passar nos critérios desse marco


Fase da elaboração• Objetivos

– Analisar o domínio do problema– Definir uma arquitetura de base– Desenvolver o planejamento do projeto,

de forma a eliminar os maiores riscos• Visão de um “oceano com um palmo

de profundidade”• Saídas

– Caso de uso (~80 %)– Arquitetura do sistema– Protótipo funcional da arquitetura– Planejamento mais detalhado, incluindo

as iterações– Detalhamento do processo de

desenvolvimento


Tarefas na elaboração (1)


Tarefas na elaboração (2)


Marco da fase de elaboração• Critérios de avaliação

– A visão do produto é estável?– A arquitetura proposta é estável?– O protótipo mostra que os riscos identificados foram

levados em conta e resolvidos?– O plano para a fase de construção está bem detalhado?– Os stakeholders concordam que o produto pode ser feito

no planejamento estipulado com a arquitetura proposta?– Os custos investidos estão de acordo com o planejado?


Fase de construção• Objetivos

– Desenvolver os componentes e funcionalidades da aplicação

– Integrar e testar os componentes• Saídas

– O produto integrado e testado– Manual do usuário– Descrição da versão atual do produto


Marco da fase de construção• Critérios de avaliação

– O produto está suficientemente estável e maduro para ser colocado a disposição?

– Todos os stakeholders estão satisfeitos em colocar o produto à disposição?

– Os custos investidos ainda estão de acordo com o planejado?

• A fase de transição pode ser adiada se os critérios falharem


Fase de transição• Objetivos

– Realizar a transição do software aos usuários• Inclui

– Beta-testing– Treinamento dos usuários– Conversão das bases de dados funcionais– Execução paralela com o sistema que estará substituindo– Envio do produto ao marketing e vendas


Marco da fase de transição• Critérios de avaliação

– O usuário está satisfeito?– As despesas reais com recursos são aceitáveis se

comparadas com as planejadas?• Final

– Reiniciar um novo ciclo de vida com uma nova versão do produto

– Manutenção total dos artefatos para terceiros que serão responsáveis pela manutenção

– Comercialização do produto


Sintetizando….


ArtefatosDocumento Iniciação Elaboração Construção Transição

Análise de Domínio de Negócio 80% 13% 5% 2%

Arquitetura de Software 10% 70% 10% 10%

Camada de Dados 5% 45% 40% 10%

Especificação de Casos de Uso 50% 10% 30% 10%

Realização de Casos de Uso 0% 20% 75% 5%

Implementação 0-5% 30-40% 50-60% 0-5%


Atividade em grupo

Gestão de projetos de Software GTI-16 Aula 2 Processo Unificado.

Documents

Transcript of Gestão de projetos de Software GTI-16 Aula 2 Processo Unificado.