Engenharia de Software
Planeamento e Gestão de Projectos
Hélia Guerra
Departamento de Matemática
Universidade dos Açores
[email protected]
cronograma do projecto
• É usual que os clientes queiram respostas para as
seguintes perguntas
• Percebe os problemas e as minhas necessidades?
• É capaz de desenhar um sistema que resolva os meus
problemas e satisfaça as minhas necessidades?
• Quanto tempo demorará?
• Quanto custará?
2
cronograma do projecto
• O cronograma do projecto descreve o ciclo de
desenvolvimento do software
– enumerando as etapas do processo
– dividindo cada etapa em tarefas/actividades
discretas para serem executadas
• Considera as interações entre as actividades e estima a
duração de cada actividades, indicando as datas
planeadas para a sua realização
3
cronograma do projecto
• Ajuda a perceber as necessidades do cliente através da
listagem de todas as entregas
–Documentos
–Demonstrações de funções, subsistemas, fiabilidade,
desempenho e segurança
• Determina os marcos (milestones) e actividades para
produzir as entregas
4
marcos e actividades
• Actividade: tem lugar durante um período de tempo
• Marco: completação de uma actividade -- um ponto
particular no tempo
• Percursor: evento (ou conjunto de) que tem que
ocorrer para que uma actividade se inicie
• Duração: período de tempo necessário para
completar uma actividade
• Data de término: data em que uma actividade fica
pronta
5
cronograma do projecto
• O desenvolvimento de um projecto pode ser separado
em sucessivas fases, cada uma das quais composta por
passos que são compostos por actividades
6
Wbs e grafos de actividade
• Estrutura de Decomposição de Trabalho (Work
Breakdown Structure - WBS) é o processo de dividir o
projecto em tarefas manuseáveis e de as ordenar
logicamente, com o objectivo de assegurar uma
evolução suave entre elas
• Grafos de actividade mostram as dependencias entre as
actividades
–Vértices: marcos
–Arestas: actividades envolvidas
• Os grafos de actividade podem ter pesos com
informação sobre a duração7 das actividades
critical path method (cpm)
• É o menor tempo para completar um projecto
–Revela as actividades mais críticas que condicionam a
entrega do projecto a tempo
• Tempo real: duração estimada para a actividade
terminar
• Tempo disponível: tempo disponível na
calendarização para que a actividade seja completada
• Tempo de folga: diferença entre o tempo disponível e
o tempo real para a actividade
8
critical path method (cpm)
• Caminho crítico:
- a folga em cada nó é zero.
–a folga em cada vértice é zero
–não é único
• tempo de folga = tempo disponível – tempo real
= data de início mais tarde – data de início mais cedo
9
gráficos de gantt
• Representação gráfica do projecto que mostra cada
actividade como uma barra horizontal de comprimento
proporcional ao seu tempo de duração
10
histograma de recursos
• Mostra as pessoas que estão afectas ao projecto e as que
são necessárias para cada etapa do ciclo de vida
11
curva das despesas
12
equipa de desenvolvimento
actividades
–análise de requisitos
–desenho do sistema
–desenho do programa
–escrita do programa
–testes
–treino
–manutenção
–garantia da qualidade
• Há vantagens em afectar responsabilidades diferentes a
pessoas diferentes
13
equipa de desenvolvimento
escolha dos membros
• Capacidade para executar o trabalho
• Interesse no trabalho
• Experiência com aplicações, técnicas, linguagens,
ambientes de desenvolvimento similares
• Treino
• Capacidade para comunicar com os outros
• Capacidade para partilhar responsabilidades
14
EQuipa de desenvolvimento
Comunicação
• O desenvolvimento de um projecto é afectado por
–grau de comunicação
–capacidade de cada pessoa expressar as suas ideias
• Muitas falhas de software resultam de comunicação e
entendimento deficientes
15
EQuipa de desenvolvimento
Comunicação
• Para n pessoas no projecto existem n(n-1)/2 pares de
possíveis comunicações
16
reuniões (defeitos)
(Dressler 1995)
– objectivo pouco claro
– participantes não estão preparados
– elementos fundamentais chegam atrasados ou não comparecem
– a conversa desvia-se do objectivo
– participantes não discutem, apenas argumentam
– decisões tomadas não são implementadas
17
reuniões mais produtivas
(Dressler 1995)
– decidir bem quem deverá estar presente na reunião
– fazer uma agenda
– ter alguém a moderar as discussões
– ter alguém responsável por colocar em práticas as medidas
tomadas na reunião
– minimizar o número de reuniões e de participantes
18
estilos de trabalho
• Extrovertido: transmite os seus pensamentos
• Introvertido: pede sugestões
• Intuitivo: baseia as decisões em sentimentos
• Racional: baseia as decisões em factos e opiniões
19
estilos de comunicação e
de decisão
20
estilos de trabalho
• O estilo de trabalho determina o estilo de comunicação
• Afecta a interação entre clientes, equipa de
desenvolvimento e utilizadores
21
organização do projecto
• Depende de
– conhecimentos e estilo de trabalho dos membros da
equipa
– número de pessoas na equipa
– gestão de estilos dos clientes e da equipa de
desenvolvimento
22
organização do projecto
Chief Programmer Team
–uma única pessoa (chefe ou líder) é responsável pelo
desenvolvimento do trabalho e pela coordenação do
trabalho dos restantes membros da equipa
–Cada membro da equipa comunica com frequencia com o
chefe mas não necessariamente com os outros membros
23
organização do projecto
egoless( Democrática ou plana)
–Não tem líder e todos os membros da equipa têm o
mesmo nível de responsabilidade
–todos os assuntos são votados democraticamente
– o código é partilhado por todos
24
organização do projecto
• Que modelo de organização se deve escolher?
• Fazer uma boa gestão de projecto significa encontrar o
equilibrio entre a estrutura e a criatividade
25
estimação de custos
• A estimação de custos é um dos aspectos essenciais no
planeamento e na gestão do projecto
• Tipos de custos
–facilidades: espaço, hardware, mobiliário, telefone,
papel, etc
–métodos e ferramentas: software, ferramentas CASE
–pessoal (esforço): a maior componente dos custos
• A estimação de custos deve ser feita durante o ciclo de
vida do projecto, o mais cedo possível
26
estimação de custos
(Boehm 1995)
• A incerteza logo no início do projecto pode afectar as
estimativas de custos e da dimensão do projeto
27
causas de uma estimação
deficiente (Lederer e Prasad 1992)
• Pedidos frequentes de alteração de requisitos
• Pouca atenção prestada nas tarefas
• Utilizadores não percebem os requisitos
• Análise insuficiente ao fazer a estimativa
• Falta de coordenação entre os membros da equipa no
processo de desenvolvimento do sistema
• Falta de orientação ou de método adequado para
efectuar a estimativa
28
factores que influenciam a
estimação
–Complexidade do sistema proposto
–Integração com outros sistemas já existentes
–Complexidade do programa
–Dimensão do sistema em termos de número de
funções ou de programas
–Capacidade dos membros da equipa
–Experiencia dos membros da equipa com a aplicação,
a linguagem de programação e o hardware
–SGBD
–Número de elementos da equipa
29
estimação do esforço
abordagens
• Top-down
– A estimação é feita a partir do nível do sistema, tendo
em conta a funcionalidade total
• Bottom-up
– A estimação é feita a partir de uma decomposição do
sistema em componentes, adicionando a estimação
relativa ao desenvolvimento de cada componente
30
estimação do esforço
Tipo de métodos
• Experiência de peritos
– Técnica de Delphi
– Modelo de Wolverton
• Métodos algoritmicos: E = (a + bSc) m(X)
– Walston e Felix
– Bailey e Basili
– Construtive Cost Model (COCOMO): versão
COCOMO II é a versão mais actual
• Aprendizagem automática
31
experiencia dos peritos
Top-down ou bottom-up
Analogia com outros projectos: pessimista (x),
optimista (y), média (z); estimação = (x + 4y + z)/6
Técnica de Delphi: baseda na média de valores
“secretos” estimados por peritos
32
modelo de wolverton
Considera existirem dois factores que influenciam a
produtividade: o problema ser conhecido (O) ou novo
(N) e o grau de dificuldade ser fácil (E) ou moderado
(M)
a dimensão de cada módulo é estimada pelo número
de linhas de código
Type of software
Control
Input/output
Pre/post processor
Algorithm
Data management
Time -critical
OE
21
17
16
15
24
75
OM
27
24
23
20
31
75
Difficulty
OH NE
30 33
27 28
26 28
22 25
35 37
75 75
NM
40
35
34
30
46
75
NH
49
43
42
35
57
75
33
modelo de waltson e felix
1. Customer interface complexity
Inclui um índice
de produtividade
na equação
E = 5,25 S^0,91
Considera
existirem 29
factores que
podem afectar a
produtividade ( 1
aumenta, 0
diminui)
2. User participation in requirements
definition
3. Customer -originated program
design changes
4. Customer experience with the
application area
5. Overall personnel experience
6. Percentage of development
programmers who participated in the
design of functional specifications
7. Previous experience with the
operational computer
8. Previous experience with the
programming language
9. Previous experien ce with
applications of similar size and
complexity
10. Ratio of average staff size to
project duration (people per month)
11. Hardware under concurrent
development
12. Access to development computer
open under special request
13. Acc ess to development computer
closed
14. Classified security environment
for computer and at least 25% of
programs and data
34
15. Use of structured programming
16. Use of design and code
inspections
17. Use of top -down development
18. Use of a chief programmer team
19. Overall complexity of code
20. Complexity of application
processing
21. Co mplexity of program flow
22. Overall constraints on program’s
design
23. Design constraints on the
program’s main storage
24. Design constraints on the
program’s timing
25. Code for real -time or interactive
operation or for execution under
severe time constraints
26. Percentage of code for delivery
27. Code classified as
nonmathematical application and
input/output formatting programs
28. Number of classes of items in the
database per 1000 lines of code
29. Number of pages of delivered
documentation per 1000 line s of code
modelo de bailey e basili
E = 5.5 + 0,73 S ^1,16
Cada valor na tabela é classificado entre ausente (0) a
muito importante (5)
Total methodology
(METH)
Tree charts
Top -down design
Cumulative complexity
(CPLX)
Customer interface
complexity
Application complexity
Formal documentation
Program flo w complexity
Chief programmer
teams
Formal training
Formal test plans
Internal communication
complexity
Database complexity
External communication
complexity
Customer -initiated
program design changes
Design forma lisms
Code reading
Unit development
folders
Cumulative experience
(EXP)
Programmer
qualifications
Programmer machine
experience
Programmer language
experience
Programmer application
experience
Team experience
35
cocomo II
A equação do esforço (E) calcula o número de pessoasmeses necessárias para o projecto
E = b S^c m(X), onde bS^c é o valor estimado inicial e
m(X) é o vector de informação cost driver
O modelo de custos tem três grandes etapas (protótipo
de interfaces, desenho, programação)
Assenta na premissa de que a “granulosidade do
modelo de estimação de custos precisa ser consistente
com a granulosidade da informação disponível para
suportar a estimação”(USC 1997)
36
cocomo ii
Pontos de aplicação calculados com base no número
de ecrãns e relatórios
For Screens
For Reports
Number and source of data tables
Number and source of data tables
Number of
Total < 4
Total < 8
Total 8+
Number of
Total < 4
Total < 8
Total 8+
views
(<2
(2-3
(>3
sections
(<2
(2-3
(>3
contained
server,
server,
server, >5
contained
server,
server, 3-
server,
<3
3-5
client)
<3
5 client)
>5
client)
client)
<3
simple
simple
medium
0 or 1
simple
simple
medium
3-7
simple
medium
difficult
2 or 3
simple
medium
difficult
Object type
client)
Simple
Medium
Screen
1
2
Report
2
5
8
3GL component
-
-
10
client)
Difficult
3
37
cocomo ii
Calcula o factor de produtividade com base na
experiencia e na capacidade de trabalho
Category
Very low
Low
Nominal
High
Very high
Meaning
Edit, code, debug
Simple front -end, back -end CASE, little integration
Basic life -cycle tools, moderately integrated
Strong, mature life -cycle tools, moderately
integrated
Strong, mature, proactive life-cycle tools, well integrated with processes, methods, reuse
38
modelo de aprendizagem com rede
neuronal
Rede neuronal utilizada por Shepperd para estimar o
esforço
Rede treinada com dados conhecidos de projectos
anteriores
39
gestão de riscos
• Um risco é um evento indesejado que causa prejuízo
–Impacto do risco: prejuízo associado ao risco
–Probabilidade do risco ocorrer
–Controlo do risco: o que se pode fazer para
minimizar o impacto do risco
–Exposição do risco = (prob. risco) x (impacto risco)
• Fontes de risco: genéricos e específico do projecto
40
Actividades de gestão de riscos
• Avaliar o risco
- Identificar o risco
- Analisar o risco
- Atribuir prioridade aos riscos
• Controlar o risco
- reduzir o risco
- planear a gestão do risco
- resolver o risco
41
os 10 maiores riscos
(Boehm et al. 1995)
1.Falhas na equipa
2.Cronogramas e orçamentos irrealistas
3.Desenvolvimento de funções incorrectas
4.Desenvolvimento interfaces incorrectas
5.Tentar a solução ideal
6.Alterações contínuas aos requisitos
7.Falhas nas tarefas subcontratadas
8.Falhas na reutilização de componentes
9.Falhas no desempenho em tempo real
10.Exceder a capacidade da 42tecnologia actual
Plano do projecto
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Âmbito do projecto
Cronograma do projecto
Organização da equipa de desenvolvimento
Descrição técnica do sistema
Procedimentos e standards do projecto
Plano de garantia de qualidade
Plano de gestão da configuração
Plano de documentação
Plano de gestão dos dados
Plano de gestão dos recursos
Plano de testes
Plano de treino
Plano de gestão dos riscos
43
Plano de manutenção
Resumo
• Conceitos importantes na gestão de projectos
–Planificação do projecto
–Estimação dos custos e cronograma
–Gestão dos riscos
–Organização da equipa
• A planificação do projecto envolve sugestões de todos
os membros da equipa
• Ao fazer o cronograma é preciso ter em conta que ao
aumentar a dimensão da equipa, as comunicações entre
os membros também aumentam
44