Workshop
Engenharia de
Software e Sistemas
Engenharia de Software
(Def.) Disciplina gerencial e tecnológica que lida
com a produção e manutenção sistemática de
produtos de software desenvolvidos dentro de
estimativas de custo e tempo
Deve-se entender por engenharia a ciência
relacionada com o uso prático de
conhecimentos científicos
O que é software?


Programas de computador e
documentação associada
Produtos de software podem ser
desenvolvidos para um cliente
particular ou podem ser desenvolvidos
para um mercado geral
Objetivos de Engenharia de
Software




Obter software de qualidade
Com produtividade no seu desenvolvimento,
operação e manutenção
Empregando profissionais que desenvolvam
o software dentro de custos, prazos e
níveis de qualidade controlados
E, além disso, que obtenham o melhor
custo-benefício possível entre Qualidade 
Produtividade
Motivação




Desenvolver sistemas de acordo com a
intenção do cliente/usuário
Estabelecer noção sobre tempo e
custo de desenvolvimento
Elaborar artefatos além do código
Analisar artefatos para estabelecer a
qualidade do produto
Ciclo de Vida e Processo de
Desenvolvimento de
Software
O que é um modelo de ciclo de
vida de processo de software?

Uma representação abstrata e
simplificada do processo de
desenvolvimento software,
tipicamente mostrando as principais
atividades e dados usados na
produção e manutenção de software
Principais Modelos do Ciclo
de Vida de Software


Cascata
Modelo de Desenvolvimento Evolucionário



Programação Exploratória
Prototipagem descartável
Modelos Iterativos


Espiral
Incremental
Modelo Cascata
(ou clássico)



Derivado de modelos existentes em outras
engenharias
Sua estrutura é composta por várias etapas
que são executadas de forma sistemática e
seqüencial
Na prática, existe uma interação entre as
etapas e cada etapa pode levar a
modificações nas etapas anteriores
Modelo Cascata
Definição de
Requisitos
Projeto do
Sistema e do
Software
Implementação e
Testes Unitários
Integração e
Teste do
Sistema
Operação e
Manutenção
Modelo Cascata na Prática
Definição de
Requisitos
Projeto do
Sistema e do
Software
Implementação e
Testes Unitários
Integração e
Teste do Sistema
Operação e
Manutenção
Modelo de Desenvolvimento
Evolucionário


Programação Exploratória
Prototipagem Descartável
Atividades Concorrentes
Especificação
Esboço de
Descrição
Desenvolvimento
Versão
Inicial
Versões
Intermediárias
Validação
Versão Final
Programação Exploratória

Idéia geral:





Desenvolvimento da primeira versão do sistema o
mais rápido possível
Modificações sucessivas até que o sistema seja
considerado adequado
Após o desenvolvimento de cada uma das versões do
sistema ele é mostrado aos usuários para
comentários
Adequado para o desenvolvimento de sistemas
onde é difícil ou impossível se fazer uma
especificação detalhada do sistema
Principal diferença para os outros modelos é a
ausência da noção de programa correto
Prototipagem Descartável

Como na programação exploratória, a primeira fase
prevê o desenvolvimento de um programa para o
usuário experimentar



No entanto, o objetivo aqui é estabelecer os
requisitos do sistema
O software deve ser reimplementado na fase
seguinte
A construção de protótipos com os quais os
usuários possam brincar é uma idéia bastante
atrativa:


Para sistemas grandes e complicados
Quando não existe um sistema anterior ou um
sistema manual que ajude a especificar os requisitos
Prototipagem Descartável


Os objetivos do protótipo devem estar bem claros
antes do início da codificação. Possíveis objetivos:
 Entender os requisitos dos usuários
 Definir a interface com os usuários
 Demonstrar a viabilidade do sistemas para os
gerentes.
Uma decisão importante a ser tomada é escolher o
que será e o que não será parte do protótipo
 Não é economicamente viável implementar todo
o sistema!
 Os objetivos do protótipo são o ponto de
partida
Modelos Iterativos



Requisitos de sistema SEMPRE evoluem
durante curso de um projeto. Assim a
iteração do processo sempre faz parte do
desenvolvimento de grandes sistemas
Iterações podem ser aplicadas a quaisquer
dos modelos de ciclo de vida
Duas abordagens (relacionadas)


Desenvolvimento espiral
Desenvolvimento incremental
Desenvolvimento Espiral

Acrescenta aspectos gerenciais ao processo de
desenvolvimento de software.








análise de riscos em intervalos regulares do processo de
desenvolvimento de software
planejamento
controle
tomada de decisão
O processo é representado como uma espiral em vez de
uma seqüência de atividades
Cada volta na espiral representa uma fase no processo
Não há fases fixas como especificação ou projeto voltas na espiral são escolhidas dependendo do que é
requerido
Riscos são avaliados explicitamente e resolvidos ao
longo do processo
Desenvolvimento Espiral
Determinação dos
objetivos, alternativas
e restrições
Análise das alternativas
e
identificação e/ou
resolução de riscos
Análise de
Riscos
Simulações,
modelos e
benchmarks
Planejamento
Desenvolvimento e
validação da versão
corrente do produto
Desenvolvimento Incremental




Em vez de entregar o sistema como um todo, o
desenvolvimento e a entrega são divididos em
incrementos, com cada incremento entregando parte da
funcionalidade requerida
Requisitos dos usuários são priorizados e os requisitos de
mais alta prioridade são incluídos nas iterações iniciais
Uma vez que o desenvolvimento de um incremento é
iniciado, os requisitos são "congelados". Embora os
requisitos possam continuar a evoluir para incrementos
posteriores
Em certos aspectos é similar à programação exploratória.
No entanto, o escopo do sistema deve ser claramente
entendido antes de se iniciar o desenvolvimento
Desenvolvimento Incremental
Definir
esboço dos
requisitos
Associar
requisitos a
incrementos
Projetar a
arquitetura do
sistema
Desenvolver
um
incremento
Validar o
incremento
Integrar o
incremento
Validar o
sistema
Sistema
Final
Processo

Conjunto de atividades





bem definidas
com responsáveis
com artefatos de entrada e saída
com dependências entre as mesmas e
ordem de execução
com modelo de ciclo de vida
Processo



é uma ação regular e contínua (ou sucessão
de ações) realizada de forma bem definida,
levando a um resultado
é um conjunto parcialmente ordenado de
atividades (ou passos) para se atingir um
objetivo
define quem está fazendo o que, quando e
como para atingir um certo objetivo
Modelo de Processo

é uma representação de um processo,
usualmente envolvendo




atividades a serem realizadas
agentes que realizam as atividades
artefatos (produtos) gerados
recursos necessários (consumidos)
Exemplos de processos

Processos tradicionais (pesados)


RUP, OPEN, Catalysis
Processos ágeis (leves)

XP, Agile modeling, Crystal, pragmatic
programming, Internet Speed, Scrum, ...
Exemplos de processos

Consenso em torno de




Iteratividade
Participação de usuários
Flexibilidade de configuração para
projetos específicos
Comunicação entre membros da equipe
Exemplos de processos

Divergências em torno de


Detalhamento de atividades a serem seguidas
Critério de conclusão da execução das
atividades



Rigor na atribuição de tarefas a responsáveis



Arquitetura robusta (RUP)
Arquitetura para o contexto da iteração atual (agile
modeling)
workers (RUP)
alocação sob demanda e interesse (XP)
Artefatos (documentação) gerados
Ciclo de Vida

O ciclo de vida de um sistema consiste de
quatro fases:
concepção
elaboração
construção
transição
tempo




Concepção (define o escopo do projeto)
Elaboração (detalha os requisitos e a
arquitetura)
Construção (desenvolve o sistema)
Transição (implanta o sistema)

Cada fase é dividida em iterações:
Inception
Preliminary
iteration
Elaboration
Architect. Architect. Devel..
iteration iteration iteration
Construction
Devel..
iteration
Minor Milestones: Releases
Devel..
iteration
Transition
Transition
iteration
Transition
iteration

Cada iteração




é planejada
realiza uma seqüência de atividades (de
elicitação de requisitos, análise e
projeto, implementação, etc.) distintas
geralmente resulta em uma versão
executável do sistema
é avaliada segundo critérios de sucesso
previamente definidos
Planejamento/Gerenciamento
Conteúdo





Erros clássicos de planejamento e
gerenciamento
O que é projeto?
Ciclo de vida de projetos
Elementos essenciais
Objetivos gerais do planejamento e
gerenciamento do projeto de
software
Erros Clássicos
Desenvolvimento de Software é uma
atividade complicada, então evite
erros tais como ...
Pessoas

Motivação incoerente


Pessoal problemático


Esforço do pessoal e chefe de férias …
Uma pessoa pode desconcentrar uma equipe …
Heroísmo

Posso fazer tudo, não preciso da equipe …
Pessoas

Mais pessoas no final do projeto


Em pequeno incêndio, jogue gasolina …
Atrito entre desenvolvedores e
clientes
Se você não adicionar isso, não quero
mais …
Falha de contratos



Com o módulo M, a ser criado pela empresa E,
vamos melhorar nosso cronograma …
Pessoas

Expectativas irreais


Falta de interação com o usuário


Vamos terminar o projeto em 6 meses …
Isso é ambíguo …, então vamos decidir sozinhos.
Crença cega

Essa parte do sistema é muito simples, em 1 ou
2 dias removemos todos os erros …
Processo

Planejamento insuficiente


Esse sistema é simples, não há o que
planejar …
Abandono de plano sob pressão

Devido ao cronograma apertado, vamos
codificar logo depois da especificação de
requisitos e não vamos testar …
Processo

Garantia de qualidade prejudicada


Controle de gerenciamento insuficiente


Só precisamos fazer os testes a partir da GUI
O que já fizemos? Não sei, mas sem problema …
Sem estimativas para tarefas necessárias

Não precisamos registrar o tempo para tarefa T
Processo

Planejamento para controlar depois


Fizemos em 3 meses, o que planejamos
fazer em 2, mas depois nós ganhamos
tempo …
Programação sem padronização

Vou codificar de qualquer jeito; ganho
tempo …
Produto

Requisitos demais


Desenvolvedor exagerado


Sei que o usuário não pediu, mas vamos melhorar
a performance do sistema …
Sei que o sistema não precisa e que não domino
a tecnologia, mas vou usar o recurso R …
Desenvolvimento orientado a pesquisa

Sei que vou desenvolver funcionalidade F, que é
estado-da-arte, mas minha estimativa é
razoável …
Tecnologia

Síndrome da bala de prata


Vou usar o gerador de GUIs e não terei
problemas quanto ao desenvolvimento das
GUIs …
Estimativa otimista com novas
ferramentas ou métodos

Vou usar ferramenta F, no lugar de G, daí
vou ganhar tempo …
Tecnologia

Troca de ferramentas no meio do
projeto


Vou usar a nova versão de F, pois tem
mais recursos …
Falta de controle sobre o códigofonte

Vamos trabalhar em paralelo no módulo
M (único arquivo) para ganharmos tempo
…
Projeto: Definição PMI

Um empreendimento temporário
realizado para criar um produto ou
serviço único
Por que Gerenciar?

Para atingir objetivos e produzir
resultados


Concentrar responsabilidade e
autoridade para atingir objetivos
Coordenar e integrar todas as atividades
para chegar aos resultados
Objetivos do Gerenciamento
Custo
Objetivo:
• Limite de orçamento
• Prazo de entrega
• Desempenho Almejado
Tempo
Desempenho
Qualidades de Gerente







Liderança
Comunicação
Resolver problemas
Negociação
Influenciar a organização
Mentor
Especialista técnico e em processo
Gerenciamento das Tarefas

Milestones


Ponto final de uma atividade do processo
de software (um marco no cronograma)
Deliverables

Resultado do projeto a ser entregue ao
cliente. Usualmente entregue ao final de
uma fase.
Por que Planejar?

Criar propostas que sejam




Econômicamente viáveis e
Realizadas com recursos financeiros préestabelecidos
E que estejam de acordo com as
necessidades requisitadas
Representar precisamente o que se
pode fazer
48/57
Planejamento e Estimativa


Registre suas estimativas para
comparar com os resultados reais no
final do projeto
Planejamento continua durante
desenvolvimento e manutenção


Planejamento inicial não é suficiente
Planejamento detalhado só ocorre após a
especificação de requisitos
49/57
Planejamento e o Processo
de Software
50/57
O que é um plano?

Documento que define o trabalho que e como
deve ser feito



Com uma estimativa de tempo e recursos
exigidos, e um contexto para gerenciamento de
controle e revisão, para cada marco
Servir de benchmark para comparar com
projetos anteriores, quando documentado
apropriadamente
Melhorando erros em estimativas e sua precisão
51/57
Estrutura Básica de um Plano






Introdução
Organização do Projeto
Requisitos com Recursos (Pessoas, SW,
HW)
Detalhamento das Tarefas
Análise de Riscos
Cronograma do Projeto




Milestones/Deliverables
Atribuição de tarefas a pessoas
Estimativa de tempo
Custo do Projeto
52/57
Introdução



Do que se trata o documento?
Tópicos do documento
Visão geral do sistema
Organização do Projeto

Estrutura Organizacional


Membros / Cargos
Papéis e Responsabilidades

Membros / Lista de Atividades
Recursos do Projeto



Pessoas
Hardware
Software
Detalhamento das tarefas


Descrição sucinta de cada tarefa a
ser realizada.
Resultado esperado após a tarefa
Análise de Riscos

Lista de Riscos




Descrição
Classificação (Alta/Média/Baixa)
Plano de Mitigação
Plano de Contigência
Cronograma


Atribuição de tarefas a pessoas
Estimativa de tempo
Custo

Custo dos funcionários



Salário (semanal / mensal)
Vale Transporte / Alimentação
Despesas Adicionais





Aluguel
Luz
Água
Energia
Internet
Exercício

Desenvolver o Plano de Projeto a ser
desenvolvido pela empresa.
Referência

http://www.cin.ufpe.br/~if682/