sexta-feira, 16 de abril de 2010

Modelos de Maturidade

Um modelo de maturidade ou maturidade organizacional de gerenciamento de projetos, é o grau que o gerenciamento de projetos, no contexto da organização, está sendo aplicado em uma organização.

Diversos modelos surgiram com o objetivo de mensurar o nível de maturidade de gerenciamento de projetos. Tais modelos estão sendo adotados por grandes organizações para identificar o estágio atual de maturidade e buscar melhorias, que ajudem na redução de custos, passando a ser um diferencial competitivo.

O objetivo de um modelo de maturidade é avaliar e classificar técnicas e ferramentas, tendo uma relação direta com os resultados obtidos. Modelos de maturidade não são garantia de sucesso absoluto para nenhuma empresa, mas certamente servem muito bem como um guia de referência, um caminho a ser seguido por empresas que desejam melhorar seu desempenho operacional de forma consistente ao longo do tempo.

Alguns modelos de maturidade são:

  • Organizational Project Management Maturity Model (OPM3) do PMI;
  • Kezner’s Project Management Maturity Model (PMMM) do Dr. Kerzner;
  • Project Management Maturity Model (PMMM ) da PM Solutions;
  • PRINCE2 Maturity Model (P2MM);
  • Capability Maturity Model (O CMM) e
  • Melhoria de Processos de Software Brasileiro (MPS.BR).

Também existem modelos de maturidade para gerenciamento de projetos de uma área específica, a exemplo do CMMI da SEI para projetos de TI.

O CMM é um precursor dos modelos de ma­turidade, além de ser um modelo voltado à entrega de processos técnicos (indústria de softwares), extremamente difundido e aperfeiçoado entre essa indústria;

O MPS.BR (Melhoria de Processos de Software Brasileiro, cuja denominação correta do modelo é MR-MPS, mas o nome do programa que lhe deu origem – MPS.BR – tem sido mais comumente utilizado para designá-lo) é um modelo de maturidade similar ao CMM, tendo como diferenças básicas: processos e requisitos adicionais no MPS.BR ligados às áreas de gestão do conhecimento e gerência de reuso, além de apresentar maior flexibilidade na exclusão de processos a serem considerados na avaliação.

Nos exemplos abaixo são citados resultados dos processos Gerência de Projetos (GPR), Gerência de Requisitos (GRE) e Medição (MED):

GPR 7

Cada papel ou função dentro de um projeto requer uma série de conhecimentos e habilidades e o não atendimento destes “pré-requisitos” normalmente traz consigo muitos problemas.Se um analista está acostumado a especificar requisitos usando alguma técnica da análise essencial, por exemplo, ele poderia ser alocado à função de especificador usando casos de uso, desde que algum treinamento ou qualquer outra ação de capacitação que suprisse suas necessidades fosse planejada e executada. O que o modelo quer evitar é que se dê um “jeitinho” para que a pessoa com um déficit de conhecimento importante vá adquirindo esse conhecimento de qualquer forma.

GRE 1

Os requisitos devem ser documentados, entendidos e definidos, onde essa definição tem a participação de uma pessoa (ou de mais pessoas) chamada fornecedor de requisitos, que nada mais é do que o eleito por outros stakeholders do projeto (normalmente o patrocinador) para ser aquele que diz o que o software deve fazer para quem irá desenvolvê-lo.

GPR 6

A única certeza é que os riscos existem e se os mesmo não forem devidamente tratados, a probabilidade de que algum deles ocorra e prejudique algum aspecto do projeto é de quase 100%. A priorização é importante para que aquilo que é mais importante tenha um cuidado maior do que aquilo que potencialmente pode trazer menos danos ao projeto.

MED2

“Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, não há sucesso no que não se gerencia.”, ou seja, a empresa precisa se conhecer objetivamente para alcançar o sucesso. E medidas, bem entendidas, definidas, coletadas e analisadas são a base para este auto-conhecimento.

Alguns mitos sobre um modelo de maturidade são:

  • Scrum ou XP são preferíveis ao CMMI / MPS.BR porque usam uma abordagem iterativa e não cascata.

Não há a definição de uso de um ciclo de vida de projeto específico nos modelos de maturidade. O que é necessário para que haja aderência aos modelos é a definição de qual ciclo de vida será utilizado para cada um dos projetos.


  • Modelos de maturidade só se preocupam com processos, a competência das pessoas é desconsiderada.

Os processos são de fato bastante valorizados nos modelos, mas há também resultados / práticas / objetivos específicos, tanto no MPS.BR quanto no CMMI, referenciando diretamente a necessidade de competência e conhecimento das pessoas em relação às atividades que executam.


Os modelos de maturidade organizacional de gerenciamento de projetos surgiram com objetivos em comum: auxiliar as empresas na identificação e desenvolvimento do seu nível de maturidade e, com isso, ajudar às organizações a alcançarem seus objetivos estratégicos através de projetos. Diversos modelos de maturidade foram criados devido à alta demanda de auto-avaliação e melhoria contínua dos processos de gerenciamento de projetos por parte das organizações.

A escolha do modelo a ser adotado e a avaliação do nível ideal para uma organização deve ser cuidadosamente realizada com base no conhecimento do modelo e retorno esperado. Portanto, independentemente do modelo de maturidade a ser utilizado, a avaliação da maturidade e a melhoria dos processos devem ser cuidadosamente conduzidas por profissionais qualificados, de modo a atingir os objetivos estratégicos de maneira efetiva.

sexta-feira, 12 de março de 2010

Processos, métodos, ferramentas, tipos de software e Stakeholoders

1. Processo

Modo pelo qual se realiza ou executa uma coisa; método, técnica.


2. Método

Forma pela qual será realizado um processo, tendo como objetivo, definir a forma.

3. Ferramentas

O que será ultilizado para a construçao do software. As ferramentas auxiliam os métodos e processos.

4. Tipos de Software

Tempo Real - Software que apresenta um tempo de resposta menor, ou seja, resposta imediata.
On-line - Software que apresenta um tempo de resposta maior.
Ex: Compra, pela internet, de um livro por duas pessoas ao mesmo tempo.
Embarcado - Sistemas ou dispositivos que executam funções dedicadas, ou seja, são responsáveis por uma função específica ou um conjunto restrito de funções específicas e co-relacionadas.
Científico - Trata de aplicaçoes científicas.

5. Stakeholder

Qualquer pessoa ou organização que tenha interesse, ou seja afetado pelo projeto de construção de um software.

A palavra vem de:

Stake: Interesse, participação, risco
Holder: Aquele que possui

Os primeiros stakeholders que imaginamos em um projeto são: o Gerente de Projeto, o Patrocinador do Projeto, a Equipe de Projeto e o Cliente. Entretanto, na prática podem existir muitos outros:

  • A comunidade
  • Outras áreas da empresa
  • Concorrentes
  • Fornecedores
  • Investidores e acionistas
  • Governo
  • As famílias da equipe de projeto

Além disso, cada projeto pode ter alguns stakeholders que sejam específicos para sua realidade e que não se apliquem a outros projetos.

A importância de identificar os stakeholders é que além de serem afetados pelo projeto, eles podem ter uma influência direta ou indireta no seu resultado. Uma falha nesta identificação significará que o gerente de projeto não estará pensando nas necessidades de todos os envolvidos, e isto é um fator de risco para o projeto.

O CVS e seu Funcionamento

O CVS, ou Concurrent Version System (Sistema de Versões Concorrentes) é um sistema de controle de versão que permite que se trabalhe com diversas versões de arquivos, organizados em um diretório e localizados local ou remotamente, mantendo-se suas versões antigas e os logs de quem e quando manipulou os arquivos.
É especialmente útil para se controlar versões de um software durante seu desenvolvimento, ou para composição colaborativa de um documento. A exemplo de outros softwares, o CVS pode ser baixado gratuitamente e tem o seu código aberto.
O CVS utiliza uma arquitetura cliente-servidor: um servidor armazena a(s) versão(ões) atuais do projeto e seu histórico, e os clientes se conectam a esse servidor para obter uma cópia completa do projeto, trabalhar nessa cópia é então devolver suas modificações. Tipicamente, cliente e servidor devem estar conectados por uma rede local de computadores, ou pela Internet, mas o cliente e o servidor podem estar na mesma máquina se a configuração do CVS for feita de maneira a dar acesso a versões e histórico do projeto apenas a usuários locais. O servidor geralmente roda o sistema ao estilo Unix, enquanto o cliente CVS pode rodar qualquer sistema operacional.

Para que serve o Controle de Versão de Software?


O Controle de versão apóia o desenvolvimento de diversas maneiras:
• Histórico. Registra toda a evolução do projeto, cada alteração sobre cada arquivo. Com essas informações sabe-se quem fez o que, quando e onde. Além disso, permite reconstruir uma revisão específica do arquivo sempre que desejado;
• Colaboração. O controle de versão possibilita que vários desenvolvedores trabalhem em paralelo sobre os mesmos arquivos sem que um sobrescreva o código de outro, o que traria reaparecimento de defeitos e perda de funcionalidades;
• Variações no Projeto. Mantém linhas diferentes de evolução do mesmo projeto. Por exemplo, mantendo uma versão 1.0 enquanto a equipe prepara uma versão 2.0.
Enfim,o controle de versão é fundamental para o desenvolvimento de software. Todos os ambientes de desenvolvimento modernos, tais como o Eclipse e o NetBeans, já possuem plugins para integração com algum sistema de controle de versão.

Controle de Versão de Software

O controle de versão de software, é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões – histórico e desenvolvimento – dos códigos-fontes e também da documentação.
Esse tipo de sistema é muito presente em empresas e instituições de tecnologia e desenvolvimento de software. É também muito comum no desenvolvimento de software livre; além de ser útil, em diversos aspectos, tanto para projetos pessoais pequenos e simples como também para grandes projetos comerciais.

O que são Ferramentas CASE e para que elas servem?


A sigla CASE significa “Computer-Aided Software Engineering”. Traduzindo para um bom português: “Engenharia de Software Auxiliada por Computador”.Uma ferramenta CASE é um aplicativo que auxilia os profissionais envolvidos na tarefa de produzir sistemas. O tipo de “ajuda” que a ferramenta fornece, depende exclusivamente da proposta do fabricante. Por este motivo, as ferramentas se dividem em três categorias. São elas:

01. Lower CASE - ferramentas de codificação (front-end);
02. Upper CASE - ferramentas de análise, projeto e implementação;
03. Integrated CASE - união de Upper e Lower CASE.

Um dos componentes indispensáveis de uma ferramenta CASE é a modelagem visual, ou seja, a possibilidade de representar, através de modelos gráficos, o que está sendo definido.

quinta-feira, 11 de março de 2010

Mitos do Software

Segundo [Pressman], diversos mitos difundidos entre programadores escondem a importância de um desenvolvimento de software de acordo com os princípios de uma engenharia. Vejamos alguns deles:

  • O estabelecimento de objetivos gerais é suficiente para se começar a escrever programas;
  • Uma vez que o programa esteja escrito e funcionando, nosso trabalho está feito;
  • Mudanças no software podem ser feitas facilmente porque ele é "flexível";
  • Dê a uma pessoa técnica um bom livro de programação e você terá um programador;
  • Até que o programa esteja "rodando" não é possível verificarmos a sua qualidade;
  • Um projeto é bem sucedido se conseguirmos um programa funcionando corretamente.