} Aula Anterior
} O que será abordado na aula de hoje? } Próxima aula
} Bibliografia
} O RUP tem duas dimensões:
◦ O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve Representa o aspecto dinâmico do processo quando ele é aprovado e
é expressa em termos de fases, iterações e marcos.
◦ O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza:
Representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo (consulte Conceitos-chave).
} A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do RUP é dividido em quatro fases sequenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais.
} As fases não são idênticas em termos de programação e esforço.
◦ Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio tamanho deve prever a seguinte distribuição de esforço e programação:
} Uma passagem pelas quatro fases é um ciclo de desenvolvimento;
} Cada passagem pelas quatro fases produz uma geração do software. A menos que produto “desapareça”, ele irá se desenvolver na próxima geração, repetindo a mesma sequência de fases de iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas diversas fases.
} Esses ciclos subsequentes são chamados de ciclos de evolução. À medida que o produto atravessa vários ciclos, são produzidos novas gerações.
} A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto.
} A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir. } Para projetos que visam melhorias em um sistema
existente, a fase de iniciação é mais rápida, mas ainda se concentra em assegurar que o projeto seja
compensatório e que seja possível fazê-lo.
} Objetivos:
◦ Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto.
◦ Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design.
◦ Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos.
◦ Estimar o curso geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração imediatamente a seguir).
◦ Estimar riscos em potencial (as origens de imprevistos). ◦ Preparar o ambiente de suporte para o projeto.
} Atividades básicas: ◦ Formular o escopo do projeto.
◦ Planejar e preparar o gerenciamento de riscos, a organização da equipe, o plano do projeto e as mudanças de custo/programação/ lucros.
◦ Sintetizar uma possível arquitetura, avaliando as mudanças no design e em fazer/comprar/reutilizar, para que seja possível estimar custo, programação e recursos.
◦ Preparar o ambiente para o projeto, avaliando o projeto e a organização, selecionando ferramentas e decidindo quais partes do processo devem ser melhoradas.
} Marco: Objetivos do Ciclo de Vida
} No fim na fase de iniciação está o primeiro marco mais importante do projeto ou Marco dos Objetivos do Ciclo de Vida. Nesse momento, você analisa os objetivos do ciclo de vida do projeto e decide prosseguir com o
projeto ou cancelá-lo.
} Artefatos:
◦ Visão -> é definida a visão que os envolvidos têm do produto a ser desenvolvido, em termos das necessidade e características mais importantes.
◦ Caso de Negócio -> fornece as informações necessárias do ponto de vista de um negócio, para determinar se vale ou não a pena investir no projeto (ROI).
◦ Plano de desenvolvimento de software -> reúne todas as informações necessárias ao gerenciamento do projeto. ◦ Modelo de Casos de Uso -> consiste de um modelo das
funções pretendidas do sistema e seu ambiente, e serve como um contrato estabelecido entre o cliente e os desenvolvedores. ◦ Glossário -> define termos importantes usados pelo projeto.
} A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base
estável para o esforço da fase de construção.
} A arquitetura se desenvolve a partir do exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco.
} A estabilidade da arquitetura é avaliada através de um ou
mais protótipos de arquitetura.
} Objetivos:
◦ Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento. ◦ Tratar todos os riscos significativos do ponto de vista da
arquitetura do projeto.
◦ Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo.
◦ Estabelecer um ambiente de suporte.
} Atividades:
◦ Definir, validar e criar a baseline da arquitetura com rapidez e eficiência.
◦ Refinar a Visão, com base nas informações novas obtidas durante a fase, estabelecendo uma compreensão sólida dos casos de uso mais críticos que conduzem as decisões de arquitetura e planejamento.
◦ Criar planos de iteração detalhados e baselines para a fase de construção.
◦ Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte de automatização necessários para dar assistência à equipe de construção.
} Marco: Arquitetura do Ciclo de Vida
} No fim na fase de elaboração está o segundo marco mais importante do projeto, o Marco da Arquitetura do Ciclo de Vida. Nesse momento, você examina os objetivos e o escopo detalhados do sistema, a opção de arquitetura e a resolução dos principais riscos.
} Artefatos:
◦ Protótipos -> são usados de uma maneira direta para reduzir o risco.
◦ Lista de Riscos -> classificada em ordem decrescente de importância
e associada a ações especificas de contingência ou diminuição de riscos.
◦ Documento de Arquitetura de Software -> fornece uma visão
geral da arquitetura abrangente do sistema, usando diversas visões de arquitetura para descrever diferentes aspectos do sistema.
◦ Modelo de Projeto -> é um modelo de objeto que descreve a
realização dos casos de uso e serve como uma abstração do modelo de implementação e seu código-fonte.
◦ Modelo de Dados -> é um subconjunto do modelo de implementação
que descreve a representação lógica e física dos dados persistentes no sistema.
} Tipos de Protótipos:
◦ Protótipo comportamental, que enfatiza a exploração de determinado comportamento do sistema.
◦ Protótipo estrutural, que explora algumas questões arquiteturais ou tecnológicas.
◦ Protótipo exploratório, que é descartado quando fica pronto, também chamado de protótipo para descarte.
◦ Protótipo evolutivo, que gradualmente evolui para se tornar um sistema real.
} A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline.
} A fase de construção é de certa forma um processo de
manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade.
} Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição.
} Objetivos:
◦ Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento e retrabalho desnecessários.
◦ Atingir a qualidade adequada com rapidez e eficiência. ◦ Atingir as versões úteis (alfa, beta e outros releases de teste) com
rapidez e eficiência.
◦ Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades necessárias.
◦ Decidir se o software, os locais e os usuários estão prontos para que o aplicativo seja implantado.
◦ Atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento.
} Atividades:
◦ Gerenciamento de recursos, otimização de controle e processo. ◦ Desenvolvimentocompleto do componente e teste dos critérios
de avaliação definidos.
◦ Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão.
} Marco: Capacidade Operacional Inicial
} No Marco da capacidade Operacional Inicial, o produto está pronto para ser passado para a Equipe de Transição. Toda a funcionalidade já foi desenvolvida e todos os testes alfa (se houver algum) foram concluídos. Além do software, um manual do usuário foi desenvolvido, e existe uma descrição do release atual (Release Notes).
} Artefatos:
◦ O próprio sistema executável, pronto para começar o teste “beta”.
◦ Conjunto de Testes -> testes implantados e executados para
validar a estabilidade da versão de cada release executável criado durante a fase de construção.
} O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais. A Fase de Transição pode atravessar várias iterações e incluir testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar os ajustes fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes do ciclo de vida do projeto.
} No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento.
} Em alguns casos, o fim do ciclo de vida atual pode
coincidir com o início de outro ciclo de vida no mesmo
produto, conduzindo à nova geração ou versão do
produto.
} Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado.
} Objetivos:
◦ Teste beta para validar o novo sistema em confronto com as expectativas do usuário.
◦ Teste beta e operação paralela relativa a um sistema legado que está sendo substituído.
◦ Conversão de bancos de dados operacionais. ◦ Treinamento de usuários e equipe de manutenção. ◦ Atividades de ajuste, como correção de erros, melhoria no
desempenho e na usabilidade.
◦ Obtenção do consentimento dos envolvidos de que as baselines de implantação são consistentes com os critérios de avaliação da visão.
} Atividades:
◦ Executar planos de implantação.
◦ Finalizar o material de suporte para o usuário final.
◦ Testar o produto liberado no local de desenvolvimento.
◦ Criar um release do produto.
◦ Obter feedback do usuário.
◦ Ajustar o produto com base em feedback.
} Marco: Release do Produto
} No fim da fase de transição está o quarto marco mais
importante do projeto, o Marco do Release do Produto. Nesse momento, você decide se os objetivos foram atendidos, e se outro ciclo de desenvolvimento deve ser iniciado. Em alguns casos, esse marco pode coincidir com o fim da fase de iniciação do próximo ciclo.
} Artefatos:
◦ Notas de Release - > identificam mudanças e erros conhecidos
em uma versão ou em uma unidade de implantação que tenha sido disponibilizada para uso.
◦ Artefatos de Instalação -> se referem ao software e às
instruções documentadas necessárias para instalar o produto.
◦ Materiais de Treinamento -> referem-se ao material usado
nos programas ou cursos de treinamento para ajudar os usuários finais com a utilização, a operação e/ou a manutenção dos produtos.
