Engenharia de Software
Prof. Wilkerson de L. Andrade
Versão resumida e traduzida dos slides originais produzidos por Ian Sommerville,
Software Engineering, 7th edition. Chapter 5.
Estes slides foram adaptados dos slides gentilmente cedidos pela professora
Patrícia D. L. Machado (DSC/UFCG).
•
Gerenciamento de atividades para assegurar
que software é entregue dentro do tempo e
orçamento previstos e de acordo com os
requisitos das organizações envolvidas no
desenvolvimento e suprimento.
•
É necessário, pois desenvolvimento de
software está sempre sujeito a restrições de
tempo e orçamento definidas pelas
organizações envolvidas.
Gerenciamento de Projeto de
Software
•
O produto é intangível.
•
O produto é flexível.
•
Engenharia de Software não é reconhecida
como uma disciplina de engenharia, com o
mesmo status de outras engenharias.
•
O processo de desenvolvimento de software
não é padronizado.
•
Muitos projetos de software são únicos,
diferentes de projetos anteriores.
Diferenciais no Gerenciamento
de Projeto de Software
•
Elaboração de Propostas;
•
Planejamento e programação de projetos;
•
Levantamento de custos do Projeto;
•
Monitoramento e revisões de projeto;
•
Seleção e Avaliação de Pessoal;
•
Elaboração de relatórios e apresentação.
•
Estas atividades não são particulares do
gerenciamento de software.
•
Muitas técnicas de gerenciamento de
projetos de engenharia são aplicáveis.
•
Sistemas de engenharia tecnicamente
complexos tendem a enfrentar os mesmos
problemas de sistemas de software.
Comuns no Gerenciamento
Convencional
Pessoal
•
Pode não ser possível alocar as pessoas
ideais para trabalhar em um projeto:
▫
Restrições de orçamento
▫
Indisponibilidade de pessoas com a experiência
adequada
▫
Necessidade de desenvolver habilidades de
empregados em um projeto de software
•
Gerentes têm que trabalhar com estas
restrições especialmente na falta de pessoal
treinado.
Planejamento de Projeto
•
Atividade que consome mais tempo no
gerenciamento de projeto
•
Atividade contínua desde a concepção inicial
do sistema até a sua entrega. Planos devem
ser regularmente revisados a medida que
novas informações são disponibilizadas.
•
Diferentes tipos de planos podem ser
desenvolvidos para dar suporte ao plano
geral do projeto do software que é focado em
custos e orçamento.
Tipos de Planos de Projeto
Plano de qualidade
Plano de validação
Plano de gerenciamento
de configuração
Plano de manutenção
Plano de pessoal
Descreve os procedimentos e padrões de qualidade
que serão usados no projeto. Veja o capítulo 27.
Descreve as técnicas, recursos e escalonamento usados
para a validação do sistema. Veja o capítulo 22.
Descreve os procedimentos de gerência de configuração
e recursos que serão utilizados. Veja capítulo 29.
Prevê requisitos de manutenção do sistema, assim
como custo e esforço requerido. Veja capítulo 29.
Descreve como as habilidades e experiências da
equipe serão desenvolvidos. Veja capítulo 25.
Processo de Planejamento de
Projeto
Estabelecer restrições do projeto (
data, pessoal, orçamento, etc
)
Fazer avaliação inicial dos parâmetros do projeto (
estrutura, tamanho, etc
)
Definir marcos (milestones) e produtos de entrega (deliverables)
Enquanto o projeto não estiver concluído ou for cancelado repita
Faça o cronograma do projeto
Inicie as atividades de acordo com o cronograma
Espere (por algum tempo)
Revise o progresso do projeto
Revise estimativas dos parâmetros do projeto
Atualize o cronograma do projeto
Re-negocie restrições do projeto e produtos de entrega
Se problemas surgirem então
Inicie revisão técnica
fim se
O Plano de Projeto
•
Define:
▫
Recursos disponíveis ao projeto;
▫
Detalhamento do trabalho;
Estrutura do Plano de Projeto
•
Introdução.
•
Organização do Projeto.
•
Análise de Riscos.
•
Requisitos de Recursos de Hardware e
Software.
•
Detalhamento do trabalho
(definição/organização de atividades).
•
Programação do Projeto.
•
Mecanismos de monitoramento e elaboração de
Organização de Atividades
•
Atividades em um projeto devem ser
organizadas para produzir saídas tangíveis para
que o gerenciamento possa julgar o processo.
• Milestones
representam o fim de um atividade
do processo.
• Deliverables
são resultados do projeto
entregues a clientes.
•
O processo cascata torna possível uma
definição direta de progresso em termos de
Milestones em um processo de
Engenharia de Requisitos
Estudo do design Análise de requisitos Desenvolvimento de protótipo Especificação de requisitos Estudo de viabilidade Relatório de viabilidade Requisitos Do usuário Relatório De avaliação Design arquitetural Requisitos Do sistemaAtividades
Milestones
Programação de um Projeto
•
Dividir o projeto em tarefas e estimar tempo e
recursos necessários a completar cada uma.
•
Organizar tarefas de forma concorrente a fim de
otimizar o uso de força de trabalho.
•
Minimizar dependências de tarefa para evitar
atrasos causados por uma tarefa esperando
que outra termine para iniciar.
•
Dependente da intuição e experiência de
Processo de Programação de um
Projeto
Identificar atividades Identificar Dependências de atividades Estimar recursos para atividades Alocar pessoas nas atividades Criar gráficos E diagramas do projeto Diagramas em Barra e de Atividades Requisitos Do softwareProblemas na Programação
•
Estimar a dificuldade de problemas e os custos
de desenvolver uma solução complexa.
•
Produtividade não é proporcional ao número de
pessoas envolvidas em uma tarefa.
•
Adicionar pessoas ao projeto em fase de
conclusão pode causar problemas de
comunicação.
•
O inesperado sempre acontece: tenha sempre
Gráficos de Barra e Redes de
Atividade
•
Notações gráficas usadas para ilustrar a
programação de projetos.
•
Mostrar a organização de tarefas do projeto.
▫
Tarefas não devem ser muito pequenas.
Usualmente 1 ou 2 semanas.
•
Gráficos de atividade mostram:
▫
Dependências entre tarefas e o caminho crítico.
▫
Programação das mesmas de acordo com o
Duração de Tarefas e
Dependências
Activity
Duration (days)
Dependencies
T1
8
T2
15
T3
15
T1 (M1)
T4
10
T5
10
T2, T4 (M2)
T6
5
T1, T2 (M3)
T7
20
T1 (M1)
T8
25
T4 (M5)
T9
15
T3, T6 (M4)
T10
15
T5, T7 (M7)
T11
7
T9 (M6)
T12
10
T11 (M8)
Rede de Atividades
star t T2 M3 T6 Finish T10 M7 T5 T7 M2 T4 M5 T8 4/7 /03 8 da y s 1 4/7 /03 15 da y s 4/8/03 15 da y s 2 5/8/03 7 da y s 5/9/03 10 da ys 19/9/03 15 da y s 11/8/03 2 5 da y s 10 da y s 2 0 da y s 5 da y s 2 5/7 /03 15 da y s 25/7 /03 1 8/7 /03 10 da y s T1 M1 T3 T9 M6 T11 M8 T12 M4Linha de Tempo de Atividades
4/7 11/7 18/7 2 5/7 1/8 8/8 1 5/8 22/8 2 9/8 5/9 12/9 1 9/9 T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Star t FinishAlocação de Pessoal
4/7 1 1/7 18/7 2 5/7 1/8 8/8 15/8 2 2/8 2 9/8 5/9 1 2/9 19/9 T4 T8 T11 T12 T1 T3 T9 T2 T6 T10 T7 T5 Fred Jane Anne Mary JimGerenciamento de Riscos
•
Identificação de riscos e planos para
minimizar seu efeito em um projeto.
•
Um risco é uma probabilidade de que
alguma circunstância adversa irá ocorrer:
▫
Riscos de Projeto afetam cronograma e recursos;
▫
Riscos de Produto afetam a qualidade ou
performance do software sendo desenvolvido;
Riscos de Software
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule.
Requirements change Project and product
There will be a larger number of changes to the requirements than anticipated.
Specification delays Project and product
Specifications of essential interfaces are not available on schedule
Size underestimate Project and product
The size of the system has been underestimated.
CASE tool under-performance
Product CASE tools which support the project do not perform as anticipated
Technology change Business The underlying technology on which the system is built is superseded by new technology.
Product competition Business A competitive product is marketed before the system is completed.
Saída de pessoal Membros experientes sairão do projeto antes da conclusão Mudança de
gerenciamento
Existirão mudanças de
Gerenciamento com diferentes prioridades Hardware não
disponível Hardware essencial para o projeto não estará disponível Mudança de
requisitos Haverá muitas mudanças inesperadas de requisitos Especificação
Não disponível
Especificações de interfaces essenciais não estarão disponíveis por atraso ou problemas técnicos
Tamanho do projeto é
maior que o esperado O tamanho do projeto foi mal estimado e é maior que o esperado Ferramentas CASE
com baixa performance
Ferramentas CASE que dão suporte ao projeto não Se comportam como esperado
Mudança de tecnologia
Tecnologia escolhida para desenvolver o sistema é Substituída por nova tecnologia mais robusta Competitividade
Do produto
Um produto competitivo inicia estratégia de marketing Antes da finalização do sistema
Processo de Gerenciamento de
Riscos
•
Identificação de Riscos
▫
Projeto, produto e negócio
•
Análise de Riscos
▫
Avaliar a possibilidade de ocorrência e as
conseqüências associadas a estes riscos
•
Planejamento de Riscos
▫
Planos para evitar ou minimizar o efeito dos
riscos
•
Monitoração de Riscos
Processo de Gerenciamento de
Riscos
Identificação do risco Análise de risco Planejamento sobre riscos Monitoramento de riscos Lista de potenciais riscos Lista de riscos prioritários
Evitar riscos, planos de contingência
Avaliação de riscos
Riscos e Tipos de Riscos
O banco de dados usado não suporta tantas transações
por segundo como esperado.
É impossível contratar pessoal com as qualificações necessárias.
Profissionais importantes não estão disponíveis em momentos críticos.
Treinamento necessário para o pessoal não está disponível.
Reestruturação da organização faz com que diferentes grupos de
gerenciamento sejam responsáveis pelo projeto.
Problemas financeiros da empresa força redução na verba destinada ao projeto.
O código gerado por ferramentas CASE é ineficiente.
Ferramentas CASE não podem ser integradas.
Mudanças de requisitos que implicam em mudanças
no design são propostas.
O tempo estimado para o desenvolvimento do software é insuficiente.
A taxa estimada sobre reparo de defeitos é menor que a taxa real.
O tamanho estimado do software é menor que o tamanho real.
Tecnologia
Pessoal
Organização
(empresa)
Ferramentas
Requisitos
Estimativas
Análise de Riscos
Problemas financeiros da empresa força redução na verba destinada ao projeto.
É impossível contratar pessoal com as qualificações necessárias para o projeto.
Profissionais importantes não estão disponíveis em momentos críticos.
Componente de software que deve ser reusado possui defeitos que limita sua funcionalidade.
Mudanças de requisitos que implicam em mudanças no design são propostas.
Reestruturação da organização faz com que diferentes grupos de gerenciamento sejam
responsáveis pelo projeto.
Risco Probabilidade Efeitos
Catastrófico Catastrófico Sério Sério Sério Sério Baixo Alto Moderado Moderado Moderado Alto
Estratégias de Gerenciamento de
Risco
Preparar um breve documento, para gerenciamento, que mostra as importantes contribuições do
projeto para os objetivos do negocio.
Alertar o cliente sobre potenciais dificuldades e
possibilidades de atraso. Investigar componentes para reuso.
Reorganizar pessoal para que haja horários em comum e para que cada um conheça e entenda o trabalho dos outros.
Substituir componentes com possibilidade de defeitos por outros com confiabilidade conhecida, normalmente comprados. Problemas financeiros
da organização
Problemas de Gerenciamento
Problemas de saúde entre membros da equipe
Componentes defeituosos
Indicadores de Riscos
Risk type
Potential indicators
Techno logy
Late delivery of hardware or support software, many reported
techno logy problems
People
Poor staff morale, poor relationships amongst team member,
job availability
Organisational
Organisational gossip, lack o f action by senior manage ment
Tools
Reluctance by team members to use tools, complaints about
CASE tools, demands for high er-powered workstations
Requirements
Many requirements change requests, customer complaints
Estimation
Failure to meet agreed schedule, failure to clear reported
defects
Entrega atrasada de hardware ou software de suporte, muitos problemas diagnosticados com tecnologias.
Membros com dificuldade de relacionamento com outros membros da equipe, membros com outras oportunidade de emprego.
Especulação empresarial, conjunto de ações da gerência. Pessoal sem interesse de usar ferramentas, reclamações sobre
ferramentas CASE, demanda de estações de alto desempenho Muitos pedidos de mudança de requisitos, reclamações do cliente.
Falha ao distribuir tarefas, falha ao corrigir defeitos encontrados. Tecnologia Pessoal Organizacional Ferramentas Requisitos Estimativas
