Pular para o conteúdo principal

Planejamento e Gerenciamento de Projetos de Software

Quase todas as atividades que desempenhamos precisam ser planejadas e gerenciadas. Atividades de engenharia requerem um planejamento cuidadoso. Normalmente, os produtos são complexos, com muitas partes envolvidas, e as atividades são realizadas por um grupo muito grande de pessoas.

Na engenharia de software não é diferente. Um projeto de engenharia de software deve estar baseado em um planejamento para que se possa gerenciar adequadamente a sua realização.

Planejamento

Planejar é estimar quais as atividades deverão ser realizadas; quem deverá realizá-las; quando devem ser realizadas e finalizadas; e quanto elas deverão custar. Tudo isto requer a elaboração de estimativas em relação ao número e à dimensão dos artefatos, do número de pessoas necessárias, dos prazos e dos custos.

Para isto, a atividade de planejamento deverá resultar:

  • Na realização de estimativas
  • Na elaboração da estrutura de divisão do trabalho (WBS – Work Breakdown Structure)
  • Na definição da equipe e demais recursos
  • Na alocação de pessoa-atividade
  • Na elaboração do cronograma
  • Na elaboração do orçamento

Além disso, a análise de riscos e as revisões periódicas do plano são fundamentais para garantir que ele seja cumprido.

O planejamento está diretamente ligado ao processo de software. Conforme dissemos anteriormente, um processo de software é resultado do planejamento associado a um modelo de processo (método). O modelo de processo indica quais atividades devem ser realizadas e qual a dependência entre elas. Por exemplo, no modelo cascata, deve-se especificar os requisitos, desenhar a arquitetura, fazer o design detalhado, implementar as unidades, integrar as unidades e, finalmente, entregar o software. O planejamento deve indicar quem faz estas atividades, quanto tempo é necessário para eles, quando elas serão realizadas e quanto custará cada um delas.

Sem um planejamento adequado, os desenvolvedores não saberão o que fazer e não terão datas para iniciar ou terminar o trabalho. Sem estimativas, o responsável pelo planejamento não terá como dimensionar o tamanho e a quantidade dos artefatos a serem produzidos e o esforço necessário para produzi-los. Por fim, sem um orçamento, não se terá noção quanto o software irá custar e se haverá recursos para o desenvolvimento.

Gerenciamento

Gerenciar é fazer cumprir o que foi planejado. O papel do gerente de projetos de software é coordenar a equipe, controlar a produção dos artefatos, fazer cumprir prazos e custos, analisar métricas de produção.

O gerenciamento de software está diretamente ligado à garantia da qualidade do processo e do produto de software. O uso de métricas de qualidade, tanto do produto como do processo, são fundamentais para o gerenciamento. Com base em métricas, o gerente tem condições de avaliar se o planejamento está sendo cumprido ou não. Neste caso, as métricas podem apontar as causas dos problemas e permitir as revisões no planejamento.

Exemplos de métricas do produto utilizadas no planejamento são: tamanho do software em linha de código fonte; número de pontos-de-função; número de diagramas de arquitetura; números de defeitos; entre outras.

Exemplos de métricas de processo utilizadas no planejamento são: o esforço; a produtividade; entre outras.

Plano de Projeto de Software

O resultado de um plano de projeto de software é um documento contendo a equipe, o WBS, a alocação pessoa-tarefa, a análise de riscos, o cronograma, o orçamento entre outros.

A estrutura de um plano de projeto de software, segundo Ian Sommerville (2004) é a seguinte.

  1. Introdução
  2. Organização de projeto
  3. Análise de riscos
  4. Requisitos necessários de hardware e software
  5. Estrutura analítica de trabalho
  6. Cronograma de projeto
  7. Mecanismos de monitoramento e elaboração de relatórios

Esta estrutura pode variar de acordo com as características do projeto.

Diversos outros documentos podem complementar informações importantes:

  • Plano de qualidade – descreve os procedimentos de testes de qualidade que serão utilizados.
  • Plano de validação – descreve a abordagem, os recursos e o método utilizados pa validação.
  • Plano de manutenção – prevê requisitos, custos e esforço necessário para a manutenção.
  • Plano de desenvolvimento da equipe – descreve como as habilidades e a experiência serão desenvolvidas.
Veja mais em nosso slides.

Referência

Ian Sommerville - Engenharia de Software

Comentários

Anônimo disse…
Ai blz.. gostei de mais do seu blog principalmente do material escrito show de bola...

Mas um dos itens que mais queria rs sempre é assim oque mais nos chama atenção sempre da errado.. acho que é a lei de lei de murphy

Em
Planejamento e Gerenciamento de Projetos de Software

o Link dos slides ta com erro

http://www.dimap.ufrn.br/%7Ejair/ES/slides/PlanejamentoGerenciamentoIntroducao.pdf

Ai valeu mesmo. caso tenha como arrumar tal material favor me avisar ou mandar via email

chberta@gmail.com

T+
Jair C Leite disse…
O problema já está resolvido. Podem baixar o arquivo clicando o link.

Postagens mais visitadas deste blog

O Modelo Espiral

O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele as principais características dos modelos vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata. Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão utilizados no produto final, etc.

O Modelo Evolutivo

O modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de forma a evoluir a partir de protótipos iniciais. Para entender melhor este modelo é importante entender o que é prototipação (ou prototipagem). Prototipação é uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Esta abordagem envolve a produção de versões iniciais - "protótipos" - de um sistema futuro com o qual pode-se realizar verificações e experimentações para se avaliar algumas de suas qualidades antes que o sistema venha realmente a ser construído. Objetivos da Prototipação Num projeto de software várias questões podem ser respondida com a construcão de protótipos. Nas situações típicas de desenvolvimento podemos distinguir entre diferentes objetivos na prototipação: Exploratória - é quando o protótipo é usado para ajudar a esclarecer requisitos dos usuários com respeito ao sistema futuro. Uma prototipação também é exploratória

Sistemas Computacionais

Um sistema computacional (ou baseado em computador) é aquele que automatiza ou apóia a realização de atividades humanas através do processamento de informações. Um sistema baseado em computador é caracterizado por alguns elementos fundamentais. Hardware Software Informações Usuários Procedimentos ou Tarefas Documentação O hardware corresponde às partes eletrônicas e mecânicas (rígidas) que possibilitam a existência do software, o armazenamento de informações e a interação com o usuário. A CPU, as memórias primária e secundária, os periféricos, os componentes de redes de computadores, são exemplos de elementos de hardware. Um único computador pode possibilitar a existência de diversos sistemas e um sistema pode requisitar diversos computadores. O software é a parte abstrata do sistema computacional que funciona num hardware a partir de instruções codificadas numa linguagem de programação. Estas instruções permitem o processamento e armazenamento de informações na for