Sistemas de Informação e Programação II Odorico Machado Mendizabal

Transcrição

1 Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011

2 Processo de Desenvolvimento de Software

3 Objetivos Apresentar modelos de processos de software Apresentar metodologias de desenvolvimento de Software tradicionais Descrever modelos genéricos para desenvolvimento de software MSF, RUP

4 Processo de Software Um conjunto estruturado de atividades relacionadas, necessárias para o desenvolvimento de um sistema de software Processos podem ser aplicados sistematicamente e normalmente encontram-se agrupados em fases, por exemplo: Especificação; Projeto; Programação; Validação Manutenção/Evolução

5 Exemplos de Processo Listar exemplos de processos: Universidade Administrativos, estudantis Matrícula Datas, documentos, confirmação Empréstimo de livros Como automatizar e aprimorar processos? Implementação de um aplicativo (software) Por onde começar? Desenvolvimento de Software Projeto de Software Processos

6 Ciclo de Desenvolvimento de Software Cada projeto é único e portanto envolve um grau de incerteza Projetos são divididos em fases de modo a garantir maior controle e encadeamento com as operações correntes da empresa O conjunto de fases de um projeto é conhecido como ciclo de vida de um projeto Arcabouços (Frameworks) tem sido adotados pelas empresas MSF (Microsoft Solutions Framework) RUP (Rational Unified Process)

7 Modelos de Ciclo de Desenvolvimento de Software Cascata Modelo Incremental Prototipação Espiral Métodos Ágeis

8 Modelo Cascata Abordagem sistemática: - Fases separadas e distintas de especificação e desenvolvimento -Nenhuma etapa inicia até que a anterior acabe - É fácil de apresentar o processo aos stakeholders Análise de Requisitos Projeto de Sistema e SW Analista de Negócios Gerente de Projeto Implementação Equipe de Desenvolvimento - Enfoque nos documentos e artefatos (requisitos, código, cronogramas) - Testes ocorrem em fases mais avançadas do projeto Integração e Teste de Sistema Analistas de teste Operação e Manutenção Analista de Sistemas, Programadores, Analistas de teste

9 Modelo Cascata Desvantagens Maioria dos programas só estará disponível quando o cronograma já está bastante adiantado. Dificuldades para se introduzir alterações quando o processo está avançado. Projetos reais raramente seguem o fluxo sequencial que esse modelo propõe. Normalmente ocorre alguma interação e/ou superposição. Dificilmente os clientes são capazes de relacionar todos os requisitos de uma só vez no início do projeto. O modelo cascata é o mais usado em projetos de engenharia de sistemas de grande porte, onde um sistema é desenvolvido em várias localidades.

10 Desenvolvimento Evolucionário Desenvolvimento exploratório O objetivo é trabalhar com os clientes e desenvolver um sistema final a partir de uma especificação inicial. Deve iniciar com requisitos bem compreendidos e adicionar novas características conforme solicitação do cliente Prototipação throw-away O objetivo é compreender os requisitos de sistema. Pode iniciar com requisitos mal compreendidos para esclarecer o que é realmente necessário. Prototipação Evolutiva Desenvolver rapidamente um protótipo simples, sendo modificado sucessivamente de acordo com comentários dos stakeholders até se obter o sistema final.

11 Desenvolvimento Evolucionário Problemas Falta de visibilidade de processo; Os sistemas são frequentemente mal estruturados; Habilidades especiais (por exemplo, em linguagens para prototipação rápida) podem ser solicitadas. Aplicação Para sistemas interativos de pequeno e médio portes; Para partes de um sistema de grande porte (por exemplo, a interface de usuário); Para sistema com curto ciclo de vida.

12 Modelo Incremental Requisitos Modelagem do Negócio Modelagem do Negócio... Modelagem de Dados Modelagem de Dados Modelagem de Processos Modelagem de Processos Geração da Aplicação Geração da Aplicação Testes Testes dias dias Este diagrama exemplifica o modelo RAD (Rapid Application Development)

13 Modelo Incremental Variante do modelo em cascata Atividades ocorrendo em paralelo Desenvolvimento em fases Entrega do sistema em partes Permissão para que o usuário utilize alguns recursos enquanto outros ainda estão em desenvolvimento

14 Modelo Baseado em Prototipação Especificação do Cliente Desenho e Construção Avaliação do Cliente - Boa opção para definição de requisitos - Construído rapidamente - Possibilita examinar antecipadamente formato e aspecto dos resultados finais - Pode ser usado como um processo efetivo ou como sub-processo de outro modelo - Oferece uma boa interação com o usuário final

15 Modelo em Espiral Avaliação do Cliente Custo Acumulado Análise de Riscos Análise de Riscos Análise de Riscos Análise de Riscos Plano de requisitos Plano de Ciclo de Vida Protótipo 1 Protótipo 2 Protótipo 3 Protótipo Operacional Plano de Desenvolvimento Requisitos de Validação Requisitos de SW Projeto de Produto SW Código Plano de Testes Plano de Integração Teste de Unidade Planejamento Implementação Teste de Aceitação Teste de Integração Desenvolvimento de Software

16 Etapas do Modelo Espiral Planejamento Definição dos objetivos, alternativas e restrições Avaliação do Cliente Avaliação do planejamento e do desenvolvimento de SW Análise dos Riscos Análise de alternativas e identificação dos riscos sob o ponto de vista técnico e de gerência Desenvolvimento de SW Desenvolvimento do produto.

17 Vantagens do Modelo Espiral Aproveita as melhores características do modelo cascata e da prototipação. Acrescentando um novo elemento: a análise de riscos. Modelo evolutivo possibilita uma maior integração entre as fases e facilita a depuração e a manutenção do sistema Permite que o projetista e cliente possam entender e reagir aos riscos em cada etapa evolutiva.

18 Desvantagens do Modelo Espiral Avaliação dos riscos exige bastante experiência Excessivas iterações e geração de protótipos podem elevar os custos do projeto A constante interação com o cliente e geração de protótipos pode induzir mudanças no escopo inicial do projeto

19 Modelo Baseado em Métodos Ágeis Indivíduos e interações são mais importantes que processos e ferramentas Software funcionando é mais importante do que documentação completa e detalhada Colaboração com o cliente é mais importante do que negociação de contratos Adaptação a mudanças é mais importante do que seguir o plano inicial.

20 Algumas Metodologias Ágeis Crystal/Clear Metodologia direcionada a projetos pequenos (equipes de 6 desenvolvedores); Forte ênfase na comunicação entre os membros; Especificação e projeto são feitos informalmente, utilizando quadros publicamente visíveis Requisitos elaborados utilizando casos de uso

21 Algumas Metodologias Ágeis XP (extreme Programming) Requisitos são as histórias dos usuários Pouca Documentação Necessita equipe experiente Orientação a objetos Testes automatizados Oficina de reflexões (reuniões de fechamento a cada iteração, para rever o que pode ser melhorado) Programação em pares (peer programming) Testes Unitários Testes Automatizados Testes de Aceitação (executado pelos clientes)

22 Algumas Metodologias Ágeis Scrum Equipes pequenas Pouca Documentação Requisitos pouco estáveis ou desconhecidos Iterações curtas para promover visibilidade do desenvolvimento Encontros regulares (Scrum meetings) Desenvolvimento em iterações de 30 dias (Sprints) Não adota nenhum processo de validação prédefinido

23 Exemplo de Fases de Desenvolvimento em Scrum Reunião diária do Scrum 24h Sprints Sprint Backlog Acúmulo de tarefas pela equipe 30 dias - Ciclos Levantamento de prioridades do produto Nova demonstração de funcionalidade

24 Reuniões em Scrum Sprint Planning Meeting Acontece no início de cada iteração. São definidos quais itens farão parte do Product Backlog para o Sprint corrente. Em um segundo momento, os itens do Product Backlog são decompostos em lista de tarefas para o Sprint. Daily Scrum Acontecem diariamente e cada membro da equipe reporta ao resto da equipe o que ele fez no dia anterior, o que ele fará no próximo dia e quais são seus impedimentos. Sprint Review Meeting No final da execução do Sprint a equipe apresenta para os stakeholders o que foi implementado no Sprint. Itens incompletos retornam para o Product Backlog como candidatos. Sprint Retrospective Reunião para revisão e aprimoramento do processo. Medidas de melhoria são tomadas para os próximos Sprints. Backlog Refinement Meeting Equipe estima esforços para o desenvolvimento dos itens do Product Backlog, então o Product Owner pode priorizá-los para o próximo Sprint.

25 Tarefas em Scrum Product Backlog Product Backlog: Mantém a lista de itens a serem implementados. A classificação por prioridade e inclusão de novos requisitos durante reuniões de planejamento do sprint definem quais itens serão realizados por período. BACKLOG Item Descrição Prior 1 Como consumidor, eu quero cancelar minha encomenda antes de finalizar o pedido 2 Como consumidor, eu quero verificar o status do meu pedido. 3 Como gerente de catálogo, eu quero agrupar produtos de segmentos diferentes para promoções de venda

26 Tarefas em Scrum Product Backlog Product Backlog: Mantém a lista de itens a serem implementados. A classificação por prioridade e inclusão de novos requisitos durante reuniões de planejamento do sprint definem quais itens serão realizados por período. O progresso das atividades pode estar visualmente afixado em algum quadro ou pode estar presente em algum ferramenta de gerência de atividades.

27 Arcabouços para Desenvolvimento de Software Modelos híbridos servem como um guia, não como uma disciplina. RUP (Rational Unified Process) Sugere boas práticas de especificação de projetos Fortemente atrelado à UML Fases de projeto não estão atreladas à atividades específicas MSF (Microsoft Solutions Framework) Conjunto de boas práticas utilizadas pela empresa Modelo de Equipe, Modelo de Processos, Gerenciamento de Riscos

28 Ciclo de Desenvolvimento de Software baseado no MSF Envisioning Planning Developing Stabilizing Deploying Início do projeto Fim do projeto OBS.: Nomes de fases de processos serão mantido em inglês, pois esta é a abordagem adotada na maioria das empresas.

29 Exemplo de WBS para atividades de teste de desempenho Projeto X Envisioning Planning Developing Stabilizing Deploying Apresentação do Projeto Escopo Ambiente Plano de Teste Preparação de Teste Execução Criar Relatórios Finais Levantamento das Necessidades Validar Requisitos Solicitar Ambiente Criar Plano Criar Casos de Teste Round 1.. N Suporte pósinstalação Engajamento Definir Transações Instalar Aplicação Aprovar Plano de Teste Criar Scripts Executar Definir Carga Preparar Dados Criar Dados de Teste Analisar Requisitar Acessos Smoke Test Corrigir Defeito Validar Ambiente Configurar Monitores de Performance Re-testar WBS Work Breakdown Structure

30 Para saber mais: O C3 disponibiliza em sua infraestrutura algumas ferramentas úteis para a gerência e controle de projetos: Ferramenta para controle de versão (SVN - Subversion) Ferramenta para gerenciamento de projetos (Redmine) Ambas ferramentas são mantidas pelos grupo de técnicos

31 Exercícios 1) Descreva um WBS para as atividades de um desenvolvedor 2) Cite exemplos de projetos onde métodos ágeis se aplicam adequadamente. Justifique sua respostas. 3) Cite algumas práticas de desenvolvimento, tecnologias ou abordagens que favoreçam a manutenibilidade de um SW. 4) Como uma má elaboração de requisitos pode afetar fases posteriores ao longo do ciclo de vida do projeto? 5) Quais as vantagens em adotar frameworks como MSF e RUP ao invés de seguir uma metodologia de desenvolvimento de SW já estabelecida? 6) A interação com o cliente ao longo do ciclo de vida do projeto é fundamental para evitar má interpretações e para garantir que o cliente está ciente do progresso do projeto. Como diferentes metodologias como o modelo em cascata e Scrum abordam esta questão?