Engenharia de Software I

Transcrição

1 Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook [email protected] DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1

2 Para quê o Desenvolvimento Rápido de Software? Os negócios atualmente operam em um ambiente global sujeito a rápidas mudanças Novas oportunidades Novos mercados Mudanças de condições econômicas Surgimento de novos produtos e concorrentes O software é parte de quase todas as operações de negócios 3 Para quê o Desenvolvimento Rápido de Software? Em geral, os negócios operam em um ambiente de mudanças constantes Dificuldade de propor um conjunto completo de requisitos de software estável Clientes mudam os requisitos inevitavelmente Identificação dos reais requisitos Após a entrega do sistema Experiência inicial dos usuários 4 2

3 Como funciona o Processo? Engenharia de software ágil = filosofia + princípios de desenvolvimento Priorizam a entrega mais que análise e projeto (mas não desencorajam as atividades); a comunicação ativa e contínua entre desenvolvedores e clientes Defende a satisfação do cliente e a entrega de incremental prévio; equipes de projeto pequenas e altamente motivadas; métodos informais; artefatos mínimos e simplicidade no desenvolvimento 5 Como funciona o Processo? Processos de desenvolvimento rápido são projetados para criar um software útil rapidamente São processos iterativos Intercala a especificação, projeto, desenvolvimento e testes Software entregue em partes Cada parte inclui uma nova funcionalidade 6 3

4 Como funciona o Processo? 7 Quais são as características? Os processos de especificação, projeto e implementação são concorrentes Não há detalhamento Minimização da documentação ou gerada automaticamente O sistema é desenvolvido em uma série de incrementos Usuários finais e stakeholders participam da especificação e avaliação de cada incremento 8 4

5 Quais são as Vantagens? Entrega acelerada Clientes vêem seus requisitos na prática Especificação de novas mudanças Engajamento do usuário com o sistema Envolvimento dos usuários Feedback à equipe desenvolvedora Melhor entendimento dos requisitos 9 Quais são as Desvantagens? Problemas de gerenciamento Grandes sistemas exigem modelos mais estruturados Produção em grandes quantidades não compensa Problemas de contrato Contrato baseado em especificações de sistema Cliente paga por tempo despendido no projeto Desenvolvedores não aceitam contratos com preço fixo 10 5

6 Quais são as Desvantagens? Problemas de validação Minimizar documentação Intercalar especificação e desenvolvimento Problemas de Manutenção As alterações contínuas corrompem a estrutura dos sistemas Dificuldade de compreensão do software 11 Onde o desenvolvimento rápido de software NÃO é recomendado? Em grandes sistemas, nos quais o desenvolvimento pode envolver equipes que trabalham em locais diferentes Em sistemas embarcados, nos quais o software depende do desenvolvimento de hardware Em sistemas críticos, nos quais todos os requisitos devem ser analisados para segurança 12 6

7 Métodos Ágeis 13 Métodos Ágeis Em 2001, Kent Beck e mais 16 desenvolvedores, produtores e consultores de software, que formavam a Aliança Ágil, assinaram o Manifesto de Desenvolvimento Ágil de Software. 14 7

8 Métodos Ágeis Estamos descobrindo melhores modos de desenvolvimento de software fazendo-o e ajudando outros a fazê-lo. Por meio desse trabalho, passamos a valorizar: Indivíduos e interações ao invés de processos e ferramentas. Software funcionando ao invés de uma documentação abrangente. Colaboração do cliente ao invés de negociação de contratos. Resposta a modificações ao invés de seguir um plano. Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda. 15 Métodos Ágeis Família de metodologias de desenvolvimento que produzem software em pequenas iterações e permitem mudanças maiores em design 16 8

9 Características Iterações e versões curtas Design incremental Envolvimento do usuário Documentação mínima Comunicação informal Mudanças 17 Características Iterações e versões curtas Design incremental Envolvimento Divisão do trabalho do usuário em pequenas partes. Liberação do software para o usuário com a Documentação maior frequência mínima possível Comunicação informal Mudanças 18 9

10 Características Iterações e versões curtas Design incremental Envolvimento do usuário Documentação Não tentar concluir mínima o design com muita rapidez (de qualquer modo não se sabe o suficiente acerca do Comunicação sistema no momento). informal Adiar o máximo possível decisões sobre o design. Mudanças Aprimorar o máximo o design existente quando maiores informações forem obtidas. 19 Características Iterações e versões curtas Design incremental Envolvimento do usuário Documentação mínima Não tentar produzir padrões formais, completos e Comunicação imutáveis logo informal no início Solicitar informações de feedback (retroinformação) Mudanças aos usuários. Em geral, isso resulta em um sistema melhor ajustado

11 Características Iterações Gerar somente e versões a quantidade curtas mínima de documentação. Design incremental Código-fonte corresponde a grande parte da Envolvimento documentação. do usuário Documentação mínima Comunicação informal Mudanças 21 Características Iterações e versões curtas Design incremental Manter comunicação constante e não necessariamente Envolvimento através de documentação usuário formal (as pessoas se comunicam melhor informalmente) Documentação mínima Comunicação informal Mudanças 22 11

12 Características Iterações e versões curtas Design incremental Envolvimento do usuário Partir do princípio de que os requisitos e o ambiente Documentação sofrerão mudanças mínimae tentar encontrar formas apropriadas de lidar com isso. Comunicação informal Mudanças 23 Características É importante assegurar que não haja abuso da metodologia, principalmente associada à documentação. Se o software liberado precisar ser mantido por um grupo diferente dos desenvolvedores iniciais, uma documentação suficientemente detalhada será indispensável

13 Algumas metodologias dos Métodos Ágeis Extreme Programming (Beck, 1999; Beck 2000) Scrum (Schwaber e Beedle, 2001) Crystal (Cockburn, 2001) Adaptive Software Development (Highsmith, 2000) Feature Driven Development (Palmer e Felsing, 2002) 25 Extreme Programming - XP Utiliza OO como paradigma de desenvolvimento; Inclui um conjunto de regras e práticas com base nas atividades Planejamento Projeto Codificação Teste 26 13

14 XP: Planejamento Criação de um conjunto de histórias de usuários descrevendo as características e funcionalidades requeridas pelo software que será construído; As histórias (semelhantes aos casos de uso) são escritas pelos clientes e colocadas em cartões de indexação; O cliente atribui uma prioridade à cada história; Os desenvolvedores analisam cada história e atribuem um custo a cada uma delas, com base em número de semanas necessárias para o seu desenvolvimento; 27 XP: Planejamento Se a história precisar de mais de 3 semanas para desenvolvimento, é solicitado ao cliente que ela seja dividida em histórias menores; Histórias desenvolvidas em 3 modos 1) Todas as histórias serão implementadas imediatamente (dentro de poucas semanas) 2) As histórias com valor mais alto serão antecipadas no cronograma e implementadas primeiro 3) As histórias de maior risco serão antecipadas no cronograma e implementadas primeiro. Com o avanço do projeto, o cliente pode adicionar novas histórias, mudar a sua prioridade, subdividi-la e eliminálas

15 XP: Projeto Segue rigorosamente o KIS (keep it simple) Estimula o uso de cartões CRC (Classe, Responsabilidade e Colaboração) para a identificação e organização das classes OO relevantes para o incremento do software Cartões CRC permitem a descrição dos conceitos identificados na metáfora na forma de classes. Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o 29 design. XP: Projeto Os cartões CRC são o único produto de trabalho do projeto; 30 15

16 XP: Projeto Caso seja identificado um problema difícil na história, recomenda-se a criação imediata de um protótipo operacional daquela parte do projeto. Denominado Solução de Ponta; Encoraja a refatoração. Técnica que altera a estrutura do sistema sem modificar o comportamento externo. 31 XP: Projeto 32 16

17 XP: Codificação Depois que as histórias forem desenvolvidas e o início do projeto for feito, recomenda-se não iniciar a programação; Elemento chave da XP. É recomendado realizar testes unitários sobre cada uma das histórias que serão incluídas na versão atual; Depois de os testes unitários terem sido criados, o desenvolvedor está focado no que deve ser implementado. 33 XP: Codificação Programação em pares Duas pessoas trabalhando juntas na mesma máquina; Cada pessoa fica encarregada de uma atividade; Quando o trabalho dos programadores é completado, é feita uma integração com o trabalho de outros; Existe uma equipe responsável pela integração

18 XP: Teste São aplicados os testes unitários. Os testes de aceitação (ou teste de cliente) são especificados sob a ótica do cliente e abrangem as características e as funcionalidades do sistema global visíveis e passíveis de revisão; Resolver pequenos problemas a cada intervalo de umas poucas horas leva menos tempo do que resolver grandes problemas perto da data de entrega. Wells (1999) apud Pressman(2010). 35 Scrum Tem como objetivo fornecer um processo conveniente para projeto e desenvolvimento orientado a objeto; Abordagem empírica Aplica ideias da teoria de controle de processos industriais para o desenvolvimento de software 36 18

19 Scrum Ideias de Flexibilidade Adaptabilidade Produtividade Visa tratar mudanças frequentes de requisitos de software e outras situações Troca de equipes Adaptações de cronogramas e orçamento Troca de ferramentas de desenvolvimento 37 Scrum Baseada em princípios semelhantes da XP; Divide o desenvolvimento em ciclos iterativos (sprints) de até 30 dias; Equipes pequenas, até 10 pessoas Analistas Programadores Engenheiros Gerentes de qualidade 38 19

20 Scrum Equipes trabalham nas funcionalidades definidas no início de cada sprint; Reuniões diárias de acompanhamento Curta duração: 15 minutos 39 Scrum: ciclo de vida Pré-planejamento (pre-game phase) Desenvolvimento (game phase) Pós-planejamento (post-game phase) 40 20

21 Scrum: ciclo de vida 41 Scrum: ciclo de vida Pré-planejamento (pre-game phase) Documento backlog com requisitos Estabelece prioridade dos requisitos Definição da equipe e ferramentas Identificação de riscos e necessidades de treinamento 42 21

22 Scrum: ciclo de vida Desenvolvimento (game phase) Observação e controle dos riscos Desenvolvimento do software em sprints Novas funcionalidades são adicionadas Cada ciclo é desenvolvido de forma tradicional Análise Projeto Implementação Testes Duração do ciclo: entre 1 semana e 1 mês 43 Scrum: ciclo de vida Pós-planejamento (post-game phase) Integração do software Testes finais Documentação do usuário Reunião da equipe para Analisar o progresso do projeto Demonstrar o software atual para o cliente 44 22

23 Crystal Família de Metodologias Crystal Clear Crystal Orange Crystal Orange Web Cada uma é indicada para projetos conforme algumas classificações gama 45 Tamanho Crystal: Cockburn classifica projetos conforme fatores Medido pelo número máximo de desenvolvedores Não pelo número de linhas de código ou pontos de função Criticalidade Medida pelas perdas que um mau funcionamento causaria Há níveis de criticalidade... Próximo slide... Prioridade Medida pela pressão do tempo sobre o projeto Projetos com alta pressão requerem metodologias otimizadas para produtividade, enquanto outros projetos podem preferir a otimização para rastreabilidade, em detrimento da produtividade 46 23

24 Crystal: Níveis de criticalidade Vida Problema de mau funcionamento pode causar dano físico a uma pessoa ou perda de vida Dinheiro essencial Problema de mau funcionamento pode causar perda de dinheiro essencial para a sobrevivência da Organização Dinheiro excedente Problema de mau funcionamento pode causar perda de dinheiro não essencial para a sobrevivência da Organização Conforto Problema de mau funcionamento não causam perda monetária mensurável, mas não proporcionam conforto e prazer aos 47 usuários. Crystal Cada uma é indicada para projetos conforme algumas classificações Não cobrem a gama completa de projetos Deixa de fora projetos em larga escala e críticos para a vida Crystal Clear Projetos não críticos e nível dinheiro excedente Requerem equipes de seis a oito pessoas 48 24

25 Crystal Crystal Clear: Adequada para Projetos não críticos e nível dinheiro excedente Requerem equipes de seis a oito pessoas Crystal Orange: Adequada para Projetos Críticos, mas não para a vida Requerem equipes de até 40 pessoas Crystal Orange Web Web 49 Crystal: Métodos básicos Empregue metodologias mais abrangentes para equipes maiores Empregue metodologias mais pesadas para projetos mais críticos Dê preferência às metodologias mais leves, pois o peso é dispendioso Dê preferência à comunicação interativa, face a face, em vez de documentação formal, escrita 50 25

26 Crystal: Métodos básicos Entenda que o comportamento das pessoas varia dentro de uma equipe e ao longo do tempo As pessoas tendem a ser inconsistentes Processos de alta disciplina são mais difíceis de adotar e têm maior probabilidade de abandono Parta do princípio de que as pessoas desejam ser boas cidadãs Elas podem tomar iniciativa e se comunicar informalmente Use estas características em seu projeto 51 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Segurança pessoal Foco Fácil acesso a funcionários experientes Bom ambiente técnico 52 26

27 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Liberar código testado e funcional para usuários com a maior frequência possível. Intervalo de poucos meses Segurança pessoal Foco Fácil acesso a funcionários experientes Bom ambiente técnico 53 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Antes, durante e depois do projeto, refletir sobre o processo, no que ele pode ser melhorado Segurança pessoal Foco Fácil acesso a funcionários experientes Bom ambiente técnico 54 27

28 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Segurança pessoal Foco Fácil acesso a funcionários experientes Bom ambiente técnico Encorajar a comunicação entre membros da equipe. Na Metodologia Crystal, há a comunicação osmótica, que significando que a informação flui nas conversas de fundo entre os membros da equipe 55 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Segurança pessoal Foco Fácil acesso a funcionários experientes Bom ambiente técnico Encorajar os membros da equipe a se manifestarem sem medo de represálias Inclui Manifestação de insatisfação com alguma prática Reconhecimento da ignorância, erro ou incapacidade de concluir tarefa 56 28

29 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Segurança pessoal Foco Minimizar interrupções e se concentrar na tarefa em mãos Muitas vezes, o melhor designer, codificador ou depurador é também a pessoa mais acessível da equipe. Acabam soterrados pelos problemas de outras pessoas e não são capazes de desempenhar seu próprio trabalho Fácil acesso a funcionários experientes Bom ambiente técnico 57 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Segurança pessoal Foco Tornar possível para a equipe obter feedback rápido de usuários experientes a respeito do produto, do design, dos requisitos e de quaisquer mudanças Fácil acesso a funcionários experientes Bom ambiente técnico 58 29

30 Crystal: Princípios complementares Liberações frequentes Aprimoramento reflexivo Comunicação estreita Segurança pessoal Foco Fácil acesso a funcionários experientes Bom ambiente técnico Estabelecer um ambiente com testes automatizados e gestão de configuração, por exemplo 59 Manifesto para o desenvolvimento ágil de software