Organização Processo de Software Introdução Parte I Processo de Software Motivação e Definições Iniciais CMM e mpsbr Definições Modelos de Processo de Software Modelo Sequencial Linear Modelo de Prototipagem Modelo RAD Modelos Evolucionários: Espiral Desenvolvimento baseado em componentes Parte II Processo Unificado 2 Processo de Software Motivação e Definições Iniciais Processo de Software Definições (Sommerville) Processo de Software Conjuntos de atividades para especificação, projeto, implementação e teste de sistemas de software Modelo de Processo de Software Um modelo de processo de software é uma representação abstrata de um processo. Apresenta a descrição de um processo a partir de uma perspectiva particular. 4
Motivação Adicional 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 - RUP XP - extreme Programming 5 Processos vem sendo propostos pela indústria, países e academia Rational Unified Process (A&D Workflow) NetBeans Release Management (in OPEN SOURCE SOFTWARE DEVELOPMENT PROCESS MODELING, Lonchamp, 2005) 6 Processo de Software Processo de construção de um prédio Atividades Processo de Software dados relatórios procedimentos restrições Modelo de Processo de Software Atividades Software Problema Solução Problema Solução 7 8
Processo de Software Processo de Software Paradoxo: Para todos os programas construídos há a necessidade de se entender os requisitos e o processo de negócio do contratante Na 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ção Se 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 como proceder ou do que ocorreu em um processo 9 10 Processo de Software Processo de Software 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) Fases 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ção Os requisitos-chave do sistema e do software são identificados 11 12
Processo de Software Fases Genéricas do Processo de Sw Fase de Desenvolvimento: como Definiçã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 Processo de Software Fases Genéricas do Processo de Sw Fase de Manutenção: modificações Tipos: Corretiva, Adaptativa, Perfectiva e Preventiva Reengenharia é um tipo de manutenção que normalmente implica ou deriva da reengenharia dos processos de negócios da organização usuária 13 14 Motivação Crise do Software 30% dos projetos de software são cancelados antes de sua conclusão Do restante, 70% não atendem as expectativas Em 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ção Causas para a Crise do Software Freqüentemente o problema não é tecnológico As ferramentas disponíveis são boas e bem documentadas Os profissionais são bem treinados, estão disponíveis em boa quantidade e definitivamente sabem utilizar as ferramentas disponíveis Problemas nos profissionais Baixa capacidade de comunicação e dificuldade para trabalho em grupo Gerente incapaz de obter feedback acerca do andamento Na maioria das situações, o processo de software é inexistente 15 16
Motivação Evolução do desenvolvimento de software (Antigamente) Atividade solitária, onde o sucesso era determinado por bons analistas/programadores com domínio da tecnologia envolvida O cliente possuía pouco domínio da tecnologia envolvida O software desenvolvido normalmente estava relacionado com as atividades-meio do cliente Exemplos: Folha de pagamento, Controle de Patrimônio Distribuição de dados e aplicações era limitada ao domínio físico de redes locais Desenvolvimento de software - um tipo de Arte Motivação Evolução do desenvolvimento de software (Hoje) Grande quantidade e variedade de profissionais Ex: Designers, DBA, Especialistas em web, Programação de sistemas distribuídos O cliente possui domínio acerca da tecnologia Software desenvolvido para atividades-fim Aplicações críticas para o negócio do cliente Exemplo: e-business Distribuição de dados e aplicações: Internet Desenvolvimento de software Exigência de abordagem metodológica por parte do cliente Empresas espalhadas em diferentes regiões 17 18 Motivação Crescente 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 planejados maturidade, a qual indica o crescimento contínuo da capacidade; Qualidade na definição do processo é um dos elementoschave para que uma organização possa atingir melhores níveis de maturidade; Utilizado por governos e empresas para a contratação de serviços CMM CMM-SW, CMMi Processo de Software 19
Motivação Capability Maturity Model CMM 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 sua maturidade, a qual indica o crescimento contínuo desta capacidade. 1991, segunda versão: Modelo de Capacidade da Maturidade do Processo Um dos requisitos para se obter maturidade no modelo SEI é o amplo suporte à gerência do processo. 21 22 CMM Nível Inicial Processo 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ível Gerê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 projetos básica, convencional; Se o gerente de projetos deixar essa organização, os projetos poderão cair por terra. 23 24
CMM Nível Definido CMM Nível Gerenciado Estabelecimento 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ços facilitar a introdução de métodos e técnicas de engenharia de software. O processo foi codificado e institucionalizado Existe um processo formal definido que todos seguem Constante possibilidade de melhoria do processo; Falta de avaliação da eficiência Conjunto de métricas de qualidade e produtividade foi estabelecido; Banco de dados do processo com análises de recursos e experiências disponíveis para consulta; Ênfase na coleta de métricas para melhorar a qualidade tanto do processo quanto do produto 25 26 CMM Nível Otimizado CMM A organização possui Know-how para identificar seus elementos de processo mais fracos e reforçá-los; Disponibilidade de dados para justificativa da aplicação da tecnologia; Coleta de dados automatizada (ou parcialmente); A gerência preocupa-se com a melhoria do processo ao invés de com os reparos nos produtos; Análise rigorosa da causa dos defeitos e prevenção de falhas. Considerações Cadanívelforma umaplataformanecessáriaparao próximo; Brasil: crescente número de organizações nos níveis 2 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 fornecedores Requisitos para exportação de software para governo EUA 27 28
Processo de Software CMM Certificação Evolução da maturidade 29 30 CMM CMM Organizações maduras Organizações imaturas Papéis e responsabilidades bem definidos Existe base histórica A qualidade dos produtos e processos é monitorada O processo pode ser atualizado Existe comunicação entre o gerente e seu grupo Construir software consiste na aplicação de técnicas Processo improvisado Não existe base histórica Qualidade e funcionalidade do produto sacrificadas Não há rigor no processo a ser seguido Resolução de crises imediatas Construir software é arte Nível CMM Foco Áreas-chave de processo Inicial Pessoas competentes e heróis - Gerenciamento de requisitos Repetível - Planejamento do projeto Processos de - Visão geral e acompanhamento do projeto gerenciamento - Gerenciamento de subcontratados de projetos - Garantia da qualidade do software - Gerenciamento de configuração Definido Gerenciado Otimizado Processos de engenharia e apoio Qualidade do produto e do processo Melhoramento contínuo do processo - Definição do processo organização - Programa de treinamento - Gerenciamento de software integrado - Engenharia de produto de software - Coordenação intergrupos - Revisão conjunta - Gerenciamento quantitativo dos processos - Gerenciamento da qualidade de software - Prevenção de defeitos - Gerenciamento de mudanças tecnológicas - Gerenciamento de mudanças no processo 31 32
mpsbr mpsbr Processo de Software 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 34 mpsbr mpsbr A divisão em estágios, embora baseada nos níveis de maturidade do CMMISE/SWSM tem uma graduação diferente, com o objetivo de possibilitar uma implementação e avaliação mais gradual e adequada às pequenas e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis permite uma visibilidade dos resultados de melhoria de processos com prazos mais curtos. 35 36
Definições Definições Processo de Software 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]. 38 Processo de Software Acompanhamento 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 Software Entretanto... 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 39 40
Definições Atividades guarda-chuva: transversais às demais etapas Acompanhamento e controle do projeto de software Revisões técnicas formais Garantia de qualidade de software Gestão de configuração de software Preparação e produção de documentos Gestão de reutilização Medição Gestão de Risco 41 Definições Caracterização Estrutura comum de processo Conjuntos de Tarefas Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Atividades guarda-chuva 42 Definições Definições Estrutura 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 Estrutura comum de processo Conjuntos de Tarefas Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Conjuntos de Tarefas Permite que as atividades da estrutura sejam adaptadas às características do projeto e às necessidades da equipe de projeto Estrutura comum de processo Conjuntos de Tarefas Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Atividades guarda-chuva Atividades guarda-chuva 43 44
Definições Atividades guardachuva Garantia de qualidade Gestão de configuração de software Medição Estrutura comum de processo Conjuntos de Tarefas Tarefas Marcos, produtos finais ou intermediários sujeitos a entrega Pontos de garantia de Qualidade de software Atividades guarda-chuva Modelos de Processo de Software 45 Modelos de Processo de Software Registro histórico da prática passada e roteiro para o futuro Todo 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 resolvido Desenvolvimento Técnico: resolve o problema Integração da solução: entrega os resultados Situação status Atual quo Definição problem do definition Problema solution Integração integration Desenvolvimento technical development Técnico Modelos de Processo de Software Modelos Genéricos Modelo Cascata (ou Modelo Sequencial Linear) Etapas separadas e distintas para especificação e desenvolvimento Prototipagem Modelo RAD Desenvolvimento formal de sistemas Um modelo de sistema matemático é transformado ou orienta a implementação Desenvolvimento orientado a reuso O sistema é construído a partir de componentes existentes Processos baseados em Iteração Incremental Espiral 47 48
Modelo de Processo vs Projetos http://www.phruby.com/publications/europlop2001.pdf Diferentes níveis de detalhe Organização Definição de metas Exemplos: diminuir a taxa de defeitos lucro maior que X Definição de Atividades COMO Definição de Artefatos COMO Com ainda + detalhe! 49 50 Cascata Modelo Cascata Modelos de Processo de Software 52
Cascata Cascata O processo Cascata está associado às metodologias propostas nas décadas de 1970-1980 Principais problemas Projetos reais raramente seguem o fluxo seqüencial Dificuldade em congelar os requisitos no início e em acomodar mudanças dinâmicas O cliente precisa ter paciência Notadamente as metodologias Estruturadas Yourdon Indicado somente quando os requisitos são bem conhecidos Pode ser usado em trabalhos acadêmicos com etapas bem definidas de levantamento bibliográfico Constantine Chris Gane Raramente é usado na prática, apenas quandos os requisitos são muito bem definidos Page-Jones 53 54 Prototipagem Pressupostos Prototipagem O Cliente normalmente: define um conjunto de objetivos gerais para o software, Modelos de Processo de Software mas não identifica detalhadamente os requisitos de entrada, processamento ou saída 56
Prototipagem Prototipagem Ouvir o cliente Cliente avalia o protótipo Construir e/ou Revisar o protótipo Vantagens 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 Problemas O cliente vê o que parecer ser uma versão executável do software, ignorando que o protótipo funciona de maneira precária O desenvolvedor freqüentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável 57 58 RAD RAD Modelos de Processo de Software Desenvolvimento 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 componentes Fases Modelagem do negócio Modelagem dos dados Modelagem do processo Geração da aplicação Teste e entrega 60
Uma seqüência para cada módulo por equipe team #1 business modeling data modeling team #2 business modeling data modeling process modeling team #3 business modeling data modeling process modeling application generation process modeling application generation application generation testing & turnover testing & turnover testing & turnover RAD Principais 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 60-90 days 61 62 Desenvolvimento Evolucionário Modelo Incremental Modelo Espiral Modelos de Processo de Software Desenvolvimento Evolucionário Para a maioria dos grandes sistemas, existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema Abordagem híbrida Iteração repetir partes do processo à medida que os requisitos do sistema evoluem Por exemplo, deve-se refazer (ou complementar) o projeto do sistema e sua implementação para incluir novos requisitos Cada ciclo desenvolve uma versão mais completa 64
Desenvolvimento Evolucionário Sommerville: Descrição geral Rascunho Outline description inicial Atividades Concurr ent Concorrentes activities Especificação Specification Desenvolvimento Development Validation Validação Versão Initial version inicial Intermediate Versões intermediárias versions Versão Final version final Desenvolvimento Evolucionário - Incremental Modelo Incremental Combina Cascata com Prototipagem Cada seqüência produz um incremento Exemplo: 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ção 3o: verificação sintática e gramatical 4o: capacidade avançada de disposição de página 65 66 System/information engineering Desenvolvimento delivery Evolucionário of analysis design code test increment 2 increment 1 analysis design code test increment 3analysis design code test increment 4 1st increment delivery of 2nd increment delivery of 3rd increment analysis design code test delivery of 4th increment Desenvolvimento Evolucionário - Incremental Vantagens Os 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 posteriores Existe um risco menor de fracasso completo do sistema calendar time 67 68
Desenvolvimento Evolucionário - Incremental Problemas Pode ser difícil mapear os requisitos para incrementos específicos É difícil identificar facilidades comuns que todos os incrementos exijam Desenvolvimento Evolucionário -Espiral Espiral Proposto 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. 69 70 Desenvolvimento Evolucionário -Espiral O Processo Espiral é similar ao Incremental mas Desenvolvimento Evolucionário -Espiral Visão geral do processo Cada ciclo produz algo a ser avaliado não necessariamente código Gerência de Riscos embutida no processso Ao final de cada loop é perguntado Devemos continuar? 71 72
Desenvolvimento Evolucionário -Espiral Desenvolvimento Evolucionário -Espiral Setores da Espiral Definição de objetivos Especificação de objetivos para a fase Identificação e Redução dos Riscos Riscos são identificados e as atividades são levantadas para tratálos Desenvolvimento e Validação Um modelo de desenvolvimento para o sistema é escolhida Pode ser qualquer um dos modelos genéricos Planejamento O projeto é revisado Se a decisão for continuar, um novo loop da espiral é planejado 73 74 Desenvolvimento orientado a reuso Desenvolvimento orientado a reuso Baseia-se na reutilização sistemática onde sistemas são integrados a partir de Componentes existentes (in-house) Componentes de prateleira [COTS (Commercial-offthe-shelf)] Estágios do processo Análise dos componentes Projeto de sistema com reuso Desenvolvimento e integração Processo promissor, mas existe pouca experiência 76
Desenvolvimento orientado a reuso Especificação de Requisitos Análise de Componentes Desenvolvimento orientado a reuso Catalysis: Reuso baseado em componentes Requirements Analysis Design Implementation Modificação de Requisitos Biz Problem New New New New Solution Modificação de Requisitos Assemble Assemble Assemble Assemble Projeto do Sistema com Reuso Desenvolvimento e Integração Reuse Process Validação 77 78 Desenvolvimento orientado a reuso Catalysis: Reuso baseado em componentes Desenvolvimento orientado a reuso Catalysis: Reuso baseado em componentes Business context, problem definition, solution constraints Analyze, design, build, test cycles 79 Deliver solutions 80
Agenda Processo Unificado Introdução e Variações Processo Unificado (USDP) Definições RUP x USDP Características do Processo Unificado Descrição detalhada do Processo Unificado Processos Derivados Conclusões 82 Processo Unificado Processo Unificado Histórico e Definições RUP x USDP Características do Processo Unificado Definição principal O processo oficial definido para apoiar o uso da UML Necessidade a partir do sucesso da UML como padrão de fato para especificação de software 84
Processo Unificado Processo Unificado Histórico: UML Histórico: Processo Unificado Unified Modeling Language (UML) Linguagem visual para sistemas orientados a objetos Unified Method 0.8: 1995 Bases históricas do Processo Unificado Processo Espiral Iteratividade Gerência de riscos Padrão de fato e de direito UML foi proposta somente como uma linguagem, sem orientação de uso (i.e., sem um processo) 85 86 Processo Unificado Processo Unificado Histórico: Processo Unificado O que é o Processo Unificado? Pode ter 2 respostas: Bases históricas do Processo Unificado Processo Objectory Modelo de Processo Padrão Produto comercial da IBM/Rational Proposto por Jacobson et al Processo direcionado pelos Casos de Uso 87 88
Processo Unificado: Introdução Definições: o que é Processo Unificado...Modelo de Processo Padrão Descrição de atividades que compõem um processo que adota UML Mais simples que a proposta da Rational Processo Unificado: Introdução Definições: O que é Processo Unificado...Produto comercial Desenvolvido e mantido pela Rational Integrado a suite de produtos Disponível em CD-ROM / Internet Conhecido como Rational Unified Process E-coach: treinamento a distância http://www.rational.com/rup Para o treinamento online, clicar em Trials & Betas 89 90 RUP em Português Versão não-oficial disponível em http://www.wthreex.com/rup/index.htm 91 92
Descrição do artefato Vision 1 93 94 2 3 95 96
Gabarito do artefato de Visão (projetos pequenos) 4 97 98 Processo Unificado Estrutura do Processo Unificado Estrutura do Processo Unificado Processo Iterativo, baseado no modelo Espiral Iterativo: baseado em sucessivas versões Espiral: inclui análise de riscos 100
Processo Unificado O que é um processo iterativo na prática? Produção de sucessivas versões de artefatos Repetição de um ciclo, onde em cada volta são avaliados novos requisitos Processo Unificado Processo Centrado em Casos de Uso Modelo Temporal 1. ok 2. ok 101 Modelo de Componentes Modelo de Dados 3. falha 4. ok Modelo de Testes 102 Processo Unificado Estrutura do Processo Unificado Processo Unificado Estrutura do Processo Unificado componentes do processo agrupados logicamente em workflows tempo 103 Uma iteração 104
Fases/Etapas Milestones 105 Iniciação Iniciação 107 108
Elaboração 109 Construção 110 Workflows Transição 111
Workflow de Requisitos Workflow de Análise e Projeto 113 114 Workflow de Implementação Workflow de Testes 115 116
Workflow de Implantação Descrição de Atividades 117 Realizar síntese arquitetural Analisar o Problema 119 120
Processo Unificado: detalhamento das etapas Processo Unificado: detalhamento das fases Iniciação Elaboração Construção Transição 122 Processo Unificado: detalhamento das fases Iniciação Objetivos Estabelecer escopo do projeto e condições de fronteira Descrever os casos de uso críticos do sistema Descrever pelo menos uma arquitetura candidata para os principais casos de uso Estimar o custo e cronograma para a Elaboração Estimar riscos (fontes de incerteza) Iniciação Elaboração Construção Transição Processo Unificado: detalhamento das fases Iniciação Atividades Descrever o escopo do projeto Capturar 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ócios Avaliação de riscos, staff, plano de projeto e relações entre custo, cronograma e lucro Preparar uma arquitetura candidada Avaliar 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ção Elaboração Construção Transição 123 124
Processo Unificado: detalhamento das fases Iniciação Artefatos produzidos Iniciação Elaboração Construção Transição O documento de Visão, isto é, a visão geral dos requisitos principais do sistema, incluindo funcionalidades principais e restrições O modelo de caso de uso, listando todos os casos de uso e atores que podem ser identificados neste início (10% a 20% do total) Um glossário inicial do projeto Um 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 Inicial Um plano de projeto (para etapa de Elaboração) Um ou mais protótipos Processo Unificado: detalhamento das fases Objetivos do ciclo de vida Iniciação Milestone: Objetivos do ciclo de vida Iniciação Elaboração Construção Transição Acordo com stakeholder acerca da definição de escopo, e estimativas de custo e cronograma Entendimento dos requisitos (evidenciado pelos principais casos de uso) Estimativas reais de custo e cronograma, prioridades, riscos e processo Protótipo de Arquitetura do software 125 126 Processo Unificado: detalhamento das fases Elaboração Objetivos Definir e validar uma arquitetura baseline Iniciação Elaboração Construção Transição Baseline - release estável que serve como ponto de partida e referência no desenvolvimento futuro Gerar uma Visão baseline Gerar um plano detalhado para a fase de construção Demonstrar que a arquitetura baseline irá atender a revisão no custo e tempo estimados Processo Unificado: detalhamento das fases Elaboração Atividades Iniciação Elaboração Construção Transição 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 estimativa Lições obtidas podem servir para gerar o novo projeto da arquitetura do sistema 127 128
Processo Unificado: detalhamento das fases Elaboração Artefatos 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ífico Uma descrição da arquitetura de software Um protótipo arquitetural executável Uma lista revisada dos riscos e plano de negócios Um plano para as próximas iterações Um manual do usuário preliminar Iniciação Elaboração Construção Transição Processo Unificado: detalhamento das fases Arquitetura Elaboração Milestone: Arquitetura Perguntas: Iniciação Elaboração Construção Transição A visão do produto é estável? A arquitetura é estável? O plano para Construção está suficientemente detalhado e correto? Iterações x Releases O cliente está de acordo com a visão? A alocação de recusos está de acordo com o previsto? 129 130 Processo Unificado: detalhamento das fases Construção Atividades: Gerenciamento de recursos Desenvolver e testar os componentes Avaliar e, eventualmente, prosseguir para a próxima iteração Artefatos Produto de software integrado na plataforma de hardware Manuais de usuário Descrição dos releases Concepção Elaboração Construção Transição Processo Unificado: detalhamento das fases Construção Milestone: 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 Concepção Elaboração Construção Transição 131 132
Processo Unificado: detalhamento das fases Transição Objetivo geral: Garantir que o software estjea disponível para usuários finais Atividades Finalizar o material de apoio ao usuário final Testar 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 feedback Entregar o produto final para o usuário Concepção Elaboração Construção Transição Processo Unificado: detalhamento das fases Transição Artefatos Concepção Elaboração Construção Transição Release Notes É raro o produto que não possui instruções e modificações de último-minuto Material de treinamento e documentação 133 134 Processo Unificado: Como Aplicar em Pequenos Projetos Idéias principais Iteratividade Andamento do projeto ao redor dos casos de uso Análise de riscos Processos Derivados 135
Processos Derivados Grande número de processos surgiram para customizar ou estender o Processo Unificado Experiências na indústria e academia Há uma verdadeira coqueluche em adaptações de RUP para empresas específicas Processos Derivados Praxis Processo Acadêmico, desenvolvido na UFMG http://www.wppf.uaivip.com.br/praxis/ RUP-Small Gary Pollice et al Unified Process for Education (UPEDU) Robillard & Kruchten 137 138 Processos Derivados Diversos textos e ferramentas são voltadas à adaptação do RUP para contextos especializados: O que falta? Organizacional Tecnológico Metodológico 139
Estado da Arte Tecnologia do Processo de Software Edição, simulação, reutilização e execução automatizada de processos de software Aspectos de implementação de ambientes e ferramentas para gestão de processos Linguagens de Modelagem de Processos 141