3. EDITORIAL
“Se observarmos nos diferentes livros tradicionais de Enge-
nharia de Software, veremos que sempre existe um capítulo ou
seção destinado a Teste de software. Porém, eles normalmente
apresentam apenas informações básicas sobre esta atividade,
Ano 1 - 6ª Edição 2008 - Impresso no Brasil como por exemplo, os diferentes níveis de teste que podem
Corpo Editorial
ser aplicado, as técnicas de teste que podem ser aplicadas e os
Colaboradores critérios para seleção dos testes associados a estas técnicas. Por
Rodrigo Oliveira Spínola exemplo, no artigo “Introdução a Teste de Software” publicado
rodrigo@sqlmagazine.com.br
na edição 01 da Engenharia de Software Magazine discutimos
Marco Antônio Pereira Araújo sobre alguns desses critérios: Particionamento em classes de
Eduardo Oliveira Spínola
equivalência, Análise do Valor Limite e Grafo de Causa-Efeito.
Editor de Arte
Vinicius O. Andrade Para cada critério, vimos como aplicá-los e um exemplo da sua
viniciusoandrade@gmail.com aplicação para a geração de casos de teste.”
Diagramação “No entanto, no desenvolvimento de um software real nor-
Roberta F. Leal Arman
roberta.arman@gmail.com malmente os problemas são bem mais complexos do que
Revisão aqueles tradicionalmente usados quando estamos conhe-
Gregory Monteiro cendo esses critérios para seleção dos testes (ex: indicar qual
gregory@clubedelphi.net
o maior valor em um conjunto, indicar se um campo número
Na Web
www.devmedia.com.br/esmag
só contém caracteres válidos, dentre outros). Normalmente
Apoio
os problemas a serem resolvidos são representados através
de cenários, que podem ser facilmente representados por
Diagramas de Casos de Uso da UML (www.uml.org) aliada a
uma descrição do que cada caso de uso deve fazer.”
Neste contexto, a Engenharia de Software Magazine des-
PARCEIROS: taca nesta edição uma matéria muito interessante sobre a
elaboração de casos de teste. Será apresentada uma possível
estratégia indicando como testes podem ser obtidos a partir
dos casos de uso especificados para um projeto.
Além destas duas matérias, esta sexta edição traz mais seis artigos:
Rodrigo Oliveira Spínola • Testes com Objetos Mock: Utilizando o framework Easy-
rodrigo@sqlmagazine.com.br Mock para teste unitário de aplicações Java;
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação
• Utilizando Visualização de Informação para Compreen-
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo mi- são de Software;
nistrado cursos na área de Qualidade de Produtos e Processos de Software, Requisi- • Conceitos Introdutórios sobre Melhoria e Avaliação de
tos e Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS. Processos de Software;
BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria
na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine. • Fundamentos de Arquitetura de Software;
• Inspecionando a Usabilidade de Produtos;
Marco Antônio Pereira Araújo • Gerenciamento de Projetos: Entenda alguns dos princi-
(maraujo@devmedia.com.br)
pais conceitos;
É Doutorando e Mestre em Engenharia de Sistemas e Computação pela COPPE/
UFRJ – Linha de Pesquisa em Engenharia de Software, Especialista em Métodos • Soluções para Gerenciamento de Riscos de Projetos.
Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Desejamos uma ótima leitura!
Informática pela UFJF, Professor dos Cursos de Bacharelado em Sistemas de
Informação do Centro de Ensino Superior de Juiz de Fora e da Faculdade Meto- Equipe Editorial Engenharia de Software Magazine
dista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora. É editor da
Engenharia de Software Magazine.
Eduardo Oliveira Spínola Dê seu feedback sobre esta edição!
(eduspinola@gmail.com)
A Engenharia de Software Magazine tem que ser feita ao seu gosto. eu
Feedback
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e
s
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê
SQL Magazine. É bacharel em Ciências da Computação pela Universidade Salva-
sobre e
dor (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação Dê seu voto sobre este artigo, através do link:
na linha de Engenharia de Software, sendo membro do GESA (Grupo de Enge-
s
ta
www.devmedia.com.br/esmag/feedback d i çã o e
nharia de Software e Aplicações).
4. Caro Leitor,
Para esta sexta edição, temos um conjunto de 8 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia de
Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
01 – Engenharia de Requisitos 05 – Projeto
Título: Introdução à Engenharia de Requisitos - Parte 19 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 2
Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de requisitos. Mini-Resumo: Esta vídeo aula apresenta a notação da UML para elaboração de
Nesta décima nona parte apresentaremos passo a passo a especificação de um caso de uso diagramas de classes considerando os conceitos de classe, atributo e operação.
considerando o cenário de consulta por clientes cadastrados de uma organização fictícia.
06 – Projeto
02 – Engenharia de Requisitos Título: Introdução à Construção de Diagrama de Classes da UML – Parte 3
Título: Introdução à Engenharia de Requisitos - Parte 20 Autor: Rodrigo Oliveira Spínola
Autor: Rodrigo Oliveira Spínola Mini-Resumo: Esta vídeo aula apresenta a notação da UML para elaboração
Mini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de requisitos. de diagramas de classes considerando os relacionamentos de herança e
Nesta vigésima parte finalizaremos a especificação do caso de uso iniciada na aula anterior. associação.
03 – Engenharia de Requisitos 07 – Projeto
Título: Introdução à Engenharia de Requisitos - Parte 21 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 4
Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de requisitos. Mini-Resumo: Esta vídeo aula apresenta a notação da UML para elaboração
Nesta vigésima primeira parte apresentaremos passo a passo a especificação de um caso de diagramas de classes considerando os relacionamentos de agregação e
de uso considerando o cenário de inclusão de cliente para uma organização fictícia. composição.
04 – Engenharia de Requisitos 08 – Projeto
Título: Introdução à Engenharia de Requisitos - Parte 22 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 5
Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de Mini-Resumo: Esta vídeo aula apresenta uma heurística para elaboração de
requisitos. Nesta vigésima segunda parte finalizaremos a especificação do caso de uso diagramas de classes. Para isto, são apresentados alguns passos que podem ser
iniciada na aula anterior. seguidos para a apoiar a construção passo a passos destes diagramas.
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendi-
ÍNDICE
mento ao leitor. Se você tiver algum problema no recebimento do
06 - Conceitos Introdutórios sobre Melhoria e Avaliação de Processos de Software
seu exemplar ou precisar de algum esclarecimento sobre assinaturas,
Rodrigo Oliveira Spínola
exemplares anteriores, endereço de bancas de jornal, entre outros,
entre em contato com: 14 - Gerenciamento de Projetos
Carmelita Mulin – Atendimento ao Leitor
www.devmedia.com.br/central/default.asp Andrey Abreu
(21) 2220-5375
Kaline Dolabella 20 - Utilizando Visualização de Informação para Compreensão de Software
Gerente de Marketing e Atendimento
kalined@terra.com.br Eduardo Oliveira Spínola
(21) 2220-5375
28 - Fundamentos de Arquitetura de Software
Rodrigo Oliveira Spínola e Rafael Ferreira Barcelos
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre 36 - Planejamento de Testes a partir de Casos de Uso
em contato com:
Arilo Cláudio Dias Neto
Kaline Dolabella
publicidade@devmedia.com.br 42 - Testes com Objetos Mock
Marco Antônio Pereira Araújo
Fale com o Editor!
É muito importante para a equipe saber o que você está achando da revista: que 48 - Inspecionando a Usuabilidade de Produtos
tipo de artigo você gostaria de ler, que artigo você mais gostou e qual artigo Antônio Mendes da Silva Filho
você menos gostou. Fique a vontade para entrar em contato com os editores e
dar a sua sugestão! 54 - Soluções para Gerenciamento de Riscos de Projetos
Se você estiver interessado em publicar um artigo na revista ou no site SQL Ma-
gazine, entre em contato com os editores, informando o título e mini-resumo Cristine Gusmão
do tema que você gostaria de publicar:
60 - Introdução à Gestão de Conhecimento
Rodrigo Oliveira Spínola - Colaborador
editor@sqlmagazine.com.br Rodrigo Oliveira Spínola
6. Conceitos Introdutórios sobre Melhoria e
Avaliação de Processos de Software
De que se trata o artigo: trado. É necessário corrigir o processo que
Apesar da crescente demanda por sof- permitiu que este fosse inserido, pois, des-
tware em praticamente todas as áreas do ta forma, não será necessário corrigir os
conhecimento, o processo de produção mesmos problemas em trabalhos futuros.
continua sendo um esforço coletivo, criati- Com isto em mente, este artigo apresenta
vo e complexo, por isso, precisa ser discipli- de forma abrangente o assunto melhoria
nado, acompanhado e controlado de forma de processo de software.
a se tornar efetivo e eficiente para a orga-
Para que serve:
nização. O foco no processo permite que
Estabelecer boas práticas para facilitar
um grupo de indivíduos alinhe o compor-
os trabalhos envolvidos na melhoria de
tamento e as atividades de cada membro
processos de software.
no sentido de alcançar o objetivo comum.
Assim, acredita-se que a qualidade do pro- Em que situação o tema é útil:
duto final está fortemente relacionada à Empresas que estão em busca de exce-
qualidade do processo utilizado para o seu lência no desenvolvimento de software
desenvolvimento e manutenção. Quando possuem como uma de suas alternativas
um produto possui algum problema, não o trabalho fundamento em processos e
se deve corrigir somente o defeito encon- sua melhoria contínua.
Rodrigo Oliveira Spínola
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e Com-
putação (COPPE/UFRJ). Mestre em Engenharia
de Software (COPPE/UFRJ, 2004). Bacharel em
Ciências da Computação (UNIFACS, 2001). Co-
laborador da Kali Software (www.kalisoftware.
com), tendo ministrado cursos na área de Qua-
lidade de Produtos e Processos de Software, Re-
quisitos e Desenvolvimento Orientado a Objetos.
Consultor para implementação do MPS.BR. Atua
como Gerente de Projeto e Analista de Requisi-
tos em projetos de consultoria na COPPE/UFRJ. É
Colaborador Engenharia de Software Magazine.
6 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
7. PROCESSO
A
melhoria do processo de sof- dimentos empregados na execução de Avaliação de Processo de Software
tware pode ser considerada hoje atividades projetadas para produzir um As avaliações de processo de software
uma das grandes prioridades resultado específico; são realizadas para atender a diferentes
para as organizações que trabalham com • Para FUGGETTA (2000), um processo objetivos, geralmente estão delimitadas
software. Isto se deve à exigência do mer- de software é definido como um conjunto a diferentes escopos e, a depender das
cado por produtos com maior qualidade, coerente de políticas, estruturas organi- características dos modelos e métodos
que sejam entregues mais rapidamente e zacionais, tecnologias, procedimentos e aplicados, ainda são classificadas como
com menor custo de desenvolvimento. artefatos que são necessários para conce- pertencendo a diferentes paradigmas.
Estudos apontam que ao tentarem me- ber, desenvolver, disponibilizar e manter Uma vez que este conjunto de carac-
lhorar seus processos, as empresas estão um produto de software; terísticas podem afetar de forma dife-
em busca de: • E, finalmente, a ISO/IEC 12207 (1995) renciada uma avaliação de processo,
• entender as características dos pro- define como um conjunto de atividades existem também na literatura diferentes
cessos existentes e os fatores que afetam inter-relacionadas, que transforma en- definições para avaliação de processo:
a sua capacidade; tradas em saídas. • Para ZAHRAN (1997), uma avalia-
• planejar, justificar e implementar Neste sentido, é importante destacar ção de processo de software é um exame
ações que modificarão os processos, tor- o trabalho da International Standard disciplinado do processo de software
nando-os mais coerentes com as necessi- Organization (ISO) que estabeleceu utilizado pela organização, baseado em
dades de negócios e; uma norma padrão para processo de um modelo de processo. O objetivo é de-
• avaliar os impactos e benefícios ga- software ISO/IEC 12207 (1995) propon- terminar o nível de maturidade desses
nhos, comparando-os com os custos ad- do um framework com terminologia processos. O resultado deve identificar
vindos das mudanças realizadas. bem definida e contendo processos, e caracterizar as práticas correntes, iden-
Neste contexto de melhoria de proces- atividades e tarefas que devem ser tificando áreas de força e fraqueza e a
so, é importante destacar uma das ativi- aplicados durante a aquisição, o for- eficácia das práticas atuais em controlar
dades de maior importância: a avaliação necimento, o desenvolvimento, a ope- ou evitar as principais causas de baixa
dos processos utilizados durante a exe- ração e a manutenção de software. A qualidade, custo e cronograma ultrapas-
cução dos projetos. norma descreve a arquitetura de um sados. Os resultados de uma avaliação
Com o objetivo de apoiar a melhoria de processo de forma geral, mas não es- também podem ser usados como um in-
processo, diversos métodos surgiram ao pecifica em detalhes como implemen- dicador da capacidade desses processos
longo dos últimos anos. Alguns méto- tar ou desempenhar estas atividades, em alcançar os objetivos do desenvolvi-
dos avaliam os processos da organiza- nem descreve formato ou conteúdo da mento de software em relação à quali-
ção tomando como base algum modelo documentação a ser gerada, o que deve dade, custo e cronograma com um alto
de referência, que descreve um conjunto ser definido pela organização que pre- grau de predição.
de princípios e práticas e assume que, tende utilizá-lo de acordo com suas • Segundo HUMPHREY (1989), uma
se devidamente seguidas, irão levar a necessidades e as características parti- avaliação do processo de software é
melhores produtos de soft ware. Outros culares de cada projeto. um exame aplicado a uma organização
métodos utilizam as medições para en- Outro conceito muito importante para que desenvolve software com o objeti-
tender e avaliar os processos em uso e, conhecermos neste momento é o de vo de advertir seus gerentes e profis-
somente então, tomar ações que levem à Maturidade do Processo de Soft ware. sionais a respeito de como melhorar as
melhoria do processo. Este teve sua origem em esforços do suas operações.
Neste artigo apresentaremos alguns Soft ware Engineering Institute (SEI) ao • De acordo com a definição da ISO/IEC
conceitos relacionados a processos de atender uma solicitação da Força Aé- 12207 (1995), uma avaliação é uma deter-
software e alguns dos principais mé- rea Americana que necessitava de um minação sistemática do grau de atendi-
todos de avaliação de processo atual- método para avaliar a capacidade em mento de uma entidade em relação aos
mente utilizados para apoiar a melho- desenvolver soft ware das organizações critérios para ela estabelecidos.
ria do processo. que lhe prestavam serviços terceiriza- Neste cenário, KAN (2003) considerou
dos. PAULK et al. (1995) defi niram capa- alguns aspectos importantes para as
Processo de Software cidade como o intervalo de resultados avaliações de processos:
Podemos encontrar na literatura téc- esperados que podem ser alcançados
nica diversas definições para processo com o uso de um processo, e maturida- Contexto da avaliação
de software: de como a amplitude na qual um pro- Uma avaliação de processo pode ser
• HUMPHREY (1989) define processo cesso específico é defi nido, gerenciado, realizada em diferentes contextos,
como um conjunto de atividades, méto- medido, controlado e executado. dependendo de quem irá desempe-
dos e práticas utilizadas na produção e O resultado do trabalho do SEI (HUM- nhar os papeis essenciais durante a
no desenvolvimento de software; PHREY, 1989) representa a base de di- avaliação. Dessa forma, uma avalia-
• FLORAC et al. (1997) definem como versos outros modelos e normas com o ção pode ocorrer:
uma organização lógica de pessoas, ma- objetivo de aumentar a maturidade dos • internamente, quando é realizada
teriais, energia, equipamentos e proce- processos de software. uma auto-avaliação onde os principais
Edição 06 – Engenharia de Software Magazine 7
8. sos da organização, um subconjunto se-
lecionado dos processos ou um projeto
específico (KAN , 2003). Para a maioria
das avaliações de processo baseadas nos
conceitos de maturidade ou capacidade
(por exemplo, CMMI, Bootstrap, ISSO/
IEC 15504, MR MPS), a unidade de análi-
se é normalmente o nível organizacional.
Quando o alvo da avaliação é a orga-
nização, os resultados de uma avaliação
de processo podem ser diferentes, mes-
mo com sucessivas aplicações do mesmo
método. Isso acontece pelo fato que, em
grandes empresas, varias definições de
organização são possíveis e o escopo da
avaliação pode ser diferente em avalia-
ções sucessivas. Outra fonte de variação é
Figura 1. Melhoria de processo com a norma ISO/IEC 15504 (ISO 1998)
1 (ISO, 1998). a amostragem de projetos escolhida para
representar a organização; isso pode afe-
tar o escopo e os resultados.
Quando a unidade de avaliação é apenas
um projeto, os problemas associados com
a avaliação a nível organizacional dei-
xam de ser relevantes. Uma avaliação de
projeto de software deve incluir todos os
fatores significativos que contribuem para
o sucesso ou falha de um projeto. As ava-
liações de projeto tratam, em profundida-
de, não somente “quais” atividades foram
realizadas, mas também do “como” e “por
que” foram realizadas. Dessa forma, a in-
vestigação exaustiva é uma característica
chave de avaliação de projeto de software.
A avaliação de processo baseada em
maturidade de processo torna-se rele-
Figura 2. Determinando a capacidade através do uso da ISO 15504 (ISO, 1998). vante quando uma organização tem a
intenção de embarcar em uma estratégia
papéis são desempenhados por uma processo. De acordo com a norma, a orga- geral de melhoria a longo prazo. Porém,
equipe que pertence à própria organiza- nização deve definir os objetivos e o con- os dois tipos de avaliação podem ser
ção sendo avaliada; texto, escolher o modelo e o método para a complementares: a avaliação da matu-
• externamente, sendo realizada avaliação e definir os objetivos de melhoria ridade do processo para uma estratégia
por uma equipe de avaliação externa (ROCHA et al., 2001). geral de melhoria para a organização e
à organização; No segundo caso, determinar a capaci- avaliações de projeto para direcionar
• ou ainda pode ser realizada por tercei- dade dos processos de uma organização, ações de melhoria imediatas e específi-
ros, quando um fornecedor é avaliado por o objetivo é avaliar um fornecedor em cas no nível de projeto.
uma equipe externa para que seja averi- potencial para obter seu perfil de capaci-
guada a sua capacidade em atender aos dade. A Figura 2 mostra como a ISO/IEC Abordagens de avaliação
requisitos da organização contratante. 15504 (1998) é utilizada para determinar Vários modelos, métodos e técnicas de
a capacidade de processos. De acordo melhoria estão disponíveis e podem ser
Objetivo da Avaliação com a norma, a organização deve definir divididos em duas grandes vertentes:
Geralmente, uma avaliação de proces- os objetivos e o contexto da avaliação, os • A abordagem top-down, que é forte-
so é realizada para atender a dois objeti- modelos e métodos de avaliação e os re- mente baseada em avaliações e benchma-
vos: a melhoria dos processos e a deter- quisitos esperados (ROCHA et al., 2001). rking. São os casos do CMM (PAULK et
minação da capacidade dos processos al., 1993), ISO/IEC 15504 (2003), o BOOTS-
de uma organização. Escopo da Avaliação TRAP (KUVAJA, 1994), CMMI (CMU/SEI,
A Figura 1 mostra como a norma ISO/IEC O escopo de uma avaliação do processo 2002) e do MR mpb (Sociedade SOFTEX,
15504 (1998) é utilizada para a melhoria de de software pode cobrir todos os proces- 2004a) (Sociedade SOFTEX, 2004b).
8 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
9. PROCESSO
• A abordagem bottom-up, que utiliza Apesar dos modelos serem úteis para e o “modelo em estágios”. A representação
principalmente a medição como o guia muitas organizações, o uso de múltiplos em estágios define um conjunto de áreas
para a melhoria de processo. Por exem- modelos gerou alguns problemas devido de processo para definir um caminho de
plo, o GQM (BASILI et al., 1994). às diferenças de arquitetura, conteúdo melhoria para a organização, descrito em
Na abordagem top-down, normalmen- e abordagem. Além disso, a aplicação termos de níveis de maturidade (melhoria
te se aplica um modelo normativo que é de diversos modelos não integrados em vertical). A representação contínua per-
assumido como a melhor maneira de se uma organização aumenta os custos de mite que uma organização selecione uma
desenvolver software. Avaliando uma treinamento, das avaliações e das ativi- área de processo específica e melhore com
organização utilizando-se este modelo, dades de melhoria. relação a esta área. A representação contí-
torna-se possível identificar a maturida- Por estas razões, o SEI iniciou o projeto do nua usa níveis de capacidade para carac-
de desta organização e propor melhorias CMMI (CMM Integration), com o objetivo terizar a melhoria relacionada a uma área
relevantes. Já a abordagem bottom-up é de integrar as práticas de forma que orga- de processo específica.
baseada na análise cuidadosa das práti- nizações que almejem melhorar seus pro- Ambas as representações contêm es-
cas de processo aplicadas, na seleção de cessos nas diferentes disciplinas tenham a sencialmente as mesmas informações e a
objetivos de melhoria derivados dessa disposição um único modelo consistente. opção pelo modelo contínuo ou em está-
análise e na gerência de atividades de Sendo assim, o CMMI integra os diver- gios depende de cada organização. Cada
melhoria apoiadas por medições. sos CMMs numa estrutura única, todos modelo possui características que o tor-
com a mesma terminologia, processos de nam mais apropriado em uma situação
Modelos de Avaliação de Processo avaliação e estrutura. O projeto também ou outra (CMU/SEI, 2002).
de Software se preocupou em tornar o CMM com- O modelo em estágios oferece um
A partir de agora serão apresentados patível com a norma ISO/IEC 15504, de caminho para melhoria de processos,
alguns modelos de apoio à melhoria de modo que avaliações em um modelo se- indicando a ordem de implementação
processo e como é realizada a avaliação jam reconhecidas como equivalentes aos para cada área de processo de acor-
em cada um deles. do outro (CMU/SEI, 2002). do com os níveis de maturidade. Essa
Para permitir esta compatibilidade, o abordagem minimiza os riscos da me-
CMMI CMMI oferece duas representações dife- lhoria de processos. A representação é
Desde a década de 90, baseado no su- rentes para a sua abordagem de melhoria indicada para organizações realmente
cesso alcançado pelo SW-CMM (CMM de processos. Estas duas representações comprometidas com a implantação do
para software), um número significativo são conhecidas como o “modelo contínuo” CMMI em escala geral.
de modelos de maturidade de processo
foi desenvolvido para diferentes discipli- Nível de Maturidade Foco Áreas de Processo
nas. Assim surgiram os seguintes mode- Inicial Sem foco, processos são ad hoc e caóticos. Não há áreas de processo neste nível.
los (CMU/SEI, 2002):
Gerencial O foco está na gerência de projeto. • Gerência de requisitos
• Software Acquisition CMM (AS-
• Planejamento de projetos
CMM) – usado para avaliar a maturida-
• Monitoração e controle de projetos
de de uma organização em seus proces-
• Gerência de acordos com fornecedores
sos de seleção, compra e instalação de
• Medição e análise
software desenvolvido por terceiros;
• Garantia da qualidade do processo e do produto
• Systems Enginnering CMM (SE-CMM)
• Gerência de configuração
– usado para avaliar a maturidade da or-
ganização em seus processos de engenha- Definido O foco está na institucionalização do pro- • Desenvolvimento de requisitos
ria de sistemas, incluindo o hardware, o cesso. • Solução técnica
software e quaisquer outros elementos • Integração do produto
que participam do produto completo; • Verificação
• Integrated Product Development • Validação
CMM (IPD-CMM) – ainda mais abran- • Foco no processo organizacional
gente que o SE-CMM, inclui também ou- • Definição do processo organizacional
tros processos necessários à produção e • Gerência integrada do produto
suporte ao produto, tais como suporte ao • Gerência de riscos
usuário, processos de fabricação, etc; • Análise de decisão e resolução
• People CMM (P-CMM) – usado para • Ambiente organizacional para integração (IPPD)
avaliar a maturidade da organização • Equipe integrada (IPPD)
em seus processos de administração de Gerência Quantitativa O foco está na gerência quantitativa. • Desempenho do processo organizacional
recursos humanos no que se refere a • Gerência quantitativa de projeto
software: recrutamento e seleção de de- Otimizado O foco está na melhoria contínua do pro- • Inovação e disseminação organizacional
senvolvedores, treinamento e desenvol- cesso. • Análise e resolução de causas
vimento, remuneração, etc. Tabela 1. Níveis de maturidade do CMMI.
Edição 06 – Engenharia de Software Magazine 9
10. O modelo em estágios avalia uma or- • No nível 4 de capacidade (Gerenciado Para conduzir uma avaliação no local
ganização como estando nos níveis de quantitativamente), a área de processo é de trabalho, as seguintes atividades de-
maturidade de processo apresentados gerenciada quantitativamente utilizan- vem ser realizadas:
na Tabela 1. do-se de técnicas estatísticas e outras • Examinar as evidências – que com-
O modelo contínuo oferece uma aborda- técnicas quantitativas; preende coletar as informações a respei-
gem mais flexível para a melhoria de pro- • Ao atingir o nível 5 de capacidade (Oti- to das práticas implementadas na unida-
cessos, embora mais complexo de admi- mizado), a área de processo é gerenciada de organizacional e relacionar os dados
nistrar. É indicado para organizações que quantitativamente (capacidade nível 4) e coletados ao modelo de referência;
desejam dar prioridade à melhoria de uma alterada e adaptada para adequar-se aos • Verificar e validar as evidências –
área de processo ou conjunto de processos, objetivos de negócio da empresa. consiste em verificar a implementação
de acordo com seus objetivos de negócio. das práticas nas unidades organizacio-
Este modelo permite fácil comparação à Avaliação CMMI nais para cada instanciação e validar os
ISO/IEC 15504, porque a organização das O método de avaliação CMMI padrão para resultados da implementação descre-
áreas de processo é derivada desta norma. melhoria de processo chama-se SCAMPI. vendo as falhas na implementação das
Quando a representação contínua é uti- Ele foi desenvolvido para satisfazer os re- práticas do modelo;
lizada numa avaliação, uma área de pro- quisitos do modelo CMMI (CMU/SEI, 2002). • Documentar as evidências – registra
cesso é avaliada como estando em um de- A avaliação segundo o SCAMPI consiste de as informações obtidas identificando e
terminado nível de capacidade. Existem três fases: planejamento e preparação, con- consolidando os dados e transformado-
seis níveis de capacidade, numerados de dução de uma avaliação no local de trabalho os em registros que documentem a im-
zero a cinco. Para uma área de processo e a apresentação dos resultados. plementação das práticas, assim como
atingir determinado nível de capacidade, Para o planejamento e preparação, as se- suas forças e fraquezas;
os objetivos específicos e, conseqüente- guintes atividades devem ser realizadas: • Gerar os resultados da apresentação -
mente, as práticas específicas destes ob- • Identificar o escopo da avaliação – Mede a satisfação dos objetivos baseado
jetivos devem ser satisfeitas: onde ocorre o levantamento das necessi- na extensão da implementação da práti-
• No nível de capacidade 0 (Incomple- dades de negócio da unidade organiza- ca através da unidade organizacional. A
to), a área de processo não é realizada ou cional sendo avaliada; extensão da implementação da prática é
é parcialmente realizada; • Desenvolver o plano da avaliação – determinada baseada nos dados valida-
• Uma área de processo alcança o nível onde ficam registrados os requisitos do dos, coletados de toda a amostra das uni-
1 de capacidade (Realizado) quando está plano de avaliação, acordos, estimativas, dades organizacionais.
sendo realizada, ou mais precisamente, riscos, métodos de adaptação e conside- Quanto à apresentação dos resultados,
quando os objetivos específicos da área rações práticas associadas à avaliação; as seguintes atividades são realizadas:
de processo são alcançados; • Selecionar e preparar a equipe de ava- • Apresentar os resultados da avalia-
• Alcançando o nível 2 de capacidade liação – uma equipe treinada, experiente e ção – Provê resultados da avaliação que
(Gerenciado), a área de processo neces- apropriadamente qualificada é seleciona- podem ser usados para guiar ações de
sita que seu desempenho esteja sendo da para conduzir o processo de avaliação; melhoria. As forças e as fraquezas dos
gerenciado. Diferente do nível 1, uma • Obter e analisar as evidências iniciais processos em uso também são apre-
área de processo no nível 2 dispõe de um - obtém informações que identifiquem sentadas. Além disso, determina, se
plano para a sua realização, assim como áreas potencialmente problemáticas ou planejado, qual o nível de capacidade
um processo concebido para cobrir esta falhas na implementação das práticas; ou o nível de maturidade dos proces-
área de processo; • Preparar para a coleta de evidências sos em uso.
• No nível 3 de capacidade (Definido), – consiste em planejar e documentar a • Empacotar e arquivar os resultados
a área de processo está sob o controle de coleta de dados incluindo as fontes de da avaliação – guarda registros e da-
um processo padrão organizacional para dados, ferramentas e técnicas a serem dos importantes da avaliação e dispo-
a área de processo e este pode ser adap- usadas e contingências para gerenciar o nibiliza o material selecionado de ma-
tado para necessidades específicas; risco da falta de dados. neira apropriada.
10 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
11. PROCESSO
ISO/IEC 15504 demonstram se determinado processo é Essa norma define um conjunto de re-
A ISO iniciou, em janeiro de 1993, o adequadamente praticado em um deter- quisitos para um Modelo de Avaliação
projeto SPICE (Software Process Im- minado nível de capacidade. Há seis ní- e para um Método de Avaliação. Uma
provement and Capability dEtermi- veis de capacidade em que um processo avaliação que esteja de acordo com estes
nation) com o objetivo de produzir pode ser avaliado: requisitos é referenciada como uma ava-
inicialmente um Relatório Técnico que • Nível 0 - Processo incompleto: O pro- liação em conformidade com a avaliação
fosse mais geral e abrangente que os cesso não é implementado ou falha na ISO/IEC 15504 (2003).
modelos existentes e mais específico consecução de seu propósito. Não existe Ela não define um método de avaliação
que a norma ISO 9001. Uma versão do evidência de que os produtos de trabalho explícito, definindo apenas os requisitos
SPICE foi aprovada em 1998 como Rela- sejam adequadamente produzidos ou necessários. Isto significa que as empre-
tório Técnico (ISO/IEC TR 15504, 1998) e, que os resultados sejam alcançados; sas podem desenvolver os seus próprios
apenas em 2003, a Norma ISO/IEC 15504 • Nível 1 - Processo executado: O pro- métodos de avaliação em conformidade
(ISO/IEC 15504, 2003) foi publicada. cesso implementado alcança seu propó- com a ISO/IEC 15504 (2003).
A ISO/IEC 15504 pode ser utilizada sito, mas sua execução talvez não seja ri-
para a melhoria de processos e para a de- gorosamente planejada e acompanhada; GQM
terminação da capacidade de processos • Nível 2 - Processo gerenciado: O O GQM representa uma abordagem
de uma organização. Quando o objetivo processo executado anteriormente é sistemática para adaptar e integrar obje-
da organização for a melhoria de pro- agora implementado de forma geren- tivos de negócio aos modelos de processo
cessos, pode-se avaliá-los, gerando um ciada (planejado, monitorado e ajus- de software baseando-se em necessida-
perfil dos processos a ser utilizado na tado) e seus produtos de trabalho são des específicas de um projeto ou de uma
elaboração de um plano de melhorias. A apropriadamente estabelecidos, con- organização (BASILI et al., 1994).
análise dos resultados identifica os pon- trolados e mantidos; O resultado da aplicação do método do
tos fortes e fracos e os riscos inerentes • Nível 3 - Processo estabelecido: O GQM é a especificação de um programa
aos processos. Já quando o objetivo da processo gerenciado anteriormente é de medição que tem como objetivo in-
empresa for avaliar fornecedores para agora implementado utilizando um pro- vestigar determinados assuntos, e um
contratação, esta pode obter seus perfis cesso definido e é capaz de alcançar seus conjunto de regras para interpretar as
de capacidade. resultados de processo; medidas coletadas.
O modelo de referência da ISO/IEC • Nível 4 - Processo previsível: O pro- Dentro de um contexto de avaliação do
15504 (2003) define a dimensão de pro- cesso estabelecido anteriormente opera processo de software, o GQM pode ser
cesso, que corresponde à definição de agora dentro de limites para alcançar os utilizado para estabelecer um programa
um conjunto de processos considerados resultados de processo; de medição que possibilite investigar o
universais e fundamentais para a boa • Nível 5 - Processo otimizado: O pro- desempenho de determinados proces-
prática da engenharia de software e a di- cesso previsível anteriormente é melho- sos, tornando-se uma abordagem bas-
mensão de capacidade, que corresponde rado continuamente para satisfazer os tante eficaz para a monitoração e o con-
à definição de um modelo de medição objetivos de negócio atuais e projetados trole dos processos.
com base na identificação de um conjun- mais relevantes. O princípio por trás do método GQM
to de atributos que permite determinar a é que as medições sejam orientadas por
capacidade de um processo para atingir Avaliação ISO/IEC 15504 objetivos. Dessa forma, tanto para ava-
seus propósitos, gerando os produtos de Uma avaliação segundo a norma ISO/ liar quanto para melhorar seus proces-
trabalho e os resultados estabelecidos. IEC 15504 (2003) considera três tipos de sos, as organizações devem definir seus
Na dimensão de capacidade, as tare- elementos como importantes para sua objetivos de medição, baseados nos seus
fas, atividades e práticas, bem como as realização: um modelo de avaliação; um objetivos de negócio e transformar esses
características dos produtos de traba- método de avaliação; um ou mais avalia- objetivos em atividades que podem ser
lho, são defi nidas como indicadores que dores competentes. medidas durante a execução do projeto.
Edição 06 – Engenharia de Software Magazine 11
12. O GQM define um determinado objeti-
vo, refina este objetivo em questões e de-
fine métricas que devem propiciar infor-
mações que respondam a estas questões.
Respondendo às questões, os dados
medidos defi nem o objetivo operacio-
nalmente e podem ser analisados para
identificar se os objetivos foram ou não
alcançados. O GQM defi ne as métricas
em uma perspectiva top-down e anali-
sa e interpreta os dados medidos numa
Figura 3. O paradigma GQM (BASILI e WEISS 1984)
3 WEISS, 1984). perspectiva bottom-up, como mostrado
na Figura 3.
O método GQM é composto de quatro
fases (SOLINGEN e BERGHOUT, 1999).
Na fase de planejamento, os requisitos bá-
sicos para tornar o programa de medição
viável são executados, incluindo treina-
mento, envolvimento da gerência e pla-
nejamento do projeto. A fase de definição
identifica os objetivos e as questões e mé-
tricas associadas a cada objetivo. Durante
a fase de coleta de dados os formulários
de coleta são definidos, preenchidos e
armazenados na base de medições. Du-
Figura 4. As quatro fases do método GQM (SOLINGER e BERGHOUT, 1999). rante a fase de interpretação as medidas
são utilizadas para responder as questões
Referências formuladas, e essas questões são, então,
utilizadas novamente para verificar se os
BASILI, V. R., WEISS, D., 1984, “A Methodology for Collecting Valid Software Engineering Data”, IEEE Transactions on Software Engineer-
ing, Vol. 10, No. 3, Nov, pp. 728-738.
objetivos declarados foram atingidos.
BASILI, V. R., CALDIERA, G., ROMBACH, H.D., 1994, Goal Question Metric Paradigm, Encyclopedia of Software Engineering, 2 Volume Set, As quatro fases do método GQM são
John Wiley & Sons, Inc.w
CMU/SEI, 2001, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version1.1: Method Definition Document, CMU/SEI-
mostradas na Figura 4.
2001-HB-001, Pittsburgh, Software Engineering Institute, Carnegie Mellon University. URL: http://www.sei.cmu.edu
CMU/SEI, 2002, Capability Maturity Model Integration (CMMI), Version 1.1 CMMI for Software Engineering (CMMI-SW, V1.1), Pittsburgh,
Software Engineering Institute, Carnegie Mellon University. URL: http://www.sei.cmu.edu
Considerações Finais
FLORAC, W.A., PARK, R.E., CARLETON, A.D., 1997, Practical Software Measurement: Measuring for Process Management and Improvement, Várias abordagens associadas à me-
CMU/SEI-97-HB-003, Pittsburgh, Software Engineering Institute, Carnegie Mellon University.
HUMPHREY, W.S. 1989, Managing the Software Process, Addison-Wesley.
lhoria de processo têm ganhado impor-
ISO/IEC 12207, 1995, Information Technology – Software Life-Cycle Processes. tância na comunidade de soft ware. Os
ISO/IEC PDAM 12207, 2002, “ISO/IEC 12207 Information Technology – Amendment to ISO/IEC 12207”, Montreal: ISO/IEC JTC1 SC7.
ISO/IEC TR 15504, 1998, Information technology – Software Process Assessment.
conceitos, métodos, e práticas englobam
ISO/IEC 15504, 2003, Information Technology – Software Process Assessment, International Standard Organization. uma maneira de pensar, de agir e de en-
KAN, S. H., 2003, “Metrics and Models in Software Quality Engineering”, Second Edition, Addison-Wesley.
KUVAJA, P. et al., 1994, Software Process Assessment and Improvement: The BOOTSTRAP Approach, Oxford, Blackwell Publishers.
tender os dados gerados pelos processos
PAULK, M. C., WEBER, C. V., CURTIS, B., CHRISSIS, M. B. (eds), 1995, The Capability Maturity Model: Guidelines for Improving the Software que, coletivamente, resultam em melho-
Process, Addison-Wesley.
ROCHA, A.R., MALDONADO, J.C., WEBER, K.C., 2001, Qualidade de Software – Teoria e Prática, 1a ed., Prentice Hall, São Paulo.
ria da qualidade, aumento da produti-
Sociedade SOFTEX, 2004a, “Uma Estratégia para Melhoria de Processo de Software nas Empresas Brasileiras”, http://www.softex.br/media/ vidade e competitividade dos produtos
QuaTIC.zip.
Sociedade SOFTEX, 2004b, “Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira.”, http://www.softex.
de soft ware.
br/media/artigoCLEI_versao_final.pdf. Acessado em 02/2005. Vimos neste artigo alguns dos concei-
SOLINGEN, R., BERGHOUT, E., 1999, The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Develop-
ment, McGrawHill, 1999.
tos que norteiam a área assim como uma
breve descrição de algumas abordagens
para avaliação de processos.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine
sobre e
tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você,
s
ta
edição
leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
12 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
14. Gerenciamento de Projetos
Entenda alguns dos principais conceitos
De que se trata o artigo:
Nesse artigo foram tratados os con-
ceitos do Gerenciamento de Projetos,
a fim de desmistificar o assunto e dar
N
este artigo falaremos um sustentação à decisão de aplicação
pouco sobre Gerência de dos seus conceitos.
Projetos “GP”, um assunto
Para que serve:
que pode parecer novo para alguns por
Esclarece a base do Gerenciamento
estar sendo foco de muitas discussões
de Projetos e suas ramificações, ser-
atualmente, principalmente dentro das
vindo como ponto de partida para a
organizações, que têm buscado nas
sensibilização das organizações e pro-
técnicas e conceitos da GP uma forma
fissionais para a aplicação dos concei-
de reduzir as falhas em seus projetos.
tos em seu dia a dia.
Entretanto, como ciência formal, a GP
já tem quase meio século e se formos Em que situação o tema é útil:
pensar como conceito são alguns mi- A aplicação dos conceitos de Ge-
lhares de anos, é só lembrarmos da renciamento de Projetos auxilia na
perfeita construção das pirâmides do gestão de projetos de qualquer tipo
Egito, da muralha da china e outros e tamanho, aumentando os níveis de
grandes projetos que envolveram um qualidade dos produtos ou serviços
número grande de trabalhadores e ti- produzidos e ajudando a atingir os
Andrey Abreu veram êxito. objetivos do projeto.
andreyabreu@gmail.com
Pós graduando em engenharia de software pela
universidade GAMA FILHO, graduado em gestão
estratégica de organizações pela UNISUL, Gerente de
TI da empresa NEXXERA TECNOLOGIA S/A, gerencia
atualmente área de Desenvolvimento de Sistemas,
composta por 33 profissionais divididos em equi-
pes de desenvolvimento Java e c, que trabalham
local e remotamente em 15 linhas de projetos.
14 Engenharia de Software Magazine – Gerenciamento de Projeto
15. P L A N E J A M E N TO
Até hoje engenheiros renomados ain- O que é Gerência de Projetos? A História da Gerência de Projetos
da se perguntam como foi possível a Segundo o PMBOK (2004, p.6), “Gerên- Como ciência foi formalizada na déca-
construção, por exemplo, das pirâmi- cia de Projetos é a aplicação de conheci- da de 60, quando os negócios e organiza-
des, um grande projeto com tamanha mentos, habilidades, ferramentas e téc- ções começaram a enxergar o benefício
precisão e perfeição sem utilização das nicas, a fim de satisfazer ou exceder as do trabalho organizado em torno de pro-
modernas técnicas de planejamento, necessidades e expectativas dos stakehol- jetos e a entender a necessidade crítica
construção e controle. Esses fatos nos ders (interessados e envolvidos)”. para integrar o trabalho através de múl-
mostram que muito do que precisamos Satisfazer as necessidades e expecta- tiplos departamentos e profissões.
para ter êxito em nossos projetos já tivas dos stakeholders envolve além de Em 1969, no auge dos projetos espaciais
está pronto, já foi testado e funciona, tudo equilibrar demandas concorrentes da NASA, um grupo de 5 profissionais
não precisamos recriar novas técnicas em relação a: de gestão de projetos reuniu-se para dis-
ou conceitos, apenas entender e utili- • Escopo, prazo, custo e qualidade; cutir melhores práticas e técnicas, e foi
zar os conceitos e técnicas existentes • Stakeholders com necessidades e ex- fundado o Project Management Institu-
da melhor forma possível e com certe- pectativas diferenciadas; te, PMI (EUA) por Jim Snyder.
za os resultados serão melhores. • Requisitos identificados (necessidades) e O PMI é atualmente a maior institui-
requisitos não identificados (expectativas). ção internacional dedicada à dissemina-
Mas o que realmente é um projeto? E esse é o desafio da gerência de proje- ção do conhecimento e aprimoramento
Todos nós de forma intrínseca faze- tos, alinhar as expectativas e necessida- das atividades de gestão profissional de
mos projetos no decorrer de nossas des dos clientes com a realidade do pro- projetos e está espalhado por diversos
vidas, seja uma viajem planejada, a jeto, gerando resultado sem prejudicar países através de seus grupos dissemi-
manutenção preventiva do carro, um a qualidade e mantendo todos os atores nadores. Pelos números do PMI (posição
roteiro de férias, tudo isso são peque- envolvidos informados. jan/2006), passam de 212 mil os membros
nos projetos que planejamos e execu- Para isso, a Gerência de Projetos utiliza- e são mais de 176 mil profissionais cer-
tamos sozinhos. Porém, quando esses se de seus processos componentes que tificados (PMP’s, “Project Management
projetos começam a envolver mais podem ser classificados em cinco grupos Professional”) em 160 países.
pessoas é necessária uma organiza- de processos (iniciação, planejamento,
ção maior para que o objetivo de todo execução, controle e encerramento) e Áreas de Conhecimento da Gerência
o grupo seja atingido, e é nesse ponto de suas áreas de conhecimento, ao todo de Projetos
que entra a Gerência de Projetos. nove (gerência de integração, gerência de Como já comentado no anteriormente,
Segundo o PMBOK (Project Manage- escopo, gerência de tempo, gerência de a gerência de projetos é composta por
ment Body of Knowledge) (2004, p.21), custo, gerência de qualidade, gerência de nove áreas de conhecimento, que são a
Guia do conjunto de conhecimentos RH, gerência de comunicação, gerência base para estruturação de um projeto de
em Gerência de Projetos definido pelo de riscos e gerência de aquisições). sucesso. A Figura 1 ilustra a interação
PMI (Project Management Institute), Em resumo, a Gerência de Projetos visa entre essas áreas.
“Um projeto é um esforço temporário, manter os riscos de fracasso em um ní- Falaremos a partir de agora um pouco
executado por pessoas, restringido por vel tão baixo quanto necessário durante sobre cada uma dessas áreas, mas não en-
recursos limitados, planejado, execu- todo o ciclo de vida do projeto. traremos nesse artigo no detalhamento
tado e controlado, e empreendido para
criar um produto, serviço ou resultado
exclusivo”. Temporário por que cada
projeto tem seu início e fim muito bem
definidos, chegando-se ao fim quan-
do os objetivos foram alcançados ou
quando está claro que não serão ou
não poderão mais ser alcançados.
Percebemos então que é necessário
defi nir objetivos, realizar um planeja-
mento de execução, especificar custos,
estipular a quantidade de pessoas en-
volvidas e elaborar um cronograma,
delimitando assim a previsão de início
e término para produzir o resultado de-
sejado no projeto.
Agora que sabemos o que é um projeto
dentro do contexto apresentado, vamos
entrar na conceituação do Gerenciamen-
to de Projetos. Figura 1. Áreas de conhecimento da gerência de projetos.
Edição 06 – Engenharia de Software Magazine 15
16. de cada uma. O PMBOK (2004, p.71-295) exigido e somente o trabalho exigido, quantidades) requeridos para a execução
traz com detalhes cada uma das áreas, controlando o que está ou não incluído de cada atividade do cronograma.
seus procedimentos, artefatos, entradas no projeto, a fim de que o mesmo seja • Estimativa de duração das ativida-
e saídas. completado com sucesso. des: Estimativa individual do período
Processos envolvidos: de trabalho necessário para conclusão de
Gerenciamento de Integração • Planejamento do Escopo: Documen- cada atividade do cronograma.
Inclui os processos necessários para tação de como o escopo do projeto será • Criação do Cronograma: Análise da
garantir que os elementos do projeto definido, verificado e controlado. seqüência de atividades, dependências,
estão coordenados de maneira apro- • Definição do Escopo: Declaração duração e recursos requeridos para a
priada, principalmente no que tange a detalhada do escopo do projeto, que confecção do cronograma.
harmonização das disciplinas centrais servirá como base para futuras deci- • Controle do cronograma: Controle
(escopo, qualidade, tempo e custo) fa- sões de projeto. das possíveis mudanças do cronograma.
zendo compensações entre objetivos e • Criação da estrutura analítica do
alternativas concorrentes, a fim de atin- projeto (EAP): Divisão das entregas Gerenciamento de Custos
gir ou superar as necessidades e expec- em partes menores a fim de facilitar Descreve os processos necessários para
tativas dos Stakeholders. o gerenciamento. garantir que o projeto será concluído
Processos envolvidos: • Verificação do Escopo: Formali- dentro do orçamento previamente apro-
• Termo de abertura do projeto: zação das entregas do projeto finali- vado. Custos e escopo estão fortemente
Autorização formal DE um projeto zadas, no final do projeto, no final da relacionados, uma vez que um escopo
ou uma fase. fase do projeto, ou na liberação das mal definido implicará diretamente nas
• Declaração do escopo preliminar: Des- principais entregas. estimativas de custos do projeto.
crição em alto nível o escopo do projeto. • Controle do Escopo: Garante que Processos envolvidos:
• Plano de gerenciamento do projeto: mudanças sejam acordadas com todos, • Estimativa: Descrição da estimativa
Listagem das ações de definição, prepa- determina e gerencia quando uma mu- de custos relativa à alocação de recursos
ração, integração e coordenação, agrega- dança ocorre e com que freqüência o es- para execução do projeto.
das aos resultados de todos os demais copo pode mudar. • Orçamentação: Agregação dos cus-
processos, compondo um plano de ge- tos estimados para estabelecer uma
renciamento do projeto. Gerenciamento do Tempo linha base dos custos totais, a fim de
• Execução do plano de projeto: Exe- Contém os processos relativos ao servir para a medição de desempenho
cução das ações definidas no plano de controle do término do projeto dentro do projeto.
gerenciamento do projeto a fim de aten- do prazo previsto, garantindo o cum- • Controle de custos: Controle das
der aos requisitos definidos na declara- primento dos prazos definidos em um variações e mudanças no orçamento e
ção do escopo. cronograma de atividades. É conside- identificação das causas dessas varia-
• Monitorar e controlar o trabalho do rada a área de maior exigência dentro ções seja positiva ou negativa, sendo
projeto: Monitoramento e verificação do do projeto por ser a que é mais visível que a gestão inapropriada pode causar
andamento da execução das ações do em sua gestão. problemas de qualidade e cronograma,
plano de gerenciamento do projeto. Processos envolvidos: e elevar o nível de risco.
• Controle integrado de mudanças: • Defi nição das atividades: Identifica-
Coordenação das mudanças de projeto e ção das atividades dentro do cronogra- Gerenciamento da Qualidade
acompanhamento da aprovação e entrega. ma que precisam ser realizadas para ge- Objetiva garantir a conclusão do proje-
• Encerrar projeto: Encerramento for- rar as entregas. to dentro dos níveis desejados de quali-
mal do projeto ou de uma fase. • Seqüenciamento das atividades: dade, garantindo a satisfação de todos os
Identificação das dependências entre ati- envolvidos no projeto.
Gerenciamento do Escopo vidades no cronograma. Principais Dimensões:
Composto por processos que garantem • Estimativa de recursos das ativi- • Satisfação do cliente: O projeto deve
que o projeto contemple todo o trabalho dades: Estimativa de recursos (tipos e produzir o que se propôs a produzir e o
16 Engenharia de Software Magazine – Gerenciamento de Projeto
17. P L A N E J A M E N TO
produto satisfazer as necessidades re- como resultado o plano de gerenciamen- lidade de eventos negativos no projeto,
ais do cliente. to de pessoal. tratando os processos de identificação,
• Prevenção de erros: O cliente • Contratar / Mobilizar a equipe do análise, resposta, monitoramento, con-
sempre é o próximo elemento no pro- projeto: Efetiva obtenção dos recursos trole e planejamento de riscos.
cesso, o custo da prevenção é menor humanos necessários para conclusão Processos envolvidos:
que o da correção. do projeto. • Planejamento do gerenciamento
• Responsabilidades: Todos são res- • Desenvolvimento da equipe: Traba- de riscos: Definição de como tratar,
ponsáveis pelo sucesso do projeto, po- lhar a melhoria de competências e inte- planejar e executar as atividades de
rém a gerência deve fornecer os recursos ração entre membros, a fim de melhorar risco do projeto.
necessários para que exista o sucesso. continuamente o desempenho do projeto. • Identificação de riscos: Identificação
• Melhoria contínua: O mundo está • Gerenciamento da equipe do pro- / Documentação dos riscos que podem
em constante mudança, exigindo o apri- jeto: Trabalhar / Acompanhar o de- afetar o projeto.
moramento constante dos mecanismos sempenho individual dos membros da • Análise qualitativa de riscos: Priori-
de controle de projetos a fim de garantir equipe, dar e obter feedbacks, tratar zação dos riscos do projeto, levando em
a qualidade do produto ou serviço. problemas rotineiros e coordenar mu- consideração a probabilidade dos mes-
Processos envolvidos: danças, objetivando aumentar o de- mos ocorrerem e sua freqüência.
• Planejamento da qualidade: Identi- sempenho do projeto. • Análise quantitativa de riscos: Aná-
ficação/definição dos padrões de quali- lise do efeito dos eventos de risco e atri-
dade para o projeto e descrição de como Gerenciamento das Comunicações buição de classificação numérica a esses
satisfazê-los. Visa gerar, coletar, distribuir, armaze- riscos, realizada sobre os riscos levanta-
• Garantia da qualidade: Aplicação nar e recuperar as informações sobre o dos na análise qualitativa.
das atividades de qualidade a fim de projeto de forma oportuna e adequada. • Planejamento de resposta de ris-
garantir que serão empregados todos Toda a equipe do projeto deve entender co: Criação de opções e ações com o
os processos necessários para atender que as comunicações afetam o projeto intuito de aumentar as oportunidades
aos requisitos dentro dos níveis exigi- como um todo. e reduzir as vulnerabilidades dos obje-
dos de qualidade. Processos envolvidos: tivos do projeto.
• Controle da qualidade: Monitora- • Planejamento das comunicações: • Monitoramento e controle de riscos:
mento / Acompanhamento dos resulta- Determina as necessidades de informa- Acompanhamento dos riscos identifica-
dos do projeto, baseando-se nos padrões ções e comunicações às partes interessa- dos, monitoramento dos riscos restantes,
estabelecidos de qualidade, garantindo das no projeto. identificação de novos riscos, execução /
que os mesmos estão sendo satisfeitos e • Distribuição das informações: Di- avaliação do plano de resposta de riscos.
identificando formas de eliminar possí- vulgar às partes interessadas as infor- Este processo é efetuado durante todo o
veis resultados insatisfatórios. mações necessárias. ciclo de vida do projeto.
• Relatório de desempenho: Confec-
Gerenciamento de Recursos ção / Divulgação de relatório de desem- Gerenciamento de Aquisições
Humanos penho (andamento do projeto, progres- Trata do processo de aquisição de bens,
Compreende organizar e gerenciar a so, previsão). produtos e serviços de fornecedores ex-
equipe do projeto, essa composta por • Gerenciamento das partes interes- ternos à organização, visando dar condi-
pessoas com funções e responsabilida- sadas: Gerenciamento junto às partes ções de realização do projeto.
des atribuídas e claramente definidas, interessadas quanto à satisfação de seus Processos envolvidos:
possibilitando o uso mais efetivo das requisitos, bem como o gerenciamento • Planejamento de compras e aqui-
pessoas envolvidas no projeto. de problemas do projeto. sições: Definição do que, como e
Processos envolvidos: quando comprar.
• Planejamento de recursos humanos: Gerenciamento de Riscos • Plano de contratações: Levantamento
Identificação / definição das pessoas e Objetiva aumentar a probabilidade de e discriminação dos produtos, serviços e
suas atribuições dentro do projeto, tendo eventos positivos e diminuir a probabi- identificação de possíveis fornecedores.
Edição 06 – Engenharia de Software Magazine 17
18. Figura 2. Atividades dos processos da gerência de projetos.
• Solicitação de resposta dos fornece- • Iniciação: Define e autoriza for-
dores: Obter informações gerais, cota- malmente o início de um projeto ou
ções, preços e ofertas. fase, delimitando o escopo e objeti-
• Seleção dos fornecedores: Análise e vos preliminares;
escolha de possíveis fornecedores, nego- • Planejamento: Define de forma
ciação e confecção de um contrato com detalhada os objetivos e propicia o
cada fornecedor individualmente. planejamento das ações necessárias
• Manutenção do contrato: Geren- para que o projeto seja realizado com
ciamento das relações entre comprador sucesso;
e fornecedor, bem como das cláusulas • Execução: Integra recursos e pessoas
constantes no contrato entre as partes e a fim de realizar o planejamento do pro-
análise de desempenho do fornecedor jeto com sucesso;
Figura 3. Triângulo do Gerenciamento de Projetos. para contratações futuras e manutenção • Monitoramento / Controle: Moni-
das contratações atuais. tora / Mede os resultados do projeto a
• Encerramento do contrato: Fina- fim de identificar problemas e solucio-
lizar cada contrato, liquidando todos ná-los gerando o mínimo de impacto
os itens pendentes. no resultado;
• Encerramento: Finaliza formalmente
Grupo de Processos da Gerência o projeto ou fase, englobando a aceitação
de Projetos do produto / serviço e encerramento for-
Como falamos anteriormente, a gerên- mal das atividades.
cia de projetos possui cinco grupos de Para esclarecer melhor, a Figura 2 apre-
processos que agrupam as atividades das senta o diagrama da interação das ativi-
áreas de conhecimento vistas acima em dades apresentadas neste artigo no con-
fases bem definidas e complementares: texto destes processos.
18 Engenharia de Software Magazine – Gerenciamento de Projeto