PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MSC. EMILIANO MONTEIRO

Transcrição

1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MSC. EMILIANO MONTEIRO

2 CONTEÚDO Conceitos básicos Caracterização de um processo Estágios básicos Linha do tempo Cascata Espiral Prototipação Modelo-V Orientado ao Re-uso RUP SCRUM Kanban Considerações Finais

3 CONCEITOS BÁSICOS - PROCESSO Um conjunto de tarefas ordenadas constitui um processo, uma séria de etapas que envolvem atividades, restrições e recursos para alcançar a saída desejada. Um processo é um conjunto de procedimentos, organizados de modo que nos permita construir produtos que satisfaçam a uma série de objetivos e padrões.

4 CARACTERIZAÇÃO DE UM PROCESSO Um processo envolve um conjunto de ferramentas e técnicas, entre elas: a) o processo deve descrever todas as suas atividades b) o processo utiliza recursos e esta sujeito a restrições dos mesmos c) o processo pode ser composto de sub-processos d) cada atividade do processo tem critérios de entrada e saída e) as atividades são organizadas em sequência, com uma ordem de execução f) todo processo tem um conjunto de diretrizes que explicam os objetivos de cada atividade g) restrições e controles podem ser aplicadas a cada atividade.

5 ESTÁGIOS BÁSICOS Basicamente o desenvolvimento de software tem os seguintes estágios: 1. Análise e definição de requisitos 2. Projeto do sistema 3. Programação 4. Testes de integração e de sistemas 5. Entrega do sistema e treinamento de usuários 6. Manutenção 7. Descarte

6 TIME-LINE Atualmente existem mais de 100 filosofias de desenvolvimento:

7 CASCATA Características: Um dos primeiros modelos, proposto por Winston W. Royce, em O desenvolvimento de um estágio deve terminar antes do próximo começar. Só quando todos os requisitos forem enunciados é que a equipe de desenvolvimento pode iniciar suas atividades. Pode ser usado para estimar quando falta para o término do projeto. É fácil de explicar aos clientes. Não reflete como o código é desenvolvido. É frequentemente utilizado na resolução de problemas nunca antes resolvidos. Ao final de cada fase é produzido um artefado, sem detalhar como. Trata o desenvolvimento de software como resolução de problema. Enfoque nos documentos e artefatos.

8 ESPIRAL Criado por Barry Boehm em 1988, é similar a um risco envolvido que forma o desenho da espiral. É um modelo incremental e interativo. Avaliação e análise de risco Requisitos Primero concebe as operações, depois gera requisitos, depois desenvolve e finalmente habilita os testes, reiniciando o ciclo novamente. Testes Lançamento Codificação

9 PROTOTIPAÇÃO A prototipação pode ser a base de um processo de software. Permite o desenvolvimento rápido para esclarecer dúvidas, reduzindo os riscos e a incerteza do desenvolvimento. O protótipo começa com um conjunto simples de requisitos, quando apresentado aos clientes, este protótipo passa por refinamentos sucessivos, até que um protótipo final tenha sido obtido, permitindo então a codificação final.

10 MODELO V É uma variação do modelo em cascata. Proposto pelo ministério de defesa da Alemanha em A codificação é o vértice do V, a análise e projeto ficam em um lado e o testes do outro. Durante a verificação de problemas (lado direito), caso encontrados) o lado esquerdo pode ser revisto, permitindo a correção. O modelo V pode ser incrementado com prototipação. Principais desvantagens: Não aborda operações, manutenção, reparo nem descarte de sistemas!

11 DESENVOLVIMENTO ORIENTADO AO REUSO Sommervile (2003), na maioria dos projetos de software, ocorre algum reuso de software. Isto acontece quando as pessoas envolvidas no projeto de um software conhece outros projetos similares. Estes softwares similares sofrem pequenas modificações e são incorporados ao novo projeto em desenvolvimento. A abordagem voltada para a componentização de software, também trata do reuso de código entre projetos. Uma categoria de sistemas que se beneficia desta forma de trabalho são softwares de prateleira, pois muitos possuem funções similares, nesta categoria entram pequenas automações comerciais. Sua principal vantagem esta na redução de software a ser produzido, também propicia a redução do tempo de entrega. Sua desvantagem esta no controle sobre a evolução do sistema, pois partes do sistema, componentizadas estão sob controle de terceiros.

12 RUP Significa Rational Unified Process (processo unificado Rational), criado pela Rational Software Corporation. E desde fevereiro de 2003 pertence a IBM. O produto da IBM fornece uma base de conhecimento com artefatos de modelo e descrições detalhadas para muitos tipos diferentes de atividades. Os pilares da RUP: Um processo flexível que guie o desenvolvimento. Ferramentas que automatizem esse processo. Serviços que acelerem a adoção destes processos e ferramentas. Blocos de construção são também chamados de elementos de conteúdo. Linhas mestras: Gestão de requisitos Uso de arquitetura baseada em componentes Uso de software de modelos visuais Verificação da qualidade do software Gestão e Controle de Mudanças do Software Foco nos 4 P: Pessoas, Projeto, Produto, Processos

13 BREVE RESUMO DO RUP

14 DESENVOLVIMENTO ÁGIL 1. Acceptance Test Driven Development (ATDD) 2. Agile Modeling 3. Agile Unified Process (AUP) 4. Continuous integration (CI) 5. Crystal Clear 6. Crystal Methods 7. Dynamic Systems Development Method (DSDM) 8. Extreme Programming (XP) 9. Feature Driven Development (FDD) 10. Graphical System Design (GSD) 11. Kanban 12. Lean software development 13. Scrum 14. Scrum-ban 15. Story-driven modeling 16. Test-driven development (TDD) 17. Velocity tracking 18. Software Development Rhythms

15 SCRUM Scrum é um processo iterativo de desenvolvimento incremental de software. Ele vai do desenvolvimento de produto até a entrega da aplicação. Seu foco está em: Ser uma estratégia de desenvolvimento flexível, do produto, onde uma equipe de desenvolvimento funciona como uma unidade para alcançar um objetivo comum. Os criadores (em 1986 foram Hirotaka Takeuchi e Ikujiro Nonaka) descreveram o scrum como: uma nova abordagem para o desenvolvimento de produtos comerciais que aumenta a velocidade e flexibilidade, com base em estudos de caso de empresas de fabricação nas indústrias de fotocopiadoras, automotivo e impressora. Eles chamaram esta abordagem de holística ou rugby, porque todo o processo é realizado por uma equipe multifuncional em várias fases sobrepostas

16

17 KANBAN

18 KANBAN BOARD

19 KANBAN BOARD

20 KANBAN

21 CONSIDERAÇÕES FINAIS Conhecer os processos de desenvolvimento habilita o aluno a realizar uma melhor escolha de processo para uso em projetos futuros. A vantagem de conhecer vários processos permite inclusive evitar futuros problemas com projetos em andamento (o principal seria a mudança da metodologia de trabalho) o que impacta no custo e cronograma do projeto. Também permite conhecer vantagens e desvantagens de cada um possibilitando que se possa inclusive desenvolver um processo próprio e específico para uma empresa ou projeto de software.

22 REFERÊNCIAS BIBLIOGRÁFICAS Básica PFLEEGER, Shari Lawrance. Engenharia de software teoria e prática. 2ª. ed. São Paulo : Prentice Hall, SOMMERVILLE, Ian. Engenharia de Software. 6ª. Ed. São Paulo : Addison Wesley, BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 1.ed. Rio de Janeiro: Elsevier, Complementar FERNANDES, Aguinaldo, Aragon. TEIXEIRA, Descartes de Souza. Fábrica de software implantação e gestão de operações. São Paulo : Atlas, MONTEIRO, Emiliano S. Projeto de Sistemas e bancos de dados. São Paulo: Brasport, LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e o projeto orientados a objetos e ao processo unificado. 2.ed. Porto Alegre: Bookman, Outras referências podem ser encontradas na página da disciplina em: