Semana passada um comentário no Twitter me chamou muita atenção. O comentário era o mesmo do título deste post: “Alguém sabe se alguma empresa usa de verdade o MPS.Br?”.

Vamos desconsiderar o equivoco em uma pergunda como esta e entender o que é o tal do MPS.Br. Como vocês já devem saber, o MPS.Br é um modelo de melhoria de processos de software muito similar ao CMMI, mas criado e mantido por brasileiros (Softex).

E assim como o CMMI, o MPS.Br nada mais é do que um conjunto de boas práticas de engenharia de software e gestão. Ele fala o que deve ser feito, mas não como fazer, até porque cada empresa tem sua realidade e pode implementar uma determinada prática de um jeito. O plano do projeto por exemplo pode ser um doc, pode ser sistematizado, pode ser dividido em vários documentos e sistemas, enfim, pode ser do jeito que a empresa achar melhor, ela deve apenas seguir as recomendações que o MPS.Br pede.

Estas recomendações são boas práticas de engenharia de software e gestão, e a empresa pode implementa-las ou não, todavia, para obter o certificado MPS.Br nível X, a empresa deve implementar todas as práticas do nível que deseja. E esta implementação deve ser aprovada por um avaliador MPS.Br.

Agora que já tiramos algumas dúvidas, vamos responder a pergunta… O que você acha?
Alguma empresa usa de verdade o MPS.Br?

A resposta é objetiva. Claro que sim, aliás não apenas as “empresas avaliadas”.

Veja o post completo →

Pergunta: Não consigo compreender o que é a tal da rastreabilidade bi-direcional e pra que ela serve. Você pode me ajudar?
- Mary Senko de São Paulo

Resposta: Primeiramente vamos entender que não existe um, mas três tipos de rastreabilidade:

• Rastreabilidade vertical
• Rastreabilidade horizontal
• Rastreabilidade bi-direcional

O que é a rastreabilidade bi-direcional é uma dúvida muito comum. É um assunto largamente discutido na comunidade de engenharia de software e cada um tem uma opinião (normalmente diferente).

A rastreabilidade nos ajuda a entender o relacionamento entre os produtos de trabalho, quer sejam eles especificações de requisitos, código, arquitetura, testes e vários outros, e nos ajuda a garantir a integridade entre estes elementos.

Para requisitos, a ratreabilidade nos ajuda a entender a relação entre os requisitos definidos pelo cliente e os produtos como especificações, protótipos, testes e até o produto final.

A capacidade de se iniciar do topo e rastrear todo o caminho até chegar aos seus casos de testes, ou começar por um determinado caso de testes e segui-lo até o topo é o que chamamos de rastreabilidade bi-direcional. Este também é um exemplo de rastreabilidade vertical e é também o que esta implícito em rastreabilidade de requisitos no CMMI.

Se você é um engenheiro de software, pense nele como um objeto. O objeto master tem abaixo dele vários outros objetos que o “apoiam” diretamente e herdam seus atributos e métodos e estes podem ser rastreados em conjunto como parte da taxonomia do objeto. O mesmo vale para os requisitos.
Veja o post completo →

Apesar da percepção de que as melhores prática do CMMI e do Agile são opostas um com o outros, recentes pesquisas apontam justamente o oposto. O fato é que as organizações podem se beneficiar de ambos os modelos e melhorar significantemente o desempenho.

No final de 2008, o SEI publicou um artigo intitulado “Agile ou CMMI: Por que não abraçar os dois?. Este relatório foi escrito pela equipe do SEI e industria. Como sabemos, CMMI e Agile usam métodos diferentes para se realizar o mesmo trabalho, e como já era de se esperar, ambos tem suas comunidades e seguidores. Mike Konrad, um membro senior da equipe do SEI, concorda e afirma que a tendência natural é formar “novos feudos” ao redor de método diferentes (e normalmente novos). No entanto, de acordo com o relatório, esta ação não é saudável para a profissão de Engenharia de Software.

“Como ambas as comunidades continuavam a aumentar, parecia ser o momento certo para abordar esta questão”. Explica Konrad. “Além dodisso, foi uma excelente oportunidade para nós do SEI dissipar alguns mitos e ajustar nosso entendimento.”

O aumento na adoção de CMMI e Agile aconteceu através de diversos fatores. Por exemplo, a adoção do CMMI normalmente vem de uma necessidade de negócios (como aumento de qualidade e produtividade), ou seja, vem de cima pra baixo, enquanto no Agile as coisas acontecem de forma mais flat. Desta forma, era inevitável o cruzamento de ambos os modelos já que a aprovação vinha aumentando.

Veja o post completo →

O Carnegie Mellon Software Engineering Institute ou simplesmente SEI é (podemos dizer) um centro de pesquisa e desenvolvimento com sede no campus da universidade Carnegie Mellon em Pittsburgh nos Estados Unidos. O SEI também tem escritórios em Arlington, Virginia, e Frankfurt na Alemanha. A maior parte dos recursos recebidos do SEI vem do departamento de defesa dos Americano.

O SEI também tem uma relação estreita com a industria e meio acadêmico através de pesquisa e colaborações.
As três principais áreas de atuação que são:

• Práticas de gestão
• Práticas de engenharia de software
• Práticas de aquisição

História do SEI

Desde 1984, o SEI tem por objetivo servir como um provedor global em engenharia de software e melhoria de processos como um todo. Com o tempo o SEI se tornou a maior autoridade mundial em práticas de engenharia de software através de seu principal programa (CMMI) que permitem as organizações melhorar seus processos e com isso conseguir mais qualidade com um custo menor e com previsibilidade.

Nos últimos anos a importância do software nas organizações tem se tornado maior e mais crítica, desta forma não apenas os Sistemas de Defesa precisam de softwares mais precisos e com qualidade como também empresas de transporte, finanças, medicina, entretenimento, enfim, praticamente todas as áreas de negócio.

O SEI têm contribuído com este crescimento em várias áreas, incluindo:

• Melhoria de processos de software
• Segurança de rede
• Arquitetura de software
• Linhas de produto de software
• Aquisições
• Atendimento a serviços
• Qualidade
• Desenvolvimento pessoal
• Previsibilidade

Áreas de trabalho

O SEI define iniciativas específicas destinadas a resolver os problemas que impedem a maturidade e capacidade das organizações para adquirir, construir e desenvolver sistemas previsivelmente no prazo, dentro do custo esperado, atendendo os requisitos e sem vulnerabilidade.

Práticas de gestão

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 →

Estamos estreando nossa sessão de entrevistas com um convidado de peso, o CMMI Lead Appraiser Antonio Braga. O Sr. Antonio Braga já realizou mais de 60 avaliações SCAMPI CMMI no Brasil e exterior e hoje é uma das maiores referencias sobre CMMI aqui no Brasil.

Nesta nova sessão você encontrará quinzenalmente entrevistas com pessoas que são referência em engenharia de software em geral. Mas… vamos a entrevista…

Entrevista com Antonio Braga

Blog CMMI: Algumas empresas acham que CMMI aumenta o custo, o que você diria a elas?
Braga: CMMI não aumenta o custo. O CMMI é composto pela melhores praticas no desenvolvimento de sistemas. O CMMI incentiva o trabalho segundo processos, sistematização, o que evita re-trabalho e define exatamente as atividades que devem ser seguidas.

Agora muito cuidado deve ser tomado pelas empresas ao definir seus processos e na criação de guias e regras de customização (tailoring) para evitar a criação de camisas-de-força, que engessem seu trabalho.

Blog CMMI: O que uma empresa precisa para iniciar com CMMI?
Braga: O apoio da alta gerencia é fundamental. Um projeto de melhoria de processos compatíveis com o CMMI deve ser iniciado somente quando a organização tem bem definido os benefícios que ira atingir com tal projeto.

A partir daí deve ser alocado um grupo (pode ser uma pessoa) ou ate alocação parcial, para ser responsável pela definição dos processos. Este deve ser primariamente um trabalho de facilitador com o pessoal que efetivamente usa os processos na prática.

Blog CMMI: Quais os pontos que as empresas mais devem ter atenção em um programa de melhoria CMMI?
Braga: Primeiro, os benefícios que a empresa vai atingir.
Não há mágica, não é um trabalho rápido, requer amadurecimento da organização e do pessoal envolvido, isso nos lembra que o primeiro M de CMMI é justamente Maturidade.
Definição de funções, alocação de pessoal e treinamento são fundamentais.

Blog CMMI: Quais os benefícios que uma empresa pode obter com o CMMI?
Braga: O SEI realizou algumas pesquisas sobre este assunto. De um modo geral as empresas que melhoram seus processos usando o CMMI como referência, encontram benefícios como:

• Aumento de produtividade: Não se re-inventa a roda, o que deve ser feito esta definido.
• Diminuição de custo: A partir da redução do re-trabalho e aumento de produtividade.
• Estimativas mais corretas: Isso gera propostas mais adequadas o que pode representar mais negócios. Estimativas mais corretas evitam projetos deficientes.
• Qualidade: A padronização dos processos e uso das melhores práticas te leva a gerar produtos de melhor qualidade.
• Aumento da Satisfação do cliente: Há um aumento de satisfação por parte do cliente através da entrega de produtos de melhor qualidade e nos prazos acordados.

Veja o post completo →

Aqui você poderá saber onde haverá cursos sobre como: CMMI, Six Sigma, MPS.Br, PMI, entre outros… enfim, cursos de engenharia de software que lhe ajudem a melhorar a maturidade de sua organização com modelos como os citados.

Quer divulgar um curso? Entre em contato conosco.

O SPIN – Software Process Improvement Network – é uma rede composta por pessoas interessadas em conhecer e promover o aperfeiçoamento das práticas de Engenharia de Software. Ele foi originalmente proposto pelo SEI.

Os SPINs se organizam geográficamente e promovem reuniões periódicas visando a troca de experiências em programas de melhoria de processo de software tais como CMMI, MPS.Br, Six Sigma, PMI entre outros. Nestas reuniões há palestras, mini-cursos e divulgação de resultados. Assim como o Blog CMMI, os SPINs querem ajudar a disseminar a engenharia de software e aperfeiçoar nosso mercado de TI como um todo.

Próximo encontro SPIN SP Veja o post completo →

Olá, tenho recebido muitas mensagens perguntando como avaliar fornecedores que “usam CMMI”. Recebi e-mails com perguntas como:

“… Selecionamos três fornecedores que possuem certificação CMMI… Gostaria de algumas dicas do que podemos fazer para garantir que eles usam o CMMI…”
“… Como posso verificar que meu fornecedor segue o CMMI?”
“… o que meus fornecedores precisam fazer para estarem aderentes ao CMMI…”

Foram várias mensagens, mas a pergunta é praticamente a mesma: “Como avalio meus fornecedores CMMI/MPS.Br?”

Antes de mais nada, temos que lembrar que modelos como CMMI e MPS.Br nada mais são do que um conjunto de boas práticas e recomendações em gestão e engenharia de software. Um nível é atribuído quando uma empresa mostra (de forma independente e oficial) que executa determinadas práticas.

Atendendo aos diversos pedidos, montamos uma lista com 10 coisas que você (como cliente) pode analisar e verificar em seus fornecedores.

• Empresas CMMI 2 praticam os 7 primeiros itens
• Empresas CMMI 3 praticam os 9 primeiros itens
• Empresas CMMI 4 ou 5 praticam todos os itens

10 dicas do que verificar em seus fornecedores sobre CMMI e MPS.Br

1. Você recebe a equipe “que paga”?

Segundo os modelos, cada profissional deve estar apto para executar suas atividades. Entende-se por “apto” que ele possui todo conhecimento e capacitação necessários (obvio, não?). Porém, em muitas empresas isso não acontece.

Você tem certeza de que aqueles cinco programadores java “plenos” são mesmo plenos (e Java)?

Outra coisa que atrapalha muito nos projetos é a rotatividade, pois é certo que seu fornecedor não vai ter alguém na “prateleira” com o mesmo perfil e capacitação que a pessoa que saiu. Se seu projeto troca de analista toda hora, seguramente você terá problemas em breve. Isto atrapalha tanto você quanto seu fornecedor, mas, normalmente ele não vê isso como problema.

A regra é simples, se você pagou por x plenos, y seniores e z juniores, o fornecedor deve te disponibilizar estes profissionais.

Veja o post completo →

Prólogo

O objetivo deste mini-tutorial é mostrar como se inicia um projeto.
Para facilitar o entendimento (e disseminar conhecimento) ele é focado na simplicidade, facilitando assim o entendimento.

A estimativa de tamanho em APF toma por base que todos os elementos são de complexidade média, todavia é importante vocês terem em mente que isto é apenas o início. Em se interessando procurem ler mais sobre estimativa, planejamento, desenvolvimento de requisitos e controle de mudanças – aos que estão iniciando com MPS.BR ou CMMI, este tutorial vai ajudar bastante nos primeiros níveis.

Tutorial Mini Projeto – O nascimento da idéia

Um amigo te liga e pede para você fazer uma visita pois ele precisa de um projeto, ele te fala que é bem simples e precisa apenas de um aplicativo para gerenciar seus contatos.

Chegando em seu escritório, a conversa começa e ele fala que tem mais de 1.000 contatos em uma agenda (papel mesmo) e que quer (e precisa) automatizar isso. Na sua cabeça você já percebe que terá uma tela (até agora).

Conversa vai, conversa vem, ele comenta que um grande problema que ele tem é que ele não consegue dizer de onde são os contatos. Ele comenta que se ele pudesse agrupar-los, isso o ajudaria muito.

Ele também comenta que gostaria que tudo ficasse em uma única tela, ele não gosta de ficar passeando de uma tela pra outra.

Veja o post completo →

A Jornada Goiânia em Engenharia de Software é um evento sem fins lucrativos realizado pela LG Informática e pela Estratégia Tecnologia da Informação, desde 2001, em Goiânia – GO.
Trata-se de um evento técnico, voltado para o público de profissionais e estudantes da área de tecnologia da informação.

Criada para atender uma demanda existente na comunidade de profissionais,alunos e empresas de tecnologia na região Centro-Oeste, a JGES já faz parte do calendário regional de eventos sobre tecnologia, tendo como principal objetivo difundir conhecimento e experiência relevantes e atuais para um público ávido por novidades e informações consistentes na área de informática.

Em cada edição, o evento apresenta um tema relevante da atualidade, atraindo um público de bom nível e número considerável de participantes. Neste ano será realizada a nona edição do evento, que contará com mini-cursos e palestras enfocando o tema: Aplicações Práticas em Engenharia de Software.

Para mais informações sobre o evento clique aqui