Palestra Aula 2 e 3 e 4

Engenharia de Software
Docente: MSc. Luis Jorge Nhacanhaca, 2021| aula 02, 03, 04

Processo de Software e
Modelos de Processo de Software
Conceitos Basicos
Elaborado por MSc. Luis Jorge Nhacanhaca

Topicos
1. Processos de Software.
2. Modelos de Processo de Software
o Modelo em cascata
o Prototipação
o RAD
o Desenvolvimento evolucionário
o Engenharia de Software baseada em componentes.
o Processo Unificado (RUP)
Metodos Ageis
o Programação Extrema (XP).
o Scrum Elaborado por MSc. Luis Jorge Nhacanhaca
Conceitos fundamentais
Processo de Software e Modelos de Processo de Software:
Software são programas de computador e

documentação associada. Os produtos de software
podem ser desenvolvidos para um cliente especifico ou
para um mercado geral. (Sommerville).
Engenharia de software – é uma disciplina de

engenharia relacionada a todos os aspectos de produção
de software. (Sommerville)

Processo de Software:
Processo
O que é?
• Um conjunto de actividades que recebem insumos,
transformando-os, de acordo com uma lógica pré-
estabelecida e com agregação de valores, em
produtos / serviços para responderem às necessidades
dos clientes / usuários.

“Um processo define quem está fazendo o quê,

quando e como para atingir determinado
objectivo”
Ivar Jacobson
Grady Booch
James Rumbaugh

Processo de Desenvolvimento
Não confundir com processo de negócio!
Processo de Negócio:
• Um grupo de actividades relacionadas de forma lógica que usa os
recursos da organização para fornecer resultados definidos em apoio
aos objetivos da organização. Foco nos objectivos estratégicos da
organização.
Processo de Desenvolvimento:
• Um conjunto de passos ordenados e executados com o objectivo de
alcançar uma meta. No caso de desenvolvimento de software, a meta
consiste em criar um software ou desenvolver um já existente. Pode
ser visto como um processo de negócio aplicado a objectivos
específicos
Actividades de Processo de Desenvolvimento:
Um processo de desenvolvimento de software possui 4 etapas

básicas:
• Especificação do software: a funcionalidade do software e as

restrições em sua operação devem ser definidas.
• Projecto ou Desenvolvimento do software: o software deve ser

produzido de modo que atenda a suas especificações.

• Validação do software: o software tem de ser validado para

garantir que ele faz o que o cliente deseja.
• Evolução do software: evolução do software de modo a

atender as modificações das necessidades dos usuários

Objectivos:
• Processos de software visam assegurar o desenvolvimento de

software:
• com prazos e necessidade de recursos definidos
• com elevada produtividade (de forma econômica)
• com qualidade assegurada
• Processos permitem
• organizar
• instrumentar
• planear
• acompanhar projectos
• treinar equipes Elaborado por MSc. Luis Jorge Nhacanhaca
Processo de Desenvolvimento:
Sem o uso de processos....

• Procedimentos existentes na organização não são
documentados e usados de forma
• consistente na prática
• Erros são cometidos repetidamente
• Dificuldade de prever cronogramas e orçamentos
• Alto índice de defeitos, retrabalho e desperdício
• Dificuldade de implementar boas práticas e lições
aprendidas
• Dificuldade de realizar ações para prevenção de
defeitos Elaborado por MSc. Luis Jorge Nhacanhaca
Componentes de Processos

Artefato
 é um resultado de uma actividade, exemplos documento
revisto e aceito
• módulo implementado, testado e aceito
• construto integrado, testado e aceito
• framework documentado, implementado, testado e
aceito
 quando entregue ao usuário (cliente) o artefato é um
produto

Insumo
• elemento necessário para a realização de uma tarefa ou
actividade
• pode ser um elemento de saída de outras actividades ou
tarefas

Tarefa
 é uma ação desempenhada por alguma pessoa visando a
realização ou monitoramento do projecto
 não representa uma evidência de progresso no
desenvolvimento
• ter trabalhado 20 horas não implica ter produzido um
artefato de qualidade, mesmo que se tenha estimado
serem necessárias 20 horas para o seu desenvolvimento
 consome recursos - consumo real

• esforço (tempo de pessoa),
• equipamento,
• financeiro Elaborado por MSc. Luis Jorge Nhacanhaca
Actividade
 conjunto de tarefas que levam a um ou mais artefatos de

qualidade controlada
• representa uma evidência de progresso no desenvolvimento
 os artefatos resultantes existem e podem ser usados
• permite o controle da qualidade do resultado
 num extremo pode ser a mera constatação que o resultado
existe
 no outro extremo pode envolver técnicas muito avançadas
de controle da qualidade
 o esforço é medido através das tarefas constituintes
Atividades são “mini-projetos”
• possuem início e fim definidos

• consomem um volume finito de recursos
• produzem artefatos definidos
• possuem critérios de conclusão estabelecidos

Ferramentas e equipamentos
• auxiliam a execução das atividades e tarefas dos

processos
• podem automatizar partes da execução das atividades
e tarefas
• agilizam a execução dos processos

Papel
• descreve como as pessoas se comportam no processo
e quais são as responsabilidades que elas têm
• requer habilidades específicas necessárias
• papéis não são pessoas
 pessoas executam papéis

Componentes de Processos - Exemplo de Actividade
• Actividade: Realizar estimativas para o projecto
Descrição
A partir do escopo preliminar do projeto, detalhar as
atividades necessárias a sua realização, as estimativas de
consumo de recursos, os prazos e orçamentos.
• Papel:
Gerente de Projecto

Componentes de Processos - Exemplo de Actividade
• Artefatos de Entrada:
Escopo do projecto; Plano do projecto; Acordo de serviço;
Estrutura analítica do projeto (EAP)
• Artefatos de Saída:
Estimativas de custo da actividades; Estimativa de esforço das
actividades, Cronograma e Plano do projecto actualizados
• Tarefas:
Detalhar actividades e recursos; Detalhar cronograma; Detalhar
estimativa de custo das actividades;
Detalhar orçamento do projecto
• Os processos de software são escolhidos conforme a

natureza do projecto.
• Os prazos das actividades variam, do mesmo modo

que os resultados de cada actividade.
• Diferentes organizações podem utilizar processos

diferentes para produzir o mesmo tipo de produto.
Processo de software é um conjunto de actividades que leva á

produção de um produto de software. Isto é cujo o objetivo é o
desenvolvimento e ou evolução de software. (Sommerville).
• Uma coleção de padrões que definem um conjunto de

actividades, acções, tarefas de trabalho, produtos de trabalho
necessarios ao desenvolvimento de softwares. (Pressman).
• A aplicação de uma abordagem sistemática, disciplinada e

possível de ser medida para o desenvolvimento, operação e
manutenção do software (IEEE)

Conceitos Basicos

Modelos de Processo de Software:
Uma descrição simplificada de um processo de software,
que é apresentada a partir de uma perspectiva especifica.
Uma abstração do processo que esta sendo descrito.
(Sommervile)
• Definem
• As actividades para o desenvolvimento do
software
• Especificam os produtos de cada actividade
• Indicam os papéis das pessoas envolvidas
Tambem é chamado de ciclo de vida de processos.
O que é ciclo de vida?
Conjuntos de fases que devem ser executadas para o

desenvolvimento de um produto de software. O ciclo de
vida determina a ordem e interação entre as fases e
actividades.

Modelos de ciclo de vida
• são representações abstratas de processos

• descrevem processos a partir de uma perspectiva
específica
• podem ser vistos como frameworks de processos
• devem ser aplicados e personalizados segundo
necessidades específicas

Vantagens
Oferecem um roteiro útil para o trabalho de engenharia de
software
Mas, nenhum modelo de processo é perfeito
Outras vantagens
• Padronização dos artefatos
• Melhor comunicação da equipe
• Menos treinamento de pessoal
• Existem vários modelos de processo de software (ou

paradigmas de engenharia de software).
• Cada um representa uma tentativa de Modelos de

Processos.
• Cada um representa uma tentativa de colocar ordem

em uma actividade inerentemente caótica.

Metodologias Tracionais
• As metodologias tradicionais são também chamadas

de pesadas ou orientadas a documentação.
• Essas metodologias surgiram em um contexto de

desenvolvimento de software muito diferente do
atual, baseado apenas em um mainframe e terminais
burros [Royce (1970)].

• Na época, o custo de fazer alterações e correções era

muito alto, uma vez que o acesso aos computadores
eram limitados e não existiam modernas ferramentas
de apoio ao desenvolvimento do software, como
depuradores e analisadores de código. Por isso o
software era todo planeado e documentado antes de
ser implementado.
• A principal metodologia tradicional e muito utilizada

até hoje é o modelo Clássico
Algumas premissas que a influenciam a metodologia

tradicional
• Linearidade do modelo: as atividades são feitas em
sequência e uma só se inicia quando a anterior está
finalizada;
• Determinismo: tendo como base as especificações,

se elas forem seguidas rigorosamente, o resultado
gerado também será o correto. Tem-se a ideia
“equivocada” de que o uso do determinismo é uma
forma de reduzir erros e perdas de tempo; em
• Foco na execução: como as pessoas são em sua grande

maioria especialistas, as tarefas são simples e
determinísticas, bastando a elas somente a execução.
Presume-se que, se cada membro da equipe executar
corretamente a tarefa que lhe cabe, a especificação será
transformada corretamente em software.
• Crescimento exponencial do custo de alteração: o

custo de uma alteração tende a crescer à medida que o
processo de desenvolvimento avança.

Vantagens
• Maior percepção por parte do cliente referente ao
valor total do projecto;
• Entrega do produto em sua totalidade;
• Maior enfoque na etapa de planeamento, com o
objectivo de eliminar os riscos;
• Projectos são realizados de forma mais rápida.
Desvantagens
• Planeamento rígido, com pouca flexibilidade de trabalho;
• Não é interessante para clientes que querem sempre
inovar e adicionar melhorias no seu produto.
• Todo o processo é centralizado no gerente de projetos.
Metodologias Ágil
• A metodologia ágil surgiu da necessidade de

minimizar riscos e custos associados ao
desenvolvimento de software.
• Não rejeita os processos e ferramentas, a documentação,

a negociação de contratos ou o planeamento,
simplesmente mostra que eles têm importância
secundária quando comparado com os indivíduos e
interações, com o software estar executável, com a
colaboração do cliente e as respostas rápidas a mudanças
e alterações.
Metodologias Ágil
Vantagens
• Se você busca alcançar a famosa transformação digital, esse é
o caminho. O mundo digital está em constante metamorfose,
escolher metodologias rígidas como as tradicionais irá apenas
atrasar seu negócio.
• Maior liberdade no planeamento do projeto e em cada etapa de
trabalho;
• Projetos são discutidos e flexibilizados em conjunto;
• Equipe trabalha mais unida e a divisão do trabalho é realizada
de acordo com as habilidades de cada membro do time;
• Existe uma participação mais ativa do cliente em todas as
etapas do projeto, através de feedbacks.
Metodologias Ágil
Desvantagens
• O produto é entregue por partes, o que pode não
ser vantajoso para o cliente que precisa de um
projeto 100% pronto;
• Planeamento extenso, que exige várias análises em
cada etapa do projeto;
• Pode ter um custo mais volátil do que um projeto
realizado com metodologias tradicionais.


• Modelo em cascata
• Prototipação
• RAD
• Desenvolvimento evolucionário
• Engenharia de Software baseada em componentes.
• Processo Unificado (RUP)
• Programação Extrema (XP).
• Scrum
• FDD
Modelo Sequencial Linear ou Cascata:
• Sugere uma abordagem sistemática sequencial.

• Inicia no nível de sistema e progride até a
manutenção.

Modelo em Cascata:

Modelo em Cascata:

Modelo em Cascata:
Análise de requisitos de software:

• o processo de elicitação dos requisitos é intensificado e
concentrado especificamente no software
• deve-se compreender o domínio da informação, a
função, desempenho e interfaces exigidos
• os requisitos (para o sistema e para o software) são
documentados e revistos com o cliente
• os objectivos do sistema são estabelecidos por meio de
consulta aos usários do sistema ou cliente.
Modelo em Cascata:
Projecto de sistema e de software:
• enfoca a estrutura de dados, arquitectura do software,

representações da interface e detalhes procedimentais.
Traduz os requisitos de forma que a representação do
software possa ser avaliada antes da codificação.

Modelo em Cascata:
• Implementação ou Codificação
• Tradução das representações do projeto para uma

linguagem “artificial” resultando em instruções
executáveis pelo computador e implementado num
ambiente de trabalho

Modelo em Cascata:
Teste (integração):
• Concentra-se:
• nos aspectos lógicos internos do software,
garantindo que todas as instruções tenham sido
testadas
• nos aspectos funcionais externos, para descobrir
erros e garantir que a entrada definida produza
resultados que concordem com os esperados.
Modelo em Cascata:
• Manutenção (operação):
• Provavelmente o software deverá sofrer mudanças depois

que for entregue ao cliente.
• Causas das mudanças: erros, adaptação do software para

acomodar mudanças em seu ambiente externo e exigência
do cliente para acréscimos funcionais e de desempenho,
• esta é a fase mas longa.

Modelo em Cascata:
Vantagem:
• Maior capacidade de organização do projecto, visto
que uma etapa só inicia após a anterior.
Desvantagem:
• Modificações poderão causar confusões.
• Dificilmente o cliente expõe todos os requisitos de
uma só vez.
• Só teremos uma versão executável após o término do
projecto.
Problemas com o Modelo em Cascata:
• Projectos reais raramente seguem o fluxo seqüencial que

o modelo propõe;
• Logo no início é difícil estabelecer explicitamente todos
os requisitos. No começo dos projectos sempre existe uma
incerteza natural;
• O cliente deve ter paciência. Uma versão executável do
software só fica disponível numa etapa avançada do
desenvolvimento (na instalação);
• Difícil identificação de sistemas legados (não acomoda a
engenharia reversa).
Modelo em Cascata:

Modelo em Prototipação:
• O objetivo é entender os requisitos do usuário e, assim,

obter uma melhor definição dos requisitos do sistema.
• Possibilita que o desenvolvedor crie um modelo
(protótipo)do software que deve ser construído
• Apropriado para quando o cliente não definiu
detalhadamente os requisitos,

O Paradigma de Prototipação para obtenção dos requisitos:







• Senta-se com o cliente e realiza um projecto rápido para atender

somente a aspectos do software que ficarão visíveis (protótipo).
• O protótipo é avaliado pelo cliente e usado para refinar os

requisitos de software que serão desenvolvidos.
• Novas interações são realizadas para que tenhamos a evolução

do protótipo e melhor entendimento do desenvolvedor.
• Técnica para enumerar requisitos, deve-se evitar passar ao cliente

que poderia ser sua versão final.

Problemas:
• O cliente imagina que seja a sua versão final sem considerar que na
sua geração requisitos de qualidade ou manutenabilidade não foram
tratados.
• O cliente exige que seja utilizado o protótipocom alguns “remendos”
e a gerencia aceita.
• A utilização de linguagens e tecnologia quaisquer pode seruma

prática pelo desenvolvedor que acaba se adaptando ao seu uso e
esquece da real Necessidade que teve ao escolhe-las.
Solução:
• Definir as regras do jogo no começo.
• Comentários sobre o Paradigma de Prototipação
• Ainda que possam ocorrer problemas, a prototipação

é um ciclo de vida eficiente.
• A chave é definir as regras do jogo logo no começo.
• O cliente e o desenvolvedor devem ambos concordar
que o protótipo seja construído para servir como um
mecanismo para definir os requisitos

Modelo RAD:
• Modelo de desenvolvimento incremental que enfatiza um ciclo de
desenvolvimento curto.
• Adaptação de alta-velocidade do modelo cascata.
• Agiliza o desenvolvimento baseando-se na construção de

componentes.
• Requisitos bem conhecidos e objectivos de projecto restritos.
• Se tivermos a possibilidade de componentizar um sistema e estes

componentes ou módulos puderem ser desenvolvidos em 60 a 90
dias, poderemos ter várias equipes trabalhando no desenvolvimento.
Modelo RAD:

Modelo RAD:
Modelagem do negócio: modelagem do fluxo de informação

entre as funções donegócio.
• Que informação dirige o processode negócio?
• Que informação é gerada?
• Quem a gera?
• Para onde vai?
• Quem a processa?
Modelagem dos dados: fluxo de informação refinado num
conjunto de objectos de dados, que darão suporte ao negócio.
Modelo RAD:
• Modelagem do processo: os objectos de dados obtidos são

transformados para conseguir o fluxo de informação necessários
para implementar uma função do negócio.
• Geração da aplicação: trabalha com o reuso de componentes de

programas existentes ou cria componentes reusáveis.
• Teste e entrega: como muitos dos seus componentes já devem ter

sido testados, esta fase acaba por ser reduzida.
Modelo RAD:
Problemas:
• Exige muito RH para criar as equipe RAD.

• Necessidade do compromisso do cliente e dos
desenvolvedores com actividades continuamente rápidas.
• Se o sistema não puder ser componentizado o RAD não
atenderá à expectativa.
• Quando tiver riscos técnicos elevados, o RAD não é
aconselhável. Elaborado por MSc. Luis Jorge Nhacanhaca
Modelos Evolucionários:
Iterativo X Incremental

Modelos de processo que foram projectados para acomodar um

produto que evolui com o tempo.
Modelo Incremental:
• Combina omodelo seqüencial linearcom a filosofia interativa
da prototipagem.
• O primeiro incremento é chamado de núcleo do produto.
Modelo Incremental:
• Desenvolve-se um plano para cada incremento de forma que o
núcleo do produto seja modificado para melhor satisfazer às
necessidades do cliente e a elaboração de características e
funcionalidades adicionais.
• Útil quando não há mão de obra disponível para uma
implementação completa, dentro do prazo comercial de
entrega.
Modelo Incremental:

Modelo Incremental:

Modelo Espiral:
• Combina a natureza interativa da prototipação com os aspectos controlados e
sistemáticos do modelo seqüencial linear(cascata).
• Desenvolve o software em um série de versões incrementais.
• Na última iteração sãoproduzidas versões cada vez mais completas.
• Divide-se em regiões de tarefas compostas por seus respectivos conjuntos de
tarefas.
• Pode ser adaptado para a aplicação ao longo do seu ciclo de vida.

Modelo Espiral:

Modelo Espiral:

Exercicios
As etapas identificadas na figura por 1 e 2 são, respectivamente, projecto e instalação.

Processo de Software e
Conceitos Basicos Continuação

Modelos de Processo de Software Especializado
Engenharia de Software baseada em componentes:
• CBSE – Component-Based Software Engineering)

• Apoiada pela orientação a objetos.
• Classes se adequadamente projectadas e implementadas, são reusáveis ao
longo de diferentes aplicações e arquitecturas de sistemas baseados em
computadores.
• Incorpora muitas das características do modelo espiral evolucionário.
• Compõe a aplicação de software apartir de componentes de software
previamente preparados.
Um componente é uma unidade de composição com interfaces

contratualmente especificadas e dependências de contexto explícitas
somente. Um componentede software pode ser implantado
independentemente e está sujeito à composição por terceiros. ”
(Szyperski, 2002).
Componente:
• Entidade executável independente.
• Seus serviços estão disponíveis por meio de uma interface, por
onde todas as suas Elaborado
interações ocorrem.
por MSc. Luis Jorge Nhacanhaca
Características de um componente:
• Padronizado.
• Independente.
• Passível de composição.
• Implantável.
• Documentado.
Interfaces de um componente:
• Requires: quais serviços devem ser fornecidos por outros componentes do
sistema.
• Provides: serviço fornecido pelo componente.

Componentes VS OO
• Componentes são entidades implantáveis.

• Componentes não definem tipos.
• Componentes são independentes de linguagem.
• Componentes são padronizados.
Modelos de componentes:
• COM+.
• EJB.
• CORBA.

Processo de identificaçãode componente.

Processo de identificaçãode componente.

• A primeira iteração será composta pelas classes extraídas da biblioteca e

novas classes construídas.
• O fluxo volta para ao espiral e tudo se repete.
• Tem como palavra chave o reuso.
• Reduz em até 70% a montagem de componentes.
• Reduz em até 84% o custo do projecto.
• Podemos dizer que o PU foi originado da Engenharia de Software baseada em
componentes.
Processo Unicado – Rational Unified Process - RUP
• Podemos dizer que o PU foi originado da Engenharia de Software baseada em

componentes.
• O RUP é um modelo derivado do UML e do PU.
• Trata-se de um modelo híbrido.
• Traz elementos de todos os modelos genéricos.
• Apóia a iteração.
• Ilustra boas práticas de especificação e projecto.

Descrito apartir de três perspectivas:

• Dinâmica – fases do modelo ao longo do tempo.
• Estática – actividades realizadas no processo.
• Prática – boas práticas a serem usadas durante o processo.

Processo Unificado – Rational Unified Process - RUP


Modelo constituído por 4 fases discretas:
Concepção: estabelecer um business case para o sistema.

Avaliação do ambiente de negócio em relação à contribuiçãode um sistema para o
negócio. (escopo)
Elaboração: desenvolver um entendimento do domínio do problema, estabelecer
um framework, desenvolver um plano de projecto e identificar os
riscos principais do projecto.(modelode requisitos para o sistema).(arquitectura).
Modelo constituído por 4 fases discretas:
Construção: relacionada ao projecto, programação e teste de sistema. As partes

são desenvolvidas separadamente e integradas. Software funcional +
documentação.(desenvolvimento)
Transição: fase final do RUP . Transferência do desenvolvimento para ousuário.
Entrada do sistema em produção. Fase onerosa e problemática. (implantação).

• Cada faze pode ser realizada de forma iterativa, com resultados desenvolvidos
incrementalmente.
• O conjunto total de fases pode ser realizada de forma incremental.

O RUP recomenda 6 melhores práticas fundamentais

• Desenvolver o software iterativamente: incrementos de software priorizados
e entregues.
• Gerenciar requisitos: documentação e acompanhamento das mudanças dos
requisitos.
• Usar arquitecturas baseadas em componentes: estruturar a arquitectura de
sistema de componentes.

O RUP recomenda 6 melhores práticas fundamentais

• Modelar o software visualmente: modelos gráficos UML.
• Verificar a qualidade do software: atendam aos padrões de qualidade da

organização.
• Controlar as mudanças do software: usando um SGM e procedimentos

Visão estática do RUP (os Workflows):

• Fases são dinâmicas e tem objectivos.
• Workflows são estáticos e constituem actividades técnicas que não
estão associadas a uma única fase.
• As fases não estão associadas aos workflows específicos.

Modelos de Processo de Software: Processo Unificado
• Modelagem de negócios: processos de negócio são modelados usando casos

de uso de negócios.
• Requisitos: agentes que interagem com o sistemas são identificados e os
UCs são desenvolvidos para modelar os requisitos de sistema.
• Análise e projecto: modelo de projecto é criado e documentado usando
modelos de arquitectura, modelos de componente, modelos de objecto e
modelos de sequencia.
• Implementação: componentes de sistema são implementados e estruturados
em subsistemas de implementação.
Modelos de Processo de Software: Processo Unificado
• Teste: processo iterativo realizado em conjunto com a implementação.

• Implantação: versão do produto é criada, distribuída aos usuários e
instalada.
• Gerenciamento de configuração e mudanças: gerencia as mudanças do
sistema.
• Gerenciamento de projectos: gerencia o desenvolvimento o sistema.
• Ambiente: está relacionado à disponibilização de ferramentas apropriadas
de software para a equipe de desenvolvimento.

Métodos Ágeis: Manifesto
• Inicio da década de 90 alguns desenvolvedores se manifestaram

sobre a realidade encontrada no desenvolvimento de software de
pequeno porte.
• Manifesto ágil e declaração de interdependência..

Métodos Ágeis:
Mas o que significa ser ágil?

• Ser ágil é conseguir criar saídas e responder às mudanças de
forma rápida, buscando a opção mais eficaz em um ambiente
turbulento, sendo assim capaz de balancear a flexibilidade e a
estabilidade.
• No caso da Metodologia Ágil, a melhor forma de aplicar este
conceito é construir somente aquilo que o cliente valoriza.
Métodos Ágeis:
Mas o que significa ser ágil?

• Ser ágil é conseguir criar saídas e responder às mudanças de
forma rápida, buscando a opção mais eficaz em um ambiente
turbulento, sendo assim capaz de balancear a flexibilidade e a
estabilidade.
• No caso da Metodologia Ágil, a melhor forma de aplicar este
conceito é construir somente aquilo que o cliente valoriza.
Métodos Ágeis:
Existem várias opções para aplicar o conceito de ágil em seu projecto. Entre os
métodos mundialmente mais conhecidos, destacam-se:
• Crystal
• FDD (Feature Drive Development)
• DSDM (Dynamic System Development Method)
• XP (eXtreme Programming)
• AUP (Agile Unified Process)
• Scrum e Kanban

• “Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o

e ajudando outros a fazê-lo. Ao longo deste trabalho, começamos a
valoriza:
• Indivíduos e interações em vez de processos e ferramentas.
• Software funcional em vez de documentação extensiva.
• Colaboração com o cliente em vez de negociação de contracto.
• Resposta à mudança em vez de seguimento de um plano.
• Ou seja,mesmo havendo valor nos itensda direita, valorizamos mais os
itens da esquerda.”
Doze princípios do manifesto ágil.

1. Nossa maior prioridade é satisfazer o cliente, através da entrega
adiantada e contínua de software de valor.
2. 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.
3. Entregar software funcionando com freqüencia, na escala de semanas
até meses, com preferência aos períodos mais curtos.

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar
em conjunto e diáriamente, durante todo o curso do projecto.
5. Construir projectos ao redor de indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar que farão seu trabalho.
6. 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.

7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes de
manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a
agilidade.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que
não precisou ser feito.
11. As melhores arquitecturas, requisitos e designs emergem de times
auto-organizáveis.
12. Em intervalos regulares, a equipe reflete em como ficar mais
efectivo, então, se ajustam e optimizam seu comportamento de
acordo. Elaborado por MSc. Luis Jorge Nhacanhaca
Métodos Ágeis: Processos de desenvolvimento rápido
• Projectados para criar software útil rapidamente.

• Em geral são iterativos nos quais a especificação, o projecto, o
desenvolvimento e o teste são intercalados.
• Processos de especificação, projecto e implementação são
concorrentes.
• Documentação mínima (necessária) gerada pelo ambiente de
programação.
• Projectados para criar software útil rapidamente.

• Em geral são iterativos nos quais a especificação, o projecto, o
desenvolvimento e o teste são intercalados.
• Processos de especificação, projecto e implementação são
concorrentes.
• Documentação mínima (necessária) gerada pelo ambiente de
programação.
Vantagens:
• Entrega acelerada dos serviços ao cliente.
• Engajamento do usuário com o sistema (envolvimento).
Problemas na implantação:
• Problemas de gerenciamento (mudanças rápidas, documentação, tecnologias
não conhecidas).
• Problemas de contracto (preço fixo?).
• Problemas de validação (TDD - Test Driven Development ).
• Problemas de manutenção.
Métodos Ágeis: Extreme Programming - Características
• Foi durante um bom tempo a ferramenta ágil mais conhecida do

mercado.
• Tem seu nome do desenvolvimento iterativo e envolvimento extremo
do cliente.
• Todos os seus requisitos são expressos como cenários (histórias de
usuários) e são implementados directamente como uma série de tarefas.
• Os programadores trabalham em pares.


• Testes são desenvolvidos antes da escrita do código.

• Todos os testes executados com sucesso quando um novo código é
integrado ao sistema.
• Envolvimento do cliente apoiado pelo engajamento em tempo
integral deste na equipe do de desenvolvimento sendo responsável
pela definição de teste de aceitação do sistema.

Métodos Ágeis: Extreme Programming - Princípios
• Feedback rápido
• Presumir simplicidade
• Mudanças incrementais
• Abraçar mudanças
• Trabalho de alta qualidade.

Métodos Ágeis: Extreme Programming - Valores
• Comunicação.
• Simplicidade.
• Feedback.
• Coragem.
• Respeito.

Métodos Ágeis: Extreme Programming - Práticas
• Jogo de planeamento.
• Planeamento incremental.
• Pequenas versões (menores ainda que no RUP).
• Metáfora.
• Projecto Simples (não confundir com projecto fácil).
• Time/equipe coeso(pessoas engajadas e multidisciplinar).
• Testes de aceitação/Cliente on-site.
• Ritmo sustentável (trabalho motivado e hora extra quando

trouxer vantagens).
• Reuniões em pé.
• Processos de Software – Método
• Posse colectiva (o código não tem dono).
• Programação em pares.
• Padrões de codificação.
• Desenvolvimento orientado a testes. (TDD, Test first)
• Refatoração (é o processo de modificar um sistema de software

para melhorar a estrutura interna do código sem alterar seu
comportamento externo)
• Integração contínua.
Métodos Ágeis: Extreme Programming - Abordagem Extrema
• Novas versões podem se compiladas várias vezes por dia.
• Incrementos são entregues aproximadamente a cada duas semanas.
• Quando o desenvolvedor compila o sistema para criar uma nova

versão, ele deve executar todos os testes automatizados existentes e
os testes para a nova funcionalidade.
Métodos Ágeis: Extreme Programming - Teste
• O processo de testes dentro do XP é mais enfatizado que em outros métodos

ágeis.
Características:
• TDD – Test Driven Development (test-firt): define tanto uma interface
quanto um comportamento para a funcionalidade. (entrada, testes, saída).
• Desenvolvimento incremental de teste a partir de cenários.
• Envolvimento do usuário no desenvolvimento e validação de testes.

Métodos Ágeis: Extreme Programming - Teste
Características:
• O uso de ferramentas de teste automatizadas: teste escrito como
um componente executável antes do código. Deve possibilitar a
entrada e verificar se a saída atende.

Métodos Ágeis: Scrum
O Scrum é um pacote com mais de 50 modelos de relatórios

completos, 9 livros que indicam as melhores práticas no
gerenciamentode projetos, Um framework em software com
ferramenta CASE para auxiliar os seus implementadores e uma
ferramenta de Gerenciamentode Projectos integrada ao pacote de
escritório da sua organização?

Ferramentas CASE (do inglês Computer-Aided Software Engineering) é

uma classificação que abrange todas ferramentas baseadas em
computadores que auxiliam actividades de engenharia de software,
desde análise de requisitos e modelagem até programação e testes.
• Podem ser consideradas como ferramentas automatizadas que

tem como objectivo auxiliar o desenvolvedor de sistemas em
uma ou várias etapas do ciclo de desenvolvimento de software.

• Scrum não é um processo prescribente, ou seja, ele não descreve o

que fazer em cada situação.
• Ele é usado para trabalhos complexos nos quais é impossível

predizer tudo o que irá ocorrer.

• Scrum é um conjunto de valores, princípios e práticas que

fornecem a base para que a sua organização adicione suas práticas
particulares de engenharia e gestão e que sejam relevantes para a
realidade da empresa.

Métodos Ágeis: Scrum - Historial
• Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de

projetos em empresas de fabricação de automóveis e produtos de consumo.
• Por Takeuchi e Nonaka no artigo "The New Product Development Game" (

Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que
projectos usando equipes pequenas e multidisciplinares (cross-functional)
produziram os melhores resultados, e associaram estas equipes altamente
eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em
certos casos). Elaborado por MSc. Luis Jorge Nhacanhaca
O Scrum é um pacote com mais de 50 modelos de relatórios completos, 9 livros

que indicam as melhores práticas no gerenciamentode projetos, 1 framework em
software com ferramenta CASE para auxiliar os seus implementadores e uma
ferramenta de Gerenciamentode Projectos integrada ao pacote de escritório da sua
organização?

Não.
• É um processo iterativo e incremental para o desenvolvimento
de produtos e gerenciamento de projectos.
• Está mais para framework do que para uma metodologia.
• Ele não te dirá o que fazer , apenas te dará transparência para
enfrentar os desafios do dia a dia, a decisão é tua.

Características
• Clientes se tornam parte da equipe de desenvolvimento (os clientes

devem estar genuinamente interessados na saída);
• Entregas frequentes e intermediárias de funcionalidades 100%

desenvolvidas;
• Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
• Discussões diárias de status com a equipe;

Métodos Ágeis: Scrum -Características
• A discussão diária na qual cada membro da equipe responde às

seguintes perguntas:
• O que fiz desde ontem?
• O que estou planeando fazer até amanhã?
• Existe algo me impedindo de atingir minha meta?
• Transparência no planeamento e desenvolvimento;

Métodos Ágeis: Scrum -Características
• Reuniões frequentes com os stakeholders (todos os envolvidos no

processo) para monitorar o progresso;
• Problemas não são ignorados e ninguém é penalizado por

reconhecer ou descrever qualquer problema não visto;
• Locais e horas de trabalho devem ser energizadas, no sentido de

que "trabalhar horas extras" não necessariamente significa
"produzir mais".

• Método ágil para gerenciamento de projectos baseado em equipes

pequenos e auto-organizados.
• Apresenta forte-visibilidade e rápida adaptação a mudanças.
• Tomou nome quando Jeff Shutherland e Ken Shwaber utilizaram
seu corpo de conhecimento na Easel em 1994.
• Foi apresentado formalmente em 1996 na Object Oriented
Programming, Systems, Languages, and Applications.
• RUP é centrado em arquitectura e negócio o Scrum é

centrado em valores, entregas reais de produtos.
• Iterativo para garantir inspeção e adaptaçãodo produto
e incremental para garanti-la no processo.

Métodos Ágeis: Scrum 3 pilares
• Nenhuma nova prática quando integrada ao Scrum pode derrubar

um destes pilares, senão já não é mais Scrum.
• Transparência: os aspectos do processo que afetam o resultado
devem ser visíveis para aqueles que gerenciam os resultados.
Tudo que se vê deve ser conhecido. Se alguém acha que algo está
feito, isso quer dizer que está "pronto".

• Inspeção: detecção de variâncias inaceitáveis no processo devem

ser inspecionadas e detectadas.
• Daily Scrum: progresso em direção ao objectivo do Sprint e
adaptações para o próximo dia de trabalho.
• Sprint Review e Sprint Planning: inspecionar o progresso em
direção à meta da Sprint e adaptações que optimizem o valor do
próximo Sprint.
• Sprint Retrospective: revisar o Sprint que passou e determinar

quais adaptações devem ser f eitas para o próximo.
• Adaptação: se for detectado no decorrer da inspeção que um ou

mais aspectos do processo saiu dos trilhos e que oproduto final
será inaceitável, eles devem ser ajustados

Métodos Ágeis: Fluxo do Scrum
• Composto por papéis, reuniões e artefatos.

• Product Backlog, Sprint Backlog e Burndown Chart.


• O Produt Owner define a visão do produto.

• Para tanto ele recolhe informações junto ao cliente, usuários
finais, time, gerentes, stk, etc.
• A visão define o que o PO esperaque seja entregue como
produto final do projecto e sabe-se que ele foi finalizado
quando a visão foi atendida.
• Definição de Pronto.
• Escopo aberto.
Métodos Ágeis: Fluxo do Scrum - Product Backlog
• O PO cria uma lista inicialde necessidades(Product Backlog)com o

auxílio do Scrum Master.
• O Product Backlog contem os requisitos para o produto que a equipe
está desenvolvendo.
• O PO é o responsável pelo Product Backlog: conteúdo,disponibilidade
epriorização.
• O Product Backlog é o documento dinâmico.
• Não existe um padrão para documentação técnica, pode ser UC, Use
Stories.
Métodos Ágeis: Fluxo do Scrum - Product Backlog
• Quanto mais no topo do Product Backlog, mais prioritária será a

necessidade e automaticamente mais detalhada ela estará.
• Quanto mais no fundo,menos prioritária será a necessidade e
automaticamente menos detalhada ela estará.

Continua......

Muito Obrigado
Lembrem-se sempre, seu maior adversário é você!!!

Palestra Aula 2 e 3 e 4

Enviado por

Dados do documento

Descrição 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

Palestra Aula 2 e 3 e 4

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Docente: MSc. Luis Jorge Nhacanhaca, 2021| aula 02, 03, 04

Elaborado por MSc. Luis Jorge Nhacanhaca

Software são programas de computador e

Engenharia de software – é uma disciplina de

Elaborado por MSc. Luis Jorge Nhacanhaca

Elaborado por MSc. Luis Jorge Nhacanhaca

“Um processo define quem está fazendo o quê,

Elaborado por MSc. Luis Jorge Nhacanhaca

Um processo de desenvolvimento de software possui 4 etapas

• Especificação do software: a funcionalidade do software e as

• Projecto ou Desenvolvimento do software: o software deve ser

Elaborado por MSc. Luis Jorge Nhacanhaca

Actividades de Processo de Desenvolvimento:

• Validação do software: o software tem de ser validado para

• Evolução do software: evolução do software de modo a

Elaborado por MSc. Luis Jorge Nhacanhaca

• Processos de software visam assegurar o desenvolvimento de

Sem o uso de processos....

Elaborado por MSc. Luis Jorge Nhacanhaca

Elaborado por MSc. Luis Jorge Nhacanhaca

Elaborado por MSc. Luis Jorge Nhacanhaca

 consome recursos - consumo real

 conjunto de tarefas que levam a um ou mais artefatos de

Atividades são “mini-projetos”

• possuem início e fim definidos

Elaborado por MSc. Luis Jorge Nhacanhaca

• auxiliam a execução das atividades e tarefas dos

Elaborado por MSc. Luis Jorge Nhacanhaca

Elaborado por MSc. Luis Jorge Nhacanhaca

Elaborado por MSc. Luis Jorge Nhacanhaca

• Os processos de software são escolhidos conforme a

• Os prazos das actividades variam, do mesmo modo

• Diferentes organizações podem utilizar processos

Processo de software é um conjunto de actividades que leva á

• Uma coleção de padrões que definem um conjunto de

• A aplicação de uma abordagem sistemática, disciplinada e

Elaborado por MSc. Luis Jorge Nhacanhaca

Elaborado por MSc. Luis Jorge Nhacanhaca

O que é ciclo de vida?

Conjuntos de fases que devem ser executadas para o

Elaborado por MSc. Luis Jorge Nhacanhaca

• são representações abstratas de processos

Elaborado por MSc. Luis Jorge Nhacanhaca

• Existem vários modelos de processo de software (ou

• Cada um representa uma tentativa de Modelos de

• Cada um representa uma tentativa de colocar ordem

Elaborado por MSc. Luis Jorge Nhacanhaca

• As metodologias tradicionais são também chamadas

• Essas metodologias surgiram em um contexto de

Elaborado por MSc. Luis Jorge Nhacanhaca

• Na época, o custo de fazer alterações e correções era

• A principal metodologia tradicional e muito utilizada

Algumas premissas que a influenciam a metodologia

• Determinismo: tendo como base as especificações,

• Foco na execução: como as pessoas são em sua grande

• Crescimento exponencial do custo de alteração: o

Elaborado por MSc. Luis Jorge Nhacanhaca

• A metodologia ágil surgiu da necessidade de

• Não rejeita os processos e ferramentas, a documentação,

Elaborado por MSc. Luis Jorge Nhacanhaca

Elaborado por MSc. Luis Jorge Nhacanhaca

Modelo Sequencial Linear ou Cascata: