DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

Transcrição

1 DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011

2 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James Rumbaugh, discutem a necessidade de um processo de software Guiado por Casos de Uso; Centrado na Arquitetura, Iterativo e Incremental O Processo Unificado

3 O Processo Unificado reconhece: Características Importância da comunicação com o cliente para descrever a visão do cliente de um sistema (isto é, o caso de uso). Enfatiza o papel da arquitetura e ajuda a concentrar nas metas de compreensão, abertura a modificações futuras e reuso. Sugere um fluxo de processo que é iterativo e incremental.

4 Dirigido por Casos de Uso Um caso de uso é uma sequência de acões executada por um ou mais atores; Um ponto chave do UP é o emprego de casos de uso como força condutora de desenvolvimento; Dirigido por casos de uso refere-se: para dirigir todo o trabalho de desenvolvimento, desde a captação inicial até a aceitação do código;

5 Dirigido por Casos de Uso Os casos de uso são apropriados para capturar requisitos, dirigir a análise, projeto e implementação. Os casos de uso são expressos sob a perspectiva dos usuários; Oferece uma habilidade para compreensão dos requisitos reais do sistema; Facilita a gerência de projetos.

6 Centrado na Arquitetura Arquitetura é a organização fundamental do sistema como um todo; O UP especifica que a arquitetura do sistema em construção deve ser uma das principais preocupações da equipe de projeto; A arquitetura em conjunto com os casos de uso deve orientar a exploração de todos os aspectos do sistema;

7 A arquitetura é especificada no contexto de visões de modelo; Visão conceitual; Visão de módulo; Visão de código; Visão de execução. Centrado na Arquitetura

8 Centrado na Arquitetura A arquitetura proporciona: Entendimento global do sistema; Organizar o esforço de Desenvolvimento; Facilita a possibilidade de reuso; Facilita a Evolução do sistema; Tem base nos casos de uso especificados.

9 Iterativo e Incremental Uma iteração é um miniprojeto que resulta em uma versão do sistema liberada interna ou externamente; Essa versão oferece uma melhora incremental sobre a iteração anterior. Pergunta: Quais as vantagens e desvantagens do desenvolvimento iterativo e incremental?

10 O desenvolvimento Iterativo e Incremental proporciona: Um processo lógico para uma arquitetura robusta; Facilidade com mudanças contínuas nos requisitos; Maior flexibilidade para mudar planos; Iteração contínua; Entendimento precoce; Iterativo e Incremental Foco contínuo sobre riscos: Riscos técnicos; Riscos arquitetônicos; Riscos de requisitos.

11 Histórico O Processo Unificado e a UML são usados em projetos OO de qualquer natureza. A UML fornece a tecnologia necessária para apoiar a prática de engenharia de software OO. O Processo Unificado fornece um arcabouço para a engenharia de software OO usando a UML.

12 Ferramentas de Apoio Jude Poseidon IBM (RationalRose) EA

13 Fases do Processo Unificado O Processo Unificado é algumas vezes chamado de Processo Unificado Racional (RUP Rational Unified Process) por causa da Rational Corporation, contribuinte para o desenvolvimento e apoio do processo. O RUP possui 4 fases que podem ser usadas para qualquer processo de software. 1. Concepção, 2. Elaboração, 3. Construção, 4. Transição.

14 Concepção; As 4 fases Definir escopo; Esboçar arquitetura candidata; Identificar riscos; Iniciar análise econômica do projeto. Elaboração; Capturar a maioria dos requisitos funcionais; Expandir arquitetura candidata em uma base arquitetônica; Abordar riscos significativos; Finalizar análise.

15 As 4 fases Construção; Executar tarefas de desenvolvimento; Principal marco é a capacidade operacional inicial; Transição; Entregar o sistema COMPLETAMENTE funcional aos clientes.

16 Disciplinas O RUP possui 5 disciplinas: Requisitos; Análise; Projeto; Implementação; Testes.

17 Fases / Disciplinas do RUP

18 Concepção Elaboração Processo Unificado PLANEJAMENTO MODELAGEM COMUNICAÇÃO CONSTRUÇÃO Versão Incremento de Software IMPLANTAÇÃO Produção Transição Construção

19 A fase de Concepção abrange atividades de comunicação com o cliente e planejamento. A fase de Elaboração refina e expande os casos de uso identificados na fase de concepção e expande a representação da arquitetura para 5 visões diferentes: Modelo de Caso de Uso; Modelo de Análise; Modelo de Projeto; Modelo de Implementação; Modelo de Implantação. Descrição de Fases

20 Descrição de Fases A fase de Construção refina e então traduz o modelo de projeto para componentes de software implementados. A fase de Transição transfere o software do desenvolvedor para o usuário final para testes beta e aceitação. A fase de Produção em que contínuo monitoramento e suporte são conduzidos.

21 Produtos de Trabalho por Fase Fase de Concepção: Documento de Visão Modelo inicial de caso de uso Glossário inicial do Projeto; Caso de negócio inicial; Avaliação inicial de risco Plano de projeto fases e iterações Modelo de negócio se necessário Um ou mais protótipos

22 Produtos de Trabalho por Fase Fase de Elaboração: Modelo de caso de uso; Requisitos Suplementares inclui não funcionais; Modelo de análise; Descrição da Arquitetura; Protótipo; Modelo de projeto preliminar; Lista de risco revisada;

23 Fase de Elaboração: Plano de Projeto: incluindo planos de iteração, fluxos de trabalho, marcos; Manual Preliminar do usuário; Fase de Construção: Modelo de projeto Componentes de software Produtos de Trabalho por Fase Incremento integrado de software Documentação de apoio: manuais do usuário, manuais de instalação descrição do incremento atual.

24 Produtos de Trabalho por Fase Fase de Transição Incremento de software entregue; Relatório de teste beta; Realimentação geral do usuário. Teste beta é uma ação controlada de teste na qual o software é usado por usuários finais reais com a intenção de descobrir defeitos e deficiências.

25 DESENVOLVIMENTO ÁGIL

26 Desenvolvimento Ágil Em 2001, Kent Beck e sua equipe (conhecidos como Aliança Ágil ) assinaram o Manifesto para o Desenvolvimento Ágil de Software. Passaram a valorizar: Indivíduos e interações em vez de processos e ferramentas; Softwares funcionando em vez de documentação abrangente; Colaboração do cliente em vez de negociação de contratos; Resposta a modificações em vez de seguir um plano.

27 Desenvolvimento Ágil A engenharia de software ágil enfatiza: A satisfação do cliente e a entrega incremental do software logo de início; Equipes de projeto pequenas, altamente motivadas; Produtos de trabalho de engenharia de software mínimos e simplicidade global do desenvolvimento; Métodos Ágeis são chamados de métodos leves ou magros; A comunicação ativa e contínua entre desenvolvedores e clientes.

28 Desenvolvimento Ágil A engenharia ágil de software é importante por representar uma alternativa razoável para a engenharia de software convencional para certas categorias de software e certos tipos de projeto de software. São reduzidas a um conjunto mínimo de tarefas que leva a equipe de projeto à construção e entrega.

29 Desenvolvimento Ágil O único produto de trabalho realmente importante é um incremento de software operacional que é entregue ao cliente na data de entrega combinada. Se a equipe ágil concordar que o processo funciona e produzir incrementos de software em condições de serem entregues e que satisfaçam ao cliente, a equipe fez corretamente.

30 Desenvolvimento Ágil Uma equipe Ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as especialidades dessas pessoas e sua capacidade de colaborar estão no âmago do sucesso do projeto. Na visão de Jacobson, o acolhimento de modificações é o principal guia para a agilidade.

31 A agilidade engloba também: Desenvolvimento Ágil Estruturas e atitudes de equipe que tornam a comunicação mais fácil (entre os membros); Enfatiza a rápida entrega de software operacional; Dá menos importância para produtos de trabalho intermediários (nem sempre uma boa coisa); Adota os clientes como parte da equipe de desenvolvimento; O Plano de Projeto deve ser flexível.

32 Princípios da Agilidade Satisfazer o cliente por meio de entrega contínua; Modificações são bem-vindas, ainda que tardias. As modificações como vantagem para competitividade do cliente. Entrega a cada duas semanas até dois meses. Preferência menor espaço de tempo. Pessoal de negócio e desenvolvedores trabalham juntos diariamente durante o projeto.

33 Princípios da Agilidade Construção de projetos em torno de indivíduos motivados. A conversa face a face para levar a informação para dentro de uma equipe. Software funcionando é a principal medida de progresso. Processos ágeis promovem um ritmo constante. Atenção contínua à excelência técnica. Simplicidade e maximizar a quantidade de trabalho é essencial. Melhores arquiteturas, requisitos, e projetos surgem de equipes auto-organizadas.

34 Princípios da Agilidade A agilidade pode ser aplicada a qualquer processo de software. Eliminar tudo menos os produtos de trabalho mais essenciais e mantê-los simples. Enfatizar uma estratégia de entrega incremental que forneça o software funcionando ao cliente o mais rápido possível para o tipo de produto e ambiente operacional.

35 Características do processo ágil Deve atender a 3 suposições: Difícil prever como as prioridades do cliente serão modificadas à medida que o projeto prossegue. O projeto e a construção são intercalados. As duas atividades devem ser realizadas juntas. Análise, projeto, construção e testes não são tão previsíveis do ponto de vista do planejamento como gostaríamos. Portanto, um processo ágil deve ser adaptável incrementalmente.

36 Adaptação Incremental A abordagem iterativa deve habilitar o cliente: Avaliar o incremento de software de forma regular; Fornecer o feedback à equipe de software; Influenciar as adaptações do processo feitas para acomodar o feedback.

37 Equipe Ágil Características entre as pessoas de uma equipe ágil e na equipe em si: Competência: Habilidades e conhecimento podem ser ensinados a todas as pessoas; Foco comum: todos focados e uma meta entregar um incremento de software dentro do prazo; Colaboração: Criar informações que ajudarão o cliente e outros a entender o trabalho da equipe. Capacidade de tomada decisão: Autonomia para tomada de decisão sobre tópicos técnicos do projeto.

38 Equipe Ágil Características entre as pessoas de uma equipe ágil e na equipe em si: Habilidade de resolver problemas vagos: O problema que está sendo resolvido hoje pode não ser o problema que precisará ser resolvido amanhã. Respeito e confiança mútua: Equipe consolidada. Exibe confiança e respeito.

39 Características entre as pessoas de uma equipe ágil e na equipe em si: Auto-organização: Equipe organiza-se para o trabalho a ser feito; Organiza o processo para melhor acomodar seu ambiente local; Organiza o cronograma de trabalho para conseguir melhor entrega do incremento de software; Serve para aperfeiçoar a colaboração; Equipe serve como sua própria gerência. Equipe Ágil

40 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software) DSDM (Método de Desenvolvimento Dinâmico de Sistemas) Scrum Crystal FDD (Desenvolvimento Guiado por Características) AM (Modelagem Ágil) Modelos Ágeis de Processo