Gerência de Projetos e Manutenção de Software Aula 2 ...andrea/teaching/201702/gpms/GPMS-Aula2-RevisaoES.pdf · • “Aplicação prática do conhecimento científico no projeto

Gerência de Projetos e Manutenção de Software

Aula 2- Revisão de ESAndréa Magalhães Magdaleno

[email protected]

2017.02

2GPMS 2017.02

Agenda

• Histórico

• Elementos da ES

• Ciclos de Vida

• Desenvolvimento Ágil

• Processo Unificado

• Trabalho

• Exercício

HISTÓRICO

4GPMS 2017.02

Histórico

• Como surgiu a Engenhara de Software?• Década de 60

• Conferência NATO de 1968 na Alemanha

• Crise do Software

• Tentativa de contornar a crise e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de software

5GPMS 2017.02

HistóricoEra Pós-ES

- Lower-CASE tools (programação, depuração)

- Ciclo de vida em cascata- Desenvolvimento estruturado

- Upper-CASE tools (processos, modelagem)

- Ciclo de vida espiral- Desenvolvimento orientado a objetos

6GPMS 2017.02

HistóricoPassado Recente

Fonte: Chaos Research – Standish Group

Conclusão de Projetos 2002

Projetos Bem Sucedidos

34%

Projetos Fracassados

15%

Projetos Desafiados

51%

???

7GPMS 2017.02

Sintomas de Problemas no Desenvolvimento• Entendimento impreciso das necessidades dos usuários

finais

• FaIta de habilidade para lidar com mudanças de requisitos

• Componentes que não se encaixam

• Software difícil de manter ou estender

• Descoberta tardia de sérias falhas no projeto

• Baixa qualidade de software

• Performance inaceitável do software

• Conflitos internos da equipe

• Incapacidade de reconstituir quem mudou o que, quando,onde e porquê

8GPMS 2017.02

Causas dos Problemas no Desenvolvimento• Gerenciamento insuficiente de requisitos• Comunicação ambígua e imprecisa• Arquitetura frágil• Complexidade esmagadora• Inconsistências NÃO detectadas entre requisitos, projetos,

e implementações• Testes insuficientes• Avaliação subjetiva do status do projeto• Redução tardia de risco devido ao desenvolvimento em

cascata• Propagação descontrolada de mudanças• Automação insuficiente

9GPMS 2017.02

Como Desenvolver ?

• Focando nas necessidades dos usuários• Empregando um processo racional e controlável• Focando na qualidade• Utilizando um método eficaz• Utilizando as ferramentas adequadas• Entregando dentro do prazo e do orçamento

Engenharia de Software

10GPMS 2017.02

Engenharia de Software - Definições• “Aplicação prática do conhecimento científico no projeto e

construção de programas e da documentação requerida paradesenvolver, operar e manter esses programas.”

Boehm 1980

• “Estabelecimento e uso de um conjunto de princípios deengenharia com o objetivo de construir software confiável,eficiente e economicamente viável em máquinas reais.”

Fritz Bauer

• “Aplicação de uma abordagem sistemática, disciplinada equantificável para desenvolver, operar e manter software.”

IEEE 1993

11GPMS 2017.02

Engenharia de Software - Objetivos

• Aumentar a qualidade do produto

• Aumentar a produtividade do processo de desenvolvimento

• Diminuir os custos do processo de desenvolvimento

• Obter maior confiabilidade nos prazos estabelecidos

12GPMS 2017.02

HistóricoAtualmente

Desenvolvimento distribuído de software Métodos Ágeis

Software LivreEcossistemas

Desenvolvimento Dirigido por Modelos

13GPMS 2017.02

HistóricoAtualmente

ELEMENTOS DA ES

15GPMS 2017.02

Elementos da ES

Engenharia de Software

Ferramentas

Métodos

Processo

Elementos da ES

• Processo• Define os passos gerais para

o desenvolvimento e manutenção do software

• Serve como uma estrutura de encadeamento de métodos e ferramentas

• Sequência de passos que utilizam métodos e ferramentas para transformar matéria-prima em um produto que possua valor para o cliente

• Métodos• São os “how to’s”

• Como fazer um passo específico do processo

• Ferramentas• Apoio automatizado ou semi-

automatizado para os métodos e processos

17GPMS 2017.02

Elementos da ESCuidados

• Não esquecer das pessoas !

18GPMS 2017.02

Elementos da ESCuidados

• Não esquecer das pessoas !

Gênio Solitário

19GPMS 2017.02

Elementos da ESCuidados• Desenvolvimento guiado

por ferramentas• É importante usar a

ferramenta certa para o problema

• O problema não deve ser adaptado para a ferramenta disponível

“Para quem tem um martelo, tudo parece prego”

(MURTA, 2014)

20GPMS 2017.02

Elementos da ESCuidados

(MURTA, 2014)

• Supermercado de ES• Em função do problema, se escolhe o

processo, os métodos e as ferramentas

• Cuidados• Menos do que o necessário pode levar a

desordem

• Mais do que o necessário pode emperrar o projeto

21GPMS 2017.02

Elementos da ESCuidados

(MURTA, 2014)

• Os processos existem nas organizações mesmo que não sejam claros, visíveis, documentados ou organizados.

• Processos implícitos x explícitos• Processos implícitos são difíceis de serem seguidos, em

especial por novatos

• Processos explícitos estabelecem as regras de forma clara

22GPMS 2017.02

Elementos da ESCuidados• Método-chato

• Conhece todos os detalhes de vários métodos, mas...• Não sabe quando usar

• Se perde nos detalhes e não consegue executar nada

CICLOS DE VIDA

24GPMS 2017.02

Modelos de Ciclos de Vida

http://portal.melhoria.com.br/blog/simplificando-engenharia-software-com-essence

25GPMS 2017.02

Modelos de Ciclos de Vida

• Características predefinidas

• Devem ser adaptados para o contexto real de uso• Diversidade

Diversidade

Empresas

Projetos

Modelos de desenvolv

de softwareClientes

Pessoas

26GPMS 2017.02

Modelos de Ciclos de VidaCiclo de Vida em Cascata• Década de 70

• Saída de uma etapa é a entrada para a próxima• Uma etapa só inicia quando a anterior tiver sido concluída e

verificada

• Muitas variantes

Requisitos

Design

Implementação

Teste

Implantação

Modelos de Ciclos de VidaCiclo de Vida em Cascata• Benefícios na época

• Disciplina

• Atividades claramente definidas

• Fases bem definidas e delimitadas

• Ampla aceitação e uso• Ainda é largamente utilizado!

• Simplicidade

• Desafios• Linear

• Rígido• Não permite atualização ou redefinição

das fases

• Monolítico• Não estimula a participação de

usuários e clientes

• Dificuldade de tratar as mudanças de requisitos dos clientes/usuários

• Não prevê manutenção

• Software aparece muito tarde

Requisitos

Design

Implementação

Teste

Implantação

Modelos de Ciclos de VidaCiclo de Vida Incremental

Requisitos

Design

Implementação

Teste

Implantação

...

tempo

fun

cio

nal

idad

es

Requisitos

Design

Implementação

Teste

Implantação

Requisitos

Design

Implementação

Teste

Implantação

Requisitos

Design

Implementação

Teste

Implantação

29GPMS 2017.02

Modelos de Ciclos de VidaCiclo de Vida Incremental• Ideia de “aumentar (alargar) pouco-a-pouco” o âmbito

do sistema

• Desafios• Dificuldade de gerenciamento - fases simultâneas

• Usuário achar que a primeira versão já corresponde ao sistema como um todo

• Verba do projeto acabar antes do sistema ser concluído

• Software pode não ser adaptável, manutenível ou extensível

Modelos de Ciclos de VidaDesenvolvimento Iterativo• O desenvolvimento é organizado em “mini-projetos”

• Cada “mini-projeto” é uma iteração

• Cada iteração tem duração curta e fixa (de 2 a 6 semanas)

• Cada iteração tem atividades de requisitos, projeto, programação e testes

• O produto de uma iteração é um software parcial

X semanas X semanas X semanas

Software SoftwareSoftware

...

31GPMS 2017.02

Modelos de Ciclos de VidaDesenvolvimento Iterativo• Iteração fixa

• Tarefas podem ser removidas ou incluídas

• A iteração nunca deve passar da duração previamente estipulada

• O resultado de cada iteração é um software...• Incompleto

• Em desenvolvimento (não pode ser colocado em produção)

• Mas não é um protótipo!!!

• Esse software pode ser verificado e validado parcialmente• Testes

• Usuários

• Podem ser necessárias diversas iterações para ter uma versão do sistema pronta para entrar em produção

32GPMS 2017.02

Modelos de Ciclos de VidaDesenvolvimento Iterativo• Iterações iniciais atacam os maiores riscos

• Riscos críticos são resolvidos antes que grandes investimentos sejam realizados

• Permite feedbacks dos usuários desde cedo

33GPMS 2017.02

Modelos de Ciclos de VidaDesenvolvimento Iterativo• Iterações curtas privilegiam a propagação de

conhecimento• Aumento do conhecimento sobre o software

• Diminuição das incertezas, que levam às mudanças

34GPMS 2017.02

Modelos de Ciclos de VidaDesenvolvimento Evolutivo

• As especificações evoluem a cada iteração• A cada iteração, uma parte do software fica pronta

• O conhecimento sobre o software aumenta

• As especificações são evoluídas para retratar esse aumento de conhecimento sobre o que é o software

35GPMS 2017.02

Modelos de Ciclos de VidaDesenvolvimento Evolutivo

• Mudanças sempre acontecem em projetos de software• Requisitos mudam

• O ambiente em que o software está inserido muda

• As pessoas que operam o software mudam

• Estratégias para lidar com mudanças• Evitar as mudanças

• Controlar as mudanças

• Acolher mudanças por meio de um processo evolutivo

DESENVOLVIMENTO ÁGIL

37GPMS 2017.02

Desenvolvimento Ágil

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.Através deste trabalho, passamos a valorizar:

“Indivíduos e interações mais do que processos e ferramentas

Software funcionando mais do que documentação abrangente

Colaboração do cliente mais do que negociação de contrato

Resposta a mudança mais do que plano em andamento”

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itensà esquerda.

www.manifestoagil.com.br

38GPMS 2017.02

Desenvolvimento Ágil

• Princípios ágeis• Satisfazer o cliente • Acolher modificações nos requisitos• Entregar o software com frequência• Trabalhar junto ao cliente• Manter os indivíduos motivados• Promover conversas face a face• Medir o progresso com software funcionando• Manter um ritmo constante de trabalho• Cuidar da qualidade• Buscar por simplicidade• Trabalhar com equipes auto-organizadas• Ajustar o comportamento da equipe buscando mais efetividade

www.manifestoagil.com.br

39GPMS 2017.02

Desenvolvimento Ágil

• Motivação• Resultados ruins com os cronogramas e orçamentos dos seus projetos

• Survey com 32 organizações de 10 segmentos distintos. Desse total, 14 empresas responderam que usam métodos ágeis

• A maioria das organizações tinha CMM em diferentes níveis, mas estavam buscando por algo novo devido aos problemas que enfrentavam mesmo com seus processos mais maduros

(REIFER, 2002)

40GPMS 2017.02

Desenvolvimento Ágil

• Características Principais• Desenvolvimento iterativo e incremental

• Fornecer valor rapidamente

• Orientação à adaptação, ao invés de predição

• Respostas rápidas e flexíveis a mudanças (inevitáveis)

• Projeto replanejado continuamente

• Grande envolvimento e participação do cliente

41GPMS 2017.02

Desenvolvimento Ágil

• Métodos Ágeis

42GPMS 2017.02

Desenvolvimento Ágil

• Métodos Ágeis

Pair Programming (XP)Ciclo de Gestão do

Scrum

Kanban Board

43GPMS 2017.02

Desenvolvimento Ágil

• Métodos Ágeis• Cada método tem as suas forças e limitações e é mais

apropriado para um determinado tipo de projeto

• Numerosos métodos ágeis diferentes têm emergido continuamente durante os últimos anos e não demonstram sinais de cessar

44GPMS 2017.02

Desenvolvimento Ágil• Limitações

• Ambiente de desenvolvimento globalmente distribuído

• A maioria dos métodos ágeis não oferece suporte adequado à gerência de projetos

• Subcontratação

• Aplicações críticas - controle de qualidade

• Não se observa nenhuma prática dedicada a lidar com os requisitos não funcionais do software

• A ausência de uma arquitetura definida se torna mais arriscada conforme o sistema cresce

• Se baseia fortemente no conhecimento tácito e na comunicação pessoa-pessoa

• Necessidade de autonomia da equipe

• Cliente com pouco tempo para se dedicar

• Capacidade de realizar grandes projetos de desenvolvimento de software??

• Como conciliar os interesses de diferentes clientes e garantir a participação de todos em tempo hábil para atender a velocidade das mudanças necessárias?

45GPMS 2017.02

Desenvolvimento Ágil

• Cuidados• Não é uma bala de prata – não vai resolver todos os problemas

• Nenhum processo é efetivo para todos os projetos

• Desenvolvimento ágil não é para todos. • Tentar impor os princípios ágeis em uma organização centrada em

processos e pouco colaborativa vai resultar em fracasso

PROCESSO UNIFICADO

47GPMS 2017.02

Processo Unificado

Processo Unificado

Incremental

Iterativo

Evolutivo

48GPMS 2017.02

Processo UnificadoFases• O desenvolvimento pode ser decomposto em fases,

visando retratar a ênfase principal das iterações• Concepção

• Elaboração

• Construção

• Transição

• Plano da fase• Abrangente e superficial

• Plano da iteração• Específico e detalhado

49GPMS 2017.02

Processo Unificado

Atividade Esforço

Análise 10%

Projeto 15%

Programação 30%

Testes 15%

Gerência 30%

(MURTA, 2014)

50GPMS 2017.02

Processo UnificadoExemplo• Rational Unified Process (RUP)

• Em uma iteração você caminha por todas as disciplinas com diferentes ênfases

51GPMS 2017.02

Processo UnificadoFases

• Escopo do projeto

Concepção

• Planejamento do projeto

• Especificação de requisitos

• Arquitetura básica

Elaboração• Constrói o produto

Construção

• Entrega o produto para a comunidade de usuários

Transição

52GPMS 2017.02

Processo UnificadoFases - Concepção• Escopo

• Identificação de riscos• Listagem inicial dos requisitos• Esboço dos casos de uso• Identificação de arquiteturas candidatas• Estimativas iniciais de cronograma e custo

• Principais características• Escopo ainda vago• Estimativas ainda vagas

• Esforço e duração aproximados• 5% do esforço do projeto• 10% da duração do projeto

• Marco• Objetivo do projeto

53GPMS 2017.02

Processo UnificadoFases - Elaboração• Escopo

• Mitigação dos riscos• Detalhamento da maioria dos requisitos e casos de uso• Estabelecimento e validação da arquitetura do software• Detalhamento das estimativas de cronograma e custo

• Principais características• Grande parte das atividades de análise e projeto já concluída• Diminuição significativa das incertezas• Baseline da arquitetura é estabelecida

• Esforço e duração aproximados• 20% do esforço do projeto• 30% da duração do projeto

• Marco• Arquitetura do software

54GPMS 2017.02

Processo UnificadoFases - Construção• Escopo

• Implementação dos demais componentes da arquitetura

• Preparação para a implantação

• Principais características• Baseline de testes do produto é estabelecida

• Esforço e duração aproximados• 65% do esforço do projeto

• 50% da duração do projeto

• Marco• Capacidade inicial de operação

55GPMS 2017.02

Processo UnificadoFases – Transição• Escopo

• Execução de testes finais

• Implantação do produto

• Treinamento dos usuários

• Principais características• Baseline de liberação do produto é estabelecida

• Esforço e duração aproximados• 10% do esforço do projeto

• 10% da duração do projeto

• Marco• Lançamento do produto

TRABALHO

57GPMS 2017.02

TrabalhoPortal de Conteúdo de Templates de Projeto

• Objetivo• Desenvolver um Portal de Conteúdo que apoie a distribuição gratuita

de templates de documentos de projeto

• Escopo• Definir a tecnologia para plataforma web

• Definir e implementar a arquitetura de informações

• Definir e implementar a identidade visual

• Implementar as funcionalidades solicitadas

• Implementar as características de inovação sugeridas pelo grupo

58GPMS 2017.02

TrabalhoFuncionalidades Básicas• 1. HomePage

• A HomePage deve conter informações sobre a empresa, o catálogo dedocumentos, mecanismos de buscas dos documentos, acesso aocarrinho de compras e informações de contato (email, telefone, redessociais)

• 2. Catálogo de Produtos• O catálogo de produtos deve apresentar no mínimo nome, foto e tipo

do documento

• 3. Página de Produto• A página de detalhamento de um produto deve apresentar todas as

informações sobre o templates incluindo nome, descrição, fotos, tipodo documento e exemplos de uso

• A página de detalhamento de um produto deve ter as opções decomprar, incluir na lista de desejos, compartilhar e avaliar o produto

59GPMS 2017.02

• 4. Carrinho de Compras• O carrinho de compras deve permitir que o usuário inclua um ou mais

itens de produtos para compra

• O carrinho de compras deve oferecer as opções de continuar comprando ou finalizar a compra

• 5. Checkout• O checkout deve capturar os dados pessoais (Nome, email e empresa)

do usuário

• O checkout deve permitir o download de documentos

• 6. Inovação• Outras ideias e inovações devem ser sugeridas e implementadas pelo

grupo

TrabalhoFuncionalidades Básicas

60GPMS 2017.02

• Buscar exemplos de templates de documentos que o grupo considere mais adequados• Plano de Projeto

• Plano de Comunicação

• Plano de Riscos

• Plano de Testes

• Plano de Gerência de Configuração

• Relatório de Encerramento de Projeto

• Cadastrar estes documentos com todas as informações no portal

• Cuidado com questões de licença ou compra dos documentos utilizados

TrabalhoConteúdo

EXERCÍCIO

62GPMS 2017.02

Exercício

• A iteração da concepção• Início do ciclo de desenvolvimento de um novo

produto

• Situação ideal para o desenvolvimento de um pequeno projeto. Ainda não existem requisitos para preservar, reuso ou interfaces com sistemas legados

• A maior parte do esforço está concentrado em Requisitos e na Gerência de Projetos

63GPMS 2017.02

Exercício

• Analise com o seu grupo como o processo unificado será utilizado no trabalho• Qual será a duração de uma iteração?

• O que vocês pretendem entregar em cada iteração?

• Como e quando vocês vão se reunir para atingir esse objetivo?

• Qual será o papel de cada membro do grupo?

• Quais são os riscos envolvidos?

• Quais decisões arquiteturais precisam ser tomadas (linguagem, SO, etc.)?

64GPMS 2017.02

65GPMS 2017.02

Dúvidas?

66GPMS 2017.02

Leitura Complementar

• KRUCHTEN, P.; The Rational Unified Process – An Introduction.Addison-Wesley. 2ª Edição. 2000

• Fairley, R. E., e Willshire, M. J. (2003). "Why the Vasa sank: 10problems and some antidotes for software projects". IEEESoftware, v. 20, n. 2, pp. 18–25.

• Boehm, B. (2006). "A view of 20th and 21st century softwareengineering". Proceedings of the 28th international conference onSoftware engineering, Shanghai, China: ACM, pp. 12–29.

67GPMS 2017.02

Próxima Aula

Gerência de Configuração

Garantia de Qualidade

Verificação, Validação e Testes

Planejamento de Projetos

Gerência de Riscos

Monitoramento e Controle

Reutilização

Medição e Análise

Levantamento de Requisitos

Análise de Requisitos

Projeto Codificação

Comunicação

AtividadesGerenciais

Atividades de Desenvolvimento

Atividades de Apoio

Aquisição

Gerência de Projetos e Manutenção de Software

Aula 2- Revisão de ESAndréa Magalhães Magdaleno

[email protected]

2017.02