MODELO DE PROCESSO DE SOFTWARE

Itajubá

2013

SUMÁRIO

1 INTRODUÇÃO 3

2 OBJETIVOS 4

3 MODELO DE PROCESSO DE SOFTWARE 5

3.1 Modelo em Cascata 5

3.2 Modelo de Desenvolvimento Evolucionário 6

3.3 Modelo de Desenvolvimento Rápido (RAD) 6

3.4 Modelo Formal 7

3.5 Modelo de Desenvolvimento Orientado a Reuso 8

3.6 Modelo de Desenvolvimento Incremental 8

3.7 Modelo de Desenvolvimento em Espiral 9

3.8 Modelo do Processo Unificado 9

3.9 Modelo Paxis 10

4 EVOLUÇÃO DO MODELO DE PROCESSO SCRUM 12

4.1 História 13

4.2 Características 14

4.3 Gerenciamento Ágil de Projetos com Scrum 14

4.4 Papéis 15

4.4.1 PAPÉIS PRINCIPAIS 15

4.4.2 PAPÉIS AUXILIARES 16

4.4.3 REUNIÕES SCRUM 16

4.4.4 SCRUM SIMPLIFICADO 18

4.4.5 SCRUM SOLO 18

4.5 VANTAGENS E DESVANTAGENS 18

4.5.1 COMPARAÇÃO COM O DESENVOLVIMENTO ITERATIVO 19

4.5.2 COMPARAÇÃO COM O MODELO EM CASCATA 19

4.5.3 COMPARAÇÃO COM A "CODIFICAÇÃO COWBOY" 20

4.5.4 DESVANTAGENS / CRITICAS 20

4.6 Exemplo de Software: Sistema Web de streaming de vídeo 21

4.6.1 PAPÉIS 21

4.6.2 ESCOPO DO PROJETO 21

4.6.3 PRODUCT BACKLOG 21

4.6.4 REUNIÃO DE PLANEJAMENTO DO SPRINT 22

4.6.5 INÍCIO DO SPRINT 23

4.6.6 REUNIÕES DIÁRIAS SCRUM 24

4.6.6.1 BURNDOWN CHART 24

4.6.7 REVISÃO FINAL DO SPRINT 25

5 IDE ECLIPSE E LINGUAGEM DE PROGRAMAÇÃO JAVA 26

6 CONCLUSÃO 27

REFERÊNCIAS 28

1 INTRODUÇÃO

Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projetistas de iteração, redatores técnicos e gerentes.

Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos. É recomendada a produção de documentação que realmente será útil.

2 OBJETIVOS

Podemos dizer com uma grande dose de certeza que “Modelos de Projeto de Software” é o veículo que conduz qualquer projeto de software rumo ao sucesso e qualidade. Bom, mas qualidade é algo abstrato, difícil de ser definido. Portanto vamos recorrer a um pouco de história da qualidade para podermos entender melhor esse conceito.

A história da qualidade está repleta de exemplos de resultados extraordinários: os grandes templos construídos na Grécia e Roma antigas, os feitos de navegação do século XVI, as catedrais medievais. Em todas essas realizações, não se dispunha de instrumentos de precisão ou técnicas sofisticadas. Na França, os construtores de catedrais utilizavam simples compassos e cordas com nós a intervalos regulares para desenhar e construir edifícios. Na década de 1920 surgiu o controle estatístico de produção. Nas fábricas que produziam grande quantidade de itens tornou-se impossível garantir a qualidade individual de cada peça, ao contrário do que se fazia (e ainda faz) no trabalho artesanal. Dessa forma foi preciso desenvolver mecanismos diferentes e a resposta veio da estatística.

Um dos pioneiros trabalhos associados ao assunto é o livro publicado por Walter Shewhart em 1931, Economic Control of Quality of Manufactured Producto. Shewhart, dos Bell Laboratories, teria introduzido os diagramas de controle (control charts ou Shewhart chart).

Na década de 1940 foi fundado a ABNT (Associação Brasileira de Normas Técnicas) e a ISO (International Standardization Organization). Também o Japão destacou-se como um importante pólo no assunto e contribuiu com diversas novas ferramentas: o método de Taguchi para projeto experimental, a metodologia 5S ou, ainda, os diagramas de causa e efeito de Ishikawa, também conhecidos como diagrama espinha de peixe.

Estas citações nos mostram claramente que a qualidade de um programa de computador segue as mesmas especificações de um produto qualquer da indústria tradicional.

3 MODELO DE PROCESSO DE SOFTWARE

Vamos