- Diferenças entre gerenciamento de projetos de software e outros tipos gerenciamento
- Principais tarefas dos gerentes de software
- planejamento do projeto
- representações gráficas: diagramas de barras, diagramas de atividades
- processo de gerenciamento de riscos
Diferenças entre gerenciamento de projetos de software e outros tipos de gerenciamento
O software é intangível
cada software desenvolvido é um software diferente ( grandes projetos são frequentemente únicos)
O plano inicial de software é realizado e vai sendo melhorado de acordo com novas informações sobre o planejamento do software.
O plano de projeto deve ter
struct planoDeProjeto{
introdução
organização do projeto
análise de riscos
requisitos de software e hardware
estrutura analítica
programação do projeto
mecanismos de monitoramento.
}
1-as restrições entram na introdução.
2-as pessoas, papéis e equipes entram em organização do projeto
3-todas as fases, atividades e pacotes de trabalho ( o nível mais baixo da EAP) estão da Estrutura Analítica do Projeto ( EAP).
4- Isso é importante. A programação do projeto, isso é, as atividades, a dependência e o tempo estimado para ela terminar devem estar na programação do projeto.
No planejamento do software temos:
Definições das restrições ( orçamento, prazo )
Avaliação inicial dos parâmetros do projeto
Definição dos marcos e atividades
Enquanto o projeto não é terminado ou não é cancelado {
Faça a programação do projeto "fazerProgramacaoProjeto()"
Inicie as atividades de acordo com a programação
wait( )
Examine o progresso do projeto
Atualize a programação do projeto
Reanalise as restrição dos projetos e dos produtos a serem entregues
se surgirem problemas então {
inicie uma avaliação técnica
}
}
Se isso fosse um algoritmo de verdade a parte de programação de projeto seria um método/subprograma/função/procedimento que poderia ter a seguinte estrutura
fazerProgramaçãoProjeto(){
}
Um conceito importante é atividade. O processo de desenvolvimento de um software deve ser decomposto em atividades. As atividades não devem ser muito longas. Devem durar pelo menos uma semana e no máximo de 8 a 10 semanas ( É bom guardar isso para entrar com recurso).
UM MARCO É UM PONTO FINAL DE UMA ATIVIDADE.
Cada atividade deve ter uma saída formal, como um relatório, um gráfico, um diagrama UML, um protótipo, qualquer coisa TANGÍVEL que mostre que o povo não ficou esse todinho ocioso. NÃO PRECISA SER NECESSARIAMENTE UM SOFTWARE.
Quando se faz a estimativa de tempo de uma atividade, deve-se levar em conta também que alguma coisa inesperada pode acabar acontecendo. Geralmente pega-se o tempo de atividade e se acrescenta 30% para coisas eventuais que podem acontecer e mais 20% para coisas desconhecidas que venham a acontecer.
O recurso principal para o desenvolvimento de software é o esforço humano requerido.
Diagramas utilizados para PROGRAMAÇÃO DO PROJETO, que faz parte do PLANO de PROJETO, que tem ( introdução, organização do projeto, análise de requisitos, requisitos de hardware e software, estrutura analítica, programação do projeto e mecanismos de monitoramento)
Alguns programas utilizados no gerenciamento de projetos:
- Microsoft Project
- DotProject
- TRAC
- Project Builder
- Red Mine
Diagrama de Barras e Diagrama de Redes
Geralmente esses diagramas são gerados automagicamente pelo programa utilizado no gerenciamento de projetos (exemplos: M. Project, DotProject, TRAC, Red Mine e Project Builder)
Abaixo tem-se um diagrama de redes onde os quadrados são as atividades e as elipses são os marcos.
O diagrama de redes também pode ser chamado de Diagrama de PERT, e o diagrama de barras pode ser chamado de Diagrama de Gantt.
Note que o projeto demora tanto quanto seu caminho mais longo, ou ainda, caminho crítico.
Análise de Riscos
Podem ser riscos relacionados ao PROJETO, PRODUTO e NEGÓCIO.
Porém essa não é uma classificação exclusiva.
Riscos Relacionados ao Projeto.
1 -(PROJETO) riscos que afetam a programação ( aquele monte de gráfico em barras e redes de atividade) ou os recursos alocados ao projeto.
2- (PRODUTO) riscos que afetam a qualidade do produto sendo desenvolvido.
3- (NEGÓCIO ou ORGANIZAÇÃO) A organização falir, por exemplo.
Mas isso na prática não vale muita coisa. É só porque a Enrolação de Software e a Godelagem de TI gostam de passar o dia classificando as coisas achando que estão trabalhando. Ohh jeito fácil de ganhar dinheiro...
Por exemplo, se um bom programador sai de uma empresa. Pode ser um risco para o projeto, porque a entrega do sistema pode atrasar ( PROJETO ), pode ser um risco para o produto, porque o produto pode ter a qualidade minimizada porque o novo programador não sabe programar tão bem quanto o antigo (PRODUTO, QUALIDADE), e o risco para a organização porque perdeu um programador que levou anos para chegar em um nível que organização precisava. Bem feito, porque só pagava R$ 700,00 ao programador (Organização).
Note que os riscos os riscos são constantemente reavaliados.
Identificação dos Riscos.
- Levantar os riscos. Porém nessa fase não há uma priorização desses riscos.
Riscos, além de serem classificdos quanto ao Produto, Projeto e Negócio, também podem ser classificados:
- quanto a tecnologia ( O SGBD pode não ser tão rápido quanto esperado. Mexer com multithreads em LUA pode ser tremendamente desgastante)
- quanto ao pessoal ( Não é possível recrutar pessoal com a habilidade requerida )
- quanto a organização ( Escândalos, corrupção, sujeira para todo lado)
- quanto as ferramentas ( o compilador utilizado, por exemplo, gera código ineficiente... ou então uma ferramenta CASE de geração de esquema de SGBD pode gerar esquemas sebosos)
- quanto aos requisitos ( Esse é o que mais acontece... mudança de requisitos. )
- quanto a estimativa ( Vish, esse acontece demais também... o tempo requerido para desenvolver um software é subestimado)
- Análise dos riscos. Agora sim... Vamos analisar que riscos são esses e priorizar eles.
Planejamento dos Riscos
Opa, identificamos o risco, sabemos que tipo de risco ele é ( tecnologia, pessoal, ferramentas, organização, requisitos ou estimativa), analisamos e agora sabemos sua priorização e seu impacto para a organização, então vamos traçar planos para lidar com esses riscos, diminuindo a probabilidade deles ocorrerem, minimizando seus impactos ou então caso o pior aconteça você esteja preparado para o pior.
No comments:
Post a Comment