SlideShare uma empresa Scribd logo
1 de 68
Baixar para ler offline
ISSN 1983127-7




9 771983 127008   00006
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).
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
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
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
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
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
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
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
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
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
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
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
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
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
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

Mais conteúdo relacionado

Mais procurados

Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De SoftwareCursoSENAC
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de SoftwareNécio de Lima Veras
 
Introdução a engenharia de software aula 01
Introdução a engenharia de software   aula 01Introdução a engenharia de software   aula 01
Introdução a engenharia de software aula 01Franklin Matos Correia
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De SoftwareFelipe Goulart
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Softwareelliando dias
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02Franklin Matos Correia
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Sérgio Souza Costa
 
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1Renato Leal
 
Uma Introdução a Engenharia de Software
Uma Introdução a Engenharia de SoftwareUma Introdução a Engenharia de Software
Uma Introdução a Engenharia de SoftwareVinicius Garcia
 
Cap1 introd-engenharia de software
Cap1 introd-engenharia de softwareCap1 introd-engenharia de software
Cap1 introd-engenharia de softwareAdilson Nascimento
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitosGlauber Aquino
 
02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentaisWaldemar Roberti
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - WikipediaRobson Silva Espig
 
JAD e levantamento de requisitos
JAD e levantamento de requisitosJAD e levantamento de requisitos
JAD e levantamento de requisitosEduardo Castro
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de SoftwareRobson Silva Espig
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software PressmanSimoneinfo
 
Engenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEngenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEduardo Castro
 

Mais procurados (20)

Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Introdução a engenharia de software aula 01
Introdução a engenharia de software   aula 01Introdução a engenharia de software   aula 01
Introdução a engenharia de software aula 01
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Engenharia de software
Engenharia de softwareEngenharia de software
Engenharia de software
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
 
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
Curso de Introdução a Engenharia de Software - CJR/UnB - Aula 1
 
Uma Introdução a Engenharia de Software
Uma Introdução a Engenharia de SoftwareUma Introdução a Engenharia de Software
Uma Introdução a Engenharia de Software
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
Cap1 introd-engenharia de software
Cap1 introd-engenharia de softwareCap1 introd-engenharia de software
Cap1 introd-engenharia de software
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
 
02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais02 Introdução à engenharia de software - conceitos fundamentais
02 Introdução à engenharia de software - conceitos fundamentais
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - Wikipedia
 
Aula 02
Aula 02Aula 02
Aula 02
 
JAD e levantamento de requisitos
JAD e levantamento de requisitosJAD e levantamento de requisitos
JAD e levantamento de requisitos
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
 
Engenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEngenharia Requisitos - Método RON
Engenharia Requisitos - Método RON
 

Semelhante a Es06 teste de software

Testes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de CódigoTestes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de CódigoAricelio Souza
 
Ferramentas Case de Teste
Ferramentas Case de TesteFerramentas Case de Teste
Ferramentas Case de TesteBeatriz Marques
 
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...Isaac de Souza
 
INTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdf
INTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdfINTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdf
INTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdfRonaldAlves15
 
Minicurso - Teste de software (CACSI 2015)
Minicurso - Teste de software (CACSI 2015)Minicurso - Teste de software (CACSI 2015)
Minicurso - Teste de software (CACSI 2015)Vanilton Pinheiro
 
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesRogerio P C do Nascimento
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoSandy Maciel
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Marcelo Schumacher
 
Gerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2aGerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2aLeonardo Molinari
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de TestesUFPA
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trataRoni Reis
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geralpaulo peres
 
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptxAnaKlyssia1
 
Apresentação tcc - Leticia Moretti e Rafael Azevedo
Apresentação tcc - Leticia Moretti e Rafael AzevedoApresentação tcc - Leticia Moretti e Rafael Azevedo
Apresentação tcc - Leticia Moretti e Rafael Azevedolemorettiribeiro
 

Semelhante a Es06 teste de software (20)

O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Testes de software
Testes de softwareTestes de software
Testes de software
 
Testes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de CódigoTestes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de Código
 
Ferramentas Case de Teste
Ferramentas Case de TesteFerramentas Case de Teste
Ferramentas Case de Teste
 
FC-Logic
FC-LogicFC-Logic
FC-Logic
 
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
 
INTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdf
INTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdfINTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdf
INTRODUÇÃO AOS TESTES NO FRONT-END COM REACT JS E REACT NATIVE.pdf
 
Minicurso - Teste de software (CACSI 2015)
Minicurso - Teste de software (CACSI 2015)Minicurso - Teste de software (CACSI 2015)
Minicurso - Teste de software (CACSI 2015)
 
Eng de testes
Eng de testesEng de testes
Eng de testes
 
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e Planificações
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
 
Gerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2aGerenciando Testes Com Qualidade V2a
Gerenciando Testes Com Qualidade V2a
 
Engenharia de Testes
Engenharia de TestesEngenharia de Testes
Engenharia de Testes
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Aula 05
Aula 05Aula 05
Aula 05
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
 
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx01 UNIDADE I -  Princípios, pilares e modelos de teste de software.pptx
01 UNIDADE I - Princípios, pilares e modelos de teste de software.pptx
 
Apresentação tcc - Leticia Moretti e Rafael Azevedo
Apresentação tcc - Leticia Moretti e Rafael AzevedoApresentação tcc - Leticia Moretti e Rafael Azevedo
Apresentação tcc - Leticia Moretti e Rafael Azevedo
 

Mais de Carlos Antonio Castro Oliveira (6)

Bancos de dados relacionais
Bancos de dados relacionaisBancos de dados relacionais
Bancos de dados relacionais
 
Curso struts e hibernate
Curso struts e hibernateCurso struts e hibernate
Curso struts e hibernate
 
Aplicando logica orientada_a_objeto_em_java
Aplicando logica orientada_a_objeto_em_javaAplicando logica orientada_a_objeto_em_java
Aplicando logica orientada_a_objeto_em_java
 
Estudo de caso da adoção das práticas e valores do extreme programming
Estudo de caso da adoção das práticas e valores do extreme programmingEstudo de caso da adoção das práticas e valores do extreme programming
Estudo de caso da adoção das práticas e valores do extreme programming
 
Guia php
Guia phpGuia php
Guia php
 
Qualidade de software site bb
Qualidade de software   site bbQualidade de software   site bb
Qualidade de software site bb
 

Es06 teste de software

  • 1. ISSN 1983127-7 9 771983 127008 00006
  • 2.
  • 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
  • 5.
  • 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
  • 13.
  • 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