Blog CMMI & MPS.BR

O CMMI nos pede para “extrair as necessidades dos clientes, então… como podemos realizar esta prática?

Por vezes, os clientes acreditam que estão nos passando os requisitos do sistema ao fato de apresentar uma lista simples de necessidades. Um requisito é uma coisa específica (clara, rastreavel, testavel, etc) e muitas vezes os requisitos que recebemos tem algumas destas coisas (mas não todas). A prática RD SP 1.1 começa como “extrair as necessidades” e nos pede pra executar um processo de identificação das necessidades dos requisitos.

Há muitas formas de “extrair” as necessidades de um cliente pois há empresas. Cada um com suas próprias características e estilos, mas há tópicos semelhantes e podemos oferecer alguns exemplos:

- Sessões de levantamento de dados entre o cliente e analistas de sistemas (ou requisitos) onde as necessidades são mapeadas e discutidas através de um simples quadro branco. Certifique-se de trazer sua câmera ou ter um celular que tire fotos visíveis. E sim, as fotos podem ser colocadas sob controle de configuração (e que podem “contar como prova” se adequadamente gerenciados e usados).

- Sessões de Brainstorming que são estruturadas através de uma ferramenta de mapas mentais como mind node (meu preferido) ou mindjet, mas se não tiver nada disso, faça no quadro branco também (e não esqueça da foto). Uma boa prática é começar o mapa pelos principais requisitos e ir detalhando-os o tanto quanto for possível. Use canetas de cores diferentes para destacar o que é crítico ou regras mais complexas. Abordagens gráficas normalmentente fazem um processo dito como “chato” (por seu cliente) em algo diferente e mais produtivo.

Veja o post completo →

O esquecimento de um “detalhe” (requisito) em projetos é mais comum do que se imagina. Normalmente alguém lembra: “Ops… faltou colocar isso no sistema… e agora?”. E o pior de tudo é que o mais comum é que isso aconteça próximo da entrega do sistema. Isto acontece normalmente por causa de um processo de especificação ineficaz ou até mesmo pela simples vergonha de perguntar um pouco mais de detalhe sobre um requisitos.

Quanto mais tarde se encontrar um defeito, mais caro ele será.

O gráfico abaixo é a melhor forma de se ilustrar isso:

Repare que, quanto mais tarde, o custo vai aumentando exponencialmente, e este é um dos motivos que devem levar as empresas a investirem mais e mais em planejamento, controle e engenharia de software em geral.

Vamos a um cenário hipotético. Imagine que você esta fazendo um sistema que usa um índice para reajustar os custos de diversos produtos, este índice é praticamente o coração do sistema e você fez sua correção através do dolar. Porém, quando você começa a validar o mesmo com seu cliente você “descobre” que este índice deveria ser composto pela cotação do dolar, euro e mais quatro moedas. Qual impacto isto trará ao seu projeto? Bom… se você tivesse descoberto isto no início do projeto, o custo seria praticamente nulo, mas agora no final… imagine quanto você precisará gastar para ajustar este pequeno detalhe.

Quanto mais se investe em planejamento e especificação, menor será o tempo de desenvolvimento e você acabará montando mais do que desenvolvendo.

Enfim… pense nisso e aproveite e comente suas experiências em situações como esta.
Veja o post completo →

Continuado a série de mini tutoriais de projeto, no ultimo post realizamos o dimensionamento do projeto e chegamos ao custo de R$ 8.400,00 em 210 horas.

Agora vamos compreender o impacto das mudanças.

Nota: Neste momento, você praticamente finalizou o projeto e esta validando-o com seu amigo.

Nosso projeto é uma pequena tela de cadastro de contatos e ao entrega-la ao seu cliente (seu amigo). Ele gosta tanto que mostra ao seu chefe, que também gosta muito do sistema e tem a idéia de implementar em toda empresa.

Você comenta que teria que fazer várias mudanças mas ele comenta que quer “do jeito que esta” não precisa mudar nada – Ele gostaria apenas que selecionasse a filial (ele tem 10 filiais) antes de ver os contatos. Esta solicitação vem junto com a frase “É fácil… é só uma tabelinha”.

Seguindo a mesma linha de dimensionamento que usamos, vamos então colocar:

+ Um arquivo interno
+ Uma entrada externa

O arquivo interno equivale à 10PFs e a entrada equivale à 4PFs, totalizando assim 14 pontos por função. Aplicando novamente a mesma produtividade utilizada anteriormente teremos 98 horas. Então podemos dizer que “a tabelinha” vai demandar mais 98h de trabalho em um projeto de 210h. Em outras palavras, seu amigo que já pagou R$ 8.400,00 pelo sistema terá que pagar mais R$ 3.920,00 por essa mudança.
Veja o post completo →

A Imagem abaixo demonstra muito do que acontece atualmente em grande parte das organizações.

Alguns dos principais pontos relacionados à requisitos são:

1. Os requisitos devem ser documentados
2. Os requisitos devem ser aprovados
3. Os trabalhos devem ser aprovador
4. Eles devem estar sob gerência de configuração
5. Os requisitos somente podem sofrer alterações mediante análise de impacto, aprovação e replanejamento

Um ponto chave para reduzir problemas com comunicação é a formalização da mesma. Assim consegue-se mais envolvimento e comprometimento entre os envolvidos.