Modelagem de Sistemas

Prof. Fabrício Martins Mendonça

Juiz de Fora, MG

Unidade 02: Modelos de Processo de Software

Relembrando da aula anterior...

Conjunto de passos parcialmente ordenados para atingir uma meta.

Conjunto de atividades, métodos, práticas e transformações que pessoas utilizam para

desenvolver ou dar manutenção em software ou em seus produtos associados.

PROCESSO

PROCESSO DE SOFTWARE

Modelos de Processo de Software

§ Originalmente, modelos de processo prescritivosforam propostos para trazer ordem ao caosexistente na área de desenvolvimento de software.

§ Denominam-se “prescritivos” porque prescrevemum conjunto de elementos de processo – atividadesmetodológicas, ações de engenharia de software,tarefas, produtos de trabalho, garantia da qualidade emecanismos de controle de mudanças.

§ Cada modelo de processo também prescreve umfluxo de processo - a forma pela qual os elementosdo processo estão inter-relacionados.

Modelos de Processo de Software

• Codifica-Remenda: modelo de processo sem um plano.

• Modelos em Cascata: primeiros modelos dirigidos a planos.

• Desenvolvimento Incremental: Especificação, desenvolvimentoe validação são intercaladas. Pode ser dirigido a planos ou ágil.

• Engenharia de software orientada a reuso: pode ser dirigido aplanos ou ágil. Inclui técnicas da 3ª geração (ex: RAD) etécnicas da 4ª geração (ex: RUP).

• Metodologias Ágeis: imprevisibilidade e foco em mudanças.

Especificação(???)

Produto

Processo de Software sem plano ou modelo

Codifica-Remenda

Modelo Cascata – Ciclo de Vida Clássico

Modelo em CascataRequisitos

Análise

Desenho

Implementação

Testes

Modelo Cascata

§ Baseado em projetos de engenharia clássicos de1970

§ Algumas vezes chamado de ciclo de vida clássico

Críticas:§ Projetos raramente seguem o fluxo sequencial e as

modificações podem causar confusão à medida queo projeto evolui.

§ É difícil para o cliente explicitar os requisitos.§ O cliente precisa ser paciente a entrega final do

produto.

Modelo Cascata com Realimentação

Cascata com Realimentação

Requisitos

Análise

Desenho

Implementação

Testes

Problemas do Modelo Cascata

ü Divisão inflexível do projeto em estágios distintos tornadifícil responder às mudanças nos requisitos do cliente

ü Uma fase precisa ser completada antes de se moverpara a próxima fase.

ü Por isso, esse modelo só é apropriado quando osrequisitos são bem entendidos e as mudanças durante oprocesso de projeto serão limitadas.

ü Poucos sistemas de negócio possuem requisitosestáveis.

Lidando com Mudanças

• As mudanças são inevitáveis em todos grandes projetos desoftware.ü Mudanças no negócio levam a novos e diferentes

requisitos de sistema.ü Novas tecnologias abrem novas possibilidades para

melhorar implementações.ü Mudanças de plataforma requerem mudanças na

aplicação.

• As mudanças geram retrabalho, o que faz com que o custodas mudanças inclua o retrabalho (reanálise dos requisitos)assim como o custo de implementação de novas funções.

• Prevenção de mudanças:• processo de software inclui atividades que podem

antecipar possíveis mudanças antes que o retrabalho setorne necessário. Por exemplo, a prototipação.

• Tolerância a mudanças:• o processo é desenvolvido para que mudanças possam

ser acomodadas a um custo relativamente baixo.• Geralmente envolve alguma forma de desenvolvimento

incremental: as mudanças propostas podem serimplementadas em incrementos que ainda não foramdesenvolvidos.

Lidando com Mudanças

Prototipação de software

• Um protótipo é uma versão inicial de um sistema usada parademonstrar conceitos e testar opções de projeto.

• Um protótipo pode ser usado:ü No processo de engenharia de requisitos para ajudar na

elicitação e validação de requisitos;

ü Nos processos de projeto para explorar opções edesenvolver um projeto de interface de usuário;

ü No processo de testes para executar testes fim-a-fim.

• Processo de Prototipagem Rápida:

Prototipação de software

Esboço de requisitos

iniciais

Projeto Rápido: entradas e

saídas

Elaboração do Protótipo

Validação do Protótipo

Refinamento dos requisitos necessários

O processo de desenvolvimento de protótipo

Desenvolvimento de protótipos• Pode ser baseado em linguagens ou ferramentas de

prototipagem rápida.

• Perigo: pode deixar a funcionalidade de fora do teste. Achecagem de erros e recuperação podem não estar incluídasno protótipo.

• A prototipação deve focar em áreas do produto que não sãobem entendidas. O foco deve ser em requisitos funcionais aoinvés de não funcionais (ex: segurança).

• Muitos defendem que os protótipos devem ser descartadosdepois do desenvolvimento, pois não são uma boa base paraum sistema em produção.

• Ferramentas automatizadas para prototipação: Ø Axure, Justinmind, PencilProject, Form, Fluid, ...Ø Balsamiq, Mockup Builder, Cacoo, Mockabilly, ...

Prototipação de software

• A prototipação deve ser usada quando há um alto grau deincerteza dos requisitos ou quando é necessário um rápido feedback dos usuários.

• Com o uso de protótipos é possível apresentar opções desistema aos usuários e melhorar o entendimento.

• Permite também a detecção preventiva de problemas,reduz custos e melhora a qualidade do produto final.

• A prototipação é amplamente utilizada em metodologiaságeis (Scrum, XP, Kanban, Lean) e também em modelosde processo incremental (ex: modelo espiral).

Prototipação: Análise

Vantagens da prototipação:

• Melhoria do uso do software.

• Maior proximidade com as necessidades do usuário.

• Melhorias na qualidade do projeto.

• Maior manutenibilidade.

• Reduzir esforços de desenvolvimento.

Prototipação: Análise

Desenvolvimento e Entrega Incremental

• Ao invés de entregar o sistema em uma única entrega, odesenvolvimento e a entrega são distribuídos emincrementos, nos quais cada incremento entrega parte dafuncionalidade necessária.

• Os requisitos do usuário são priorizados e os requisitos demais alta prioridade são incluídos nos primeirosincrementos.

• Assim que o desenvolvimento de um incremento é iniciadoos requisitos são congelados, mas os requisitos dosincrementos posteriores podem continuar a evoluir.

Desenvolvimento Incremental

Modelo Evolucionário

§ Aplicado quando um cliente tiver uma necessidaderazoável mas não possui os detalhes.

§ Um protótipo é desenvolvido quando requisitossimples foram aprovados e, posteriormente, outrospodem ser levantados.

§ A iteração ocorre à medida que o protótipo é ajustadopara satisfazer às necessidades do cliente e ofeedback é usado para refinar os requisitos.

§ Não se deve sacrificar qualidade em nome de umprotótipo defeituoso, mas sim aprovado.

§ O cliente deve estar ciente de que aquele não é ummodelo definitivo do software.

Vantagens da entrega incremental

• Os valores podem ser entregues ao cliente junto com cadaincremento, e funções do sistema ficam disponíveis maisrapidamente.

• Primeiros incrementos agem como protótipos para ajudar adeduzir requisitos para incrementos posteriores.

• Menor risco de falha geral do projeto.

• Os serviços mais prioritários do sistema tendem a seremmais testados.

Problemas da entrega incremental

• A maioria dos sistemas requer um conjunto de funçõesbásicas que são usadas por diferentes partes do sistema.ü Como os requisitos não são definidos em detalhes até que

um incremento seja implementado, pode ser difícil identificarfunções comuns que são necessárias a todos osincrementos.

• A essência dos processos iterativos é que a especificaçãoseja desenvolvida em conjunto com o software.ü No entanto, essa pode entrar em conflito com o modelo de

aquisição de muitas organizações, nos quais aespecificação completa do sistema é parte do contrato dedesenvolvimento do sistema.

Modelo em Espiral

§ Várias versões evolucionárias, que podem começar com um protótipo ou rascunho em papel e evoluir para um software mais completo.

§ O custo e o cronograma são ajustados com base no feedback derivado do cliente após a entrega. Pode ser difícil gerar contratos!

Modelo Espiral de Boehm

• O processo é representado como uma espiral ao invés deuma sequência de atividades com retornos.

• Cada loop na espiral representa uma fase do processo.

• Não existem fases fixas como especificação ou projeto – osloops na espiral são escolhidos de acordo com anecessidade.

• Os riscos são avaliados explicitamente e resolvidos nodecorrer do processo.

Modelo Espiral de Boehm

Setores do Modelo Espiral

• Definição de objetivosü São identificados os objetivos específicos para cada fase.

• Avaliação e redução de riscosü Os riscos são avaliados e atividades executadas para

reduzir os principais riscos.

• Desenvolvimento e validaçãoü Um modelo de desenvolvimento para o sistema é

escolhido, pode ser qualquer um dos modelos genéricos.• Planejamento

ü O projeto é revisto e a próxima fase da espiral éplanejada.

RAD: Rapid Application Development

§ Modelo de desenvolvimento rápido de aplicação§ Modelo incremental com foco no desenvolvimento

curto e construção baseada em componentes.§ Adaptação em alta velocidade do modelo em cascata§ A modelagem abrange três fases: modelagem de

negócios, modelagem dos dados e modelagemdos processos.

§ A construção enfatiza o uso de componentes egeração automática de código

§ A implantação estabelece base para iteraçõessubsequentes se necessário.

RAD: Rapid Application Development

Modelos: Técnicas de Quarta Geração

§ Concentra-se na capacidade de se especificarsoftware a uma máquina em um nível que esteja próximo à linguagem natural ou de se usar uma notação que comunique uma função significativa.

§ O código fonte é gerado automaticamente a partirdestas especificações.

§ Caracteriza-se pelo suporte automatizado à especificação de requisitos.

§ Atua bem quando existe necessidade de flexibilidade,tempo curto e permite documentação em todas asfases de forma automática

Modelo RUP - Rational Unified Process

§ Processo proprietário criado pela Rational SoftwareCorporation, adquirida pela IBM.

§ RUP usa a abordagem da orientação a objetos emsua concepção e é projetado e documentadoutilizando a notação UML para ilustrar os processos.

§ É um processo considerado pesado epreferencialmente aplicável a grandes equipes dedesenvolvimento e a grandes projetos.

§ Porém o fato do RUP ser amplamente customizáveltorna possível que seja adaptado para projetos dequalquer escala.

• É um processo genérico moderno, derivado do trabalho emUML e processos associados.

• Reúne aspectos dos 3 modelos genéricos discutidospreviamente.

• Geralmente descrito por 3 perspectivas:ü Uma perspectiva dinâmica que mostra fases no tempo;ü Uma perspectiva estática que mostra atividades do

processo;ü Uma perspectiva prática que sugere boas práticas.

Modelo RUP - Rational Unified Process

Modelo RUP - Rational Unified Process

§ RUP divide o projeto em 4 fases distintas:1. Concepção: ênfase no escopo do sistema;2. Elaboração: ênfase na arquitetura;3. Construção: ênfase no desenvolvimento;4. Transição: ênfase na implantação.

§ As fases são compostas de iterações que possuemprazo definido

§ Todas as fases geram artefatos, que são utilizadosnas próximas fases e documentam o projeto, além depermitir melhor acompanhamento.

§ Eixo horizontal – tempo e aspectos do ciclo de vida à medida que sedesenvolve

§ Eixo vertical – Disciplinas que agrupam logicamente as atividades

Modelo RUP - Rational Unified Process

Fases do RUP

• Concepçãoü Estabelece o business case para o sistema.

• Elaboraçãoü Desenvolve um entendimento da extensão do problema e

da arquitetura do sistema.

• Construçãoü Projeta o sistema, programa e testa o sistema.

• Transiçãoü Implanta o sistema no seu ambiente de operação.

Iteração do RUP

• Iteração Intra-fase

ü Cada fase é iterativa aos resultados desenvolvidosincrementalmente

• Iteração Inter-fase

ü Como mostrado pelo loop no modelo RUP, o conjuntotodo de fases pode ser executado incrementalmente.

Workflows estáticos do RUP

• Modelagem de Negóciosü Os processos de negócios são modelados.

• Requisitosü Identificação de atores do sistema e elaboração dos

casos de uso.• Análise e Projeto

ü É criado um modelo de projeto, contendo modelo daarquitetura, de componentes, de objetos e de sequencia.

• Implementaçãoü Componentes implementados e estruturados. Pode incluir

geração automática de código.

Workflows estáticos do RUP• Teste

ü O teste é um processo iterativo, realizado junto com aimplementação e segue nas fases seguintes.

• Implantaçãoü Uma release é gerada, distribuída aos clientes e

implantada em cada um.• Gerenciamento de configuração e mudanças

ü Gerencia o processo de mudanças e versões do sistema.• Gerenciamento de projeto

ü Gerencia o desenvolvimento do sistema.• Meio ambiente

ü Disponibilização de ferramentas apropriadas para aequipe de desenvolvimento.

Boas práticas do RUP

• Desenvolver software iterativamenteü Planejar incrementos baseando-se nas prioridades do

cliente e entregar as de prioridade mais alta primeiro.

• Gerenciar os requisitosü Documentar explicitamente os requisitos do cliente e

manter registros de mudanças desses requisitos.

• Usar arquiteturas baseadas em componentesü Organizar a arquitetura do sistema como um conjunto de

componentes reusáveis.

• Modelar o software visualmenteü Use modelos de gráficos UML para representar visões

dinâmicas e estáticas do software.

• Verificar a qualidade do softwareü Garanta que o software atenda aos padrões de

qualidade organizacional.

• Controlar as mudanças do softwareü Gerencie as mudanças no software usando um sistema

de gerenciamento de mudanças e ferramentas degerenciamento de configuração.

Boas práticas do RUP

Modelos de Processos com Métodos Ágeis

Agile Modeling§ É uma metodologia baseada na prática para modelagem

efetiva e documentação de sistemas de software.§ Objetivo: melhorar o esforço dos profissionais que

desenvolvem software.

Agile Alliance§ Grupo de pesquisadores que lançaram o manifesto ágil.§ Defende valores e praticas dos métodos ágeis e ajudam

organizações a adotarem tais conceitos,§ Define valores e princípios do manifesto ágil.

O que é ser ágil?

§ Adotar práticas de desenvolvimento iterativo eincremental com entregas frequentes;

§ Estar apoiado fortemente nas pessoas;§ Menos sobre processo e mais sobre o que as pessoas

podem fazer;§ Ter foco em gerar valor agregado para o cliente;§ Rápida adaptação às mudanças;§ Cooperação constante entre pessoas que entendem do

'negócio' e desenvolvedores;

Métodos Ágeis

§ EXtreme Programming (XP)§ SCRUM§ SCRUM of SCRUM§ CRYSTAL§ KANBAN§ LEAN§ Test Driven Development (TDD)§ Microsoft Solution Framework for Agile (MSF for Agile)§ Adaptive Software Development (ASD)

SCRUM Process

§ É um processo para construir softwareincrementalmente, em ambientes complexos, onde osrequisitos não são claros ou mudam com muitafrequência.

§ Scrum possui seu foco no gerenciamento de projetoda organização onde é difícil planejar o que ainda deveacontecer.

§ É um processo que controla o “caos” de interessesconflitantes e necessários.

§ O feedback constitui o núcleo da técnica degerenciamento

§ Jeff Sutherland aplicou primeiro a concepção doSCRUM na Easel Corporation in 1993.

SCRUM

Scrum é um framework para gerenciamento de projetos ágeis. Ele é enquadrado como um processo para gerenciamento de projetos e certamente não é uma metodologia, se o fosse, seria muito pesado. KEN SCHWABER (2004)

SCRUM Process

§ Scrum é um esqueleto de processos que contémgrupos de práticas e papéis pré-definidos:

§ Scrum Master: mantém os processos (normalmente nolugar de um gerente de projeto);

§ Proprietário do Produto (Product Owner): querepresenta os stakeholders e o negócio;

§ Equipe/Time (Team): um grupo multifuncional comcerca de 7 pessoas e que fazem a análise, projeto, implementação, teste etc.

Como funciona?

Filosofia do SCRUM

§ Assume que todos os requisitos não sãoconhecidos,

§ A maneira mais rápida para levantar e implementartodos os requisitos será descoberta de maneiraempírica durante todo o processo.

§ Mecanismos de controle cuidadosos são utilizados.§ É permitida a máxima flexibilidade de times de

desenvolvimento pequenos e altamente acoplados.§ Requer times bem motivados e boa liderança para

implementar de maneira eficiente.§ Ganhos de produtividade da ordem de 600% tem sido

vistos em projetos bem executados.(Capers Jones)

Papéis SCRUM

§ Product Owner:

• Determina a Visão do Produto;• Define as funcionalidades do produto (Product

Backlog);• Determina o valor de negócio de cada funcionalidade;• Responsável pela rentabilidade (ROI);• Prioriza funcionalidades;• Aceita ou rejeita o resultado do trabalho;

§ Scrum Master:

• Responsável pela aplicação dos valores e práticas doScrum;

• Resolve os impedimentos levantados pelo Time;• Conduz as reuniões diárias e as reuniões de

planejamento e de revisão;• Escudo para interferências externas;

Papéis SCRUM

§ Time:

§ Entre 5 e 10 pessoas;§ Desenvolve as funcionalidades do Produto;§ Multi-funcional programadores, testadores,

desenvolvedores de interfaces, etc.§ Auto organizável e Auto gerenciável;§ Estima as funcionalidades do Produto (Product

Backlog);§ Define as tarefas;§ Levanta impedimentos;

Papéis SCRUM

Product Backlog

O Product Backlog é a lista mestre de todas asfuncionalidades desejadas no Produto:

§ Contém todos os requisitos funcionais e não-funcionais;§ Geralmente escritos em User Stories (histórias de

usuário);§ Os itens devem ter um valor de negócio reconhecido

pelo Product Owner;§ Os itens são priorizados pelo Product Owner;§ Contém itens solicitados pelo time, desde que seja

possível ter um valor de negócio;§ Seus itens são repriorizados a cada ciclo (Sprint);

SCRUM Process

§ Sprint§ Sprint é o período de tempo (15 a 30 dias) para

construção dos itens do Product Backlog emfuncionalidades do produto;

§ O progresso da Sprint é acompanhado pela SprintBacklog e Sprint Burndown;

§ Todo código desenvolvido é testado e os bugs sãocorrigidos antes do inicio da Revisão da Sprint.

§ Característica importante: Daily SCRUM Meeting;

Daily SCRUM Meeting

• Reunião de no máximo 15 minutos;• Conduzida pelo Scrum Master;• De preferência todos de pé (Stand Up Meeting);

“Porque um projeto atrasa um ano?“Atrasando um dia após o outro”

Fluxo de um Processo SCRUM

§ Questões Levantadas:§ O que foi finalizado ontem?§ O que é planejado para hoje?§ Existe algo que possa atrapalhar o trabalho?

§ Benefícios:§ Evita duplicação de esforço;§ Melhor entendimento e interdependência entre os

membros do Time;§ Comunicação do Time;§ Identificar riscos antes que eles ocorram;

Daily SCRUM Meeting

§ No início do ciclo de cada sprint (a cada 7-30 dias), umSprint Planning Meeting é realizado.

§ Selecione o trabalho que está a ser feito.

§ Prepare o Sprint Backlog que detalha o tempo que levará para fazer esse trabalho, com toda a equipe.

§ Identificar e comunicar o quanto o trabalho é susceptível de ser feito durante o sprint atual.

Sprint Planning Meeting

Fluxo de um Processo SCRUM

Sprint§ O Time seleciona itens do topo do backlog do produto.§ Os integrantes selecionam somente o quanto de

trabalho eles podem executar durante a Sprint, depoisda primeira Sprint a velocidade do Time deve serutilizada como parâmetro.

§ O objetivo da Sprint é definido.§ Os itens selecionados são então destrinchados em

tarefas, que se tornam o backlog da Sprint.

Criar as tarefas

Não é possível exibir esta imagem no momento.

Como cliente, gostaria de poder mudar a data da minha reserva

TaskBoard

Retrospectiva/Revisão da Sprint

Sprint

Timelineda Sprint

O que pode

melhorar?O que deu

certo?

Comentários Finais

• Processos dirigidos a planos são processos em que todasas atividades do processo são planejadas com antecedênciae o progresso é medido em relação a esse plano.

• Nos processos ágeis o planejamento é incremental e é maisfácil modificar o processo para refletir alterações nosrequisitos do cliente.

• Na realidade, os processos mais práticos incluem elementosdos processos ágeis e dirigidos a planos.

• Não existe processo de software certo ou errado.

Comentários Finais

§ SCRUM é interessante porque fornece ummecanismo de informação de status que é atualizadocontinuamente, e porque utiliza a divisão de tarefasdentro da equipe de forma explícita.

§ Qualquer metodologia de processo pode utilizar afilosofia do SCRUM e garantir boas práticas sobre oprojeto.

§ SCRUM e XP são complementares. SCRUM fornecepraticas de gerenciamento enquanto XP provêpráticas integradas de engenharia de software.