Engenharia de Software Avançada

(Parte I)
 .Allan Araujo
I have worked as a project manager or product manager since 2006. During this
time, I directly managed about a hundred of projects helping people and
organizations to succeed and improve themselves.

Currently, I work as a project manager at CESAR (awarded as the best R&D

institute in Brazil).

- MSc, BSc in Computer Science - UFPE

- Project Management Professional (PMP) – PMI
- PMI Agile Certified Practitioner (PMI-ACP) - PMI
- Certified Scrum Master (CSM) - Scrum Alliance
- Certified Product Owner (CSPO) - Scrum Alliance

allanrsa @ {gmail.com, skype, msn.com}

br.linkedin.com/in/allanrsa
 Sumário
PARTE I

- Motivação (Engenharia de Software)

- Gerenciamento de Projetos de Software

- Requisitos de Software

PARTE II

- Análise de Projetos e Sistemas

- Testes de Software

- Gerenciamento de Configuração
 Avaliação
PARTE I

- Práticas em sala de aula

PARTE II

- Seminários em tema atuais

Nota = (Parte I + Parte II)*0,5

O Problema
O Problema
O Problema
Principais fatores de insucesso
requisitos incompletos

falta de envolvimento
de usuários

mudanças de
requisitos e
especificações

falta de apoio de negócios

falta de recursos
Como resolver?
BDUF

Big Design Up Front

Processo!!
Ainda assim...
Por quê?
Previsibilidade
Cone da Incerteza
 Prática - Poesias

1. Cada equipe deve entregar uma poesia com 5 estrofes.

Cada estrofe deve ter 4 linhas. Cada linha deve ter 9-10
palavras.
2. Cada membro escreve apenas uma palavra e passa.
3. Deve rimar.
4. ... E deve tocar meu coração!
5. Serão realizados 4 sprints de 2 minutos, precedidas por 1
minuto de planejamento.
6. Equipes competem entre si por um contrato final com o
cliente!
 É natural que os
usuários tenham
novas idéias e suas
opiniões mudem
quando vêem as
primeiras versões do
software.
“Desenvolver é como criar uma
receita, enquanto produzir é
seguir a receita.” Poppendieck
“O desenvolvimento é um processo de
aprendizado, que envolve tentativa e
Larman
erros”
“Ao contrário do cenário numa linha de
produção em massa, o software não é algo
previsível ou imune a mudanças”
Larman
“Como a manufatura previsível, não pode ser
comparada ao software, dificilmente as práticas e
valores enraizados nesse paradigma trazem algum
benefício” Larman
O desenvolvimento de software depende
muito mais das pessoas e da
comunicação
64% das funcionalidades
desenvolvidas nos softwares
não são utilizadas.

Standish Group
Essas
funcionalidades
fazem parte dos
64% que ele nem
repara que estão lá,
quando o software
é entregue.
70% dos usuários utilizam as
funcionalidades básicas de um software.

20% utilizam as funcionalidades

intermediárias.

10% utilizam as funcionalidades

avançadas.
Microsoft
A Lei de Pareto, também conhecido como princípio 80/20.
20% do esforço do
desenvolvimento
80% dos benefícios
 Muitas vezes, pelo fato do
cliente só poder pedir uma vez,
ele acaba pedindo coisas que
não tem certeza que precisa.
Os softwares mais
famosos e utilizados no
mundo são os mais
simples
“Menos é Mais”
A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008
Gerenciamento de Projetos

ABORDAGEM TRADICIONAL
O QUE É UM PROJETO?

“Projeto é um esforço temporário empregado

para criar um produto, serviço ou resultado único”
PMBOK®

temporário

produto, serviço ou resultado único

Elaboração progressiva
 O QUE É UM PROJETO?
Exemplos de projetos
 Construção de um laboratório
 Redação de uma monografia
 Desenvolvimento de um software de CRM
 Consultoria em processos

Projetos X Operações Contínuas

EXERCÍCIO

Que perguntas iniciais você faria

caso você fosse designado para
gerenciar um projeto?
 EXERCÍCIO

Algumas perguntas
Escopo
 O que preciso gerenciar? Projeto ou operações contínuas?
 Qual o objetivo do meu projeto?
 Quais as atividades que preciso realizar para alcançar o Tempo
objetivo do meu projeto?
 Como fazer com que estas atividades sejam conduzidas
atendendo os prazos do projeto? Custo
 Meu projeto está caminhando bem? Vou conseguir terminá-lo
no tempo previsto? Estou gastando mais do que deveria?
 O que pode acontecer para que eu não consiga alcançar meus Qualidade
objetivos? O que estou fazendo para que não aconteça?
 Preciso contratar fornecedores? Risco
 Meus fornecedores vão me atender da forma como foi
planejada? Como devo me comunicar com eles? O que eles
estão desenvolvendo está integrado com o meu projeto? Aquisição
 Como gerenciar os caminhos críticos do projeto?
Comunicação

Capital Humano
 PROJETOS E PLANEJAMENTO
ESTRATÉGICO
Plano Estratégico
(Missão)
Planejamento
Estratégico
Estratégias

Plano Tático /
Operacional
Resultados
Projetos (Metas)
 O QUE É GERENCIAMENTO DE
PROJETOS?
“Gerenciamento de projetos é a aplicação de
conhecimento, habilidades, ferramentas e técnicas
às atividades do projeto a fim de atender
aos seus requisitos”

Gerenciar projetos inclui

 Identificar requisitos
 Estabelecer objetivos claros e atingíveis
 Balancear demandas de qualidade, escopo, tempo e custo
 Alinhar e atender expectativas das principais interessados com o projeto

Gerenciamento de projetos X Gerenciamento por Projetos

A gestão de projeto pode ser tão complexa quanto a necessidade

Gestão de Gestão da
contratação Comunicação
Gestão de
Gestão de
mudanças
Risco

Gestão de Gestão de
Integração tempo

Gestão do ciclo Gestão de Issues

de vida Competências e
Habilidades de Gestão
Gestão de escopo de Projetos Gestão de Custo

Ferramentas de Planejamento,
suporte à gestão Cronograma,
estimativas
Gestão do
conhecimento Governança e
Gestão de monitoramento
Gestão da
capital humano Qualidade
CICLO DE VIDA DE PROJETOS

“O Ciclo de Vida de um projeto determina as fases

de desenvolvimento do projeto, estabelecendo
o que precisa ser feito para a realização do mesmo”
 Cada fase é caracterizada pela entrega de um subproduto
 Direciona a definição de pontos de sincronização para o trabalho colaborativo da
equipe
 Avaliação realizada no final de cada fase no intuito de identificar pontos de melhoria
dos próximos passos/projetos

Marcos

Fase 1 Fase 2 Fase 3

 EXEMPLOS DE CICLOS DE VIDA DE PROJETOS DE SOFTWARE

Cascata

Constrói
e Conserta

Espiral
CARACTERÍSTICAS DE CICLOS DE VIDA DE PROJETOS

Fonte: PMBOK®
CARACTERÍSTICAS DE CICLOS DE VIDA DE PROJETOS

Fonte: PMBOK®
CICLO DE VIDA DE PROJETOS X CICLO DE VIDA DE PRODUTOS

Fonte: PMBOK®
Gerenciamento de Projetos

ABORDAGEM ÁGIL
Indivíduos e interação entre eles
mais que processos e ferramentas
Software em funcionamento
mais que documentação
abrangente
Colaboração com o cliente
mais que negociação de
contratos
Responder a mudanças mais
que seguir um plano
Princípios por trás do
manifesto ágil
“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”.
 “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 equipe
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 é 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, equipe,
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 ajusta e
otimiza seu comportamento de acordo”.
O Scrum
Scrum
• Pilares
• Transparência (Transparency);
• Inspeção (Inspection);
• Adaptação (Adaptation).
Papéis
do Scrum
 Scrum Master
Líder Servidor

Protege o time

Remove

impedimentos

Guia do Scrum
 Pequenos (5 a 9 pessoas)

Desenvolve as funcionalidades

Auto-organizável

Auto-gerenciável

Multifuncional

Estima o esforço

Defina as tarefas
O Time
Responsável pela qualidade
Product
Product OwnerDetermina a visão do produto
Owner
Define as funcionalidades

Escolhe as datas de release

Dá o feedback

Gerencia os stakeholders

Aceita ou rejeita os resultados

Prioriza de acordo com o ROI

Product Owner
 Prática & Debate

Processo Preditivo x Processo

Empírico

Gerenciamento Centralizado x
Descentralizado
Extreme Programming

Respeito
Extreme Programming
Extreme Programming
Whole
Team

Stories
Test First
Slack
Programming

Sit Together Pair Weekly Cicle

Programming Ten Minutes Build

Continuos
Integration Incremental Energized Work
Design

Informative
Workspace

Quartely
Cicle
Adaptado de xprogramming.com
Feature-Driven Development

• Cumulative Flow Diagram (CFD)

• Parking Lot Diagrams (one-page projects summary)
Feature-Driven Development
>> Práticas
• Domain object modeling;
• Developing by feature;
• Individual class (code) ownership;
• Feature teams;
• Inspections;
• Configuration management;
• Regular builds;
• Visibility of progress and results.
Dynamic Systems Development
Method (DSDM)
Dynamic Systems Development
Method (DSDM)
>> Princípios
• Focus on business needs;
• Deliver on time;
• Collaborate
• Agile contracts + MoSCoW;
• Never compromise quality;
• Build incrementally from firm foundations
• “Early architecture”;
• Develop iteratively;
• Communication continuous and clearly;
• Demonstrate control
•http://pt.wikipedia.org/wiki/Dynamic_Systems_Devel
opment_Method (defined workflow).
Crystal
Process
Tailoring
Crystal
>> Princípios
• Frequent delivery;
• Reflective improvement;
• Osmotic communication;
• Personal safety;
• Focus;
• Easy access to expert users;
• Technical environment
• Automated tests, configuration management,
frequent integration.
 Lean Software Development
Não é uma metodologia ágil.

Quality

Decisions
Kanban Development
Kanban Development
>> Princípios
• Visualize the workflow;
• Limit WIP;
• Manage flow;
• Make process policies explicit;
• Improve collaboratively.

>> Considerações
• Sistema contínuo e puxado;
• Iterações podem ser desnecessárias, assim como
estimativas (*).
Process Tailoring (Customização)
Process Tailoring (Customização)
>> Shu
• Obedecer

>> Ha
• Conscientemente modificar as regras.

>> Ri
• Encontrar um caminho próprio.
Requisitos

ABORDAGEM DE DESIGN
Será que o sistema contribui para
os objetivos da organização?

http://pt.wikipedia.org/wiki/Engenharia_de_requisitos#Estudos_de_viabilidade
Dadas as restrições tecnológicas,
organizacionais (econômicas, políticas,
ambientais, recursos disponíveis) e
temporais associadas ao projeto, será
que o sistema pode ser implementado?

http://pt.wikipedia.org/wiki/Engenharia_de_requisitos#Estudos_de_viabilidade
Caso haja necessidade de
integração entre diferentes
sistemas, será que esta é possível?

http://pt.wikipedia.org/wiki/Engenharia_de_requisitos#Estudos_de_viabilidade
http://pt.wikipedia.org/wiki/Engenharia_de_requisitos#Estudos_de_viabilidade
 A quem
perguntamos?
STAKEHOLDERS
 Processo de Design
Todo processo de Design é tanto um
Processo Criativo como um um processo de
Solução de Problema. (Lobach, 1976)

É um conjunto de Operações necessárias,

dispostas em ordem lógica, que nos leva de
forma confiável e segura à solução de um
problema. (Munari, 2000).

http://www.machsources.com/suppliers/jinshengtai/products/20934.html
UCD
User Centered Design