Engenharia de Software I
Administração de Projetos
-Estimativas
Prof. Lucio Kamiji
kamiji@dc.unifil.br
Administração de Projetos
• É um conjunto de atividades relacionadas
com um objetivo específico.
• Primeira atividade: estimativas (futuro e
incertezas)
• Existem técnicas para estimar o tempo e o
esforço.
Observações sobre a Realização de
Estimativas
• As estimativas dos recursos, custo e programação
de atividades para um esforço de desenvolvimento
de SW exige:
– Experiência
– Acesso a boas informações históricas
– Coragem para se comprometer com medidas
quantitativas quando dados qualitativos forem tudo o que existir.
Observações sobre a Realização de
Estimativas
• Fatores que influenciam no processo de
estimativa:
– Complexidade do projeto – Tamanho do projeto
– Estrutura do projeto
– Disponibilidade de informações históricas
– Riscos (são medidos pelo grau de incerteza das
estimativas quantitativas estabelecidas para recursos, custo e prazos).
Objetivo do Planejamento de Projetos
• É fornecer uma estrutura que possibilite ao gerente
fazer estimativas razoáveis de recursos, custos e
prazos.
• Dilema do Gerente de Projetos:
– Exigências de medida quantitativa logo no início do projeto
– Não existem informações sólidas disponíveis
– Análise detalhada dos requisitos de SW é necessária – Essa análise pode levar dias, semanas e até meses
Escopo do Software
• É a primeira atividade do planejamento de SW
• Delimitar o escopo do SW:
– Declarar explicitamente os dados quantitativos (número de usuários simultâneos, quantidade de clientes, tempo máximo de resposta permitido)
– Anotar as restrições e/ou as limitações (custo do produto que restringe o tamanho da memória) – Descrever os fatores mitigantes (algoritmos
Escopo deve Descrever:
• Funcionalidades
• Desempenho
• Restrições
• Interfaces
• Confiabilidade
Página 92 - Exemplo de uma
declaração de escopo
Recursos
• Estimativa de recursos é a segunda
atividade do planejamento de SW
Pessoas Ferramentas de HW e SW Especificar • Habilidades exigidas • Disponibilidade • Duração das Tarefas • Data de Início Especificar • Descrição • Disponibilidade • Duração do Uso • Data da EntregaRecursos Humanos
• Avaliar o escopo e selecionar as habilidades
exigidas para o projeto
• Especificar os postos organizacionais
(gerente, engenheiro de SW, etc.)
• Especificar as especialidades
(telecomunicações, banco de dados,
microprocessador)
Recursos de Hardware
• HW de desenvolvimento: ambiente de
desenvolvimento do projeto
• HW de produção: ambiente de execução do
produto
• Outros recursos de HW: podem ser
especificados como recursos para o
desenvolvimento de SW
Recursos de Software
• Antes:
– Bootstrapping: era executada para uma rotina interna do computador para testar a memória e os periféricos.
– Tradutor de linguagem assembly: foi utilizado para desenvolver um Assembler mais sofisticado.
– Bootstrapping de compiladores de alto nível e outras ferramentas.
• Hoje:
– CASE (computer aided software engeneering) engenharia de software auxiliada por computador (ESAC). Ferramentas de engenharia de software que auxiliam na construção de um software.
C.A.S.E.
Banco de dados CASE Planejamento de S.I. Gerenciamento de Projeto Apoio Análise e projeto Programação Integração e testes Ferramentas de construção de protótipos e simulação Manutenção FrameworkFerramentas de Planejamento de
Sistemas de Informação
• Proporciona um “meta-modelo” a partir da qual S.I. específicos são derivados.
• Normalmente respondem:
– Onde se originam os dados críticos ao negócio? – Para onde vão tais informações?
– Como elas são usadas?
– Como elas são transformadas à medida que realizam as funções do negócio?
– Quais novas informações são adicionadas?
• A grosso modo a transferência de dados é melhorada e as tomadas de decisão é agilizada.
Ferramentas de Gerenciamento de
Projetos
• Gerar estimativas do esforço, custo e duração do
projeto
• Definir uma estrutura de divisão de trabalho
• Planejar um programação de atividades do projeto
• Monitorar projetos
• Compilar as métricas que estabelecerão a baseline
(produtividade e qualidade).
Ferramentas de Apoio
• Ferramentas de:
– Produção de documentos
– Software de sistemas em rede – Banco de Dados
– Correspondência Eletrônica – BBS (bulletin boards)
– Gerenciamento de Configuração: usada para
controlar e gerenciar a informação que é criada á medida que o SW é desenvolvido.
Ferramentas de Análise e Projeto
• Criar um modelo do sistema a ser
construído
• Auxiliar na avaliação da qualidade
• Realizar a verificação da consistência e da
validade do modelo
• Ajudar a eliminar erros antes que estes se
propaguem no programa
Ferramentas de Programação
• Utilitários básicos • Editores • Compiladores • Depuradores (debuggers) • Ferramentas de P.O.O.• Linguagens de 4a. Geração
• Sistemas avançados de pesquisa em banco de dados • Conjunto de ferramentas de computadores pessoais
Ferramentas de Integração e Testes
• Analisadores de cobertura de caminho (path
coverage analysers)
• Testes de regressão automáticos
Ferramentas de Construção de Protótipos
e Simulação
• Pode partir de um simples Screen Painters
• Até produtos de simulação para análise da
determinação de tempo e de tamanho em
sistemas embutidos em tempo real
• Basicamente concentram-se na criação de
telas e relatórios
Ferramentas de Manutenção
• Ajuda a decompor um programa existente e
proporciona esclarecimentos ao engenheiro
• Para concluir o processo de engenharia reversa
o engenheiro deve utilizar a inteligência
humana
• Num futuro próximo ainda não vai ser possível
substituir a inteligência humana pela
Ferramentas de Framework
• Jbuilder
• Delphi
• Visual Café
• Visual Age
• Visual C++
• demais IDE´s
Reusabilidade
• Blocos devem ser catalogados para que
possam facilmente serem consultados e
padronizados
• Regras para reúso:
– Se o software existente cumprir os requisitos, adquira-o.
– Se o software existente exigir “alguma modificação” antes que possa ser
adequadamente integrado ao sistema, proceda cautelosamente.
Estimativas de Projetos de SW
• No começo o custo de HW era maior que o custo de SW
• O custo global de SW não representava muito
• Atualmente, o custo global de SW representa muito em relação ao custo global
• Sendo assim, grandes erros de estimativas de custos podem causar diferenças entre lucro e prejuízo
• As estimavas de custo e esforço de SW jamais serão uma ciência exata, pois existem muitas variáveis: -humanas, técnicas, ambientais e políticas.
Passos Sistemáticos que Oferecem
Estimativas com Riscos Aceitáveis
1. Atrasarmos as estimativas até um ponto tardio do
desenvolvimento do projeto;
2. Usarmos técnicas de decomposição relativamente
simples para gerar estimativas de custo e de
esforço de projeto;
3. Desenvolvermos um modelo empírico para o
custo e esforço de software; e
4. Adquirirmos uma ou mais ferramentas de
estimativas automatizadas.
Detalhe dos Passos Sistemáticos
1. A primeira opção é atraente mas não é prática. Pois normalmente as estimativas devem ser dadas logo no início. Mas quanto mais sabemos menos erramos.
2. Técnicas de decomposição: assume uma abordagem “divida e conquiste”. Ao dividirmos em funções mais importantes as estimativas podem ser dada por etapas.
3. Modelos empíricos de estimativas: pode ser usada para
complementar a decomposição, sendo que este modelo baseia-se na experiência (história).
4. Ferramentas de Estimativa Automatizadas: implementam uma ou mais técnica de decomposição ou modelos empíricos.
Técnicas de Decomposição
• É sub-divisão dos problemas em
partes menores, para que sejam
melhor administráveis.
• Resolvendo-se cada um deles e que
ao resolver todas as partes,
Estimativas por LOC e por FP
• São usadas de duas maneiras:
– Variáveis de estimativa são usadas para “classificar por tamanhos” cada elemento do software; e
– Métricas de baseline (linha básica) coletadas a partir de dados passados e usadas em conjunto com variáveis de estimativa para desenvolvermos projeções de custo e de esforço.
Estimativa do Esforço
• É a técnica mais comum para se levantar os
custos de qualquer projeto de
desenvolvimento de engenharia.
• Um número de pessoas-dia, mês o ano é
aplicado à solução de cada tarefa do projeto.
• Um custo é associado a cada unidade de
esforço e um custo estimado.
• Exemplo: página 112 (leiam)
Modelos Empíricos de Estimativa
• Modelo de Estimativa: usa fórmulas empiricamente
derivadas para prognosticar informações de planejamento do projeto.
• Modelo de Recursos: consistem em uma ou mais equações empiricamente derivadas que prognosticam o esforço,
duração do projeto e outros dados inerentes ao projeto. – Segundo Basili, possui 4 classes:
• Modelos estáticos de variável simples • Modelos estáticos de múltiplas variáveis • Modelos dinâmicos de múltiplas variáveis; e • Modelos teóricos.
Detalhes das 4 Classes
• Modelo estático de variável simples (COCOMO):
– Recurso = c1 x (características estimadas) ^ c2
onde o recurso pode ser o esforço, a duração do projeto, tamanho do staff ou as linhas da documentação do SW.
• Modelo estático de múltiplas variáveis:
– Recurso = c11e1 + c21e2 + ....
onde ei é a i-ésima característica de software e Ci1, Ci2 são
constantes empiricamente derivadas para a i-ésima característica.
• Modelo dinâmico de múltiplas variáveis: projeta os requisitos de recursos como uma função do tempo.
• Modelo teórico: examina o SW a partir do ponto de vista microscópico (número de operandos e operadores).
COCOMO
• Barry Boehm, define a seguinte hierarquia:
Modelo 1 - básico é um modelo estático de valor simples que
computa o esforço (e custo) de desenvolvimento de SW como uma função do tamanho de programa expresso em linhas de código
estimadas.
Modelo 2 - intermediário computa o esforço de desenvolvimento de SW como uma função do tamanho do programa e de um conjunto de “direcionadores de custo” que incluem avaliações subjetivas do produto, do hardware, do pessoal e dos atributos do projeto.
Modelo 3 - avançado incorpora todas as características da versão intermediária, com uma avaliação do impacto dos direcionadores de custo sobre cada passo (análise, projeto, etc.) do processo de engenharia de SW.
3 Classes de Projetos (Boehm)
1) Modo orgânico: projetos de SW simples, relativamente pequenos, nos quais pequenas equipes com boa
experiência em aplicações trabalham num conjunto de requisitos tão rígidos;
2) Modo semidestacado: um projeto de SW intermediário (em tamanho e em complexidade) no qual equipes com níveis de experiência mistos devem atingir uma combinação de requisitos rígidos e não tão rígidos;
3) Modo embutido: um projeto de SW que deve ser
desenvolvido dentro de um conjunto rígido de restrições operacionais, de HW e SW.
Equações COCOMO Básico
E = ab(KLOC) exp (bb)
D = cb(E exp(db)
onde E é o esforço aplicado em pessoa-mês, D é o tempo de desenvolvimento em meses e KLOC é o número estimado
de linhas de código do projeto expresso em milhares.
Coeficientes ab e cb e os expoentes bb e db:
Projeto de SW ab bb cb db
Orgânico 2,4 1,05 2,5 0,38
Semidestacado 3,0 1,12 2,5 0,35
4 Categorias para Modelo Básico
(Boehm)
1. Atributos do produto
a. Confiabilidade exigida do SW
b. Tamanho do banco de dados da aplicação c. Complexidade do produto
2. Atributos do HW
a. Restrições ao desempenho de run-time b. Restrições de memória
c. Volatilidade do ambiente de máquina virtual
4 Categorias para Modelo Básico
(Boehm) - continuação
3. Atributos do Pessoal a. Capacidade de análise b. Capacidade em engenharia de SW c. Experiência em aplicaçõesd. Experiência em máquina virtual
e. Experiência em linguagens de programação
4. Atributos de projeto
a. Uso de ferramentas de SW
b. Aplicação de métodos de engenharia de SW
COCOMO Intermediário
E = ai(LOC) exp(bi) x EAF
onde E é o esforço aplicado em pessoas-m~es e LOC é o número estimado de linhas de código para o projeto.
Coeficientes ai e os expoentes bi:
Projeto de SW ai bi
Orgânico 3,2 1,05
Semidestacado 3,0 1,12
