Arquivos de May, 2009

Uma visão geral sobre qualidade de software 31 May 2009 as 11:26 pm de Rodrigo Ricci

Todos nós temos conhecimento que o desenvolvimento de projetos de software é uma tarefa árdua e extremamente difícil. Um sistema mal construído pode gerar milhões de reais em prejuízos em poucas horas, dependendo do tamanho do cliente e do porte da operação suplantada. O primeiro registro de “bug” foi em 1945 quando a Oficial Naval Grace Murray Hopper, encontrou uma traça dentro de um dos computadores da marinha americana. O fato de ter encontrado um “bug” (inseto em inglês) dentro de um computador que estava com mau funcionamento por conta dessa ocorrência, permitiu com que o termo se tornasse comum na área de desenvolvimento de software e associado a falhas durante a execução.Qualidade de software com CMMI

Ao longo da história evolutiva do computador e do desenvolvimento de aplicativos, é muito comum totalmente normal encontrarmos situações na qual existiram, existem e ainda irão existir situações de problemas durante a realização de alguma tarefa em um determinado sistema. Mas em muitos desses casos, as conseqüências desses atos foram resultados de tragédias calamitosas que sacrificaram vidas humanas ou até mesmo prejudiciais ao meio ambiente. Um caso interessante, foi à explosão do ônibus espacial Columbia em 1986, quando alguns funcionários da própria NASA que haviam sido demitidos após o fracasso do projeto, declararam para a imprensa que o acidente aconteceu por conta de falhas no software na hora do lançamento, pois não tiveram testes suficientes no software. Leia o post completo →

+ Abrindo portas com o CMMI Por Washington Souza 27 May 2009 as 10:42 am Nenhum comentário

Hoje temos diversas empresas grandes aqui no Brasil, várias destas com atuação no exterior, todavia, por maiores que elas sejam aqui, lá fora elas são ilustres desconhecidas tentando um lugar ao sol. É muito complicado você chegar nos EUA ou algum pais da Europa e convencer uma empresa a comprar TI do Brasil, esta tarefa é pelo menos 10 vezes mais complexa do que vender aqui.

No entanto, a dificuldade diminui se sua empresa tiver uma certificação autorização reconhecida mundialmente, pegamos por exemplo o CMMI (que é o mais reconhecido).

Lembre-se que o modelo proposto pela SEI é levado muito a sério e tem trazido resultados significantes, principalmente quando levado a sério pelas organizações. A India investiu pesado em CMMI e hoje eles têm pelos menos 10 vezes mais empresas com CMMI (em cada nível) do que nós. Como sabemos, hoje eles são uma potência reconhecida mundialmente (ta certo que existem outros fatores que também contribuem, mas, não vamos tirar o mérito deles).

No mesmo caminho esta a China que é um dos países que mais crescem em avaliações (se não o que mais cresce), ultrapassando a India.

A concorrência esta ficando cada vez mais difícil, pois por melhor que sejam seus processos, sem o CMMI (falo dele porque é o mais reconhecido, porém existem outros), ficará bem mais complicado de convencer seus possíveis clientes de que “você é bom”.

Lembre-se que mesmo com um modelo de capacidade como CMMI haverá concorrência dura, mas pelo menos sua empresa terá chances de ganhar.

+ Você não entendeu corretamente alta maturidade se… Por Washington Souza 26 May 2009 as 4:00 pm Nenhum comentário

Os exemplos a seguir devem ser encarados com instrutivos e não pejorativos

Você não entendeu corretamente OPP se…

… uma tabela contendo os defeitos por fase parece um excelente modelo de performance de processos (PPM – Process performance model)
…A média de linhas de código produzidas por dia por desenvolvedor parece um baseline de desempenho de processo pra você
… um gráfico de controle usado para “gerenciar” defeitos escapados parece um excelente PPM para você
… um sistema e Earned Value Management parece atender completamente o nível 4 pra você

Você não entendeu corretamente QPM se…

… monitorar os bugs ao longo do ciclo de vida do projeto parece “gerenciamento estatístico” para você
… você recalcula os limites de controle de seu baseline pelo menos duas vezes ao ano
… decisões gerenciais são utilizadas para ajustar os limites de controle
… densidade de defeitos parece um perfeito subprocesso para gerenciamento estatístico

Você não entendeu OID corretamente se…

… 42 projetos six sigma – todos voltados à inspeção – fazer uma companhia ter maturidade nível 5
… uma melhoria de 5% em um processo com variação de +-7% parece excelente e pode ser implementada imediatamente
… o resultado (e força) de uma melhoria somente pode ser mensurado pelo poder de persuasão do autor
… as propostas de melhoria são desenvolvidas de acordo com a ordem de chegada
… você não consegue ver como PPMs – Process Performance Models e PPB – Process Performance Baselines podem contribuir com OID

Você não entendeu CAR corretamente se…

… você classifica como “severidade alta” os defeitos e diz “vamos rodar uma análise de causa e ver o que esta acontecendo”
… análise de causa é utilizada apenas para encontrar as causas raiz dos defeitos
… você não vê valor em aplicar DAR para selecionar quando utilizar ou não CAR
… você não vê o valor de aplicar CAR para selecionar quando e como aplicar OID
… você não consegue ver como PPMs – Process Performance Models e PPB – Process Performance Baselines podem contribuir com CAR

+ 101 dicas para implementação do CMMI nível 3 – Parte II Por Washington Souza 19 May 2009 as 1:56 pm 3 comentários

OT – Treinamento organizacional

101 dicas para o CMMI nivel 350. Tenha um mapa de treinamentos necessários para cada função
51. Defina claramente quais os treinamentos de responsabilidade da empresa e quais são os do projeto
52. Envolva a área de treinamento no planejamento do projeto
53. Identifique quais são os treinamentos necessários para atender os objetivos estratégicos da empresa
54. Mantenha um programa de treinamento contínuo
55. Colete informações de desempenho dos treinamentos
56. Verifique se após os treinamentos houve melhora de desempenho nas pessoas
57. Tenha uma descrição de responsabilidades e autoridades de cada função
58. Planeje o investimento com treinamentos e periodicamente verifique os benefícios
59. Armazene os dados de treinamentos

PI – Integração de produto

60. Identifique as necessidades de integração entre produtos e componentes
61. Planeje como será a sequência de integração
62. Crie critérios para garantir que os produtos estão prontos para serem integrados
63. Tenha métodos alternativos de integração e selecione o melhor (se possível com DAR)
64. Armazene informações sobre o processo de decisão sobre integrações
65. Tenha guias ou processos de como as atividades de integração devem ser realizadas
66. Verifique a compatibilidade entre as interfaces
67. Documente os ajustes necessários nas interfaces
68. Crie mecanismos que garantam que o produto final contem as versões corretas dos códigos e componentes

RD – Desenvolvimento de requisitos

69. Identifique as necessidades do projeto
70. Identifique as expectativas que os envolvidos tem com o projeto
71. Tenha guias que auxiliem o desenvolvimento de requisitos
72. Traduza os requisitos de negócio e necessidades em requisitos técnicos
73. Verifique antes da validação com cliente
74. Defina critérios que liberem os produtos para validação com cliente
75. Assegure o entendimento correto dos requisitos – valide formalmente com o cliente
76. Faça o mapeamento dos requisitos com funções, códigos, componentes, aquisições, etc.

Veja o post completo →

+ Dúvidas frequentes sobre PPQA (FAQ PPQA) Por Washington Souza 18 May 2009 as 3:24 am Nenhum comentário

O que é PPQA?
PPQA significa Process and Product Quality Assurance (Garantia de qualidade de processo e produto) e é a área responsável no CMMI pela qualidade tanto nos projetos quanto organizacionalmente.

Como PPQA realiza seus trabalhos?
A principal ferramenta de trabalho do PPQA (vamos chamar apenas de PPQA o analista de PPQA) é o checklist de auditoria. O PPQA deve seguir o checklist e verificar se o processo esta sendo seguido conforme previsto

Qual o resultado dos trabalhos de PPQA?
Um relatório mostrando como foi a auditoria. Este relatório deve ser enviado à todos envolvidos no projeto

Como PPQA ajuda nos projetos?
O principal objetivo é mostrar à alta direção como esta o projeto (o que esta em conformidade e o que não esta)

PPQA audita apenas projetos?
Não, diversas outras atividades de suporte devem ser auditadas para garantir que o processo esta sendo seguido. O principal exemplo é OT.

A quem PPQA responde?
À alta direção da empresa (presidência ou direção)

Porque PPQA responde para a alta direção?
Para garantir independência e que não haverá conflito de interesses ou manipulação dos resultados. A alta direção deve saber a real situação dos projetos.
Veja o post completo →

+ Top 10 dicas para um bom gerenciamento de projetos Por Washington Souza 15 May 2009 as 11:56 pm Nenhum comentário

1. Monitore diariamente o desempenho do projeto
Monitore diariamente elementos como custo, qualidade e atendimento a prazo. Você deve documentar no plano de projetos qual a qualidade esperada e variação de custo e prazo. Considere a utilização de EVM para monitorar o custo e prazo, além disso, tome ações sempre que o desempenho sair dos seus limites de controle.

2. Gerencie o escopo
Verifique quais são as reais expectativas do cliente e em casos de divergência negocie com base nos dados que você tem (uma proposta comercial com o escopo ajuda muito).
Ambos devem ter ciência do que foi comprado e o que será feito. Não há problema algum em alterar o escopo, porém deve ficar claro o impacto de alterações (para mais ou para menos). Formalize sempre o que será feito e formalize também toda mudança.

3. Tenha auditorias de qualidade periódicas e independentes em seus projetos
Uma auditoria independente (PPQA por exemplo) ajuda muito a saber se o projeto esta bem sob a óptica da empresa. Utilize isto para corrigir possíveis problemas em casa e não no seu cliente.

4. Faça reuniões de acompanhamento periódicas
O PMI fala muito sobre isso. É muito importante fazer eventos de acompanhamento tanto interno (com sua equipe) quanto com seu cliente (apresentando o desempenho). Documente sempre os eventos de acompanhamento e utilize esta documentação para na próxima reunião.

5. Mantenha a equipe motivada
Motivação é um dos pontos chave de todo projeto (em breve escreveremos mais sobre isso). Uma equipe motivada produz produtos de mais qualidade e em tempos menores. Apple e Pixar são grandes exemplos de equipes empresas motivadas. Bonifique o desempenho acima do previsto. Diversos problemas deixarão de ocorrer pelo simples fato de ter uma equipe motivada.

6. Gerencie os riscos do projeto
Durante todo o projeto você gerencia riscos, pode-se até dizer que o gerenciamento de projetos é na verdade gerenciamento de riscos, desta forma, identifique todos os possíveis riscos e defina planos para gerenciamento destes riscos. Sempre que possível tenha uma contingência para os casos onde “algo deu errado”

Veja o post completo →

+ 101 dicas para implementação do CMMI nível 3 – Parte I Por Washington Souza 13 May 2009 as 2:52 am 2 comentários

DAR – Análise de decisão e resolução

101 dicas para o CMMI nivel 31. Crie um guia para orientar as tomadas de decisões formais
2. Crie critérios que definam quando um processo de decisão formal deve ser realizado
3. Defina critérios para a seleção de alternativas
4. Identifique as soluções alternativas
5. Analise o que normalmente é feito em processos similares
6. Defina claramente o método que será utilizado para análise das alternativas
7. Nunca, jamais se esqueça de analisar as alternativas e documentar esta análise
8. Analise os riscos associados a escolha ou não de uma solução
9. Documente todo o processo de decisão formal
10. Mantenha os dados em gestão de conhecimento para consulta posterior

IPM – Gerenciamento integrado de projeto

11. Tenha uma base de processos
12. Mantenha uma base de melhores documentos, lições aprendidas, modelos, templates e outros
13. Mantenha um plano integrado de trabalho que contemple as atividades de outros grupos bem como previsão de alocação
14. Crie planos que definam como conflitos serão tratados
15. Defina critérios de entrada e saída para as atividades
16. Utilize os planos integrados para o gerenciamento do projeto (um plano de gerenciamento de projeto pode lhe ajudar bastante)
17. Periodicamente atualize a base de conhecimento da organização
18. Mantenha um canal para entrada de sugestões
19. Periodicamente avalie as sugestões e forneça feedback de como estão as sugestões
20. Defina o envolvimento dos stakeholders e comunique-os de suas responsabilidades
21. Identifique e gerencie as dependências e compromissos do projeto
22. Documente ações preventivas e/ou corretivas quando necessário

OPD – Definição do processo organizacional

23. Crie padrões para definição de processos
24. Documente os processos
25. Elabore uma matriz contendo os processos, produtos, atividades e responsabilidades
26. Documente o relacionamento entre os processos e produtos
27. Defina SDLC’s para os principais produtos e serviços
28. Defina critérios para tailoring dos processos quando necessário
29. Documente os processos tailoring dos projetos (quando necessário)
30. Mantenha uma base de medições
31. Periodicamente verifique se há necessidades de ajustes nos processos
32. Estabeleça padrões de infra-estrutura e ativos de processo de acordo com o papel
33. Realize revisão entre pares sempre que houver alterações nos processos
Veja o post completo →

+ Porque estimativas são tão importantes em TI? Por Washington Souza 11 May 2009 as 11:41 pm 2 comentários

Porque estimativas são tão importantes? Cronograma exemplo de projeto de TI

Vejamos como cada um na equipe enxerga o tempo para se fazer este micro-projeto

Escopo
- Administração de usuário com (operações padrão + login)
- Administração de grupos (operações padrão + associação)
- Permissões (operações padrão + associação)

Estimativas
- Programador: 16h
- Analista Programador: 24h
- Analista de Sistemas: 32h
- Gerente de projetos: 40h Veja as diferenças.

Quando apresentamos as estimativas à cada um deles as explicações foram:
- Programador: “Realmente, esqueci que tem o levantamento, especificação, validação, etc”
- Analista programador: “Tem mais algumas coisinhas pra se fazer, mas acho que mais uns 2 ou 4 dias resolve”
- Analista de Sistemas: “Já tá tudo lá, se tiver mais alguma coisa resolver em um dia. Coloca dois pra garantir”
- Gerente de projetos: “Acredito que esta correto, estimei com APF (análise de pontos por função)” Reparem que apenas o gerente do projeto teve segurança em sua estimativa. Os outros quando questionados mudaram suas opiniões – ah, este caso é real.
Veja o post completo →

+ CMMI: Ajuda ou atrapalha? Por Washington Souza 08 May 2009 as 10:43 pm 3 comentários

Olá pessoal, já a um bom tempo estou querendo escrever sobre isso, mas o texto de João Werther Filho da Desenvolva foi certeiro. Ele explica se o CMMI ajuda ou atrapalha de um jeito muito simples e fácil.

CMMI: Ajuda ou atrapalha?

De uma forma bem sucinta, o CMMI (Capability Maturity Model Integration – Modelo Integrado de Capacitação e Maturidade) é um modelo bastante aceito e de alta credibilidade no que se refere a medir a maturidade do processo de uma organização. Quanto mais madura o seu processo, maior a qualidade do produto final oriundo do processo. Pelo menos é o que pensa o SEI (Software Engineering Institute), órgão da Universidade Carnegie Mellon, patrocinado pelo Departamento de Defesa dos Estados Unidos, e responsável pela elaboração e manutenção do modelo CMMI.

yes or noO SEI acredita que a maturação do processo da organização é diretamente proporcional à qualidade do produto final obtido, mas não é só isso. O SEI acredita que o modelo CMMI também facilita para que a organização consiga elaborar o produto final do seu projeto com meios para que o custo, esforço real, e qualquer outra variável relevante ao processo, não se desvie muito do estimado e que tenha a melhor produtividade possível. E tudo isso aplicando as melhores práticas existentes dos processos. As melhores práticas de gerenciamento de projetos, por exemplo, que estão publicadas hoje no PMBoK (Project Management Body of Knowledge – Corpo de Conhecimento da Gerência de Projetos), estão, de certa forma, descritas no modelo. Em outro exemplo mais aplicável para nossa área, ou seja, no caso de processos de desenvolvimento de software, estão contidas no modelo as melhores práticas da engenharia de software.

Para muitos, um processo de desenvolvimento de software baseado no CMMI é muito burocrático e o custo do produto final termina aumentando. Afinal, segundo eles, nem todas as práticas são realmente necessárias na maioria dos casos e muito trabalho poderia ser evitado, principalmente em projetos pequenos. Frases como “O CMMI engessa o processo”, “O custo de desenvolvimento fica alto devido ao CMMI”, “O CMMI vai contra um processo ágil” são emitidas freqüentemente por profissionais que seguem essa linha de pensamento. Para eles, a qualidade gerada pelo CMMI possui um preço muito alto a se pagar e não agrega muito valor à organização.

Veja o post completo →

+ 101 dicas para implementação do CMMI nível 2 – Parte II Por Washington Souza 05 May 2009 as 12:03 am 1 comentário

Continuando o post anterior (101 dicas para implementação do CMMI nível 2).

SAM – Gerenciamento de acordos com fornecedores

57. Crie processos para gerenciamento de fornecedores
58. Mantenha uma base de fornecedores com dados de desempenho
59. Crie critérios para aquisições
60. Tenha SLA’s estabelecidos para projetos e serviços
61. Estabeleça critérios para a seleção de fornecedores
62. Mantenha dados históricos de como foi o processo de seleção de um determinado fornecedor
63. Monitore o desempenho dos serviços de seus fornecedores
64. Tenha contratos formais

PP – Planejamento de projeto

65. Estime tudo nos projetos
66. Obtenha aprovações formais das estimativas
67. Utilize dados históricos para as estimativas
68. Formalize o entendimento do escopo por ambas as partes
69. Formalize o que será entregue
70. Desenvolva um cronograma
71. Documente toda atividade a ser realizada no projeto
72. Identifique dependências críticas e RCCs
73. Defina metas para os projetos
74. Planeje os recursos necessários
75. Planeje os compromissos
76. Planeje os eventos de auditoria de qualidade
77. Planeje o envolvimento dos stakeholders do projeto
78. Elabore um plano de gerenciamento de riscos coerente
79. Considere a utilização de um plano para gerenciamento do projeto (o CMMI não fala nada disto, mas eu recomendo)
80. Tenha um plano de projeto documentado
81. Obtenha aprovação do plano de projetos
82. Para alta maturidade existem diversos outros elementos que devem ser planejados – trataremos disto posteriormente
Veja o post completo →

+ Em qual processo CMMI sua empresa esta? Por Washington Souza 04 May 2009 as 5:44 am Nenhum comentário

Olá pessoal, o objetivo desta enquente é ter uma idéia de qual o nivel CMMI os leitores aqui do blog estão para vermos onde precisamos focar mais.

Por favor respondam:

[poll id="1"]

+ Qual o impacto que um desvio não corrigido de PPQA pode trazer? Por Washington Souza 03 May 2009 as 11:53 pm Nenhum comentário

Durante uma auditoria de PPQA ou Revisão entre pares (RP) diversos itens são verificados e o resultado é um conjunto de itens em conformidade e desvios. Vamos focar nos desvios

Um desvio é um problema ou algo que não esta em conformidade com o previsto.
Vamos a um cenário:

Em sua empresa após o levantamento de requisitos, gera-se um documento contendo todos os requisitos e o cliente deve aprová-los. Este documento servirá de insumo para a próxima fase onde serão desenvolvidos protótipos.

CMMI e o custo da não qualidade - quanto maior o tempo, maior o custo
Um desvio encontrado na auditoria de PPQA foi de que os requisitos não há evidências de que os requisitos foram aprovados pelo cliente

O analista de PPQA comunica isto a gerencia e estabelece uma data para correção – lembre-se que: “PPQA deve fornecer visibilidade de como esta o projeto a direção”.

O gerente do projeto é o responsável pelo projeto e conseqüentemente corrigir os desvios. Se ele não corrigir os desvios devem ser escalados para o nível superior e assim por diante.

Imaginando que “ninguém fez nada” e deixou os desvios paradinhos lá durante um mês.

O cliente começou a validar o sistema e não esta concordando com nada do que foi definido, e para ajudar quem esta validando entrou agora no projeto.

Tudo isto não seria problema se você tivesse corrigido os desvios, mas como não fez isto, o que pode fazer agora? Bom, na melhor das hipóteses, o prejuízo será pequeno.

Este exemplo é simples, mas uma grande parte dos prejuízos em projetos vem de situações como esta. Repare que se você tivesse corrigido este desvio no momento certo, o custo seria X, agora ele será no mínimo 10 X.
Veja o post completo →