Gerenciamento de Projetos de Software

O padrão de trabalho de uma empresa de TI envolvida no desenvolvimento de software pode ser visto dividido em duas partes:

Criação de Software
Gerenciamento de Projetos de Software

Um projeto é uma tarefa bem definida, que é uma coleção de várias operações feitas para atingir um objetivo (por exemplo, desenvolvimento e entrega de software). Um projeto pode ser caracterizado como:

Cada projeto pode ter um objetivo único e distinto.
O projeto não é uma atividade de rotina ou operações do dia-a-dia.
O projeto vem com uma hora de início e uma hora de término.
O projeto termina quando seu objetivo é alcançado, portanto, é uma fase temporária na vida de uma organização.
O projeto precisa de recursos adequados em termos de tempo, mão de obra, finanças, material e banco de conhecimento.

Projeto de Software

Um Projeto de Software é o procedimento completo de desenvolvimento de software, desde a coleta de requisitos até o teste e manutenção, realizado de acordo com as metodologias de execução, em um período de tempo especificado para atingir o produto de software pretendido.

Necessidade de gerenciamento de projeto de software

O software é considerado um produto intangível. O desenvolvimento de software é uma espécie de fluxo totalmente novo no mundo dos negócios e há muito pouca experiência na construção de produtos de software. A maioria dos produtos de software é feita sob medida para atender aos requisitos do cliente. O mais importante é que a tecnologia subjacente muda e avança com tanta frequência e rapidez que a experiência de um produto pode não ser aplicada ao outro. Todas essas restrições de negócios e ambientais trazem riscos no desenvolvimento de software, portanto, é essencial gerenciar projetos de software com eficiência.

A imagem acima mostra restrições triplas para projetos de software. É uma parte essencial da organização de software entregar produtos de qualidade, mantendo o custo dentro do orçamento do cliente e entregar o projeto conforme programado. Existem vários fatores, internos e externos, que podem impactar este triângulo de três restrições. Qualquer um dos três fatores pode afetar severamente os outros dois.

Portanto, o gerenciamento de projetos de software é essencial para incorporar os requisitos do usuário junto com as restrições de orçamento e tempo.

Gerente de Projeto de Software

Um gerente de projeto de software é uma pessoa que assume a responsabilidade de executar o projeto de software. O gerente de projeto de software está totalmente ciente de todas as fases do SDLC pelas quais o software passaria. O gerente de projeto nunca pode se envolver diretamente na produção do produto final, mas ele controla e gerencia as atividades envolvidas na produção.

Um gerente de projeto monitora de perto o processo de desenvolvimento, prepara e executa vários planos, arranja os recursos necessários e adequados, mantém a comunicação entre todos os membros da equipe para tratar de questões de custo, orçamento, recursos, tempo, qualidade e satisfação do cliente.

Vamos ver algumas responsabilidades que um gerente de projeto tem -

Gerenciando pessoas

Atuar como líder do projeto
Ligação com as partes interessadas
Gestão de recursos humanos
Configurando hierarquia de relatórios, etc.

Gerenciando Projeto

Definição e configuração do escopo do projeto
Gerenciando atividades de gerenciamento de projetos
Monitorando o progresso e desempenho
Análise de risco em todas as fases
Tome as medidas necessárias para evitar ou resolver os problemas
Atuar como porta-voz do projeto

Atividades de gerenciamento de software

O gerenciamento de projetos de software compreende várias atividades, que incluem o planejamento do projeto, a decisão do escopo do produto de software, a estimativa de custo em vários termos, a programação de tarefas e eventos e o gerenciamento de recursos. As atividades de gerenciamento de projetos podem incluir:

Project Planning
Scope Management
Project Estimation

Planejamento de Projeto

O planejamento do projeto de software é uma tarefa executada antes do início da produção do software. Está lá para a produção de software, mas não envolve nenhuma atividade concreta que tenha qualquer conexão de direção com a produção de software; em vez disso, é um conjunto de vários processos, o que facilita a produção de software. O planejamento do projeto pode incluir o seguinte:

Gerenciamento do escopo

Ele define o escopo do projeto; isso inclui todas as atividades e processos que precisam ser realizados para que o produto de software seja entregue. O gerenciamento do escopo é essencial porque cria limites do projeto ao definir claramente o que seria feito no projeto e o que não seria. Isso faz com que o projeto contenha tarefas limitadas e quantificáveis, que podem ser facilmente documentadas e, por sua vez, evita o estouro de custos e tempo.

Durante o gerenciamento do escopo do projeto, é necessário -

Defina o escopo
Decida sua verificação e controle
Divida o projeto em várias partes menores para facilitar o gerenciamento.
Verifique o escopo
Controle o escopo incorporando mudanças no escopo

Estimativa de Projeto

Para uma gestão eficaz, uma estimativa precisa de várias medidas é uma obrigação. Com a estimativa correta, os gerentes podem gerenciar e controlar o projeto com mais eficiência e eficácia.

A estimativa do projeto pode envolver o seguinte:

Software size estimation
O tamanho do software pode ser estimado em termos de KLOC (Kilo Line of Code) ou calculando o número de pontos de função no software. As linhas de código dependem das práticas de codificação e os pontos de função variam de acordo com o usuário ou requisito de software.
Effort estimation
Os gerentes estimam os esforços em termos de necessidades de pessoal e horas de trabalho necessárias para produzir o software. Para estimativa de esforço, o tamanho do software deve ser conhecido. Isso pode ser derivado da experiência dos gerentes, dados históricos da organização ou tamanho do software podem ser convertidos em esforços usando algumas fórmulas padrão.
Time estimation
Uma vez que o tamanho e os esforços são estimados, o tempo necessário para produzir o software pode ser estimado. Os esforços necessários são separados em subcategorias de acordo com as especificações dos requisitos e a interdependência de vários componentes do software. As tarefas de software são divididas em tarefas, atividades ou eventos menores por Work Breakthrough Structure (WBS). As tarefas são agendadas no dia-a-dia ou em meses do calendário.

A soma de tempo necessária para concluir todas as tarefas em horas ou dias é o tempo total investido para concluir o projeto.
Cost estimation
Isso pode ser considerado o mais difícil de todos porque depende de mais elementos do que qualquer um dos anteriores. Para estimar o custo do projeto, é necessário considerar -

Tamanho do software
Qualidade de software
Hardware
Software ou ferramentas adicionais, licenças etc.
Pessoal qualificado com habilidades específicas para tarefas
Viagem envolvida
Communication
Treinamento e suporte

Técnicas de estimativa de projeto

Discutimos vários parâmetros que envolvem estimativa de projeto, como tamanho, esforço, tempo e custo.

O gerente de projeto pode estimar os fatores listados usando duas técnicas amplamente reconhecidas -

Técnica de Decomposição

Esta técnica pressupõe o software como um produto de várias composições.

Existem dois modelos principais -

Line of Code A estimativa é feita em nome do número de linhas de códigos no produto de software.
Function Points A estimativa é feita em nome do número de pontos de função no produto de software.

Técnica de Estimativa Empírica

Esta técnica usa fórmulas derivadas empiricamente para fazer estimativas. Essas fórmulas são baseadas em LOC ou FPs.

Putnam Model
Este modelo é feito por Lawrence H. Putnam, que é baseado na distribuição de frequência de Norden (curva de Rayleigh). O modelo de Putnam mapeia o tempo e os esforços necessários com o tamanho do software.
COCOMO
COCOMO significa COnstructive COst MOdel, desenvolvido por Barry W. Boehm. Ele divide o produto de software em três categorias de software: orgânico, semi-desanexado e incorporado.

Agendamento de Projeto

O agendamento do projeto em um projeto refere-se ao roteiro de todas as atividades a serem realizadas com a ordem especificada e dentro do intervalo de tempo alocado para cada atividade. Os gerentes de projeto tendem a definir várias tarefas e marcos do projeto e organizá-los mantendo vários fatores em mente. Eles procuram tarefas que estão no caminho crítico do cronograma, que são necessárias para serem concluídas de maneira específica (devido à interdependência das tarefas) e estritamente dentro do tempo alocado. A organização das tarefas fora do caminho crítico tem menos probabilidade de impactar em todo o cronograma do projeto.

Para agendar um projeto, é necessário -

Divida as tarefas do projeto em formas menores e gerenciáveis
Descubra várias tarefas e correlacione-as
Estimar o prazo necessário para cada tarefa
Divida o tempo em unidades de trabalho
Atribua um número adequado de unidades de trabalho para cada tarefa
Calcule o tempo total necessário para o projeto do início ao fim

Gestão de recursos

Todos os elementos usados para desenvolver um produto de software podem ser considerados como recursos para esse projeto. Isso pode incluir recursos humanos, ferramentas produtivas e bibliotecas de software.

Os recursos estão disponíveis em quantidade limitada e permanecem na organização como um conjunto de ativos. A escassez de recursos dificulta o desenvolvimento do projeto e pode atrasar o cronograma. A alocação de recursos extras aumenta o custo de desenvolvimento no final. Portanto, é necessário estimar e alocar recursos adequados para o projeto.

A gestão de recursos inclui -

Definir o projeto de organização adequado, criando uma equipe de projeto e atribuindo responsabilidades a cada membro da equipe
Determinar os recursos necessários em um determinado estágio e sua disponibilidade
Gerencie recursos gerando solicitações de recursos quando forem necessários e desalocando-os quando não forem mais necessários.

Gestão de Riscos do Projeto

A gestão de riscos envolve todas as atividades relativas à identificação, análise e provisão para riscos previsíveis e não previsíveis no projeto. O risco pode incluir o seguinte:

Equipe experiente saindo do projeto e nova equipe entrando.
Mudança na gestão organizacional.
Mudança de requisito ou requisito de interpretação incorreta.
Subestimação do tempo e recursos necessários.
Mudanças tecnológicas, mudanças ambientais, competição empresarial.

Processo de Gestão de Risco

Existem as seguintes atividades envolvidas no processo de gestão de risco:

Identification - Anote todos os riscos possíveis que podem ocorrer no projeto.
Categorize - Categorize os riscos conhecidos em alta, média e baixa intensidade de risco de acordo com seu possível impacto no projeto.
Manage - Analise a probabilidade de ocorrência de riscos nas várias fases. Faça um plano para evitar ou enfrentar riscos. Tente minimizar seus efeitos colaterais.
Monitor - Monitore de perto os riscos potenciais e seus primeiros sintomas. Monitore também os efeitos das medidas tomadas para mitigá-los ou evitá-los.

Execução e monitoramento do projeto

Nesta fase, as tarefas descritas nos planos do projeto são executadas de acordo com seus cronogramas.

A execução precisa de monitoramento para verificar se tudo está indo de acordo com o planejado. Monitorar é observar para verificar a probabilidade de risco e tomar medidas para lidar com o risco ou relatar o status de várias tarefas.

Essas medidas incluem -

Activity Monitoring - Todas as atividades programadas em alguma tarefa podem ser monitoradas no dia a dia. Quando todas as atividades em uma tarefa são concluídas, ela é considerada concluída.
Status Reports - Os relatórios contêm o status das atividades e tarefas concluídas em um determinado período, geralmente uma semana. O status pode ser marcado como concluído, pendente ou em andamento, etc.
Milestones Checklist - Cada projeto é dividido em várias fases onde as principais tarefas são realizadas (marcos) com base nas fases do SDLC. Esta lista de verificação de marcos é preparada uma vez a cada poucas semanas e relata o status dos marcos.

Gerenciamento de comunicação do projeto

A comunicação eficaz desempenha um papel vital no sucesso de um projeto. Ele preenche as lacunas entre o cliente e a organização, entre os membros da equipe, bem como outras partes interessadas no projeto, como fornecedores de hardware.

A comunicação pode ser oral ou escrita. O processo de gerenciamento de comunicação pode ter as seguintes etapas:

Planning - Esta etapa inclui a identificação de todas as partes interessadas no projeto e o modo de comunicação entre eles. Ele também considera se quaisquer recursos de comunicação adicionais são necessários.
Sharing - Depois de determinar vários aspectos do planejamento, o gerente se concentra em compartilhar as informações corretas com a pessoa certa no tempo certo. Isso mantém todos os envolvidos no projeto atualizados com o andamento do projeto e seu status.
Feedback - Os gerentes de projeto usam várias medidas e mecanismos de feedback e criam relatórios de status e desempenho. Esse mecanismo garante que a entrada de várias partes interessadas chegue ao gerente de projeto como feedback.
Closure - Ao final de cada grande evento, final de uma fase do SDLC ou do próprio projeto, é formalmente anunciado o encerramento administrativo para atualização de todas as partes interessadas por meio de envio de e-mail, distribuição de cópia impressa de documento ou outro meio de comunicação efetiva

Após o fechamento, a equipe passa para a próxima fase ou projeto.

Gerenciamento de configurações

O gerenciamento de configuração é um processo de rastreamento e controle das mudanças no software em termos de requisitos, design, funções e desenvolvimento do produto.

O IEEE o define como “o processo de identificar e definir os itens no sistema, controlando a mudança desses itens ao longo de seu ciclo de vida, registrando e relatando o status dos itens e solicitações de mudança e verificando a integridade e exatidão dos itens”.

Geralmente, uma vez que o SRS é finalizado, há menos chance de exigência de mudanças do usuário. Caso ocorram, as alterações são tratadas apenas com a aprovação prévia da alta administração, pois há possibilidade de estouro de custos e prazos.

Linha de base

Uma fase do SDLC é assumida se tiver uma linha de base, ou seja, a linha de base é uma medida que define a integridade de uma fase. Uma fase é definida como linha de base quando todas as atividades pertencentes a ela são concluídas e bem documentadas. Se não fosse a fase final, sua saída seria usada na próxima fase imediata.

O gerenciamento da configuração é uma disciplina da administração da organização, que cuida da ocorrência de qualquer mudança (processo, requisito, tecnológica, estratégica etc.) após uma fase ser definida. O CM verifica todas as alterações feitas no software.

Controle de mudança

O controle de alterações é função do gerenciamento de configuração, que garante que todas as alterações feitas no sistema de software sejam consistentes e feitas de acordo com as regras e regulamentos organizacionais.

Uma mudança na configuração do produto passa pelas seguintes etapas -

Identification- Uma solicitação de mudança chega de uma fonte interna ou externa. Quando a solicitação de mudança é identificada formalmente, ela é devidamente documentada.
Validation - A validade da solicitação de mudança é verificada e seu procedimento de tratamento é confirmado.
Analysis- O impacto da solicitação de mudança é analisado em termos de cronograma, custo e esforços necessários. O impacto geral da mudança prospectiva no sistema é analisado.
Control- Se a mudança em perspectiva impactar muitas entidades no sistema ou for inevitável, é obrigatório obter a aprovação de altas autoridades antes que a mudança seja incorporada ao sistema. É decidido se a mudança vale a pena incorporar ou não. Caso contrário, a solicitação de mudança é recusada formalmente.
Execution - Se a fase anterior determinar a execução da solicitação de mudança, esta fase toma as ações apropriadas para executar a mudança e faz uma revisão completa, se necessário.
Close request- A alteração é verificada para implementação correta e fusão com o resto do sistema. Essa alteração recém-incorporada ao software é documentada de maneira adequada e a solicitação é formalmente encerrada.

Ferramentas de gerenciamento de projetos

O risco e a incerteza aumentam de forma multifacetada no que diz respeito à dimensão do projeto, mesmo quando o projeto é desenvolvido de acordo com metodologias definidas.

Existem ferramentas disponíveis que auxiliam no gerenciamento eficaz de projetos. Alguns são descritos -

Gráfico de Gantt

Os gráficos de Gantt foram desenvolvidos por Henry Gantt (1917). Representa o cronograma do projeto em relação aos períodos de tempo. É um gráfico de barras horizontais com barras que representam as atividades e o tempo programado para as atividades do projeto.

Gráfico PERT

O gráfico PERT (Program Evaluation & Review Technique) é uma ferramenta que representa o projeto como um diagrama de rede. É capaz de representar graficamente os principais eventos do projeto de forma paralela e consecutiva. Os eventos, que ocorrem um após o outro, mostram dependência do evento posterior em relação ao anterior.

Os eventos são mostrados como nós numerados. Eles são conectados por setas rotuladas que representam a sequência de tarefas no projeto.

Histograma de recursos

Esta é uma ferramenta gráfica que contém barras ou gráficos que representam o número de recursos (geralmente equipe qualificada) necessários ao longo do tempo para um evento (ou fase) do projeto. O Histograma de recursos é uma ferramenta eficaz para planejamento e coordenação de equipe.

Análise do Caminho Crítico

Esta ferramenta é útil para reconhecer tarefas interdependentes no projeto. Também ajuda a descobrir o caminho mais curto ou o caminho crítico para concluir o projeto com sucesso. Como o diagrama PERT, cada evento é atribuído a um período de tempo específico. Esta ferramenta mostra a dependência do evento presumindo que um evento pode prosseguir para o próximo apenas se o anterior for concluído.

Os eventos são organizados de acordo com o horário de início mais próximo possível. O caminho entre o nó inicial e o nó final é um caminho crítico que não pode ser reduzido ainda mais e todos os eventos precisam ser executados na mesma ordem.