CERTICS – A Nova Certificação de Software Brasileira

Todos que desenvolvem ou mantém software conhecem (em algum nível) os modelos de maturidade do CMMI e MPS-BR. Didaticamente, podemos dizer que estes modelos avaliam a maturidade de uma organização no desenvolvimento de software (CMMI-DEV ou MPS-BR Desenvolvimento), gestão de dados (DMM), gestão de serviços (CMMI-SVC ou MPS-SV) ou mesmo a gestão de aquisição de software (CMMI-ACQ ou MPS-Aquisição). Os modelos de maturidade não devem ser confundidos com processos de software, i.e., eles apenas definem que objetivos uma organização deve atingir. O processo pelo qual uma organização atinge um objetivo (o como) não é relevante para estes modelos de maturidade.

Naturalmente, toda organização requer processos para desenvolver software ou fabricar produtos de software e diversos normativos de indústria apresentam melhores práticas para orientar a construção de processos de software. Um destes normativos é a ISO 15504, também chamada de SPICE. A partir dos princípios do SPICE, o Ministério da Ciência, Tecnologia e Inovação criou esta nova certificação, chamada de CERTICS. Em termos técnicos, o CERTICS tem por objetivo padronizar o processo de fabricação e evolução de produtos de software de empresas que desenvolvam software.

A CERTICS não deve ser confundida com um mero processo de desenvolvimento de software como por exemplo o RUP. Ela é muito abrangente e cobre todo o processo de fabricação de um produto, que é muito mais amplo que “fazer um software”. Exemplos de aspectos incluidos na CERTICS incluem ações de monitoramento de mercado ou mesmo ações de monitoramento de necessidades dos clientes.

Mais uma certificação? Para quê?

A CERTICS tem um objetivo nobre, que é fornecer vantagens para produtos de software desenvolvidos no Brasil. Se a sua empresa desenvolvedor produtos e for certificada CERTICS, ela terá benefícios diversos em licitações do governo Brasileiro.

“Dentre os benefícios de uma certificação de credibilidade que comprove desenvolvimento e inovação tecnológica em território nacional destaca-se a preferência do software certificado em licitações. Além disso, o certificado é também uma forma de comunicar ao mercado, de forma legítima, a existência de práticas e competências tecnológicas relacionadas ao software.”, Modelo de Referência do CERTICS.

Faço Produtos há 1450 anos? Preciso mesmo desta certificação?

Não. Você não precisa, mas pode ganhar muito com ela.

Observo da minha experiência de consultoria em empresas de produtos que aspectos primários que deveriam ser endereçados por estas empresas são completamente ignorados. No CERTICS, é esperado que toda empresa fabricante de produtos atenda aos 16 resultados esperados indicados na figura abaixo.

Resultados Esperados no CERTICS

A CERTICS ainda está em seu estágio embrionário e deve evoluir bastante com as críticas da comunidade de software. De toda forma, considero a iniciativa interessante. Se a sua empresa faz software, mantenha um olho nela. No mínimo, ela irá indicar pontos de atenção e preocupações que o seu produto de software deve atender.

Para quem tiver maior curiosidade sobre este novo modelo, recomendo os seguintes sítios.

– FAQ – http://www.certics.cti.gov.br/perguntas-frequentes.html

– Modelo de Referência – http://www.certics.cti.gov.br/downloads/ModeloCERTICS_Detalhado.pdf

– ISO 15504 – Definições básicas.

Os Sete Pecados Capitais do Desenvolvimento de Software

O quadro o Jardim das Delícias Terrenos é um dos mais impactantes quadros a avisar aos transgressores da fé católica o destino deles ao final de uma vida impura. Obra-prima de quase 2 metros de altura e largura, o quadro retrata o inferno dos luxuriosos, gulosos, avarentos, invejosos, preguiçosos, iracundos e vaidosos.

O Jardim das Delícias Terrenas
Obra prima de Hieronymus Bosch, pintor holandês contemporâneo de Leonardo da Vinci

 

Se a engenharia de software tivesse um inferno, poderíamos nos arriscar, como Dante Aligheri, a descrever os sete pecados capitais do desenvolvimento de software que os porquinhos de software cometem em base diária. Mary Poppendieck, uma das autoras doLean Software Development, descreva 7 formas de desperdício no desenvolvimento de software. Apresento e contextualizo estes pecados capitais abaixo no dia a dia do trabalho de software.

1. Funcionalidades extras. Pesquisas de institutos como o Standish Group (XP Conference, 2002) mostram que metade das funcionalidades de um software são raramente ou nunca usadas. Ainda assim, é muito comum que desenvolvedores “criativos” introduzam funcionalidades não desejadas em seus software que não trazem valor agregado algum para os seus clientes. A redução do desperdício tem forte relação com escrever menos linhas de código.

2. Transferência de responsabilidades, conhecimentos, ações e feedbacks. O uso de papéis muito especializados é um sintoma deste problema. “Arquitetos” e “projetistas” que não sabem codificar, “desenvolvedores” que não sabem testar ou implantar software e “gerentes de projeto” que se orgulham de não entrar em temas técnicos são exemplos de handovers (repassese fontes comuns de desperdício.

3. Defeitos. Se orgulhar de ter um time de testes que encontra muitos defeitos é no mínimo contra-produtivo. Devemos nos lembrar que defeitos são desperdícios, ou dinheiro jogado fora. As ações de projetos devem impedir que defeitos sejam introduzidos em primeiro lugar, e não focar em pegar defeitos ao final.  Um exemplo simples é no ciclo tradicional de especificação, codificação e testes. Ao invés, o teste deve validar e corrigir a especificação antes que a primeira linha de código seja escrita, visto que a maior parte dos defeitos nasce ainda na especificação do software. Da mesma forma, é papel do desenvolvedor usar técnicas diversas (refatoração, teste de unidade e integração contínua) para reduzir a quantidade de defeitos introduzidas no software.

4. Débito Técnico. Fazer código de má qualidade tende a gerar débito técnico no código, módulo e arquitetura de um produto. O débito técnico gera um efeito muito ruim a médio e longo prazo e gera efeitos colaterais no produto em pontos não imaginados. Livros como “Clean Code”, do Robert Martin, exploraram a criação de código de qualidade

5. Trabalho em progresso. Manter uma longa lista de tarefas com o status em  ”execução” esconde problemas e eventualmente gera desperdício. Cada pessoa de um time deve manter o mínimo número de tarefas abertas. Cada tarefa aberta deve ser rapidamente terminada para reduzir o seu tempo de ciclo, evitar retrabalhos e trabalho multitarefa. Um exemplo vem da metodologia japonesa chamada Kanban, que introduz o conceito chamado (WIP). O WIP (Work In Progress) tem um valor limite pequeno (tipicamente 3) e impede que uma pessoa tenha mais de 3 tarefas em execução. Um outro exemplo de combate a este desperdício é a prática de entregar software com frequência para os usuários chave, que limita o tamanho do backlog de tarefas em aberto para todo o time de desenvolvimento.

6. Trabalho multitarefa. Há algum tempo este mito assola os times de software, atolados no trabalho de novas demandas e na resolução de defeitos e adaptações de diversos softwares em paralelo. Estudos diversos mostram que o fator multitarefa reduz a produtividade, gera desmotivação e trabalho de pior qualidade, o que introduz mais defeitos e gera mais trabalho em progresso.

7. Esperas e atrasos. Provocar esperas e atrasos gera um efeito nocivo na produtividade do time e é também uma forma de desperdício. Por exemplo, enviar um email para uma equipe de desenvolvimento validar um documento de casos de uso gera espera, atraso e descontinuidade do trabalho. Apresentar este documento ao vivo melhora o entendimento para todos e também reduz ciclo de validação do documento gerado. Allistar Cockburn descreve a prática chamada de “Radiadores de Informação” em seu método ágil chamado Crystal Clear, que consiste em manter pessoas próximas e privilegiar a comunicação ao vivo com o uso de quadros brancos. Outros métodos ágeis como o Scrum ou o XP também advogam práticas similares.

Eliminar desperdícios é chave para gera software mais eficaz e em menos tempo para clientes. Um bom livro sobre este tema é o livro: Implementing Lean Software Development: From Concept to Cash, de Mary e Tom Poppendieck.

Lean Software Development