definições (sommerville) motivação e processo de software...

Processo de SoftwareIntrodução

Processo de SoftwareIntrodução

http://www.labes.ufpa.br2

OrganizaçãoParte I

Processo de SoftwareMotivação e Definições IniciaisCMM e mpsBrDefinições

Modelos de Processo de SoftwareModelo Sequencial LinearModelo de PrototipagemModelo RADModelos Evolucionários: EspiralDesenvolvimento baseado em componentes

Parte IIProcesso Unificado

Motivação e Definições Iniciais

Processo de Software


Processo de SoftwareDefinições (Sommerville)

Processo de SoftwareConjuntos de atividades para especificação, projeto, implementação e teste de sistemas de software

Modelo de Processo de SoftwareUm modelo de processo de software é umarepresentação abstrata de um processo. Apresenta a descrição de um processo a partir de uma perspectiva particular.


Motivação Adicional

Processos vem sendo propostos pela indústria, países e academia

Análise Estruturada (Yourdon, Gane)Objectory (Jacobson)V-Model (Alemanha)Rational Unified Process - RUPXP - eXtreme Programming


Motivação Adicional

Processos vem sendo propostos pela indústria, países e academia

NetBeans Release Management(in OPEN SOURCE SOFTWARE DEVELOPMENT PROCESS MODELING, Lonchamp, 2005)

RationalUnifiedProcess(A&D Workflow)


Processo de SoftwareProcesso de construção de um prédio

Atividades

Problema Solução



Atividades

Problema Solução

dadosrelatórios

restriçõesprocedimentos

Software

Modelo deProcesso de Software


Processo de SoftwareParadoxo:

Para todos os programas construídos há a necessidade de se entender os requisitos e o processo de negócio do contratanteNa grande maioria das situações não hádocumentação de como a organização de desenvolvimento de software vai agir para atender a requisiçãoSe a organização não sabe nem como trabalha, como vai descrever soluções para terceiros?



Modelo e Processo de Software

Processo de Sw:o que acontece na realidade

Modelo de Processo de Sw:representação abstrata daquilo de comoproceder ou do que ocorreu em um processo



2ª definição para Processo de Software“Todos os elementos do mundo real envolvidos no desenvolvimento e manutenção de um produto de software”Inclui os recursos, ferramentas, atividades, artefatos e organização (Derniame, 1998 apud GDPA)


Processo de SoftwareFases Genéricas do Processo de Sw

Fase de Definição: o quêEngenheiro de Software tenta identificar: que informação deve ser processada, que função e desempenho são desejados, que comportamento deve ser esperado do sistema, que interfaces devem ser estabelecidas, quais restrições de projeto, quais critérios de validaçãoOs requisitos-chave do sistema e do software são identificados


Processo de SoftwareFases Genéricas do Processo de Sw

Fase de Desenvolvimento: comoDefinição de como os dados devem ser estruturados, como a função deve ser implementada dentro da arquitetura do software, como os detalhes procedimentais devem ser implementados, como as interfaces devem ser caracterizadas, como o projeto deve ser traduzido em linguagem de programação, e como o teste deve ser realizado



Fases Genéricas do Processo de SwFase de Manutenção: modificações

Tipos: Corretiva, Adaptativa, Perfectiva e PreventivaReengenharia é um tipo de manutenção que normalmente implica ou deriva da reengenharia dos processos de negócios da organização usuária


Motivação

Crise do Software30% dos projetos de software são cancelados antes de sua conclusãoDo restante, 70% não atendem as expectativasEm média, os projetos ultrapassam em 189% seus orçamentos e em 220% seus cronogramas (The Standish Group, numa análise de 8000

projetos em 352 empresas)


MotivaçãoCausas para a Crise do Software

Freqüentemente o problema não é tecnológicoAs ferramentas disponíveis são boas e bem documentadasOs profissionais são bem treinados, estão disponíveis em boa quantidade e definitivamente sabem utilizar as ferramentas disponíveis

Problemas nos profissionaisBaixa capacidade de comunicação e dificuldade para trabalho em grupoGerente incapaz de obter feedback acerca do andamento

Na maioria das situações, o processo de software éinexistente


MotivaçãoEvolução do desenvolvimento de software (Antigamente)

Atividade solitária, onde o sucesso era determinado por bons analistas/programadores com domínio da tecnologia envolvidaO cliente possuía pouco domínio da tecnologia envolvidaO software desenvolvido normalmente estava relacionado com as atividades-meio do cliente

Exemplos: Folha de pagamento, Controle de PatrimônioDistribuição de dados e aplicações era limitada ao domínio físico de redes locaisDesenvolvimento de software - “um tipo de Arte”


MotivaçãoEvolução do desenvolvimento de software (Hoje)

Grande quantidade e variedade de profissionaisEx: Designers, DBA, Especialistas em web, Programação de sistemas distribuídos

O cliente possui domínio acerca da tecnologiaSoftware desenvolvido para atividades-fim

Aplicações críticas para o negócio do clienteExemplo: e-business

Distribuição de dados e aplicações: InternetDesenvolvimento de software

Exigência de abordagem metodológica por parte do clienteEmpresas espalhadas em diferentes regiões


MotivaçãoCrescente importância de métodos para avaliação da qualidade de software baseados no processo

Capability Maturity Model (SEI-CMM) e SPICE (ISO)Avalia uma organização segundo:

capacidade de produzir resultados planejadosmaturidade, a qual indica o crescimento contínuo dacapacidade;

Qualidade na definição do processo é um dos elementos-chave para que uma organização possa atingir melhores níveis de maturidade;Utilizado por governos e empresas para a contratação de serviços

CMMCMM-SW, CMMi



MotivaçãoCMM – Capability Maturity Model for Software

Desenvolvido em 1987 pelo SEI - Software Engineering Institute, filiado à Universidade Carnegie Mellon.Avalia uma organização pela sua capacidade de produzir resultados planejados e pela suamaturidade, a qual indica o crescimento contínuodesta capacidade.1991, segunda versão: Modelo de Capacidade daMaturidade do ProcessoUm dos requisitos para se obter maturidade no modelo SEI é o amplo suporte à gerência do processo.


Capability Maturity ModelCapability Maturity Model


CMM – Nível InicialProcesso de desenvolvimento caótico;Falta de integração;Sucesso dos projetos se deve a esforços heróicos;Diante de uma crise, a organização abandona os procedimentos definidos e reverte à codificação e testes.

Chega desse negócio de projeto!Estamos atrasados!

Vamos COMEÇAR A PROGRAMAR!!!


CMM – Nível RepetívelGerência do projeto, segurança do produto e controle de mudanças já estabelecidos;A organização cumpre seus prazos e orçamentos;Sucesso através de administração de projetosbásica, convencional;Se o gerente de projetos deixar essaorganização, os projetos poderão “cair porterra”.


CMM – Nível DefinidoEstabelecimento de um Grupo de Processo de Engenharia de Software responsável por:

focalizar e cobrir os esforços de melhoria do processo;manter a gerência informada do estado desses esforçosfacilitar a introdução de métodos e técnicas de engenharia de software.

O processo foi codificado e institucionalizadoExiste um processo formal definido que todos seguemConstante possibilidade de melhoria do processo;Falta de avaliação da eficiência


CMM – Nível GerenciadoConjunto de métricas de qualidade e produtividade foiestabelecido;Banco de dados do processocom análises de recursos e experiências disponíveis paraconsulta;Ênfase na coleta de métricaspara melhorar a qualidadetanto do processo quanto do produto


CMM – Nível OtimizadoA organização possui Know-how para identificar seuselementos de processo mais fracos e reforçá-los;Disponibilidade de dados para justificativa da aplicaçãoda tecnologia;Coleta de dados automatizada (ou parcialmente);A gerência preocupa-se com a melhoria do processo aoinvés de com os reparos nos produtos;Análise rigorosa da causa dos defeitos e prevenção de falhas.


CMMConsiderações

Cada nível forma uma plataforma necessária para o próximo;Brasil: crescente número de organizações nos níveis2 e 3;Para alcançar níveis elevados de maturidade, a organização deve preocupar-se com a gerência e o controle do processo;Compradores:

Avaliação dos fornecedoresRequisitos para exportação de software para governo EUA



Evolução damaturidade


CMM

Certificação


CMM

Papéis e responsabilidadesbem definidos

Processo improvisado

Existe base histórica Não existe base histórica

A qualidade dos produtos eprocessos é monitorada

Qualidade e funcionalidade doproduto sacrificadas

O processo pode ser atualizado Não há rigor no processo aser seguido

Existe comunicação entre ogerente e seu grupo

Resolução de crises imediatas

Organizações maduras Organizações imaturas

Construir software consiste naaplicação de técnicas

Construir software é “arte”


CMMNível CMM Foco Áreas-chave de processo

Inicial Pessoas competentes e heróis

RepetívelProcessos degerenciamento

de projetos

- Gerenciamento de requisitos- Planejamento do projeto- Visão geral e acompanhamento do projeto- Gerenciamento de subcontratados- Garantia da qualidade do software- Gerenciamento de configuração

Definido Processos de engenhariae apoio

- Definição do processo organização- Programa de treinamento- Gerenciamento de software integrado- Engenharia de produto de software- Coordenação intergrupos- Revisão conjunta

Gerenciado Qualidade do produto edo processo

- Gerenciamento quantitativo dos processos- Gerenciamento da qualidade de software

Otimizado Melhoramento contínuodo processo

- Prevenção de defeitos- Gerenciamento de mudanças tecnológicas- Gerenciamento de mudanças no processo

mpsBr



mpsBr“O mpsBr é um projeto estruturante que vai promover a qualificação de um grupo amplo de empresas compatível com os padrões de qualidade aceitos internacionalmente pela comunidade de software, a custos acessíveis para a grande maioria das empresas brasileiras, sendo adequado ao perfil e cultura das empresas de software do país.”

Página do Softex


mpsBr


mpsBr

A divisão em estágios, embora baseada nos níveis de maturidade do CMMISE/SWSMtem uma graduação diferente, com o objetivo de possibilitar uma implementação eavaliação mais gradual e adequada às pequenas e médias empresas. A possibilidadede se realizar avaliações considerando mais níveis permite uma visibilidade dosresultados de melhoria de processos com prazos mais curtos.

Definições



Definições“Conjunto de todas as atividades realizadas no contexto de um projeto de desenvolvimento de software”[GRUHN04]

O conjunto de atividades necessárias para transformar os requisitos do usuário em software. [HUM89d]

O uso de um processo de software bem definido (automatizado ou não) leva à redução dos custos de produção, bem como à melhoria da qualidade e integridade do software [GIM94].


Processo de SoftwareAcompanhamento do progresso de projetos

Você entende meu problema e minhas necessidades?Você pode projetar um sistema que resolverá meu problema ou satisfará minhas necessidades?Quanto tempo você levará para desenvolver meu sistema?Quanto irá custar o desenvolvimento desse sistema?


Processo de SoftwareEntretanto... A definição de um processo não é bala de prata!

A existência prática com processos bem definidos énecessária para a maturidade das organizações

Porém, processos rigorosamente definidos mas não alinhados com os objetivos da organização são entraves burocráticos, e não fatores de produção


DefiniçõesAtividades guarda-chuva: transversais às demais etapas

Acompanhamento e controle do projeto de softwareRevisões técnicas formaisGarantia de qualidade de softwareGestão de configuração de softwarePreparação e produção de documentosGestão de reutilizaçãoMediçãoGestão de Risco


Definições

Caracterização

Estrutura comum de processo

Tarefas

Marcos, produtos finais ouintermediários sujeitos a entrega

Pontos de garantia deQualidade de software

Conjuntos de Tarefas

Atividades guarda-chuva


DefiniçõesEstrutura Comum de Processo

É estabelecida definindo um pequeno número de atividades que são aplicáveis a todos os projetos de software, independente de seu tamanho ou complexidade


Tarefas






Definições

Conjuntos de TarefasPermite que as atividades da estrutura sejam adaptadas às características do projeto e às necessidades da equipe de projeto


Tarefas






Definições


Garantia de qualidadeGestão de configuração de softwareMedição


Tarefas





Modelos de Processo de Software


Modelos de Processo de SoftwareRegistro histórico da prática passada e roteiro para o futuroTodo processo pode ser caracterizado como um ciclo:

Situação atual: o estado atual das “coisas”Definição do problema: identifica o problema específico a ser resolvidoDesenvolvimento Técnico: resolve o problemaIntegração da solução: entrega os resultados

statusquo

problemdefinition

technicaldevelopment

solutionintegration

Definiçãodo

Problema

DesenvolvimentoTécnico

Integração

SituaçãoAtual


Modelos de Processo de SoftwareModelos Genéricos

Modelo Cascata (ou Modelo Sequencial Linear)Etapas separadas e distintas para especificação e desenvolvimento

PrototipagemModelo RADDesenvolvimento formal de sistemas

Um modelo de sistema matemático é transformado ou orienta a implementação

Desenvolvimento orientado a reusoO sistema é construído a partir de componentes existentes

Processos baseados em IteraçãoIncrementalEspiral


Modelo de Processo vs Projetoshttp://www.phruby.com/publications/EuroPLoP2001.pdf


Diferentes níveis de detalhe

Organização

Definição de Atividades

Definição de Artefatos

Definição de metasExemplos:“diminuir a taxa de defeitos”“lucro maior que X”

COMO

COMO Com ainda+ detalhe!

Modelo Cascata



Cascata


Cascata

O processo Cascata está associado às metodologias propostas nas décadas de 1970-1980

Notadamente as metodologias EstruturadasYourdonConstantineChris GanePage-Jones


CascataPrincipais problemas

Projetos reais raramente seguem o fluxo seqüencialDificuldade em congelar os requisitos no início e em acomodar mudanças dinâmicasO cliente precisa ter paciência

Indicado somente quando os requisitos são bem conhecidosPode ser usado em trabalhos acadêmicos com etapas bem definidasde “levantamento bibliográfico”

Raramente é usado na prática, apenas quandos os requisitos sãomuito bem definidos

Prototipagem



Prototipagem

PressupostosO Cliente normalmente:

define um conjunto de objetivos gerais para o software,mas não identifica detalhadamente os requisitos de entrada, processamento ou saída


Prototipagem

Ouvir ocliente

Construir e/ouRevisar oprotótipo

Clienteavalia oprotótipo


PrototipagemVantagens

O progresso é visível e rápido nas primeiras iteraçõesÉ um método indicado para validar requisitos de interação com o usuário

ProblemasO cliente vê o que parecer ser uma versão executável do software, ignorando que o protótipo funciona de maneira precáriaO desenvolvedor freqüentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável

RAD



RADDesenvolvimento rápido de aplicação

Incremental, com ciclo curtoÉ uma adaptação “de alta velocidade” do modelo seqüencial linear, no qual a rapidez é obtida com componentesFases

Modelagem do negócioModelagem dos dadosModelagem do processoGeração da aplicaçãoTeste e entrega


businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling


testing&

turnover

businessmodeling

datamodeling

processmodeling


testing&

turnover

team #1

team #2team #3

60 - 90 days

Uma seqüênciapara cada módulopor equipe


RADPrincipais desvantagens

Nem todos os tipos de aplicação são apropriados para o RAD.

Se o sistema não puder ser adequadamente modularizado, a construção e seleção de componentes será problemática

Não é adequado quando são enfrentados riscos técnicos elevados

Por exemplo, adoção profunda de uma nova tecnologia

Desenvolvimento EvolucionárioModelo IncrementalModelo EspiralModelos de Processo de Software


Desenvolvimento EvolucionárioPara a maioria dos grandes sistemas, existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema

Abordagem híbridaIteração

repetir partes do processo à medida que os requisitos do sistema evoluemPor exemplo, deve-se refazer (ou complementar) o projeto do sistema e sua implementação para incluir novos requisitosCada ciclo desenvolve uma versão mais completa


Desenvolvimento Evolucionário

Validation Finalversion

Development Intermediateversions

Specification Initialversion

Outlinedescription

Concurrentactivities

Sommerville:Descrição geral

Rascunhoinicial

Especificação

Desenvolvimento

Validação

Versãoinicial

Versõesintermediárias

Versãofinal

AtividadesConcorrentes


Desenvolvimento Evolucionário -Incremental

Modelo IncrementalCombina Cascata com PrototipagemCada seqüência produz um incrementoExemplo: Processador de Texto

1o release: gestão básica de arquivos, edição e produção de documentos (núcleo do produto)2o: capacidades mais sofisticadas de edição3o: verificação sintática e gramatical4o: capacidade avançada de disposição de página


Desenvolvimento Evolucionárioanalysis design code test

System/informationengineering

analysis design code test



increment 2

increment 3

increment 4

increment 1

delivery of1st increment

delivery of2nd increment

delivery of3rd increment

delivery of4th increment

calendar time



VantagensOs clientes não precisam esperar até que todo o sistema seja entregue, para então tirarem proveito dele.

O primeiro estágio deve satisfazer os requisitos mais importantes e, assim, o software pode ser imediatamente usado

Os clientes podem utilizar os primeiros incrementos como um protótipo e obter uma experiência que forneça os requisitos para estágios posterioresExiste um risco menor de fracasso completo do sistema



ProblemasPode ser difícil mapear os requisitos para incrementos específicosÉ difícil identificar facilidades comuns que todos os incrementos exijam


Desenvolvimento Evolucionário - Espiral

EspiralProposto Boehm (1988)O processo não é descrito como uma seqüência de atividades (com eventuais retornos)O processo é representado como uma espiral, onde cada loop representa uma fase do processo.



O Processo Espiral é similar ao Incremental mas

Cada ciclo produz algo a ser avaliadonão necessariamente código

Gerência de Riscos embutida no processsoAo final de cada loop é perguntado “Devemos continuar?”



Visão geral do processo





Setores da EspiralDefinição de objetivos

Especificação de objetivos para a faseIdentificação e Redução dos Riscos

Riscos são identificados e as atividades são levantadas para tratá-los

Desenvolvimento e ValidaçãoUm modelo de desenvolvimento para o sistema é escolhidaPode ser qualquer um dos modelos genéricos

PlanejamentoO projeto é revisadoSe a decisão for continuar, um novo loop da espiral é planejado

Desenvolvimento orientado a reuso



Baseia-se na reutilização sistemática ondesistemas são integrados a partir de

Componentes existentes (in-house)Componentes de prateleira [COTS (Commercial-off-the-shelf)]

Estágios do processoAnálise dos componentesProjeto de sistema com reusoDesenvolvimento e integração

Processo promissor, mas existe poucaexperiência



Especificaçãode Requisitos

Análise deComponentes

Modificação deRequisitos

Modificação deRequisitos

Projeto do Sistemacom Reuso

Desenvolvimentoe Integração

Validaçãohttp://www.labes.ufpa.br

78


Catalysis: Reuso baseado em componentes

SolutionBiz Problem

Req

uire

men

ts

Ana

lysis

Des

ign

Impl

emen

tatio

n

New

New

New

New

Ass

embl

e

Ass

embl

e

Ass

embl

e

Ass

embl

e

Reuse Process



Catalysis: Reuso baseado em componentes



Catalysis: Reuso baseado em componentesBusiness context, problem definition, solution constraints

Analyze, design, build, test cycles

Deliver solutions

Processo UnificadoIntrodução e VariaçõesProcesso Unificado

Introdução e Variações


AgendaProcesso Unificado (USDP)

DefiniçõesRUP x USDPCaracterísticas do Processo Unificado

Descrição detalhada do Processo UnificadoProcessos DerivadosConclusões

Processo Unificado

Histórico e DefiniçõesRUP x USDPCaracterísticas do Processo

Unificadohttp://www.labes.ufpa.br

84

Processo Unificado

Definição principalO processo “oficial” definido para apoiar o uso da UMLNecessidade a partir do sucesso da UML como padrão de fato para especificação de software


Processo Unificado

Histórico: UMLUnified Modeling Language (UML)

Linguagem visual para sistemas orientados a objetosUnified Method 0.8: 1995Padrão de fato e de direitoUML foi proposta somente como uma linguagem, sem orientação de uso (i.e., sem um processo)


Processo Unificado

Histórico: Processo UnificadoBases históricas do Processo Unificado

Processo EspiralIteratividadeGerência de riscos


Processo Unificado

Histórico: Processo Unificado

Bases históricas do Processo Unificado

Processo ObjectoryProposto por Jacobson et alProcesso direcionado pelos Casos de Uso


Processo Unificado

O que é o Processo Unificado?Pode ter 2 respostas:

Modelo de Processo PadrãoProduto comercial da IBM/Rational


Processo Unificado: Introdução

Definições: o que é Processo Unificado

...Modelo de Processo PadrãoDescrição de atividades que compõem um processo que adota UMLMais simples que a proposta da Rational


Processo Unificado: IntroduçãoDefinições: O que é Processo Unificado

...Produto comercialDesenvolvido e mantido pela RationalIntegrado a suite de produtosDisponível em CD-ROM / InternetConhecido como Rational Unified ProcessE-coach: treinamento a distância

http://www.rational.com/rupPara o treinamento online, clicar em “Trials & Betas”



RUP em PortuguêsVersão não-oficial

disponível emhttp://www.wthreex.com/rup/index.htm


Descrição do artefatoVision


1


2


3


4


Gabarito do artefato de Visão(projetos pequenos)

Estrutura do Processo Unificado


Processo Unificado

Estrutura do Processo UnificadoProcesso Iterativo, baseado no modelo Espiral

Iterativo: baseado em sucessivas versõesEspiral: inclui análise de riscos


Processo Unificado

O que é um processo iterativo na prática?Produção de sucessivas versões de artefatosRepetição de um ciclo, onde em cada “volta”são avaliados novos requisitos


Processo Unificado

Processo Centrado em Casos de Uso

1. ok 2. ok

3. falha4. ok

Modelo de TestesModelo de Componentes

Modelo de Dados

Modelo Temporal


Processo Unificado


tempo

componentesdo processoagrupadoslogicamenteem workflows


Processo Unificado


Uma iteração


Milestones

Fases/Etapas


Inic

iaçã

o


Inic

iaçã

o


Ela

bora

ção

http://www.labes.ufpa.br110Construção


Tran

siçã

o

Workflows


Workflowde Requisitos


Workflow de Análise e Projeto


Workflow de Implementação


Workflow de Testes


Workflow de Implantação

Descrição de Atividades


Realizar síntese arquitetural


Analisar o Problema

Processo Unificado: detalhamento das etapas


Processo Unificado: detalhamento das fases

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



IniciaçãoObjetivos

Estabelecer escopo do projeto e condições de fronteiraDescrever os casos de uso críticos do sistemaDescrever pelo menos uma arquitetura candidata para os principais casos de usoEstimar o custo e cronograma para a ElaboraçãoEstimar riscos (fontes de incerteza)




IniciaçãoAtividades

Descrever o escopo do projetoCapturar o contexto na forma de requisitos e restrições para determinar um critério de aceitação do produto final

Planejar e preparar o Plano de NegóciosAvaliação de riscos, staff, plano de projeto e relações entre custo, cronograma e lucro

Preparar uma arquitetura candidadaAvaliar alternativas de projeto (atividade pode ser suprimida se o sistema não possui novidades ou possui uma arquitetura bem conhecida)

Preparar o ambiente de projeto (environment)Escolha de recursos físicos e humanos, e ferramentas de software

Obs: Geralmente a concepção é completada em dois dias ou menos para sistemas pequenos




IniciaçãoArtefatos produzidos

O documento de Visão, isto é, a visão geral dos requisitos principais do sistema, incluindo funcionalidades principais e restriçõesO modelo de caso de uso, listando todos os casos de uso e atoresque podem ser identificados neste início (10% a 20% do total)Um glossário inicial do projetoUm plano de negócios inicial, contendo:

Contexto do negócio, Critério de sucesso (projeção de lucro, reconhecimento do mercado, etc), Provisionamento Financeiro

Análise de Riscos InicialUm plano de projeto (para etapa de Elaboração)Um ou mais protótipos




IniciaçãoMilestone: Objetivos do ciclo de vida

Acordo com stakeholder acerca da definição de escopo, e estimativas de custo e cronogramaEntendimento dos requisitos (evidenciado pelos principais casos de uso)Estimativas reais de custo e cronograma, prioridades, riscos e processoProtótipo de Arquitetura do software


Objetivos dociclo de vida



ElaboraçãoObjetivos

Definir e validar uma arquitetura baselineBaseline - release estável que serve como ponto de partida e referência no desenvolvimento futuro

Gerar uma Visão baselineGerar um plano detalhado para a fase de construçãoDemonstrar que a arquitetura baseline irá atender a revisão no custo e tempo estimados




ElaboraçãoAtividades

Elaborar a visão: entendimento sólido dos casos de uso mais críticos (que determinam as decisões arquiteturais e de planejamento)A arquitetura é elaborada e componentes de software são selecionados

Componentes potenciais são avaliados segundo decisões make/buy/reuse para determinar custo e estimativaLições obtidas podem servir para gerar o novo projeto da arquitetura do sistema




ElaboraçãoArtefatos produzidos

Um modelo de caso de uso (pelo menos 80% dos casos de uso)Requisitos suplementares que capturem requisitos não-funcionais e requisitos que não estão associados com um caso de uso específicoUma descrição da arquitetura de softwareUm protótipo arquitetural executávelUma lista revisada dos riscos e plano de negóciosUm plano para as próximas iteraçõesUm manual do usuário preliminar




ElaboraçãoMilestone: Arquitetura

Perguntas:A visão do produto é estável?A arquitetura é estável?O plano para Construção está suficientemente detalhado e correto?

Iterações x ReleasesO cliente está de acordo com a visão?A alocação de recusos está de acordo com o previsto?


Arquitetura



ConstruçãoAtividades:

Gerenciamento de recursosDesenvolver e testar os componentesAvaliar e, eventualmente, prosseguir para a próxima iteração

ArtefatosProduto de software integrado na plataforma de hardwareManuais de usuárioDescrição dos releases

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



ConstruçãoMilestone: Início da Capacidade Operacional

O release está maduro e estável para ser usado?Todos os stakeholders estão prontos para a transição?O consumo de recursos é aceitável?

Início da capacidade operacional




TransiçãoObjetivo geral:

Garantir que o software estjea disponível para usuários finaisAtividades

Finalizar o material de apoio ao usuário finalTestar o produto entregue

Simular o ambiente do cliente (se possível) ou instalar o software no cliente

Realizar um ajuste fino do produto com base no feedbackEntregar o produto final para o usuário




TransiçãoArtefatos

Release NotesÉ raro o produto que não possui instruções e modificações de “último-minuto”

Material de treinamento e documentação



Processo Unificado: Como Aplicar em Pequenos Projetos

Idéias principaisIteratividadeAndamento do projeto ao redor dos casos de usoAnálise de riscos

Processos Derivados


Processos Derivados

Grande número de processos surgiram para customizar ou estender o Processo UnificadoExperiências na indústria e academiaHá uma verdadeira coqueluche em adaptações de RUP para empresas específicas


Processos Derivados

PraxisProcesso Acadêmico, desenvolvido na UFMGhttp://www.wppf.uaivip.com.br/praxis/

RUP-SmallGary Pollice et al

Unified Process for Education (UPEDU)Robillard & Kruchten


Processos Derivados

Diversos textos e ferramentas são voltadas à adaptação do RUP para contextos especializados:

OrganizacionalTecnológicoMetodológico

O que falta?


Estado da Arte

Tecnologia do Processo de SoftwareEdição, simulação, reutilização e execução automatizada de processos de softwareAspectos de implementação de ambientes e ferramentas para gestão de processosLinguagens de Modelagem de Processos

definições (sommerville) motivação e processo de software...

Documents