ISSN 1983127-79 771983 127008   00006
EDITORIAL                                                                                                      “Se observa...
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 ...
Conceitos Introdutórios sobre Melhoria e     Avaliação de Processos de Software                                           ...
PROCESSO A          melhoria do processo de sof-       dimentos empregados na execução de          Avaliação de Processo d...
sos da organização, um subconjunto se-                                                                                    ...
PROCESSO  • A abordagem bottom-up, que utiliza         Apesar dos modelos serem úteis para                           e o “...
O modelo em estágios avalia uma or-          • No nível 4 de capacidade (Gerenciado         Para conduzir uma avaliação no...
PROCESSOISO/IEC 15504                               demonstram se determinado processo é           Essa norma define um con...
O GQM define um determinado objeti-                                                                                        ...
Gerenciamento de Projetos    Entenda alguns dos principais conceitos                                                      ...
P L A N E J A M E N TO Até hoje engenheiros renomados ain-      O que é Gerência de Projetos?                             ...
de cada uma. O PMBOK (2004, p.71-295)       exigido e somente o trabalho exigido,      quantidades) requeridos para a exec...
P L A N E J A M E N TOproduto satisfazer as necessidades re-      como resultado o plano de gerenciamen-       lidade de e...
Figura 2. Atividades dos processos da gerência de projetos.                                                               ...
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Es06   teste de software
Upcoming SlideShare
Loading in...5
×

Es06 teste de software

961

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
961
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
75
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Es06 teste de software"

  1. 1. ISSN 1983127-79 771983 127008 00006
  2. 2. 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 podemCorpo Editorial ser aplicado, as técnicas de teste que podem ser aplicadas e osColaboradores critérios para seleção dos testes associados a estas técnicas. PorRodrigo Oliveira Spínola exemplo, no artigo “Introdução a Teste de Software” publicadorodrigo@sqlmagazine.com.br na edição 01 da Engenharia de Software Magazine discutimosMarco Antônio Pereira Araújo sobre alguns desses critérios: Particionamento em classes deEduardo Oliveira Spínola equivalência, Análise do Valor Limite e Grafo de Causa-Efeito.Editor de ArteVinicius O. Andrade Para cada critério, vimos como aplicá-los e um exemplo da suaviniciusoandrade@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 Armanroberta.arman@gmail.com malmente os problemas são bem mais complexos do queRevisão aqueles tradicionalmente usados quando estamos conhe-Gregory Monteiro cendo esses critérios para seleção dos testes (ex: indicar qualgregory@clubedelphi.net o maior valor em um conjunto, indicar se um campo númeroNa Webwww.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).
  3. 3. 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 deSoftware 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 – ProjetoTítulo: Introdução à Engenharia de Requisitos - Parte 19 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 2Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira SpínolaMini-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 deNesta 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 – Projeto02 – Engenharia de Requisitos Título: Introdução à Construção de Diagrama de Classes da UML – Parte 3Título: Introdução à Engenharia de Requisitos - Parte 20 Autor: Rodrigo Oliveira SpínolaAutor: Rodrigo Oliveira Spínola Mini-Resumo: Esta vídeo aula apresenta a notação da UML para elaboraçãoMini-Resumo: Esta vídeo aula é parte do curso de introdução à engenharia de requisitos. de diagramas de classes considerando os relacionamentos de herança eNesta vigésima parte finalizaremos a especificação do caso de uso iniciada na aula anterior. associação.03 – Engenharia de Requisitos 07 – ProjetoTítulo: Introdução à Engenharia de Requisitos - Parte 21 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 4Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira SpínolaMini-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çãoNesta vigésima primeira parte apresentaremos passo a passo a especificação de um caso de diagramas de classes considerando os relacionamentos de agregação ede uso considerando o cenário de inclusão de cliente para uma organização fictícia. composição.04 – Engenharia de Requisitos 08 – ProjetoTítulo: Introdução à Engenharia de Requisitos - Parte 22 Título: Introdução à Construção de Diagrama de Classes da UML – Parte 5Autor: Rodrigo Oliveira Spínola Autor: Rodrigo Oliveira SpínolaMini-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 derequisitos. 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 seriniciada na aula anterior. seguidos para a apoiar a construção passo a passos destes diagramas.Atendimento ao LeitorA DevMedia conta com um departamento exclusivo para o atendi- ÍNDICEmento ao leitor. Se você tiver algum problema no recebimento do 06 - Conceitos Introdutórios sobre Melhoria e Avaliação de Processos de Softwareseu exemplar ou precisar de algum esclarecimento sobre assinaturas, Rodrigo Oliveira Spínolaexemplares anteriores, endereço de bancas de jornal, entre outros,entre em contato com: 14 - Gerenciamento de ProjetosCarmelita Mulin – Atendimento ao Leitorwww.devmedia.com.br/central/default.asp Andrey Abreu(21) 2220-5375Kaline Dolabella 20 - Utilizando Visualização de Informação para Compreensão de SoftwareGerente de Marketing e Atendimentokalined@terra.com.br Eduardo Oliveira Spínola(21) 2220-5375 28 - Fundamentos de Arquitetura de Software Rodrigo Oliveira Spínola e Rafael Ferreira BarcelosPublicidadePara informações sobre veiculação de anúncio na revista ou no site entre 36 - Planejamento de Testes a partir de Casos de Usoem contato com: Arilo Cláudio Dias NetoKaline Dolabellapublicidade@devmedia.com.br 42 - Testes com Objetos Mock Marco Antônio Pereira AraújoFale com o Editor!É muito importante para a equipe saber o que você está achando da revista: que 48 - Inspecionando a Usuabilidade de Produtostipo de artigo você gostaria de ler, que artigo você mais gostou e qual artigo Antônio Mendes da Silva Filhovocê menos gostou. Fique a vontade para entrar em contato com os editores edar a sua sugestão! 54 - Soluções para Gerenciamento de Riscos de ProjetosSe 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ãodo tema que você gostaria de publicar: 60 - Introdução à Gestão de ConhecimentoRodrigo Oliveira Spínola - Colaboradoreditor@sqlmagazine.com.br Rodrigo Oliveira Spínola
  4. 4. 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
  5. 5. 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 diferentespara as organizações que trabalham com • Para FUGGETTA (2000), um processo objetivos, geralmente estão delimitadassoftware. Isto se deve à exigência do mer- de software é definido como um conjunto a diferentes escopos e, a depender dascado por produtos com maior qualidade, coerente de políticas, estruturas organi- características dos modelos e métodosque sejam entregues mais rapidamente e zacionais, tecnologias, procedimentos e aplicados, ainda são classificadas comocom 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 diferentescessos 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 exameações que modificarão os processos, tor- o trabalho da International Standard disciplinado do processo de softwarenando-os mais coerentes com as necessi- Organization (ISO) que estabeleceu utilizado pela organização, baseado emdades 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 dessesnhos, comparando-os com os custos ad- do um framework com terminologia processos. O resultado deve identificarvindos 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 aso, é importante destacar uma das ativi- aplicados durante a aquisição, o for- eficácia das práticas atuais em controlardades de maior importância: a avaliação necimento, o desenvolvimento, a ope- ou evitar as principais causas de baixados 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 processoslongo 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 altode 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), umase 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çãomé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 asmelhoria 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/IECconceitos 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 aosmente 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 asProcesso de Software cidade como o intervalo de resultados avaliações de processos: Podemos encontrar na literatura téc- esperados que podem ser alcançadosnica diversas definições para processo com o uso de um processo, e maturida- Contexto da avaliaçãode 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 ano 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 é realizadateriais, energia, equipamentos e proce- processos de software. uma auto-avaliação onde os principais Edição 06 – Engenharia de Software Magazine 7
  6. 6. 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égiapapé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égiapor 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çãorequisitos 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 serObjetivo 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 etminaçã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
  7. 7. PROCESSO • A abordagem bottom-up, que utiliza Apesar dos modelos serem úteis para e o “modelo em estágios”. A representaçãoprincipalmente a medição como o guia muitas organizações, o uso de múltiplos em estágios define um conjunto de áreaspara a melhoria de processo. Por exem- modelos gerou alguns problemas devido de processo para definir um caminho deplo, 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 (melhoriate 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 umadesenvolver software. Avaliando uma treinamento, das avaliações e das ativi- área de processo específica e melhore comorganizaçã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 árearelevantes. 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 aobjetivos 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. Cadamelhoria 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çãoModelos 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çãoprocesso 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 realmentecesso alcançado pelo SW-CMM (CMM de processos. Estas duas representações comprometidas com a implantação dopara software), um número significativo são conhecidas como o “modelo contínuo” CMMI em escala geral.de modelos de maturidade de processofoi desenvolvido para diferentes discipli- Nível de Maturidade Foco Áreas de Processonas. 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 projetosCMM) – usado para avaliar a maturida- • Monitoração e controle de projetosde de uma organização em seus proces- • Gerência de acordos com fornecedoressos de seleção, compra e instalação de • Medição e análisesoftware 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 requisitosria de sistemas, incluindo o hardware, o cesso. • Solução técnicasoftware e quaisquer outros elementos • Integração do produtoque participam do produto completo; • Verificação • Integrated Product Development • ValidaçãoCMM (IPD-CMM) – ainda mais abran- • Foco no processo organizacionalgente que o SE-CMM, inclui também ou- • Definição do processo organizacionaltros processos necessários à produção e • Gerência integrada do produtosuporte ao produto, tais como suporte ao • Gerência de riscosusuá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 organizacionalrecursos humanos no que se refere a • Gerência quantitativa de projetosoftware: recrutamento e seleção de de- Otimizado O foco está na melhoria contínua do pro- • Inovação e disseminação organizacionalsenvolvedores, treinamento e desenvol- cesso. • Análise e resolução de causasvimento, remuneração, etc. Tabela 1. Níveis de maturidade do CMMI. Edição 06 – Engenharia de Software Magazine 9
  8. 8. O modelo em estágios avalia uma or- • No nível 4 de capacidade (Gerenciado Para conduzir uma avaliação no localganizaçã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 dadosnistrar. É 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çãode 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 osISO/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 – registracesso é avaliada como estando em um de- A avaliação segundo o SCAMPI consiste de as informações obtidas identificando eterminado 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 comoatingir 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 baseadojetivos 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. Ato), 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 desita que seu desempenho esteja sendo da para conduzir o processo de avaliação; melhoria. As forças e as fraquezas dosgerenciado. 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, seplano para a sua realização, assim como áreas potencialmente problemáticas ou planejado, qual o nível de capacidadeum 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 resultadosa á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
  9. 9. PROCESSOISO/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çãoprojeto SPICE (Software Process Im- minado nível de capacidade. Há seis ní- e para um Método de Avaliação. Umaprovement and Capability dEtermi- veis de capacidade em que um processo avaliação que esteja de acordo com estesnation) 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çãofosse 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çãoque a norma ISO 9001. Uma versão do evidência de que os produtos de trabalho explícito, definindo apenas os requisitosSPICE 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ópriosapenas 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; GQMterminação da capacidade de processos • Nível 2 - Processo gerenciado: O O GQM representa uma abordagemde 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 processocessos, 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 umaelaboraçã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 dotos fortes e fracos e os riscos inerentes • Nível 3 - Processo estabelecido: O GQM é a especificação de um programaaos 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 umcontratação, esta pode obter seus perfis cesso definido e é capaz de alcançar seus conjunto de regras para interpretar asde 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 do15504 (2003) define a dimensão de pro- cesso estabelecido anteriormente opera processo de software, o GQM pode sercesso, que corresponde à definição de agora dentro de limites para alcançar os utilizado para estabelecer um programaum conjunto de processos considerados resultados de processo; de medição que possibilite investigar ouniversais 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 GQMto de atributos que permite determinar a é que as medições sejam orientadas porcapacidade 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 seusfas, atividades e práticas, bem como as realização: um modelo de avaliação; um objetivos de negócio e transformar essescaracterísticas dos produtos de traba- método de avaliação; um ou mais avalia- objetivos em atividades que podem serlho, são defi nidas como indicadores que dores competentes. medidas durante a execução do projeto. Edição 06 – Engenharia de Software Magazine 11
  10. 10. 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 numaFigura 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/feedback12 Engenharia de Software Magazine – Conceitos Introdutórios sobre Melhoria e Avaliação de Processos
  11. 11. 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
  12. 12. 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 Projetosda 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ícioprecisã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íticaconstruçã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 espaciaisestá pronto, já foi testado e funciona, tudo equilibrar demandas concorrentes da NASA, um grupo de 5 profissionaisnã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 foizar 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 demos projetos no decorrer de nossas des dos clientes com a realidade do pro- projetos e está espalhado por diversosvidas, 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çãoroteiro de férias, tudo isso são peque- envolvidos informados. jan/2006), passam de 212 mil os membrosnos 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 Managementprojetos 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ênciao grupo seja atingido, e é nesse ponto de suas áreas de conhecimento, ao todo de Projetosque 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 porment Body of Knowledge) (2004, p.21), custo, gerência de qualidade, gerência de nove áreas de conhecimento, que são aGuia do conjunto de conhecimentos RH, gerência de comunicação, gerência base para estruturação de um projeto deem Gerência de Projetos definido pelo de riscos e gerência de aquisições). sucesso. A Figura 1 ilustra a interaçãoPMI (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 poucoexecutado 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 detalhamentotado e controlado, e empreendido paracriar um produto, serviço ou resultadoexclusivo”. Temporário por que cadaprojeto tem seu início e fim muito bemdefinidos, chegando-se ao fim quan-do os objetivos foram alcançados ouquando está claro que não serão ounão poderão mais ser alcançados. Percebemos então que é necessáriodefi 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ícioe término para produzir o resultado de-sejado no projeto. Agora que sabemos o que é um projetodentro do contexto apresentado, vamosentrar 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
  13. 13. de cada uma. O PMBOK (2004, p.71-295) exigido e somente o trabalho exigido, quantidades) requeridos para a execuçãotraz 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 deGerenciamento 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 dagarantir 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 apriada, 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 doalternativas concorrentes, a fim de atin- projeto (EAP): Divisão das entregas Gerenciamento de Custosgir ou superar as necessidades e expec- em partes menores a fim de facilitar Descreve os processos necessários paratativas 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 fortementeAutorização formal DE um projeto zadas, no final do projeto, no final da relacionados, uma vez que um escopoou 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 estimativaListagem das ações de definição, prepa- determina e gerencia quando uma mu- de custos relativa à alocação de recursosraçã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 umarenciamento 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 desempenhocuçã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 dasder 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, sendoprojeto: Monitoramento e verificação do do projeto por ser a que é mais visível que a gestão inapropriada pode causarandamento 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 Qualidadeacompanhamento 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 deveque o projeto contemple todo o trabalho dades: Estimativa de recursos (tipos e produzir o que se propôs a produzir e o16 Engenharia de Software Magazine – Gerenciamento de Projeto
  14. 14. P L A N E J A M E N TOproduto 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 deré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 podemem 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 ema 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 essessatisfazê-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 oos processos necessários para atender que as comunicações afetam o projeto intuito de aumentar as oportunidadesaos 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 oveis 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çõesHumanos 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: LevantamentoIdentificação / definição das pessoas e Objetiva aumentar a probabilidade de e discriminação dos produtos, serviços esuas 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
  15. 15. 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

×