Modelo de Ciclo de Vida PDF

Engenharia de Software
Modelos de Ciclo de Vida
Prof. M.Sc. Marco Antônio X. Valentim

Modelos de Processos de Software
• As fases do processo de Desenvolvimento de
Software podem ser organizadas seguindo um
fluxo sequencial mais rígido ou mais
interativo.
• Para isso precisamos conhecer os Modelos de
Processos de Software.
• Leia o capítulo 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 Evolucionários
• Prototipagem
• Espiral
• Desenvolvimento Concorrente
– Modelos Especializados em Processo
• Desenvolvimento baseado em Componentes
• Modelos Baseados em Métodos Formais
• Orientados a Aspectos
– Processo Unificado
3
Modelos Prescritivos
• Um modelo de prescritivo de processo
preenche o arcabouço de processo com
conjuntos explícitos de tarefas.
• Cada modelo prescritivo de processo também
prescreve um fluxo de trabalho = maneira
como os elementos se inter-relacionam.
• Todos os modelos acomodam as atividades
genéricas de arcabouço, mas diferem na
ênfase e no fluxo.
4
• Modelo de Processo de Software: Cascata
– Segue fluxo sequencial;
– Uma fase começa quando a outra termina;
– Adequado em projetos com o escopo bem
definido e claro.
Correlacione
com o Modelo
Análise Implementação Implantação de Ciclo de Vida.
Projeto Testes Operação e

Manutenção
• Modelo de Processo de Software: Cascata
– Desvantagens:
• projetos reais não seguem um fluxo sequencial:
dificuldade de acomodar mudanças depois de iniciado.
• Dificuldade de declaração de todas as exigências pelo
cliente.
• Retrabalho quando se volta em fases anteriores porque
ocorre interrupção das fases mais adiantadas.
Análise Implementação Implantação
Projeto Testes Operação e

Manutenção
• 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 funções entregues primeiro são testadas mais
vezes, à medida que os próximos incrementos são
entregues.
– Imagine um sistema para a área de RH.
– Um RH pode ser dividido por serviços: Folha de
Pagamento (FP), Segurança do Trabalho (ST),
Recrutamento e Seleção (RS), Treinamento e
Desenvolvimento (TD), etc.
– Se o programa for desenvolvido de modo
seqüencial, ficará bem grande.
– Podemos dividir para conquistar!
– Veja a ilustração a seguir:
Subsistema Folha de Pagamento
Projeto Testes Operação
Análise
Implementação Implantação
Subsistema Recrutamento e Seleção

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 rápido é obtido usando uma abordagem de
construção baseada em componentes.
– Os requisitos devem ser bem entendidos e o alcance do projeto
restrito;
– O modelo RAD é usado principalmente para aplicações de sistema de
informação ;
– Cada função principal pode ser direcionada para uma equipe RAD
separada e então integrada para formar o todo.
10
O Modelo RAD
Equipe #3
Equipe #1 Equipe #2 Modelagem
do Negócio
Modelagem Modelagem Modelagem
do Negócio do Negócio dos Dados
Modelagem Modelagem
Modelagem dos Dados do Processo
dos Dados Modelagem Geração da
Aplicação
do Processo
Modelagem Teste e
Geração da
do Processo Aplicação
Modificação
Geração da Teste e
Aplicação Modificação
Teste e
60 a 90 dias Modificação
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-rápido” a fim de
terminar o projeto num prazo curto;
– Nem todos os tipos de aplicação são apropriadas para o RAD:
• Deve ser possível a modularização efetiva da aplicação;
• se alto desempenho é uma característica e o desempenho é
obtido sintonizando as interfaces dos componentes do
sistema, a abordagem RAD pode não funcionar;
13
Exercício
Em sala de aula:
• Vamos definir um projeto.
– Elabore um esboço 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 representação para apresentar como ele seria
desenvolvido se seguisse as estratégias do Cascata,
Incremental, RAD.
• Modelo de Processo de Software: Evolutivo
Prototipagem
– Baseado no paradigma de Interação Homem
Computador; 2) Planejamento
Estimativa
Cronogramação
Monitoração
3) Modelagem
Análise
Projeto
1) Comunicação
Iniciação do projeto
Levantamento de requisitos
4) Construção do Protótipo
Codificação
Testes
5) Avaliação, Implantação, Feedback

15
Prototipagem
– Baseado no projeto de Interface;
16
Espiral
Espiral
– Definição dos objetivos
• Especificação dos objetivos específicos desta fase.
– Análise dos riscos
• Identificação e solução dos principais riscos
– Desenvolvimento e validação
– Planejamento
• O projeto é revisto e se define planos para a próxima
“volta da espiral”
Espiral
– Ideal quando o projeto possui complexidade e o
escopo precisa ser melhor esclarecido.
• Ideal para projetos baseados em inovação
• A medida que se passa pelo centro da espiral, todas as
fases anteriores são revisadas e atualizadas;
• Adequado para o gerenciamento de riscos e mudanças.
• Modelo de Processo de Software: Métodos
Formais
– Métodos formais permitem ao engenheiro de software
especificar, desenvolver e verificar um sistema aplicando
uma rigorosa notação matemática.
– Elimina muitos problemas encontrados nos outros
modelos: ambiguidade, incompletude, inconsistência.
– Servem de base para a verificação de programas,
oferecendo a promessa de um software livre de defeitos.
– Apropriado para softwares críticos (por exemplo, de
aeronaves e dispositivos médicos).
• Modelo de Processo de Software: Métodos
Formais
– O desenvolvimento de modelos formais é
atualmente muito lento e dispendioso.
– Exige treinamento extensivo para dar aos
desenvolvedores o preparo necessário.
– É difícil usar os modelos como um mecanismo de
comunicação com a maioria dos clientes.
• Modelo de Processo de Software:
Desenvolvimento Concorrente
– As atividades ocorrem em paralelo mas estão em
diferentes estados.
– O modelo define uma série de eventos que vão disparar
transições de estado para estado, para cada uma das
atividades.
– Em vez de usar uma sequência como o modelo cascata, ele
define uma rede de atividades.
– Pode ser aplicado a todo tipo de desenvolvimento de
software e fornece uma visão exata de como está o estado
do projeto.
Exemplo:
Entrevista x
Construção do Protótipo
– 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
– Compõe aplicações a partir de componentes de software
previamente preparados.
– Seguem os seguintes passos implantados com uma
abordagem evolucionária:
1. Pesquisa e avaliação de componentes disponíveis para o domínio
em questão.
2. Considerações sobre a integração de componentes.
3. Projeto de arquitetura de software.
4. Integração dos componentes à arquitetura.
5. Testes para garantir a funcionalidade adequada.
– Leva ao reuso de software, que segundo estudos tem
como consequências:
• Redução significativa do prazo de desenvolvimento.
• Redução significativa no custo do projeto.
• Aumento do índice de produtividade.
– Em que situações o desenvolvimento baseado em
componentes não é adequado?
Aquelas em que não existam componentes padrão disponíveis ou em
que não 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 relação ao planejado e melhorar a
qualidade dos produtos produzidos;
– Foca “no como” e não “no quê”;
– Focado no indivíduo e não na equipe;
– Oferece métricas e análise de métricas (ex: tamanho do
programa, tempo da revisão, qtde de defeitos encontrados na revisão 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 próprio;
– Foca a descoberta de erros precocemente;
– Define cinco atividades estruturais:
– Planejamento (isola requisitos, estimativa de recursos, planeja métricas)
– Projeto de alto nível (escopo preliminar)
– Revisão de projeto de alto nível (projeto detalhado)
– Desenvolvimento (construção e testes)
– Autópsia (verifica qualidade, eficiência)
Processo de Software em Equipe (TSP)
– Processo pode mudar diariamente;
– Existe um processo;
– Pode ser desenvolvido um processo próprio;
– Foco na equipe;
– Objetivos do TSP:
– Equipes autodirigíveis – de alto desempenho
– Orientada a motivação e capacitação de equipes
– Normalmente segue o CMMI – nível 5
– Fornece a organização orientação para melhorias com elevado padrão de
maturidade
– Utiliza scripts ou roteiros, formulários e padrões;
– Atividades metodológicas:
• Lançamento do projeto
• Projeto de alto nível
• Implementação
• Integração e testes
• Autópsia
São quatro as lições 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 extraordinários
3. Um trabalho em equipe efetivo requer oito coisas:
1. Metas da equipe com que todos concordam
2. Papéis estabelecidos
3. Um ambiente de trabalho adequado
4. Um processo de trabalho comum
5. Um plano para o trabalho
6. O compromisso mútuo com as metas, papéis e o plano
7. Comunicação aberta entre todos os membros do time
8. Respeito mútuo e suporte de todos os membros do grupo
4. Quando times encontram essas condições, produzem um trabalho superior,
são mais produtivos e apreciam o seu trabalho
• Modelo de Processo de Software: PROCESSO
UNIFICADO
– É uma tentativa de unir os melhores recursos e características
dos modelos convencionais.
– Reconhece a importância da comunicação com o cliente e dos
casos de uso para descrever a visão do cliente.
– Utiliza a UML (Unified Modeling Language) como a notação para
modelagem e análise de projeto.
– Sugere um fluxo de processo que é iterativo e incremental.
– Também conhecido como RUP (de Rational Unified Process) – a
Rational construiu ferramentas de apoio ao processo unificado.
UNIFICADO
– O RUP descreve:
• Papéis ou perfis de trabalho, que definem quem é responsável 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 execução das atividades, definindo
quando esta deve ocorrer.
UNIFICADO
– Práticas do RUP :
• Desenvolver Software Iterativamente: os usuários recebem as liberações
de versão de cada iteração, o que facilita seu retorno sobre o software
produzido, apontando o que foi mal entendido e esclarecendo os demais
requisitos.
UNIFICADO
• Gerenciar os Requisitos: consiste em elicitar, organizar e documentar a
funcionalidade e as restrições requeridas pelo sistema; avaliar mudanças
nesses requisitos e estimar seu impacto; e registrar e documentar
decisões.
• Usar Arquiteturas Baseadas em Componentes: promover a criação de

arquiteturas estáveis e robustas, através de utilização de componentes
cuja qualidade é comprovada por sua utilização em outros sistemas,
dividir o sistema em módulos de forma que sua evolução possa ser feita
de forma isolada, facilitar o reuso, facilitar a gerência de configuração.
UNIFICADO
• Controlar as Mudanças no Software: manter a rastreabilidade entre os
elementos de cada versão liberada e entre os elementos ao longo de
liberações múltiplas e paralelas é essencial para avaliar e gerenciar
ativamente o impacto de mudanças.
• Verificar a Qualidade de Software Continuamente: a verificação continua

de qualidade faz com que o acompanhamento do status do projeto seja
mais objetivo, as inconsistências em requisitos, projeto e implementações
sejam evidenciadas, os riscos mitigados, os defeitos encontrados
precocemente.
UNIFICADO
• Modelar Software Visualmente: através da visualização dos modelos,
comportamentos do sistema podem ser descritos de forma não ambígua,
detalhes podem ser abstraídos quando necessário, inconsistências e
problemas de arquitetura podem ser encontrados mais facilmente.
UNIFICADO
– Características do RUP :
• É um processo de desenvolvimento orientado a casos de uso.
• Define um framework de processo que pode ser adaptado e estendido
pela organização que o adota.
• Utiliza largamente o suporte de ferramentas automatizadas.
UNIFICADO
– Estrutura do RUP :
• O processo possui duas dimensões, seno o eixo horizontal, que
representa os aspectos dinâmicos do processo, e o eixo vertical, que
representa os aspectos estáticos.
• A parte dinâmica diz respeito à evolução do projeto ao longo do tempo, é
dividida em fases e iterações e planejada de acordo com cada projeto
especifico.
• A parte estática 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 Dinâmicos
• Cada iteração do projeto inclui atividades de análise de requisitos,
projeto (design), implementação e geração e uma versão do
sistema, mesmo que essa versão ainda seja incipiente e
incompleta.
• Para organizar e orientar as iterações de forma a assegurar
convergência para o sistema final resultante, o RUP define os
marcos do ciclo de vida do projeto.
• Os marcos são pontos ao longo do desenvolvimento do sistema
que possuem um objetivo definido que aproxima o sistema em
desenvolvimento de sua finalização.
– Aspectos Dinâmicos: fases do processo do RUP
• Iniciação ou Concepção (inception): durante essa fase, é definida

a visão geral do produto a ser desenvolvido; a principal
preocupação é uma compreensão abrangente dos requisitos do
sistema e a determinação do escopo do produto. A iniciação
termina quando o marco de Objetivo do Ciclo de Vida é alcançado.
• Elaboração (Elaboration): o foco dessa faze engloba três aspectos,

sendo o planejamento das atividades e recursos necessários ao
projeto, a especificação detalhada dos requisitos e o projeto da
arquitetura do sistema. O marco que sinaliza a finalização da
Elaboração é a Arquitetura do Ciclo de Vida, que garante a
estabilidade da visão e da arquitetura do produto, e a
concordância dos envolvidos quanto aos planos para entrega do
sistema.
• Construção (Construction): é responsável pela evolução do

sistema e de sua arquitetura, até que o sistema seja pronto para
entrega à comunidade de usuários. As principais preocupações são
o projeto (design) e a implementação do sistema.
• O marco final da Construção é a Capacidade Operacional Inicial,
atingindo quando há uma versão estável e madura para entrega e
quando os stakeholders estão prontos para execução dessa
entrega.
• Transição (Transition): nessa fase, o sistema é repassado a seua

usuários. São resolvidas as questões de empacotamento, entrega,
treinamento, suporte e manutenção.
• A conclusão da Transição se dá quando o marco da Liberação do

Produto (Produto Release) é alcançado, o que o cliente está
satisfeito com o sistema entregue.
UNIFICADO (Continuação)
– 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)
– Indivíduos e interações sobre processos e
ferramentas
– Software funcionando sobre documentação
abrangente
– Colaboração do cliente sobre seguir um plano
– Responder a mudanças sobre seguir um plano
– Desenvolvimento ágil: é uma filosofia e conjunto
de direcionamentos;
– Princípios:
• Nossa maior prioridade é satisfazer o cliente, através da
entrega adiantada e contínua de software de valor.
• Aceitar mudanças de requisitos, mesmo no fim do
desenvolvimento. Processos ágeis se adequam a
mudanças, para que o cliente possa tirar vantagens
competitivas.
– Princípios: (continuação)
• Entregar software funcionando com frequência, na
escala de semanas até meses, com preferência aos
períodos mais curtos.
• Pessoas relacionadas à negócios e desenvolvedores
devem trabalhar em conjunto e diariamente, durante
todo o curso do projeto.
• Construir projetos ao redor de indivíduos motivados;
dando a eles o ambiente e suporte necessário, e confiar
que farão seu trabalho.
• O método mais eficiente e eficaz de transmitir
informações para, e por dentro de um time de
desenvolvimento, é através de uma conversa cara a
cara.
• Software funcional é a medida primária de progresso.
• Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser
capazes de manter indefinidamente, passos constantes.
• Contínua atenção à excelência técnica e bom design,
aumenta a agilidade.
• Simplicidade: a arte de maximizar a quantidade de
trabalho que não precisou ser feito.
• As melhores arquiteturas, requisitos e designs emergem
de times auto-organizáveis.
• Em intervalos regulares, o time reflete em como ficar
mais efetivo, então, se ajustam e otimizam seu
comportamento de acordo.
– Valores do XP
• Comunicação: o andamento do projeto é comunicado a
todos os interessados constantemente.
• Simplicidade: há uma preocupação extrema com a
procura da “coisa mais simples que possa funcionar”.
• Retroalimentação (Feedback”): todas as teorias são
testadas tão cedo quanto possivel.
• Coragem: práticas ágeis de desenvolvimento de
software são inovadoras e requem ata confiança no
processo para ser empregadas corretamente.
– Práticas do XP
• O jogo do Planejamento (The Planning Game)
• Pequenas Liberações;
• Metáfora;
• Projeto Simples
• Teste;
• Refatoração (Refactoring);
• Programação em pares;
– Práticas do XP
• Propriedade coletiva do código;
• Integração continua;
• Semana de 40 horas;
• Cliente presente;
• Padrões de codificação.
– São focados aspectos sobre o gerenciamento de
recursos humanos:
• Competência (preparo técnico)
• Foco comum
• Colaboração
• Capacidade na tomada de decisão
• Habilidade de resolver problemas vagos
• Respeito e confiança mútua
• Auto-organização
• Desenvolvimento ágil: Extreme Programming

(XP): Planejamento
• Histórias de usuário
• Valores
• Critérios de aceitação
Protótipos Teste Projeto

Protótipos • Testes unitário • Cartões CRC
• Testes de integração • Prototipagem
Protótipos
Codificação
• Programação em pares
• Desenvolvimento ágil: Extreme Programming (XP):
– Estória são escritas pelo usuário (cliente) e colocada em um
cartão. O cliente atribui um valor (prioridade) para a Estória .
– O custo é estabelecido com base no esforço para implementação
da Estória .
– Clientes e desenvolvedores organizam quais Estória serão
implementadas na próxima versão (incremento).
– Programação em pares: cada uma possui um papel diferente
(uma codifica, outra observa diretrizes de desenvolvimento e
realiza as integrações, por exemplo);
– Testes de aceitação acontecem após a finalização dos testes
unitários e testes de integração.
• Desenvolvimento ágil: Extreme Programming (XP):
(continuação)
– Após a entrega do primeiro incremento, calcula-se a
velocidade do projeto (quantidade de Estórias
implementadas por incremento).
• SCRUM
• O SCRUM foi estabelecido por Ken Schwaber e Jeff Sutherland e está
baseado no manifesto ágil.
• O SCRUM não é uma metodologia, é um framework, o que significa que

SCRUM não vai dizer exatamente o que fazer.
• Princípios do Scrum
– Pequenas equipes;
– Processo adaptável – qualidade do produto e
facilidade de modificações;
– Produz incrementos de software;
– O trabalho se dá em partições claras, de baixo
acoplamento (menos dependente de outras
partes), ou em pacotes;
– Testes e documentação constantes ao longo do
processo de construção.
• Framework do Scrum
Ciclo de vida do SCRUM

Fonte: http://unisinos-eslp.blogspot.com/2011/04/metamodelos-para-metodologias-ageis.html
• Papéis no SCRUM
– Os times de SCRUM têm pelo menos três papéis:
– O Scrum Master : é a pessoa responsável 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 comunicação 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.
– O Product Owner : é o dono do
produto. Ele possui a visão do
retorno que o projeto trará para a
empresa e para os envolvidos,
logo sua missão é cuidar do
Product Backlog (lista de
requisitos), planejar releases,
priorizar requisitos e passar ao
time uma visão clara dos objetivos
do projeto pronto.
• Artefatos:
– User Story
– Product Backlog
– Tasks
– Sprint Backlog
– Task Board
– Burn-down chart (gráfico)
– Story Points
• Artefatos:
– User Story
• São descrições simples que representam uma
funcionalidade.
– Product Backlog
• É basicamente uma lista de requisitos priorizadas, que
podem incluir de tudo: de aspectos do negocio a
tecnologias, questões técnicas e correções de bugs.
• Artefatos:
– Task:
• Cada story deverá ser quebrada em tarefas
• Idealmente, tarefas correspondem a 1 dia de trabalho
• São a menor unidade de divisão
• 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, revisão
• 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 esforço restante no
Product Backlog e o tempo.
• Artefatos:
– Burn-down Chart
• Artefatos:
– Story Points
• Medida de esforço de implementação
• Associado a cada story
• Valores concretos ou relativos?
– Pode ser associado a uma referência concreta: homem-dia-
trabalho
– Podeser simplesmente um valor relativo: escolhe-se a story
mais simples e pontua com valor 2.
• Usa-se uma série adaptada de Fibonacci:
– 1, 2, 3, 5, 8, 13, 20, 40 e 100.
• Medida para determinar a VELOCITY da equipe
• Cerimônias (Meetings):
– Sprint
– Sprint Planning (Planejamento do Sprint)
– Daily Sprint (Reunião diárias)
– Revisão do Sprint
– Retrospectiva do Sprint
– Sprint
• Representa um Time box dentro do qual um conjunto
de atividades deve ser executado.
• As Sprints são compostas por uma reunião de
planejamento da Sprint, reuniões diárias, o trabalho de
desenvolvimento, uma revisão da Sprint e a
retrospectiva da Sprint.
– Planejamento do Sprint
• Reunião de planejamento da Sprint possui um time-box
com no máximo oito horas para uma Sprint de um mês
de duração. Para Sprints menores, este evento é
usualmente menor. O Scrum Master garante que o
evento ocorra e que os participantes entendam seu
propósito. O Scrum Master ensina o Time Scrum a
manter-se dentro dos limites do time-box.
– Reunião diárias
• Reunião de planejamento da Sprint possui um time-box
com no máximo oito horas para uma Sprint de um mês
de duração. Para Sprints menores, este evento é
usualmente menor. O Scrum Master garante que o
evento ocorra e que os participantes entendam seu
propósito. O Scrum Master ensina o Time Scrum a
manter-se dentro dos limites do time-box.
– Reunião diárias
• 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 obstáculo que impeça a mim ou o Time
de Desenvolvimento no atendimento da meta da
Sprint?
– Revisão do Sprint
• A Revisão da Sprint é executada no final da Sprint para
inspecionar o incremento e adaptar o Backlog do
Produto se necessário. Durante a reunião de Revisão da
Sprint o Time Scrum e as partes interessadas colaboram
sobre o que foi feito na Sprint. Com base nisso e em
qualquer mudança no Backlog do Produto durante a
Sprint, os participantes colaboram nas próximas coisas
que podem ser feitas para otimizar valor.
• A Retrospectiva da Sprint ocorre depois da Revisão da
Sprint e antes da reunião de planejamento da próxima
Sprint. Esta é uma reunião time-boxed de três horas
para uma Sprint de um mês. Para Sprint menores, este
evento é usualmente menor.
– O propósito da Retrospectiva da Sprint é:

• Inspecionar como a última Sprint foi em relação às
pessoas, aos relacionamentos, aos processos e às
ferramentas;
• Identificar e ordenar os principais itens que foram bem
e as potenciais melhorias; e,
– O propósito 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=preocupações do cliente que permeiam diversos
níveis do sistema, incluindo:
– Propriedades de alto nível (ex: segurança, tolerância a falha).
– Funções (ex: aplicação de regras de negócio).
– Sistêmicas (ex: sincronização e gestão de memória).
– Adotar características do modelo espiral e do modelo

concorrente.
– Estamos no “estado da arte” sobre esse assunto.
(continuação)
– Aspectos são representações de concerns que atravessam
as representações de outros concerns.
– Concern é uma propriedade, sendo esta propriedade um
requisito funcional ou não 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 relação a outros
requisitos é um forte candidato a ser um aspecto.
– Rastreabilidade de requisitos.
(continuação)
– De maneira geral, os métodos para separação de
propriedades envolvem as seguintes atividades (AKSIT et
al. 2001):
– Identificação de propriedades: seleção de propriedades que o sistema vai
incluir;
– Representação de propriedades separadamente: especificação de
propriedades em unidades ou num conjunto de unidades que concretizam a
realização de cada uma das propriedades;
– Desenvolvimento Orientado a aspectos (AspectJ);
– Composição de propriedades: integração de unidades separadas a fim de dar
a elas alguma coerência para formar o conjunto do sistema.
<<aspecto>>
manutenção
INVENTÁRIO
Equipamento
<<aspecto>> Depósito <<aspecto>>
Segurança Localização disponibilidade
Plataforma
Log
<<aspecto>>
Pedido
(continuação)
– 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
Reflexões
• Principais produtos do processo de
desenvolvimento de software:
Operação e
Projeto Testes Manutenção
•Produtos solicitados •Produto sendo
•Protótipo utilizado no dia a dia.
testados pelo cliente.
•Modelo do BD • Novas demandas e
• Documento de • Termo de Aceite
•Def. Arquiteturas bugs aparecem.
especificação de
Requisitos.
•Programas e demais • Produtos instalados e

Análise produtos construídos disponível para
e verificados. utilização.
Bibliografias consultadas
• PRESSMAN, Roger S. Engenharia de Software.
São Paulo: Makron Books, 1995. 1056p.
• PICHLER, Roman. Gestão de Produtos com
Scrum. São Paulo: Ed. Campus, 2011.
• MACHADO, Felipe N. Análise e gestão de
Requisitos de Software. São Paulo:Érica, 2011.

Modelo de Ciclo de Vida PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelo de Ciclo de Vida PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Modelos de Ciclo de Vida

Prof. M.Sc. Marco Antônio X. Valentim

Projeto Testes Operação e

Projeto Testes Operação e

Subsistema Recrutamento e Seleção

Subsistema Treinamento e Desenvolvimento

5) Avaliação, Implantação, Feedback

• Usar Arquiteturas Baseadas em Componentes: promover a criação de

• Verificar a Qualidade de Software Continuamente: a verificação continua

• Iniciação ou Concepção (inception): durante essa fase, é definida

• Elaboração (Elaboration): o foco dessa faze engloba três aspectos,

• Construção (Construction): é responsável pela evolução do

• Transição (Transition): nessa fase, o sistema é repassado a seua

• A conclusão da Transição se dá quando o marco da Liberação do

• Desenvolvimento ágil: Extreme Programming

Protótipos Teste Projeto

• O SCRUM não é uma metodologia, é um framework, o que significa que

Ciclo de vida do SCRUM

– O Time ou Equipe: é formada pelos analistas,

– O propósito da Retrospectiva da Sprint é:

– O propósito da Retrospectiva da Sprint é:

• Criar um plano para implementar melhorias no modo

– Adotar características do modelo espiral e do modelo

•Programas e demais • Produtos instalados e

Você também pode gostar