Modelo de Ciclo de Vida

Engenharia de Software
Modelos de Ciclo de Vida
Prof. M.Sc. Marco Antnio X. Valentim

Modelos de Processos de Software
As fases do processo de Desenvolvimento de
Software podem ser organizadas seguindo um
fluxo sequencial mais rgido ou mais
interativo.
Para isso precisamos conhecer os Modelos de
Processos de Software.
Leia o captulo 3 do Pressman.
Paradigmas de Engenharia de Software
Existem dezenas.
Grupos de Modelos, segundo Pressman(2006)
Modelos Prescritivos
Modelos em Cascata
Modelos Incrementais
Incremental
RAD
Modelos Evolucionrios
Prototipagem
Espiral
Desenvolvimento Concorrente
Modelos Especializados em Processo
Desenvolvimento baseado em Componentes
Modelos Baseados em Mtodos Formais
Orientados a Aspectos
Processo Unificado
3
Modelos Prescritivos
Um modelo de prescritivo de processo
preenche o arcabouo de processo com
conjuntos explcitos de tarefas.
Cada modelo prescritivo de processo tambm
prescreve um fluxo de trabalho = maneira
como os elementos se inter-relacionam.
Todos os modelos acomodam as atividades
genricas de arcabouo, mas diferem na
nfase e no fluxo.
4
Modelo de Processo de Software: Cascata
Segue fluxo sequencial;
Uma fase comea quando a outra termina;
Adequado em projetos com o escopo bem
definido e claro.
Correlacione
com o Modelo
Anlise Implementao Implantao de Ciclo de Vida.
Projeto Testes Operao e

Manuteno
Modelo de Processo de Software: Cascata
Desvantagens:
projetos reais no seguem um fluxo sequencial:
dificuldade de acomodar mudanas depois de iniciado.
Dificuldade de declarao de todas as exigncias pelo
cliente.
Retrabalho quando se volta em fases anteriores porque
ocorre interrupo das fases mais adiantadas.
Anlise Implementao Implantao
Projeto Testes Operao e

Manuteno
Modelo de Processo de Software: Incremental
dividido em incrementos.
Os processos de cada incremento podem ser
independentes. Pode-se utilizar o Cascata.
Risco menor de fracasso completo do sistema.
A funes entregues primeiro so testadas mais
vezes, medida que os prximos incrementos so
entregues.
Imagine um sistema para a rea de RH.
Um RH pode ser dividido por servios: Folha de
Pagamento (FP), Segurana do Trabalho (ST),
Recrutamento e Seleo (RS), Treinamento e
Desenvolvimento (TD), etc.
Se o programa for desenvolvido de modo
seqencial, ficar bem grande.
Podemos dividir para conquistar!
Veja a ilustrao a seguir:
Subsistema Folha de Pagamento
Projeto Testes Operao
Anlise
Implementao Implantao
Subsistema Recrutamento e Seleo

Subsistema Treinamento e Desenvolvimento

Tempo
Tempo
Modelo de Processo de Software Incremental:
RAD
RAD ( Rapid Application Development) um modelo sequencial linear
que enfatiza um ciclo de desenvolvimento extremamente curto;
O desenvolvimento rpido obtido usando uma abordagem de
construo baseada em componentes.
Os requisitos devem ser bem entendidos e o alcance do projeto
restrito;
O modelo RAD usado principalmente para aplicaes de sistema de
informao ;
Cada funo principal pode ser direcionada para uma equipe RAD
separada e ento integrada para formar o todo.
10
O Modelo RAD
Equipe #3
Equipe #1 Equipe #2 Modelagem
do Negcio
Modelagem Modelagem Modelagem
do Negcio do Negcio dos Dados
Modelagem Modelagem
Modelagem dos Dados do Processo
dos Dados Modelagem Gerao da
Aplicao
do Processo
Modelagem Teste e
Gerao da
do Processo Aplicao
Modificao
Gerao da Teste e
Aplicao Modificao
Teste e
60 a 90 dias Modificao
11
12
Modelo de Processo de Software
Incremental: RAD
Desvantagens:
Exige recursos humanos suficientes para todas as equipes;
Exige que desenvolvedores e clientes estejam
comprometidos com as atividades de fogo-rpido a fim de
terminar o projeto num prazo curto;
Nem todos os tipos de aplicao so apropriadas para o RAD:
Deve ser possvel a modularizao efetiva da aplicao;
se alto desempenho uma caracterstica e o desempenho
obtido sintonizando as interfaces dos componentes do
sistema, a abordagem RAD pode no funcionar;
13
Exerccio
Em sala de aula:
Vamos definir um projeto.
Elabore um esboo geral do que o projeto.
Em uma folha em branco represente visualmente
como o projeto ser realizado considerando os
modelos de ciclo de vida estudados.
Crie uma representao para apresentar como ele seria
desenvolvido se seguisse as estratgias do Cascata,
Incremental, RAD.
Modelo de Processo de Software: Evolutivo
Prototipagem
Baseado no paradigma de Interao Homem
Computador; 2) Planejamento
Estimativa
Cronogramao
Monitorao
3) Modelagem
Anlise
Projeto
1) Comunicao
Iniciao do projeto
Levantamento de requisitos
4) Construo do Prottipo
Codificao
Testes
5) Avaliao, Implantao, Feedback

15
Prototipagem
Baseado no projeto de Interface;
16
Espiral
Espiral
Definio dos objetivos
Especificao dos objetivos especficos desta fase.
Anlise dos riscos
Identificao e soluo dos principais riscos
Desenvolvimento e validao
Planejamento
O projeto revisto e se define planos para a prxima
volta da espiral
Espiral
Ideal quando o projeto possui complexidade e o
escopo precisa ser melhor esclarecido.
Ideal para projetos baseados em inovao
A medida que se passa pelo centro da espiral, todas as
fases anteriores so revisadas e atualizadas;
Adequado para o gerenciamento de riscos e mudanas.
Modelo de Processo de Software: Mtodos
Formais
Mtodos formais permitem ao engenheiro de software
especificar, desenvolver e verificar um sistema aplicando
uma rigorosa notao matemtica.
Elimina muitos problemas encontrados nos outros
modelos: ambiguidade, incompletude, inconsistncia.
Servem de base para a verificao de programas,
oferecendo a promessa de um software livre de defeitos.
Apropriado para softwares crticos (por exemplo, de
aeronaves e dispositivos mdicos).
Modelo de Processo de Software: Mtodos
Formais
O desenvolvimento de modelos formais
atualmente muito lento e dispendioso.
Exige treinamento extensivo para dar aos
desenvolvedores o preparo necessrio.
difcil usar os modelos como um mecanismo de
comunicao com a maioria dos clientes.
Modelo de Processo de Software:
As atividades ocorrem em paralelo mas esto em
diferentes estados.
O modelo define uma srie de eventos que vo disparar
transies de estado para estado, para cada uma das
atividades.
Em vez de usar uma sequncia como o modelo cascata, ele
define uma rede de atividades.
Pode ser aplicado a todo tipo de desenvolvimento de
software e fornece uma viso exata de como est o estado
do projeto.
Exemplo:
Entrevista x
Construo do Prottipo
Pode-se adiantar atividades.
Pode-se utilizar componentes.
Desvantagens:
Exige recursos humanos suficientes para todas as equipes;
Equipe deve ser bem treinada e organizada.
Desenvolvimento baseado em componentes
Compe aplicaes a partir de componentes de software
previamente preparados.
Seguem os seguintes passos implantados com uma
abordagem evolucionria:
1. Pesquisa e avaliao de componentes disponveis para o domnio
em questo.
2. Consideraes sobre a integrao de componentes.
3. Projeto de arquitetura de software.
4. Integrao dos componentes arquitetura.
5. Testes para garantir a funcionalidade adequada.
Leva ao reuso de software, que segundo estudos tem
como consequncias:
Reduo significativa do prazo de desenvolvimento.
Reduo significativa no custo do projeto.
Aumento do ndice de produtividade.
Em que situaes o desenvolvimento baseado em
componentes no adequado?
Aquelas em que no existam componentes padro disponveis ou em
que no se queira pagar pelos componentes.
26
27
Modelos de Processos Pessoal e de
Equipe Processo de Software Pessoal
(PSP)
um framework para auxiliar o desenvolvedor a
estimar e planejar suas tarefas, acompanhar sua
performance em relao ao planejado e melhorar a
qualidade dos produtos produzidos;
Foca no como e no no qu;
Focado no indivduo e no na equipe;
Oferece mtricas e anlise de mtricas (ex: tamanho do
programa, tempo da reviso, qtde de defeitos encontrados na reviso e depois);
Modelos de Processos Pessoal e de Equipe
Processo de Software Pessoal (PSP)
Processo pode mudar diariamente;
Existe um processo;
Pode ser desenvolvido um processo prprio;
Foca a descoberta de erros precocemente;
Define cinco atividades estruturais:
Planejamento (isola requisitos, estimativa de recursos, planeja mtricas)
Projeto de alto nvel (escopo preliminar)
Reviso de projeto de alto nvel (projeto detalhado)
Desenvolvimento (construo e testes)
Autpsia (verifica qualidade, eficincia)
Processo de Software em Equipe (TSP)
Processo pode mudar diariamente;
Existe um processo;
Pode ser desenvolvido um processo prprio;
Foco na equipe;
Objetivos do TSP:
Equipes autodirigveis de alto desempenho
Orientada a motivao e capacitao de equipes
Normalmente segue o CMMI nvel 5
Fornece a organizao orientao para melhorias com elevado padro de
maturidade
Utiliza scripts ou roteiros, formulrios e padres;
Atividades metodolgicas:
Lanamento do projeto
Projeto de alto nvel
Implementao
Integrao e testes
Autpsia
So quatro as lies do TSP
1. A maior parte do desenvolvimento de software e ser feita por equipes
2. Equipes com as habilidades apropriadas e em que todos os membros
trabalham juntos cooperativamente e efetivamente podem produzir
resultados extraordinrios
3. Um trabalho em equipe efetivo requer oito coisas:
1. Metas da equipe com que todos concordam
2. Papis estabelecidos
3. Um ambiente de trabalho adequado
4. Um processo de trabalho comum
5. Um plano para o trabalho
6. O compromisso mtuo com as metas, papis e o plano
7. Comunicao aberta entre todos os membros do time
8. Respeito mtuo e suporte de todos os membros do grupo
4. Quando times encontram essas condies, produzem um trabalho superior,
so mais produtivos e apreciam o seu trabalho
Modelo de Processo de Software: PROCESSO
UNIFICADO
uma tentativa de unir os melhores recursos e caractersticas
dos modelos convencionais.
Reconhece a importncia da comunicao com o cliente e dos
casos de uso para descrever a viso do cliente.
Utiliza a UML (Unified Modeling Language) como a notao para
modelagem e anlise de projeto.
Sugere um fluxo de processo que iterativo e incremental.
Tambm conhecido como RUP (de Rational Unified Process) a
Rational construiu ferramentas de apoio ao processo unificado.
UNIFICADO
O RUP descreve:
Papis ou perfis de trabalho, que definem quem responsvel por cada
tarefa.
Artefatos, que representam os produtos do processo, o que ser gerado
durante o processo de desenvolvimento.
Atividades, executadas durante o processo de desenvolvimentos, que
descrevem como os representantes de cada papel trabalham para atingir
os objetivos do projeto e construir o sistema de software.
Fluxos de atividades, que orientam a execuo das atividades, definindo
quando esta deve ocorrer.
UNIFICADO
Prticas do RUP :
Desenvolver Software Iterativamente: os usurios recebem as liberaes
de verso de cada iterao, o que facilita seu retorno sobre o software
produzido, apontando o que foi mal entendido e esclarecendo os demais
requisitos.
UNIFICADO
Prticas do RUP :
Gerenciar os Requisitos: consiste em elicitar, organizar e documentar a
funcionalidade e as restries requeridas pelo sistema; avaliar mudanas
nesses requisitos e estimar seu impacto; e registrar e documentar
decises.
Usar Arquiteturas Baseadas em Componentes: promover a criao de

arquiteturas estveis e robustas, atravs de utilizao de componentes
cuja qualidade comprovada por sua utilizao em outros sistemas,
dividir o sistema em mdulos de forma que sua evoluo possa ser feita
de forma isolada, facilitar o reuso, facilitar a gerncia de configurao.
UNIFICADO
Prticas do RUP :
Controlar as Mudanas no Software: manter a rastreabilidade entre os
elementos de cada verso liberada e entre os elementos ao longo de
liberaes mltiplas e paralelas essencial para avaliar e gerenciar
ativamente o impacto de mudanas.
Verificar a Qualidade de Software Continuamente: a verificao continua

de qualidade faz com que o acompanhamento do status do projeto seja
mais objetivo, as inconsistncias em requisitos, projeto e implementaes
sejam evidenciadas, os riscos mitigados, os defeitos encontrados
precocemente.
UNIFICADO
Prticas do RUP :
Modelar Software Visualmente: atravs da visualizao dos modelos,
comportamentos do sistema podem ser descritos de forma no ambgua,
detalhes podem ser abstrados quando necessrio, inconsistncias e
problemas de arquitetura podem ser encontrados mais facilmente.
UNIFICADO
Caractersticas do RUP :
um processo de desenvolvimento orientado a casos de uso.
Define um framework de processo que pode ser adaptado e estendido
pela organizao que o adota.
Utiliza largamente o suporte de ferramentas automatizadas.
UNIFICADO
Estrutura do RUP :
O processo possui duas dimenses, seno o eixo horizontal, que
representa os aspectos dinmicos do processo, e o eixo vertical, que
representa os aspectos estticos.
A parte dinmica diz respeito evoluo do projeto ao longo do tempo,
dividida em fases e iteraes e planejada de acordo com cada projeto
especifico.
A parte esttica descreve as disciplinas do processo, que agrupam
atividades logicamente de acordo com sua natureza; a parte do
processo que descreve quem faz o que, como e quando isso feito.
Modelo de Processo de Software: RUP
Estrutura do RUP :
UNIFICADO
Aspectos Dinmicos
Cada iterao do projeto inclui atividades de anlise de requisitos,
projeto (design), implementao e gerao e uma verso do
sistema, mesmo que essa verso ainda seja incipiente e
incompleta.
Para organizar e orientar as iteraes de forma a assegurar
convergncia para o sistema final resultante, o RUP define os
marcos do ciclo de vida do projeto.
Os marcos so pontos ao longo do desenvolvimento do sistema
que possuem um objetivo definido que aproxima o sistema em
desenvolvimento de sua finalizao.
Aspectos Dinmicos: fases do processo do RUP
Iniciao ou Concepo (inception): durante essa fase, definida

a viso geral do produto a ser desenvolvido; a principal
preocupao uma compreenso abrangente dos requisitos do
sistema e a determinao do escopo do produto. A iniciao
termina quando o marco de Objetivo do Ciclo de Vida alcanado.
Elaborao (Elaboration): o foco dessa faze engloba trs aspectos,

sendo o planejamento das atividades e recursos necessrios ao
projeto, a especificao detalhada dos requisitos e o projeto da
arquitetura do sistema. O marco que sinaliza a finalizao da
Elaborao a Arquitetura do Ciclo de Vida, que garante a
estabilidade da viso e da arquitetura do produto, e a
concordncia dos envolvidos quanto aos planos para entrega do
sistema.
Construo (Construction): responsvel pela evoluo do

sistema e de sua arquitetura, at que o sistema seja pronto para
entrega comunidade de usurios. As principais preocupaes so
o projeto (design) e a implementao do sistema.
O marco final da Construo a Capacidade Operacional Inicial,
atingindo quando h uma verso estvel e madura para entrega e
quando os stakeholders esto prontos para execuo dessa
entrega.
Transio (Transition): nessa fase, o sistema repassado a seua

usurios. So resolvidas as questes de empacotamento, entrega,
treinamento, suporte e manuteno.
A concluso da Transio se d quando o marco da Liberao do

Produto (Produto Release) alcanado, o que o cliente est
satisfeito com o sistema entregue.
UNIFICADO (Continuao)
Visite o site a seguir para obter exemplos de ferramentas e modelos
de documentos:
http://www14.software.ibm.com/webapp/download/bycategorysearch.js
p?q0=L107029V38585S93
http://www-
142.ibm.com/software/products/us/en/category/rational?pgel=lnav
Desenvolvimento gil:
Manifesto pelo Desenvolvimento gil de Software
(Agile Alliance, 2005)
Indivduos e interaes sobre processos e
ferramentas
Software funcionando sobre documentao
abrangente
Colaborao do cliente sobre seguir um plano
Responder a mudanas sobre seguir um plano
Desenvolvimento gil: uma filosofia e conjunto
de direcionamentos;
Princpios:
Nossa maior prioridade satisfazer o cliente, atravs da
entrega adiantada e contnua de software de valor.
Aceitar mudanas de requisitos, mesmo no fim do
desenvolvimento. Processos geis se adequam a
mudanas, para que o cliente possa tirar vantagens
competitivas.
Princpios: (continuao)
Entregar software funcionando com frequncia, na
escala de semanas at meses, com preferncia aos
perodos mais curtos.
Pessoas relacionadas negcios e desenvolvedores
devem trabalhar em conjunto e diariamente, durante
todo o curso do projeto.
Construir projetos ao redor de indivduos motivados;
dando a eles o ambiente e suporte necessrio, e confiar
que faro seu trabalho.
O mtodo mais eficiente e eficaz de transmitir
informaes para, e por dentro de um time de
desenvolvimento, atravs de uma conversa cara a
cara.
Software funcional a medida primria de progresso.
Processos geis promovem um ambiente sustentvel. Os
patrocinadores, desenvolvedores e usurios, devem ser
capazes de manter indefinidamente, passos constantes.
Contnua ateno excelncia tcnica e bom design,
aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de
trabalho que no precisou ser feito.
As melhores arquiteturas, requisitos e designs emergem
de times auto-organizveis.
Em intervalos regulares, o time reflete em como ficar
mais efetivo, ento, se ajustam e otimizam seu
comportamento de acordo.
Valores do XP
Comunicao: o andamento do projeto comunicado a
todos os interessados constantemente.
Simplicidade: h uma preocupao extrema com a
procura da coisa mais simples que possa funcionar.
Retroalimentao (Feedback): todas as teorias so
testadas to cedo quanto possivel.
Coragem: prticas geis de desenvolvimento de
software so inovadoras e requem ata confiana no
processo para ser empregadas corretamente.
Prticas do XP
O jogo do Planejamento (The Planning Game)
Pequenas Liberaes;
Metfora;
Projeto Simples
Teste;
Refatorao (Refactoring);
Programao em pares;
Prticas do XP
Propriedade coletiva do cdigo;
Integrao continua;
Semana de 40 horas;
Cliente presente;
Padres de codificao.
So focados aspectos sobre o gerenciamento de
recursos humanos:
Competncia (preparo tcnico)
Foco comum
Colaborao
Capacidade na tomada de deciso
Habilidade de resolver problemas vagos
Respeito e confiana mtua
Auto-organizao
Desenvolvimento gil: Extreme Programming

(XP): Planejamento
Histrias de usurio
Valores
Critrios de aceitao
Prottipos Teste Projeto

Prottipos Testes unitrio Cartes CRC
Testes de integrao Prototipagem
Prottipos
Codificao
Programao em pares
Desenvolvimento gil: Extreme Programming (XP):
Estria so escritas pelo usurio (cliente) e colocada em um
carto. O cliente atribui um valor (prioridade) para a Estria .
O custo estabelecido com base no esforo para implementao
da Estria .
Clientes e desenvolvedores organizam quais Estria sero
implementadas na prxima verso (incremento).
Programao em pares: cada uma possui um papel diferente
(uma codifica, outra observa diretrizes de desenvolvimento e
realiza as integraes, por exemplo);
Testes de aceitao acontecem aps a finalizao dos testes
unitrios e testes de integrao.
Desenvolvimento gil: Extreme Programming (XP):
(continuao)
Aps a entrega do primeiro incremento, calcula-se a
velocidade do projeto (quantidade de Estrias
implementadas por incremento).
SCRUM
O SCRUM foi estabelecido por Ken Schwaber e Jeff Sutherland e est
baseado no manifesto gil.
O SCRUM no uma metodologia, um framework, o que significa que

SCRUM no vai dizer exatamente o que fazer.
Princpios do Scrum
Pequenas equipes;
Processo adaptvel qualidade do produto e
facilidade de modificaes;
Produz incrementos de software;
O trabalho se d em parties claras, de baixo
acoplamento (menos dependente de outras
partes), ou em pacotes;
Testes e documentao constantes ao longo do
processo de construo.
Framework do Scrum
Ciclo de vida do SCRUM

Fonte: http://unisinos-eslp.blogspot.com/2011/04/metamodelos-para-metodologias-ageis.html
Papis no SCRUM
Os times de SCRUM tm pelo menos trs papis:
Papis no SCRUM
O Scrum Master : a pessoa responsvel por garantir que
o processo seja entendido e seguido. A responsabilidade
do ScrumMaster manter o foco no processo, remover
impedimentos da equipe e auxiliar na comunicao ente
equipe e o Producto Owner;
O Time ou Equipe: formada pelos analistas,

desenvolvedores e testadores de software, que a cada
Sprint, baseados nas prioridades do Backlog, devem
entregar uma parte do software pronto.
Papis no SCRUM
O Product Owner : o dono do
produto. Ele possui a viso do
retorno que o projeto trar para a
empresa e para os envolvidos,
logo sua misso cuidar do
Product Backlog (lista de
requisitos), planejar releases,
priorizar requisitos e passar ao
time uma viso clara dos objetivos
do projeto pronto.
Artefatos:
User Story
Product Backlog
Tasks
Sprint Backlog
Task Board
Burn-down chart (grfico)
Story Points
Artefatos:
User Story
So descries simples que representam uma
funcionalidade.
Product Backlog
basicamente uma lista de requisitos priorizadas, que
podem incluir de tudo: de aspectos do negocio a
tecnologias, questes tcnicas e correes de bugs.
Artefatos:
Task:
Cada story dever ser quebrada em tarefas
Idealmente, tarefas correspondem a 1 dia de trabalho
So a menor unidade de diviso
Cada tarefa vira um post-it
Artefatos:
Sprint Backlog:
Conjunto de task (tarefas) de cada uma das stories da
sprint corrente.
Lista de stories a serem realizadas durante a sprint
Baseada nas maiores prioridades do product backlog
De acordo com a capacidade da equipe em uma sprint
Artefatos:
Task Board
To do (para fazer)
Doing (fazendo)
Done (Feito)
Pode ter outras colunas:
Burn-down chart, reviso
Artefatos:
Burn-down Chart
Permite acompanhar e prever o progresso do projeto.
Com base na velocidade dos sprints do passado, o
Release Burndown antecipa o futuro, de modo que a
equipe de Scrum possa adaptar o produto e o projeto
conforme a necessidade.
Ele baseado em dois fatores: o esforo restante no
Product Backlog e o tempo.
Artefatos:
Burn-down Chart
Artefatos:
Story Points
Medida de esforo de implementao
Associado a cada story
Valores concretos ou relativos?
Pode ser associado a uma referncia concreta: homem-dia-
trabalho
Podeser simplesmente um valor relativo: escolhe-se a story
mais simples e pontua com valor 2.
Usa-se uma srie adaptada de Fibonacci:
1, 2, 3, 5, 8, 13, 20, 40 e 100.
Medida para determinar a VELOCITY da equipe
Cerimnias (Meetings):
Sprint
Sprint Planning (Planejamento do Sprint)
Daily Sprint (Reunio dirias)
Reviso do Sprint
Retrospectiva do Sprint
Sprint
Representa um Time box dentro do qual um conjunto
de atividades deve ser executado.
As Sprints so compostas por uma reunio de
planejamento da Sprint, reunies dirias, o trabalho de
desenvolvimento, uma reviso da Sprint e a
retrospectiva da Sprint.
Planejamento do Sprint
Reunio de planejamento da Sprint possui um time-box
com no mximo oito horas para uma Sprint de um ms
de durao. Para Sprints menores, este evento
usualmente menor. O Scrum Master garante que o
evento ocorra e que os participantes entendam seu
propsito. O Scrum Master ensina o Time Scrum a
manter-se dentro dos limites do time-box.
Reunio dirias
Reunio de planejamento da Sprint possui um time-box
com no mximo oito horas para uma Sprint de um ms
de durao. Para Sprints menores, este evento
usualmente menor. O Scrum Master garante que o
evento ocorra e que os participantes entendam seu
propsito. O Scrum Master ensina o Time Scrum a
manter-se dentro dos limites do time-box.
Reunio dirias
O que eu fiz ontem que ajudou o Time de
Desenvolvimento a atender a meta da Sprint?
O que eu farei hoje para ajudar o Time de
Desenvolvimento atender a meta da Sprint?
Eu vejo algum obstculo que impea a mim ou o Time
de Desenvolvimento no atendimento da meta da
Sprint?
Reviso do Sprint
A Reviso da Sprint executada no final da Sprint para
inspecionar o incremento e adaptar o Backlog do
Produto se necessrio. Durante a reunio de Reviso da
Sprint o Time Scrum e as partes interessadas colaboram
sobre o que foi feito na Sprint. Com base nisso e em
qualquer mudana no Backlog do Produto durante a
Sprint, os participantes colaboram nas prximas coisas
que podem ser feitas para otimizar valor.
A Retrospectiva da Sprint ocorre depois da Reviso da
Sprint e antes da reunio de planejamento da prxima
Sprint. Esta uma reunio time-boxed de trs horas
para uma Sprint de um ms. Para Sprint menores, este
evento usualmente menor.
O propsito da Retrospectiva da Sprint :

Inspecionar como a ltima Sprint foi em relao s
pessoas, aos relacionamentos, aos processos e s
ferramentas;
Identificar e ordenar os principais itens que foram bem
e as potenciais melhorias; e,
O propsito da Retrospectiva da Sprint :
Criar um plano para implementar melhorias no modo

que o Time Scrum faz seu trabalho;
Modelos de Processos de
Software
Desenvolvimento
Orientado a Aspectos
Desenvolvimento Orientado a Aspectos
um paradigma novo de engenharia de software que
fornece mecanismos para definir, especificar, projetar e
construir aspectos.
Aspectos=preocupaes do cliente que permeiam diversos
nveis do sistema, incluindo:
Propriedades de alto nvel (ex: segurana, tolerncia a falha).
Funes (ex: aplicao de regras de negcio).
Sistmicas (ex: sincronizao e gesto de memria).
Adotar caractersticas do modelo espiral e do modelo

concorrente.
Estamos no estado da arte sobre esse assunto.
(continuao)
Aspectos so representaes de concerns que atravessam
as representaes de outros concerns.
Concern uma propriedade, sendo esta propriedade um
requisito funcional ou no funcional (YU et al, 2004) que
pode ser enxergado em um crosscutting concern que
uma propriedade transversal, ou seja, um requisito (ou
propriedade) que est transversal em relao a outros
requisitos um forte candidato a ser um aspecto.
Rastreabilidade de requisitos.
(continuao)
De maneira geral, os mtodos para separao de
propriedades envolvem as seguintes atividades (AKSIT et
al. 2001):
Identificao de propriedades: seleo de propriedades que o sistema vai
incluir;
Representao de propriedades separadamente: especificao de
propriedades em unidades ou num conjunto de unidades que concretizam a
realizao de cada uma das propriedades;
Desenvolvimento Orientado a aspectos (AspectJ);
Composio de propriedades: integrao de unidades separadas a fim de dar
a elas alguma coerncia para formar o conjunto do sistema.
<<aspecto>>
manuteno
INVENTRIO
Equipamento
<<aspecto>> Depsito <<aspecto>>
Segurana Localizao disponibilidade
Plataforma
Log
<<aspecto>>
Pedido
(continuao)
Visitar site: http://www.din.uem.br/arquivos/pos-
graduacao/mestrado-em-ciencia-da-
computacao/dissertacoes/A%20Engenharia%20de%20Req
uisitos%20Orientada%20a%20Aspectos%20-
%20A%20Abordagem%20DAORE%20%28Luciana%20de%2
0Paiva%20Silva%29.pdf
Reflexes
Principais produtos do processo de
desenvolvimento de software:
Operao e
Projeto Testes Manuteno
Produtos solicitados Produto sendo
Prottipo utilizado no dia a dia.
testados pelo cliente.
Modelo do BD Novas demandas e
Documento de Termo de Aceite
Def. Arquiteturas bugs aparecem.
especificao de
Requisitos.
Programas e demais Produtos instalados e

Anlise produtos construdos disponvel para
e verificados. utilizao.
Bibliografias consultadas
PRESSMAN, Roger S. Engenharia de Software.
So Paulo: Makron Books, 1995. 1056p.
PICHLER, Roman. Gesto de Produtos com
Scrum. So Paulo: Ed. Campus, 2011.
MACHADO, Felipe N. Anlise e gesto de
Requisitos de Software. So Paulo:rica, 2011.

Modelo de Ciclo de Vida

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modelo de Ciclo de Vida

Diunggah oleh

Hak Cipta:

Format Tersedia

Engenharia de Software

Modelos de Ciclo de Vida

Prof. M.Sc. Marco Antnio X. Valentim

Projeto Testes Operao e

Projeto Testes Operao e

Subsistema Recrutamento e Seleo

Subsistema Treinamento e Desenvolvimento

5) Avaliao, Implantao, Feedback

Usar Arquiteturas Baseadas em Componentes: promover a criao de

Verificar a Qualidade de Software Continuamente: a verificao continua

Iniciao ou Concepo (inception): durante essa fase, definida

Elaborao (Elaboration): o foco dessa faze engloba trs aspectos,

Construo (Construction): responsvel pela evoluo do

Transio (Transition): nessa fase, o sistema repassado a seua

A concluso da Transio se d quando o marco da Liberao do

Desenvolvimento gil: Extreme Programming

Prottipos Teste Projeto

O SCRUM no uma metodologia, um framework, o que significa que

Ciclo de vida do SCRUM

O Time ou Equipe: formada pelos analistas,

O propsito da Retrospectiva da Sprint :

O propsito da Retrospectiva da Sprint :

Criar um plano para implementar melhorias no modo

Adotar caractersticas do modelo espiral e do modelo

Programas e demais Produtos instalados e

Anda mungkin juga menyukai