segunda-feira, 25 de julho de 2011

Gerenciamento de Comunicações em Projetos - Matriz de Comunicação

Uma parte importante em um projeto, que freqüentemente acaba não sendo muito privilegiada, é o gerenciamento das comunicações.
Dentro da Engenharia de Requisitos a comunicação formal se torna bastante importante na gestão das mudanças nos requisitos (solicitações de mudanças).
O gerenciamento das comunicações do projeto é o setor que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações aos envolvidos no projeto. Devem ser especificados métodos que permitam a transmissão da informação de maneira clara e sem ruídos (alterações).
A matriz de comunicação é uma ferramenta que especifica quais documentos serão comunicados, para quais stakeholders (envolvidos no projeto), em que freqüência (quando) e por qual meio (como). Ela deve estar presente dentro do plano de gerenciamento das comunicações do projeto (documento de planejamento das comunicações). Ela pode ser criada em qualquer software básico de escritório.



Exemplo de Matriz de Comunicação

Uma matriz de comunicação tem as informações (poderão ser alteradas/adaptadas conforme necessidades específicas):

1.    Tipo - tipo da comunicação. Ex: reunião de status mensal, reunião com usuário, prestação de contas semanal, relatório de status do projeto, etc.
2.    Objetivo - descrição da comunicação. Ex: informar status atual aos participantes do projeto, informativos financeiros de gastos/receitas, etc.
3.    Meio - meio da distribuição da informação. Ex: e-mail, telefone, comunicador instantâneo, vídeo-conferência, reunião presencial, etc.
4.    Periodicidade - freqüência, motivo ou datas específicas que deve ocorrer à comunicação. Ex: semanal, mensal, em qualquer “estouro” de prazo, em qualquer “estouro” em custos, etc.
5.    Destinatário(s)- envolvido(s) que deve(m) receber a comunicação. Ex: usuários, stakeholders, analistas de sistemas, programadores, gerente do projeto, diretor técnico, patrocinador, fornecedor, etc.
6.    Responsabilidade- responsável pela informação. Ex: gerente do projeto, analista de sistemas responsável, etc.
7.    Documento(s) - documento(s) gerado(s). Ex: ata de reunião, relatório de status do projeto, planilha de custos do projeto, etc.

Negligenciar a comunicação em um projeto poderá trazer diversas conseqüências negativas.  Membros da equipe terão diferentes conhecimentos sobre projeto, patrocinadores não estarão informados sobre o andamento, membros participantes poderão não receber informações vitais e necessárias, entre outras conseqüências, que poderão trazer impactos em cronograma, prazos e custos.

Fonte:
Project Management Institute Inc. Guia PMBOK. 3. edição. Project Management Institute Inc. 2004.

domingo, 17 de julho de 2011

Processos de Obtenção de Requisitos – Parte (1/8) – Entrevista

A obtenção de requisitos é o processo de reunir informações sobre os sistemas existentes e sobre o sistema proposto. Para isso são usadas como fontes de informações documentações atuais, conhecimento de usuários do sistema e outros participantes do projeto e especificação de sistemas atuais utilizados e de outros sistemas similares.

Uma técnica simples, importante e que pode ser utilizada em qualquer situação é a entrevista.

Uma entrevista pode ser aberta ou fechada:

  • Entrevista Aberta, não existe um roteiro a ser seguido, o entrevistador explora vários assuntos e busca uma compreensão mais ampla das necessidades;
  • Entrevista Fechada, o entrevistado responde a um conjunto de perguntas específicas e pré formuladas.

Na prática costuma ser realizada uma mistura desses dois tipos, procurando utilizar o melhor dos dois mundos, tendo algumas perguntas para serem usadas como ponto de partida e perguntas chave que serão importantes para o projeto e prosseguindo de forma mais livre (mas mantendo foco) para entender melhor as necessidades do entrevistado.

A entrevista é bastante útil para o entendimento geral do sistema atual e para entender as dificuldades enfrentadas e novas necessidades dos usuários. Mas ela pode ser menos eficiente para obtenção de requisitos ligados as estruturas organizacionais, pois nem sempre numa organização a estrutura real de tomada de decisões coincide com a estrutura oficial e esse tema geralmente é um assunto “tabu”.

Para uma entrevista produtiva o Analista de Requisitos ou Analista de Sistemas precisa de uma prévia preparação (estruturação da entrevista). Algumas dicas são:

  • Preparação de uma lista de perguntas iniciais e perguntas importantes. Nessas perguntas, num primeiro momento, é importante uma maior liberdade e evitar a indução de respostas, em fases mais adiantadas poderão ser utilizadas perguntas com respostas mais fechadas;
  • Revisão das perguntas momentos antes da entrevista e eventualmente consultas (se forem necessárias e breves) poderão ser feitas durante a entrevista;
  • Antes da entrevista é útil fazer uma pesquisa sobre a empresa e sobre o entrevistado, isso evitará desperdício de tempo, mas informações importantes devem ser verificadas durante a entrevista;
  • Repostas poderão ser anotadas numa agenda durante a entrevista ou gravadas eletronicamente (muitas pessoas se sentem desconfortáveis com informações sendo gravadas, então...). O ideal é manter um equilíbrio de tempo entre anotações e perguntas, tentando não “quebrar” o raciocínio e a entrega de informações do entrevistado.

Modelo de uma entrevista estruturada:


Parte 1 – Estabelecendo o perfil do cliente/usuário

Previamente poderão ser pesquisadas informações como nome do entrevistado, cargo, nome da organização, ramo de atividade, entre outras informações relevantes.

No inicio da entrevista algumas perguntas são:

Quais são as suas responsabilidades?
Quais são os produtos do seu trabalho?
Para quem você gera esses produtos?
Como é medido o seu sucesso?
Quais são os problemas que interferem para o sucesso de seu trabalho?
O que, se existe, facilita ou dificulta o seu trabalho?

Parte 2 - Avaliando o Problema

Para quais problemas faltam boas soluções?

Quais são? (Dica: Continue perguntando, “Mais algum?”).

Para cada problema, pergunte:
  • Por que esse problema existe?
  • Agora, como resolvê-lo?
  • Como você poderia resolvê-lo?
Parte 3 - Entendendo o Ambiente do Usuário

Quem são os usuários?
Qual é a sua formação?
Qual é a sua experiência em computação?
Os usuários são experientes nesse tipo de aplicação?
Quais plataformas são usadas?
Quais são os planos para a futura plataforma?
Outras aplicações usadas são relevantes para essa aplicação? Se sim, fale um pouco sobre elas.
Quais são as suas expectativas para a usabilidade do produto?
Quais são as suas expectativas para o tempo de treinamento?
Que tipo de auxílio ao usuário você precisa (ex: cópia impressa ou documentos on-line).

Parte 4 - Recapturando para Entender

Você me disse que:
(Liste os problemas que o cliente descreveu com suas próprias palavras).
  • ·
  • ·          
  • ·          
  • ·          
Eles representam adequadamente os problemas que você está tendo com a solução existente?
Quais outros problemas, caso exista, você está enfrentando?

Parte 5 - Suposições do Analista sobre o Problema do Cliente

(Valide ou invalide suposições).
(Se não foi discutido) Quais problemas, se houver, estão associados: (Liste quaisquer necessidades ou problemas adicionais que você acha que está preocupando o cliente ou o usuário).
  • ·          
  • ·          
  • ·          
Para cada problema sugerido, pergunte:

Esse é um problema real?
·         Quais são as razões deste problema?
·         Como você gostaria de resolvê-lo?
·         Qual é o peso da solução desse problema, comparado aos outros que você mencionou?

Parte 6 - Avaliando a sua Solução (se aplicável)

(Resuma as principais capacidades da solução que você propôs).
O que aconteceria se você conseguisse:
  • ·          
  • ·          
  • ·          
Como você classificaria cada uma dessas capacidades, por ordem de sua importância?

Parte 7 - Avaliando a Oportunidade

Quem na sua organização precisa dessa aplicação?
Quantos usuários desse tipo usariam a aplicação?
O que você considera que seja uma solução bem sucedida?

Parte 8 - Avaliando Necessidades de Segurança, Desempenho e Suportabilidade (pode não ser aplicável a todos os usuários)

Quais são suas expectativas sobre a segurança?
Quais são suas expectativas sobre o desempenho?
Você irá dar suporte ao produto ou serão outras pessoas que farão isso?
Você tem necessidades especiais de suporte?
O que você pensa sobre a manutenção e serviços de rede?
Quais são os requisitos de segurança?
Quais são os requisitos de instalação e configuração?
Existem requisitos especiais de licenciamento?
Como o software será distribuído?
Existem requisitos de etiquetagem ou de empacotamento?

Parte 9 - Outros Requisitos

Existe algum requisito legal, de regulação, ambiental ou de padronização que deva ser atendido?
Você acha que existem outros requisitos que devemos conhecer?

Parte 10 - Fechamento

Existe alguma outra questão que eu deveria ter feito?
Se depois, eu tiver alguma dúvida, posso ligar para você? Enviar e-mail?  Você concorda em participar de uma revisão de requisitos?

Parte 11 - Resumo do Analista

Depois da entrevista, e enquanto as informações estiverem frescas em sua mente, resuma as três necessidades ou problemas de maior prioridade identificados pelo usuário/cliente.

1.
2.
3.

Os resultados das entrevistas deverão ser compilados. É esperado que se encontrem necessidades e problemas comuns entre os entrevistados. Esse será o inicio de um “repositório” de requisitos que dará origem aos futuros documentos de requisitos.
Embora seja importante, a entrevista não deve ser o único método de obtenção de requisitos, mas utilizada em conjunto com outros métodos.

Breve: Processos de Obtenção de Requisitos – Parte (2/8) – Questionário


Fontes:

SOMMERVILLE, Ian. Engenharia de Software. 8. edição. São Paulo. Pearson Education do Brasil. 2007.
LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements. 1. edição, Reading MA, Addison-Wesley Professional. 1999.

quarta-feira, 6 de julho de 2011

Custo de erros em projetos de desenvolvimento de software

Cada projeto é único (mesmo projetos semelhantes terão diferenças significativas) e é impossível fazer estimativas ou ter fórmulas genéricas para estimar o custo de erros que poderão acontecer.

Na monografia de Marco Aurélio Cordeiro para o curso de Pós Graduação em Informática Aplicada da Pontifica Universidade Católica do Paraná (Curitiba, 2002) ele cita um estudo realizado nos anos 70 pelas empresas GTE, TRW e IBM, onde um custo relativo de um erro localizado durante a análise de requisitos é 0.1, já um erro localizado na fase de implementação é 1 (10 vezes mais), na fase de testes seu custo relativo sobe para 2 (20 vezes mais), terminando com um custo relativo de 20 (200 vezes mais) na fase final de manutenção. O gráfico abaixo retrata essa situação.

 
Vale ressaltar que esse é um estudo realizado numa outra realidade de desenvolvimento de software muito diferente da atual (anos 70), mas que já mostra que há muito tempo o custo para correção de erros é uma preocupação nas organizações.

Já na monografia de Paulo Henrique Ramos apresentada no curso de Mestrado em Ciência da Computação na Universidade Federal de Pernambuco (Recife, 2011) ele cita um estudo onde o custo de uma falha localizada na fase de testes pode ser 30 vezes o custo inicial, se ele fosse localizado na fase inicial (análise de requisitos).

Roger S. Pressman no livro Engenharia de Software (6. edição, 2006) declara que o custo de defeitos na fase de projeto é cerca de três a seis vezes mais alto do que na definição de requisitos e o custo é ainda maior em fases finais como na fase de testes.

Seja qual for a metodologia usada ou o estudo utilizado, a conclusão é sempre que o custo de correção de um defeito é sempre muito inferior quando identificado no inicio de um projeto e muito superior quando identificado na finalização do projeto.

A importante fase Análise de Requisitos exige maior qualidade, pois suas falhas poderão comprometer todo o projeto.

sábado, 2 de julho de 2011

Gerenciamento de Mudanças

O gerenciamento de mudanças de requisitos deve ser aplicado a todas as mudanças propostas (requeridas) sobre os requisitos. Obrigatoriamente é um processo formal, para que todas as requisições de mudanças sejam tratadas consistentemente e as mudanças no documento de requisitos sejam feitas de maneira controlada (SOMMERVILLE, 2007).

A natureza dos projetos com sua elaboração progressiva e aumento do seu entendimento durante sua evolução/execução leva a mudanças. Essas mudanças não devem ser evitadas (com o risco do projeto fracassar), é preciso lidar com elas.

Para os fornecedores/desenvolvedores de software o universo ideal é onde os projetos de sistemas a serem desenvolvidos tenham um orçamento aberto onde seja remunerada a hora técnica de cada colaborador envolvido pelo tempo que o projeto durar (onde cada mudança solicitada gera alterações no prazo e ou no custo). Nessa situação ideal mudanças nos requisitos e no escopo são situações bem aceitas, pois são igualmente remuneradas.

Por outro lado, a situação mais crítica é num orçamento fechado e não aberto a alterações, onde será necessário lidar com as mudanças de requisitos permanecendo dentro de um cronograma estipulado e sem ultrapassar os custos negociados.



Acima um exemplo de um processo de mudança em um requisito, iniciado com a identificação de um problema, passando por uma análise do problema, uma análise das mudanças e seus custos para o projeto (nessa fase ocorreria a aprovação da mudança solicitada) e terminando com a implementação e documentação das mudanças.

  1. Análise do problema e especificação da mudança: problema identificado ou mudança requerida tem sua viabilidade analisada e eventuais dúvidas são tiradas junto ao seu solicitante.
  2. Analise da mudança e estimativa de custos: é feita análise dos efeitos da mudança junto a outros requisitos (podem ocorrer conflitos entre requisitos) e são estimados os custos dessa mudança no projeto. Completadas essas análises ocorrerá a decisão se a alteração prosseguirá ou que negociações serão necessárias para sua aprovação.
  3. Implementação da mudança: atualização do(s) documento(s) de requisito(s).

As mudanças em um projeto serão inevitáveis. A situação mais equilibrada é onde as solicitações de mudanças sejam analisadas e seus impactos avaliados. Essas mudanças terão que ser autorizadas por diferentes níveis hierárquicos, proporcional aos impactos avaliados ao projeto. Impactos classificados como grandes (relevantes nos custos e ou no cronograma) poderão levar o fornecedor a renegociações junto ao cliente.

Referência:

SOMMERVILLE, Ian. Engenharia de Software. 8. edição. São Paulo. Pearson Education do Brasil. 2007.