23

1. INTRODUÇÃO

O mercado mundial de tecnologia da informação, e em especial o nacional,

tem passado nos últimos anos por uma revolução no campo de desenvolvimento de

software, caracterizada por uma multiplicação de empresas que se autodenominam

fábricas de software. Nestas fábricas, são desenvolvidos e mantidos softwares dos

mais variados graus de complexidade, por pequenas ou grandes equipes e usando

as diversas tecnologias já desenvolvidas.

Diante de um mercado exigente e extremamente dinâmico, no qual o

equilíbrio ideal entre custo e qualidade dita o sucesso no mundo dos negócios, a

produtividade passou a ser um aspecto fundamental para a sobrevivência de

qualquer organização. Particularmente no setor de software, as organizações vêm

sofrendo transformações no sentido de se adequarem a um modelo que atenda às

demandas de mercado. Neste cenário, muitos modelos de fábrica de software têm

sido propostos e adotados. Processos de software bem definidos e flexíveis,

componentização, reuso de código e processos, representam estratégias bastante

adotadas por estas organizações.

A atuação das fábricas de software também se estende aos projetos de

terceirização ou outsourcing, que vêm obtendo um crescimento notável no mercado

nacional.

Este cenário é o resultado direto de um processo de amadurecimento da

engenharia de software – disciplina da engenharia que se ocupa de todos os

aspectos da produção de software (SOMMERVILLE, 2003) – que iniciou ainda na

década de sessenta, quando despontou o que foi chamado na época de crise do

software, gerada diretamente, segundo (PRESSMAN, 2000), pela introdução dos

computadores de terceira geração, que exigiam softwares mais complexos e

24

indubitavelmente maiores esforço de criação. Nesta época, os produtos de software

gerados foram em sua maioria de baixa qualidade, e com grande freqüência

apresentavam-se acima do custo e do prazo estimado.

A exemplo do crescimento e amadurecimento das fábricas de software da

Índia (KRIPALANI, 2003), as iniciativas brasileiras têm se multiplicado e apresentado

um crescimento considerável nos últimos meses (CESAR, 2004), especialmente

devido a fatores competitivos, uma vez que o próprio mercado nacional tem se

tornado mais exigente em termos de qualidade do produto e de redução de custos

(TARTARELLI, 2004).

Desta forma, as iniciativas de organização do modelo fabril, moldado a partir

de preceitos como o taylorismo e o fordismo, vindos desde o século XIX, têm tentado

mapear conceitos de produção em larga escala com qualidade para o mercado de

software, aumentando a produtividade e reduzindo os custos de produção, de forma

semelhante à proposta de Taylor e Ford, no surgimento das fábricas tradicionais

(TARTARELLI, 2004).

No entanto, o caso específico de uma fábrica de software, requer uma

organização mais holística, que considere vários fatores como gestão de pessoas,

gestão empresarial, qualidade de software, de processos e de produtos, utilização

de ferramentas, etc. Dentro deste contexto, este trabalho irá focar em uma estrutura

que privilegie a gestão do conhecimento, através de um modelo de referência que

enfatize o processo evolutivo da estrutura de desenvolvimento de software.

Segundo Fernandes (2004), uma área de desenvolvimento e manutenção de

sistemas ou software é uma fábrica de serviços que necessita de uma visão mais

orientada para a gestão de operações.

25

Como referência para as abordagens, ou classificações, de Fábrica de

Software será utilizada a perspectiva de escopo de fornecimento, utilizada por

Fernandes (2004). A importância da escolha dos processos que melhor se adequem

a uma iniciativa de Fábrica de Software é baseada no aumento de destaque que a

definição e padronização de processos vem sofrendo, especialmente após a

iniciativa do Software Engineering Institute da Universidade de Carnegie Mellon,

quando da criação do CMM (PAULK, 1993) – Capability Maturity Model for Software,

que define níveis de capacidade para uma organização que tem a produção de

software como objetivo primeiro.

Segundo Zahran apud Fernandes (2004), o processo funciona como o elo de

ligação entre os outros elementos desta visão holística que norteia as Fábricas de

Software, e deve interligar a Organização, o Gerenciamento, as Habilidades e a

Tecnologia utilizada, pois embasa a criação dos papéis organizacionais e definição

das responsabilidades, atividades e documentos (artefatos de insumo e produto),

assim como as diretrizes para as práticas gerenciais, ou seja, dependendo do

objetivo da fábrica, a escolha do processo mais adequado é de suma importância

para o sucesso da organização.

A competitividade acirrada entre as empresas, acelerada pela globalização,

acentua-se a cada dia influenciando-as a aprimorar seus processos de ciclo de vida

de software. Surgem normas, metodologias e modelos, com o objetivo de atender

essas necessidades. As empresas procuram dessa forma obter maior controle sobre

os seus processos, produtos e funções envolvidas, através da utilização de

metodologias onde a ênfase recaia sobre a necessidade de gerenciamento de

projetos, documentação, padronização de componentes, divisão de tarefas com

funções especializadas, tudo isso com o objetivo de reduzir custos, aumentar a

26

produtividade e garantir a qualidade dos produtos, tornando-os mais competitivos.

(TARTARELLI, 2005) Como decorrência disso, tem-se verificado já há alguns anos

uma tendência crescente entre empresas ligadas ao desenvolvimento de software,

em se estruturarem dentro dos moldes do ambiente fabril de manufatura.

Considerando esse novo contexto, este trabalho vai ao encontro das

expectativas de quem necessita implementar uma plataforma sustentada por

processos que privilegiem a entrega de produtos de software confiáveis, com

qualidade e competitivos.

1.1. Objetivos

Este trabalho está direcionado para analisar e criar conceitualmente uma

estrutura que operacionalize a construção de software de uma forma mais efetiva em

termos de custo, agregação de valor ao negócio, qualidade, previsibilidade do

atendimento aos serviços de novos desenvolvimentos e manutenções. Dentro desta

perspectiva, tem como objetivo a proposição de um modelo que condense os

aspectos relevantes de três modelos: RUP, CMMI e PMBOK, e consiga maximizar a

utilização dos recursos e agregando valor na abordagem de desenvolvimento de

softwares que utilizam preceitos de engenharia associados à manufatura.

É proposta a utilização do RUP como ferramenta para balizar e controlar as

fases do processo da fábrica de software utilizando a metodologia que propõe a

composição das dimensões estática e dinâmica, de maneira que haja sempre o

feedback necessário para a evolução dos processos. Também é proposta a adoção

dos padrões do RUP para a definição de papéis, artefatos e políticas além da

utilização dos modelos gráficos e visuais para descrição de fluxogramas dos

processos, fases e seus sub-itens. A utilização do RUP fortalece o conceito de

27

garantia de qualidade de produto, uma vez que o CMMI foca a qualidade do

processo, sendo assim, propõe-se uma atenção maior à questão da garantia da

qualidade em todas as fases da fábrica de software visando a melhora do produto,

otimização dos processos e minimização de custos com retrabalho.

No que tange à metodologia CMMI a proposta é a utilização do modelo de

maturidade crescente e quantificável, visando assegurar a garantia da qualidade

através dos conceitos, a efetiva aplicação e controle dos seguintes itens:

• Funcionalidade – adequação, interoperabilidade, conformidade e segurança

de acesso.

• Confiabilidade – maturidade, tolerância a falhas, recuperabilidade.

• Usabilidade – intelegibilidade e operacionalidade.

• Eficiência – comportamento em relação ao tempo, comportamento em relação

aos recursos.

• Manutenibilidade – analisabilidade, modificabilidade, estabilidade e

testabilidade.

• Portabilidade – adaptabilidade, capacidade para ser instalado, conformidade

e capacidade para substituir.

O PMBOK é utilizado como ferramenta gerencial e balizadora das decisões

no que tange à gerência de projetos da fábrica de software. A proposta de utilização

do PMBOK tem como fator crítico a sua eficiência em: identificação das

necessidades; estabelecimento de objetivos claros e alcançáveis; balanceamento

das demandas conflitantes de qualidade, escopo, tempo e custo; adaptação das

especificações, dos planos e da abordagem às diferentes preocupações e

expectativas das diversas partes interessadas.

28

1.2. Metodologia

A metodologia empregada baseia-se na pesquisa bibliográfica e documental

sobre a parte teórica do Rational Unified Process (RUP), do Capability Maturity

Model Integration (CMMI), do Project Management Body of Knowledge (PMBOK) e

sobre os limites possíveis de intersecção entre os processos.

O trabalho de coleta do material foi realizado a partir de um “brainstorming” do

grupo de aluno que identificou a necessidade da exploração dos modelos ditos como

referência no mercado de software. Os dados coletados foram para analisar as

características relevantes e estruturar o conhecimento em um framework factível e

aderente ao estudo.

Neste estudo, apresenta-se uma análise sobre as questões que devem ser

consideradas durante o processo de concepção, elaboração, gestão e implantação

de uma fábrica de software. Para obter os resultados esperados, o trabalho foi

estruturado da seguinte forma: na seção 2, o conceito de Fábrica de Software será

explicitado, mostrando um histórico deste tipo de organização e um modelo de

referência (baseado em um tripé: processo, gerência e qualidade). Além disso,

evidenciar-se-á todos os termos utilizados na modelagem dos processos

operacionais e gerenciais.

Já na seção 3, este trabalho propõe um estudo detalhado dos 3 principais

modelos que formam um tripé de sustentação da operação descrita na seção 2, no

que tange à utilização de estruturas citadas como melhores práticas na construção

de produtos de software. São eles: um processo de desenvolvimento baseado no

processo unificado (Processo Unificado Rational), os conceitos de gerência de

projetos e as melhores práticas já identificadas (PMBOK) e o modelo de qualidade

29

do CMMI, os quais fornecerão o embasamento para a proposição de um modelo que

implemente operações efetivas no atendimento dos requisitos de custo, prazo,

qualidade, escopo; fornecendo valor agregado ao negócio.

Como resultado dos assuntos estudados, o modelo citado no parágrafo

anterior será criado e estruturado dentro da seção 4, a qual efetua a proposição de

um framework de processos operacionais e gerenciais que possibilitam a

implantação da operação. Já a seção 5, executa a conclusão do estudo.

1.3. Contribuição do trabalho

Quanto às contribuições do presente trabalho, os principais aspectos a

ressaltar são:

• Propor e realizar a construção de uma proposta (framework) de desenvolvimento

de software (Fábrica de Software), aderente aos 3 principais modelos do mercado

(processo de desenvolvimento, gerência de projetos e qualidade em software),

através da condensação das características mais relevantes na sua implantação;

• Apontar caminhos para as empresas de software implementarem operações de

Fábrica de Software confiáveis, com serviços consistentes e que possam competir

de igual para igual no mercado de serviços off-shore;

• Prover um framework para que as empresas usuárias e compradoras de serviços

de Fábrica de software possam selecionar uma operação desta natureza e visualizar

possíveis acordos de níveis de serviço, visando à melhoria contínua;

30

• Como resultado da pesquisa, extrair as melhores práticas de cada modelo e

construir uma estrutura operacional consistente, aproveitando as melhores práticas

das experiências anteriores dos modelos estudados.

31

2. REVISÃO DE LITERATURA

2.1. As abordagens de Taylor e Ford

O taylorismo é um sistema de organização científica do trabalho baseado no

controle dos tempos de execução das tarefas, estabelecido por Frederick Winslow

Taylor. Na prática, desde os fins do século XIX , os princípios de organização

científica do trabalho, segundo Taylor, giram em torno de três idéias centrais: a

importância essencial da preparação do trabalho (e seu corolário, a distinção radical

entre concepção e execução); a pesquisa sistemática de economia de gestos e de

movimentos; a utilização máxima da máquina (LAROUSSE, 1999).

O fordismo é a teoria da organização industrial de Henry Ford, que visa

aumentar a produtividade pela estandardização dos produtos e por uma nova

organização do trabalho. É baseado no principio de que uma empresa deve dedicar-

se apenas a um produto. Para isso, deve adotar a verticalização, com o domínio das

fontes de matéria-prima e sistemas de transporte de mercadorias. Para diminuir os

custos, a produção deve ser em massa, em grande quantidade e aparelhada com

tecnologia capaz de desenvolver ao máximo a produtividade dos operários. O

trabalho deve ser também altamente especializado, cada operário realizando

determinada tarefa. Além disso, para o operário ter boa produtividade, ele deve ser

bem remunerado e ter uma jornada de trabalho menor. Os princípios do fordismo

foram amplamente difundidos, tornando-se uma das bases da organização industrial

moderna (LAROUSSE, 1999).

32

2.2. Fábrica de software

Com a constante evolução tecnológica na área computacional, os sistemas

baseados em computador vêm enfrentando muitas transformações durante as

últimas cinco décadas.

Nos anos sessenta, o hardware possuía um custo elevado e o software, que

quase sempre era único e praticamente parte integrante do hardware, um custo

baixo. Isto se dava devido na época o hardware ser considerado mais importante

que o software, uma vez que este era desenhado especificamente para executar

determinadas tarefas, sendo a função do software apenas iniciar as operações do

computador.

Desde então, os componentes de hardware foram barateando cada vez mais,

tornando os computadores, agora em forma de PC’s (computadores pessoais)

bastante acessíveis ao grande mercado (PRESSMAN, 2000).

A última década do século XX, principalmente em sua segunda metade, foi

marcada por uma transformação que fez com que o emprego das tecnologias de

informação e comunicação se tornasse um diferencial competitivo para

modernização produtiva das empresas. Segundo Castells (2000), embora o modo

capitalista de produção seja caracterizado por sua expansão contínua, sempre

tentando superar limites temporais e espaciais, foi apenas no final do século XX que

a economia mundial conseguiu tornar-se verdadeiramente global com base na nova

infra-estrutura, propiciada pelas tecnologias da informação e comunicação.

A aceleração e a confiabilidade das redes mudaram a maneira de trabalhar de

uma parcela importante dos habitantes do planeta. O correio eletrônico e a Internet

colocaram o computador como um nó de comunicação que é capaz de mexer com

todo o universo profissional em todos os setores de atividade.

33

Essas modificações fizeram com que as empresas remodelassem seus

processos para uma nova realidade. A área de informática deixou de ser monolítica

e hermética e passou a desenvolver projetos com equipes multifuncionais,

integrando profissionais de outros departamentos. As empresas não sustentaram

mais os vultosos orçamentos de tecnologia de informação e comunicação. A

dinâmica dos negócios passou a exigir prazos menores para os projetos. E também,

a demora na manutenção dos sistemas, principalmente os que utilizam a Internet,

passou a gerar prejuízos incalculáveis para a organização. Essas características

fomentaram a terceirização e a subcontratação, estimularam a utilização de

processos de engenharia de software e valorizaram o gerenciamento de projetos.

Com o aprimoramento do hardware, os programas se tornaram mais

elaborados e complexos e a diferença entre as funcionalidades dos computadores

foi se concentrando nos softwares que rodavam no mesmo, iniciando uma crescente

onda de investimentos no setor; uma situação onde a procura por software se tornou

muito acima da demanda da área, devido a ciclos de vida muito extensos e

constantes manutenções, fator que culminou na chamada crise do software ou gap

de software, citado por Naur e Randell, em 1969, durante a primeira Conferência de

Engenharia de Software da OTAN, intitulada “North Atlantic Treaty Organization

Science Conference on software engineering” (NAUR; RANDELL, 1968).

Nesta conferência se discutiram os aspectos da crise do software, como o

gerenciamento de grandes projetos, com enormes variações em produtividade, a

falta de ferramentas, o número reduzido de componentes reutilizáveis, o grande

aumento da demanda e do tamanho dos programas, a falta de padronização e os

enormes custos de manutenção, entre outros (CUSUMANO, 1991).

34

Foi neste evento que o termo engenharia de software foi empregado pela

primeira vez, numa tentativa de associar à produção de sistemas a organização e

disciplina da engenharia, no que tange à utilização de processos bem elaborados e

atividades distribuída entre os participantes do projeto. Durante os aproximadamente

trinta anos em que se fala de crise do software, pode-se citar uma série de

problemas que caracterizam esses “males” que até hoje assombram as empresas de

desenvolvimento (SILVA, 1998).

São eles:

1) Falta de métodos eficazes para determinação de prazos e custos reais, afinal,

a complexidade dos sistemas aumentou consideravelmente, mas o processo

de produção continuou seguindo antigos e defasados padrões;

2) A grande necessidade do mercado em novos produtos, comparado com a

lentidão da produção dos mesmos;

3) A baixa qualidade dos softwares produzidos, que já apresentam requisitos

defasados quando da sua finalização, gerando muitas horas de manutenção;

4) Clientes insatisfeitos pela demora da entrega do serviço e pela não

conformidade com os requisitos solicitados;

5) A falta de informações ou de documentação gerando uma difícil manutenção

do software, aumentando o prazo para correção de erros por parte da

software house;

6) A ausência de métricas e metas no que tange o desenvolvimento de um

produto de software, e;

7) Não gerenciamento de riscos de desenvolvimento durante o projeto.

35

Apesar da atividade de desenvolvimento de software aparentar possuir

características especiais, bastante avessas às operações de uma fábrica comum,

uma possível solução que vem sendo mencionada e usada desde a década de 60 é

a associação da produção da engenharia de software com o processo fabril,

surgindo então o termo “fábrica de software”.

Segundo Cusumano (1989), um processo fabril constitui-se na produção de

produtos em massa, incluindo operações centralizadas de larga escala, tarefas

simples e padronizadas, controles padronizados, trabalhadores especializados, mas

com poucas habilidades, divisão de trabalho, mecanização e automação do

processo. Desta forma, a associação do termo fábrica ao desenvolvimento de

software sugere que se apliquem técnicas para produção em larga escala, de forma

coordenada e com qualidade.

O termo fábrica de software foi pela primeira vez usado em 1960

(CUSUMANO, 1989), mas se popularizou a partir da metade da década de 70 e nos

anos 80. Logo que surgiu, o termo foi associado a ferramentas apoiadas por

computador, sistemas de controle e gerência, modularização e reusabilidade.

Foi no Japão que uma empresa pela primeira vez assumiu o termo fábrica

em 1969. Nessa época, os objetivos da Hitachi para sua fábrica consistiam em:

aumento da produtividade e confiabilidade através de padronização e controle dos

processos, e a evolução do software de um serviço desestruturado para um produto

com um bom nível de qualidade (CUSUMANO, 1989). Após algum sucesso no

controle de processos, a Hitachi investiu em ferramentas automatizadas para

gerência de projetos e reutilização de código. Esta iniciativa reafirma a importância

do tripé de sustentação da fábrica de software (processo x gerência de projeto x

qualidade) defendido neste trabalho.

36

Citada por (CUSUMANO, 1989) como a segunda fábrica de software, a SDC

(Systems Development Corporation) era na época a líder americana no campo de

software customizado, se estabelecendo como fábrica de software em 1975,

inclusive registrando os direitos autorais sobre o uso do termo. O plano para

implantação desta fábrica de software consistia em 3 elementos: o uso de um

conjunto de ferramentas integradas, procedimentos padronizados e políticas de

gerenciamento, assim como uma organização matriz, separando os projetos

desenvolvidos nos clientes (alto nível) daqueles desenvolvimentos mais pesados

(realizados na fábrica).

Com o andamento da organização, obteve-se maior precisão na

determinação de prazos e valores. Entretanto, três anos depois, o projeto foi

encerrado por dois motivos básicos: dificuldade com as ferramentas da época em

implantar reuso de código e ferramentas, e a não adequação da forma de trabalho

descentralizada com times independentes nos clientes (terceirização da equipe) à

centralização de organização necessária para a fábrica.

É importante citar que mesmo depois de encerrada a iniciativa de fábrica de

software pela SDC, a mesma continuou usando alguns procedimentos e

ferramentas, também influenciando os padrões de software depois desenvolvidos no

departamento de defesa americano e no próprio Japão.

Um modelo de evolução das Fábricas de Software e suas características é

descrito por (CUSUMANO, 1991), de acordo com o quadro 2.1:

37

Quadro 2.1 - Fases de Maturidade das Fábricas de Software

Fase 1 (Meio dos anos 60 e início de 70)

Organização Formalizada e Estrutura de Gerenciamento: - Objetivos da Fábrica Estabelecidos - Foco do produto Determinado - Inicia o processo de coleta de dados e análise - Sistemas de controle iniciais introduzidos

Fase 2 (Início de 70 até início de 1980)

Adequação tecnológica e Padronização - Sistemas de controle e objetivos se expandem - Métodos padrão adotados para projeto, codificação, testes, documentação e manutenção - Desenvolvimento on-line através de terminais - Introdução das bibliotecas de programa - Início das metodologias e ferramentas integradas - Capacitação dos funcionários para padronização de habilidades.

Fase 3 (Final de 1970)

Mecanização e apoio ao processo - Introdução ao controle de projetos apoiado por ferramentas - Introdução a ferramentas para geração de código, casos de teste e documentação - Introdução a ferramentas de banco de dados on-line e de engenharia de Work Benches.

Fase 4 (Início dos anos 80)

Refinamento do processo e extensões - Revisão dos padrões - Introdução a novos métodos e ferramentas para estabelecer controle de qualidade e programas de círculo de qualidade. - Transferências de métodos e ferramentas para subsidiárias, sub-contratados e clientes de hardware.

Fase 5 (Meio dos anos 80)

Automação Integrada e Flexível - Aumento nas capacidades das ferramentas existentes - Introdução de ferramentas de apoio ao reuso - Introdução a ferramentas de automação do projeto - Maior integração entre ferramentas através de Engenharia de Work Benches.

Fase 6 (Final dos anos 80)

Produto Incremental / Melhoria na variedade - Controle de Processo e confiabilidade, seguidos por: melhor funcionalidade e facilidades de uso - Mais tipos de produtos.

Fonte: (CUSUMANO, 1991)

Desde 1968 alguns estudos publicados associam ainda características como

reusabilidade, utilização de ferramentas para suportar o desenvolvimento, sistemas

de controle e gerenciamento, modularização e produção de famílias de produtos

como básicas para uma organização que se intitula uma Fábrica de Software.

38

Mais recentemente, (GREENFIELD, 2003) nos apresenta uma visão

semelhante, onde o conceito de Fábrica de Software está fundamentado no

desenvolvimento baseado em componentes, direcionado a modelos e a linhas de

produto de software que caracterizariam uma iniciativa de fábrica, visando tornar a

montagem de aplicações mais barata através de reuso sistemático, possibilitando a

formação de cadeias de produção.

Já Fernandes (2004) apresenta fábricas de software como:

Um processo estruturado, controlado e melhorado de forma contínua, considerando

abordagens de engenharia industrial, orientado para o atendimento a múltiplas

demandas de natureza e escopo distintas, visando à geração de produtos de

software, conforme os requerimentos documentados dos usuários e/ou clientes, da

forma mais produtiva e econômica possível.

(FERNANDES, 2004, p. 117).

Este conceito baseia-se em alguns atributos básicos que o autor advoga

como imprescindíveis em qualquer Fábrica de Software, seja qual for a sua

categorização. Alguns destes atributos são: processo definido e padrão

(desenvolvimento, controle e planejamento); interação controlada com o cliente

(entradas e saídas da fábrica); solicitações de serviço à fábrica devem ser

padronizadas; estimativas de custos e prazos baseadas no conhecimento real da

capacidade produtiva com métodos de obtenção baseados em dados históricos;

controle rigoroso dos recursos envolvidos em cada demanda da fábrica; controle e

armazenamento em bibliotecas de itens de software (documentos, código, métodos,

etc); controle do status e execução de todas as demandas; produtos gerados de

acordo com os padrões estabelecidos pela organização; equipe treinada e

capacitada nos processos organizacionais e produtivos; controle da qualidade do

39

produto; processos de atendimento ao cliente; métricas definidas e controle dos

acordos de nível de serviço definidos com o cliente.

2.2.1. Estrutura de referência

Um modelo de referência consiste em um modelo conceitual para descrever

as características que uma fábrica de software deve incorporar a suas atividades.

A referência para a produção de software industrial trata-se do modelo ESF

Core (Eureka Software Factory Core), que foi o primeiro modelo a avaliar ciclos de

vida de fábrica de software e as operações da fábrica, no sentido de integrar a parte

técnica e organizacional da empresa com a parte de gerenciamento de projetos,

definido como planejamento em longo prazo (OLIVEIRA, 2001).

Este modelo tem como foco principal a produção de software em larga escala,

principalmente a comunicação dos requisitos e facilidades para a descrição de

sistemas e processos. Neste contexto, cabe a definição de Engenharia de Software

que é a base para tratar as características da produção de software industrial, desde

a utilização de ferramentas ao gerenciamento da fábrica; consistindo numa

necessidade de compartilhar conceitos de software entre os envolvidos no processo,

em todos os níveis de responsabilidade. Então, um modelo de referência para

fábricas de software deve retratar a idéia central da engenharia de software que é a

utilização de sistemáticas da engenharia aplicadas a desenvolvimento de software.

Esta estrutura deve ser entendida não apenas como um mecanismo de

facilidades para produção de software, mas como um instrumento para avaliação de

procedimentos promovendo a comunicação nos diversos setores da empresa, como

gerentes e engenheiros, vendedores e pesquisadores, com algumas características

essenciais: (OLIVEIRA, 2001)

40

• Favorecer um ambiente para discussões e análises, para que os usuários e

operadores da fábrica de software sejam capazes de identificar suas

necessidades;

• Definir inter-relacionamento entre pessoas e grupos envolvidos no processo de

produção na organização da fábrica de software;

• Ser um referencial para que os procedimentos sejam organizados de tal forma a

ser um argumento generalizado e não uma forma de tecnologia ou arquitetura

particular.

Um conjunto de definições e princípios aplicado ao Core pode ser entendido

de acordo com alguns conceitos:

• A utilização da informação deve resultar de um processo de comunicação, ou

seja, do desenvolvimento de software;

• A produção da implantação é favorecida pela fábrica de software que

determina de que forma esta informação deve ser utilizada;

Neste processo, é fundamental a produção de software envolvendo todas as

formas de comunicação coordenada. A tecnologia de infra-estrutura utilizada de

forma apropriada no contexto de comunicação integrando ferramenta e controle de

processo, afirmando a função que as mensagens – homem e / ou máquina – tenham

características que comprovem uma confiabilidade industrial. (OLIVEIRA, 2001)

(OLIVEIRA, 2001) destaca dois princípios básicos para a Fábrica de software:

• Trabalho sobre software consiste de comunicação coordenada;

41

• As pessoas e máquinas comunicam-se de maneira fundamentalmente

diferente.

A coordenação da fábrica é restringida pelos tipos diferentes de comunicação

de que as pessoas e máquinas são capazes. Com base nos princípios de fábrica é

possível identificar três classes de fluxo de comunicação:

1. Comunicação entre pessoas;

2. Comunicação entre usuários individuais e o sistema, de forma a ser

representado como uma rede de mecanismos interconectados;

3. Comunicação entre mecanismos.

As partes que compõem esta comunicação da fábrica de software consistem

na parte organizacional da fábrica, que são as pessoas envolvidas no trabalho de

produção (camada de pessoas); e o ambiente de suporte que consiste nos

mecanismos utilizados que tratam de software e hardware (camada de

mecanismos).

O modelo de referência para a Fábrica de Software deve apresentar

condições para que cada um dos fluxos de comunicação das classes e suas

interdependências sejam definidas; de acordo com a tecnologia que se melhor

apresente para o caso.

42

2.3. Características e vantagens

Uma Fábrica de Software busca atender solicitações de desenvolvimento de

software, provendo procedimentos e métodos, equipamentos, ferramentas, e

pessoal qualificado, necessários ao processo de desenvolvimento.

Considerando como conceito de fábrica de software uma forma particular de

trabalho organizado, com uma considerável especialização de papéis, formalização

de comportamento e padronização de tarefas, conclui-se que a mesma não se

constitui apenas pelo fato de produzir software, mas está fortemente fundamentada

em um controle de processo de desenvolvimento e gerenciamento de projetos, com

aplicação de métodos que garantam a otimização da produtividade e

conseqüentemente a qualidade do produto, alinhadas às necessidades do cliente,

garantindo o cumprimento das metas de prazos e de custos.

Uma vez definido o conceito de Fábricas de Software e citadas algumas de

suas características, as mesmas serão classificadas a fim de que possa ser

caracterizado o mapeamento dos processos.

A classificação adotada será a de (FERNANDES, 2004), onde, seguindo a

Figura 2.1 são apresentados os quatro tipos de fábricas classificadas de acordo com

o seu escopo de atuação ao longo das fases de desenvolvimento de um projeto de

software.

43

Figura 2.1 - Classificação de Fábricas de software de acordo com seu

escopo de fornecimento (Fernandes, 2004)

O autor também cogita a existência de uma fábrica de testes, que englobaria

apenas a fase de teste integrado. Porém, para o objetivo desde trabalho, a fábrica

de testes se enquadraria na mesma classificação da fábrica de programas que será

definida a seguir, apesar de geraram um produto final distinto.

A fábrica de programas consiste na menor unidade de fábrica,

conseqüentemente a menos complexa. Tem por objetivo principal codificar e testar

programas de computador. No seu processo produtivo engloba praticamente as

fases de construção e testes unitários.

A fábrica de projetos atua com um pouco mais de abrangência no processo

de produção, englobando além das atividades inerentes à fábrica de programas,

fases como projeto conceitual, especificação lógica, projeto detalhado da solução,

realização de testes de integração e de aceitação. Dependendo da interface com o

cliente, a fábrica pode se caracterizar por projetos de software ou projetos físicos,

porém, seus requisitos e características básicas são muito semelhantes. No caso

das fábricas de projetos de software, há a necessidade do conhecimento do negócio

do cliente. A fábrica de projetos ampliada não será tratada neste mapeamento,

pois engloba soluções mais abrangentes de Tecnologia da Informação fugindo ao

44

escopo da pesquisa, podendo ser representada no nível da fábrica de projetos de

software.

Mesmo não estando incluído na Figura 2.1, o modelo de outsourcing de

sistemas é citado como uma especialização da fábrica de projetos, onde a mesma é

dedicada exclusivamente a um determinado cliente, diferenciando apenas na

interface da fábrica com o cliente, que deve ser adaptada aos critérios e regras

estabelecidas previamente entre ambos, normalmente através de um SLA – Service

Level Agreement – que descreve estes critérios, restrições e procedimentos de

mudança no escopo e na avaliação do serviço (ASSANO, 2002). O modelo de

outsourcing apresentado pelo autor é bem mais complexo e envolve outros

processos auxiliares, que se tornam essenciais para esta modalidade.

Merece destaque ainda a fábrica de componentes, porém, segundo

(BASILI, 1994) os processos de desenvolvimento atuais não suportam diretamente a

utilização de componentes, uma vez que definem apenas as fases de

desenvolvimento do projeto, que utilizam os componentes já catalogados.

Desta forma, o mapeamento não se estenderá a esta classe de Fábricas de

Software. Entretanto, os processos devem ser escolhidos de forma a utilizarem e

tirarem as vantagens inerentes da reutilização de artefatos durante todo o ciclo de

vida.

2.4. Como implantar uma fábrica de software

Conforme citado nas seções anteriores, o grande objetivo de uma Fábrica de

Software sem dúvida é o desenvolvimento de produtos com qualidade a baixos

custos e dentro do prazo.

45

Segundo Cusumano (1991), a evolução para um modelo de fábrica passa

pelos seguintes passos:

1) Criar sistemas de controle e organização formal para o gerenciamento do

desenvolvimento de software;

2) Escalar métodos, ferramentas, sistemas de controle e padrões para as

diferentes famílias de produtos;

3) Desenvolver ferramentas para automatizar aspectos de gerenciamento de

projetos, geração de código, testes e documentação;

4) Refinar as ferramentas de desenvolvimento e técnicas, assim como estendê-

las para subsidiárias, sub-contratadas e clientes;

5) Buscar níveis mais elevados de integração entre ferramentas, adicionando

novas funções como reutilização, projeto e análise de requisitos.

6) Aumentar gradualmente os tipos de produtos em desenvolvimento, assim

como dar mais atenção a assuntos como funcionalidade do produto e

facilidade de uso.

Desta forma, este trabalho defende que para implantar uma Fábrica de

Software ou reestruturar uma equipe de forma que a mesma possa atender a estas

necessidades, se faz necessário que se apresentem três elementos básicos:

Processo de Desenvolvimento, Planejamento e Gerência de Projetos e

Modelos de Qualidade.

Entende-se por processo de desenvolvimento o modelo que deve ser seguido

para desenvolver um software, desde a elicitação de seus requisitos e levantamento

da oportunidade até o processo de manutenção após sua instalação. Nos processos

46

são definidos, além de cada fluxo de tarefas, os papéis e atividades a serem

realizadas pela equipe.

O planejamento e a gerência de projetos podem ser considerados como a

mola propulsora do processo como um todo, de forma que acompanham todo o ciclo

de vida do software, definindo padrões de gerenciamento e de feedback com o

cliente e com a equipe. Pode-se dizer que muito do sucesso de um projeto deve-se a

uma boa gerência do mesmo.

Os modelos de qualidade são padrões criados por algumas instituições que

formatam os produtos de software e os processos de criação dos mesmos,

indicando o nível de excelência atingido pela equipe em questão. São um conjunto

de normas reconhecidas mundialmente que asseguram determinados graus de

qualidade ao produto de software e/ou processo de desenvolvimento do mesmo.

Desta forma, é importante que a fábrica cultive interesses em certificações nessas

áreas para assegurar aos clientes a aplicação dos padrões sugeridos.

2.5. Processos de desenvolvimento

Informalmente, o processo de software pode ser compreendido como o

conjunto de todas as atividades necessárias para transformar os requisitos do

usuário em software (HUMPHREY, 1989). Um processo de software é formado por

um conjunto de passos de processo parcialmente ordenados, relacionados com

conjuntos de artefatos, pessoas, recursos, estruturas organizacionais e restrições e

tem como objetivo produzir e manter os produtos de software finais requeridos

(LONCHAMP, 1993).

47

A produção de software é uma atividade que requer uma série de passos, que

ordenados de forma lógica, definem o ciclo de vida do produto de software. Este

processo de produção que define a construção desde o nascimento da idéia, até o

descarte do produto, é chamado segundo (GUEZZI, 1991) de processo de

desenvolvimento de software.

Usando um processo de desenvolvimento faz-se uso de alguns dos

benefícios de processos padronizados, entretanto, a produção de software possui

algumas características que não podem ser confundidas com outros processos de

produção, afinal, software é um produto intelectual e está constantemente em fase

de evolução (GUEZZI, 1991). Esta organização do processo de produção de

software também pode ser chamada de “ciclo de vida”. A engenharia de software

preza que este ciclo pode ser padronizado, aprimorado, controlado e automatizado

para alcançar um produto de maior qualidade, em menos tempo e com menores

custos (GUEZZI, 1991).

De acordo com Pressman (2000), no contexto de engenharia de software, um

processo é um framework para as tarefas necessárias à construção de software com

alta qualidade, definindo a abordagem que será adotada enquanto o software estiver

em desenvolvimento.

Os passos de processos são atividades. Uma atividade é um passo de

processo que produz mudanças de estado visíveis externamente no produto de

software. As atividades estão associadas a papéis, ferramentas e artefatos;

incorporam e implementam procedimentos, regras e políticas; e têm como objetivo

gerar ou modificar um dado conjunto de artefatos.

Uma atividade aloca recursos (por exemplo, máquinas e orçamento) e é

escalonada, monitorada e atribuída a desenvolvedores (agentes), que podem utilizar

48

ferramentas para executá-las. Um agente está relacionado com as atividades de um

processo e pode ser uma pessoa ou uma ferramenta automatizada. Diferentes

agentes terão percepções diferentes acerca do que acontece durante o processo de

software. Por sua vez, artefato é um produto criado ou modificado durante um

processo. Tal produto é resultado de uma atividade e pode ser utilizado

posteriormente como matéria-prima para a mesma ou para outra atividade a fim de

gerar novos produtos.

A descrição abstrata do processo de software caracteriza um modelo de

processo de software. Vários tipos de informação devem ser integrados em um

modelo de processo para indicar quem, quando, onde, como e por que os passos

são realizados.

Segundo Conradi (1994), projeto é a instância de um processo, com

objetivos e restrições específicos. Pode-se dizer que um projeto é um esforço para

desenvolver um produto de software, ou seja, envolve uma estrutura organizacional,

prazos, orçamentos, recursos e um processo de desenvolvimento.

2.5.1. Tipos de processos de software quanto à execução

Na literatura especializada pode-se encontrar duas frentes de processo de

software no tocante à execução. A primeira, definida como um processo tradicional,

ou também chamada de processo pesado, que se caracteriza por possuir como foco

principal a previsibilidade dos requisitos do sistema e o comando e o controle destes

a partir de um prévio planejamento antes do início do desenvolvimento,

transformando estas ações em um processo rigoroso (PRESSMAN, 2000). Rigoroso

pois a especificação de requisitos torna-se a etapa fundamental, onde todas as

49

necessidades do cliente são definidas e documentadas, sendo que para cada um

destes requisitos, são gerados outros documentos, tornando o processo de análise e

projeto bastante demorado e de difícil manutenção caso alguma especificação seja

alterada. Dentro deste contexto, pode-se exemplificá-lo como o processo unificado

(Processo Unificado Rational).

Pode-se, ainda, caracterizar que este tipo de processo possui uma

abordagem voltada para o planejamento detalhado, fases seqüenciais de processo e

artefatos de uma fase para a seguinte.

Já a outra frente, chamada de processo ágil ou processo leve, possui seu

foco na eficiência, abordando como premissa o compromisso entre “nada de

processo” e processos rigorosos (BECK, 2000). Esta frente propõe que a análise de

requisitos seja extremamente mutável, “abraçando” mudanças como principal área

de atuação da metodologia. Sendo assim, os planejamentos são constantes, não

havendo uma etapa exclusiva para isso, ficando o foco principal com a codificação.

Para isso os meios para estes fins são: adaptabilidade; cada item de processo deve

agregar valor; orientação a pessoas; comunicação; e aprendizado. Para exemplificar

esta outra linha de processos tem-se o XP (eXtreme Programming).

Desta forma, pode-se listar como principais pontos fracos destes tipos de

processo, os listados a seguir (ROCHA, 2005):

• Processo Tradicional: a burocracia, uma vez que agrega mais tarefas para

as suas ações; e a não adaptabilidade, onde a realidade (prazo, escopo,

processo, pessoas) difere do planejado / documentado;

50

• Processo Ágil: a escalabilidade para equipes grandes / dispersas; e a

mudança de cultura de paradigma.

Já como pontos fortes, tem-se (ROCHA, 2005):

• Processos Tradicionais: é baseado em wokflows de processo; orientado a

planejamentos; garantia alta de desenvolvimento; equipes e produtos

grandes; projetado para suportar requisitos correntes e desconhecidos;

modelo de desenvolvimento de software completo incluindo suporte a

ferramentas; atribuições centradas no objetivo das atividades; possibilita ser

instanciado e customizado de acordo com o domínio da aplicação ou da

organização.

• Processo Ágil: revisa-se o código todo o tempo; toda a equipe irá testar o

software inclusive o cliente; toda a equipe torna a atividade de projeto diária; a

arquitetura será definida e refinada todo o tempo; possui interações curtas

caracterizadas por minutos e horas; modularidade no nível de

desenvolvimento do processo; orientado a pessoas.

No caso de uma fábrica de projeto, que se assemelha à maioria das fábricas

que desenvolvem aplicações personalizadas, (ROCHA, 2005) demonstra uma

tendência para os métodos tradicionais, uma vez que se faz necessário documentar

e não raramente, validar formalmente com o cliente as decisões de requisitos e/ou

projeto. Estes produtos também possuem um ciclo de vida maior, o que torna

comum durante o desenvolvimento de um determinado projeto a entrada e saída de

pessoal, o que dificultaria a utilização de um processo orientado a pessoas como os

processos ágeis.

51

Assim, a fim de obter um ganho maior de produtividade e facilitar o

atendimento dos objetivos que a fábrica se propõe, dentro do contexto tendencioso

de uma fábrica de projetos com múltiplas demandas, pode-se observar que o

processo de desenvolvimento que melhor se adequa a estrutura proposta é o

processo unificado (Processo Unificado Rational). Desta forma, será executado o

seu estudo na seção 3 deste trabalho.

2.6. Projetos de software

Um projeto consiste numa organização sistemática de atividades para atingir

resultados; um empreendimento que visa a criação de um produto ou a execução de

um serviço específico, temporário, não-repetitivo e que envolve um certo grau de

incerteza na realização. Como todo empreendimento, as atividades precisam ser

planejadas, programadas e, durante a execução, precisam ser controladas.

(KERZNER, 2002).

Todos os projetos são divididos em fases: Início, Planejamento, Controle,

Execução, Encerramento. (MARTINS, 2002).

Figura 2.2 – Fases do Projeto de Software (MARTINS, 2002)

Início

Planejamento

Controle Execução

Encerramento

52

A figura 2.2 mostra as fases de um projeto de software segundo o autor

citado, contudo, ele menciona que, a partir da criação do PMI (Project Management

Institute), a estruturação do PMBOK permitiu descrever conceitos, padronizar

técnicas e processos utilizados para o gerenciamento de projetos. Assim, o PMI

criou um documento que foi registrado como PMBOK (Project Management Body of

Knowledge), onde consta a teoria de gestão com todos os seus procedimentos.

Desta forma, será citado a seguir de que forma tais procedimentos foram

teorizados, baseados no PMBOK:

a. Início

Compreende a definição do produto e das estimativas preliminares de prazo e

custo. A proposta básica pode passar por diversas análises antes que o projeto seja

aprovado. Consiste no nascimento do projeto, em que são definidos o esboço do

escopo do projeto ou serviço, que será entregue no final do projeto, e o Gerente do

Projeto. (MARTINS, 2003).

No final desta fase, deverão estar definidos no documento chamado

Autorização de Início de Projeto.

Todo início de projeto requer um perfeito entendimento entre os envolvidos

sobre qual é a sua Missão. (MARTINS, 2003). A missão para serem estabelecidas

metas e objetivos e tomar decisões; ou seja, qualquer questão que surgir durante o

planejamento e a execução. Neste aspecto é de fundamental importância serem

analisadas três questões:

• O que produzir: Esta questão está diretamente relacionada aos produtos,

resultados e objetivos do produto.

• Para quem produzir: Identificação dos clientes a quem se destina os produtos

ou serviços.

53

• Como será produzido: Processos e métodos que serão utilizados para atingir

o objetivo da missão.

b. Planejamento

Os recursos são mobilizados, com base em um planejamento detalhado das

definições contidas na proposta básica. O plano detalhado também pode passar por

sucessivas análises. A equipe é montada, o escopo do produto é detalhado, o

escopo do projeto é definido, o prazo e o custo são estimados, os riscos são

identificados, as ações corretivas são definidas e a forma de comunicação é

estabelecida. (MARTINS, 2003).

Nesta fase do projeto, são identificadas as pessoas que farão parte do projeto

e seus respectivos papéis. Projetos podem envolver ampla gama de pessoas com

diferentes habilidades e experiências. Mas existem muitos papéis básicos comuns a

todos os projetos.

É importante conhecer as funções que esses profissionais devem desempenhar:

(CAJADO, 1999).

1) Gerente de Projeto: executa as funções de gestão, planejamento e controle.

Deve ser uma pessoa com um perfil de liderança, poder de decisão, ser

comunicativo. É o responsável pela obtenção dos objetivos do projeto e pela

liderança da equipe; produz um plano de ação detalhado; motiva e organiza a

equipe de projeto; comunica informações do projeto a apoiadores e outros

interessados; monitora a evolução do trabalho. A gerência de

desenvolvimento de software precisa ter em mente que sua atividade deve

objetivar a qualidade, produtividade e redução de riscos através do

54

planejamento e execução do desenvolvimento do produto, sobre os quais

serão abordados mais adiante de forma específica.

2) Equipe: É composta pelo pessoal que, em tempo integral ou não, executa

tarefas para o andamento do projeto; executa atividades segundo foram

descritas no plano do projeto; desempenha papel especializado se envolvido

como consultor ou como alguém só necessário em parte do projeto.

3) Apoiador: Dá assistência ao gerente e fornece a quantidade de

conhecimentos necessária; tem, responsabilidade final sobre o sucesso do

projeto; estuda a viabilidade do projeto e ajuda em seu planejamento; é

responsável pelo encerramento do projeto no prazo e dentro do orçamento.

4) Cliente: Contribui com a verba do projeto e define as exigências do produto ou

serviço. Interno ou externo à empresa, beneficia-se das mudanças que serão

trazidas pelo projeto; influencia fortemente os objetivos do projeto e o modo

de medir seu sucesso; impõe como e quando algumas atividades devem ser

conduzidas; serve como guia ao gerente de projeto.

5) Gerente Funcional: gerencia os departamentos funcionais, que fornecerão

mão-de-obra para execução dos trabalhos do projeto.

6) Outros interessados: áreas da empresa, entidades e outras pessoas que de

alguma forma serão afetados pelo projeto.

c. Execução

Esta fase significa a realização das tarefas definidas no planejamento do

projeto: (MARTINS, 2003).

• Realização das tarefas pela equipe;

• O gerente de projeto desenvolve a equipe;

• Todos trabalham para garantir a qualidade;

55

• Todos se comunicam e distribuem informações;

• Os responsáveis fazem o gerenciamento dos riscos;

• O gerente de projeto dirige o projeto;

• Os problemas são solucionados;

• O projeto é re-planejado quando necessário, quando um risco se torna

realidade;

• Todos influenciam na organização do trabalho.

d. Controle

Esta fase consiste no acompanhamento das atividades baseadas no

planejamento, para medir o andamento do projeto, comparar o previsto com o

realizado e ajustar o que se fizer necessário no projeto. Inicia-se desde o

planejamento, e ocorre paralelamente com a fase de execução, envolvendo as

seguintes atividades:

• Gerenciamento de mudanças

• Questionamento do trabalho executado

• Reuniões de acompanhamento

• Controle de qualidade do projeto

• Controle do tempo e do orçamento.

As atividades relacionadas à fase de controle, estão descritas no PMBOK

(MARTINS, 2003), e a seguir demonstradas na figura abaixo:

56

Figura 2.3 - Atividades Relacionadas com a Fase de Controle (PMI, 2004)

e. Encerramento

Esta é a fase final do ciclo de vida de um projeto. Neste momento, o produto

ou serviço é entregue aos clientes e aceito pelos usuários; concluindo assim o

projeto. Para tal, faz-se necessário que a documentação seja verificada e atualizada,

sendo os resultados do projeto registrados e o aceite formal é obtido do apoiador e

do cliente. A equipe deve ter conhecimento do aprendizado para as conseqüentes

melhorias técnicas nos novos projetos.

A documentação deve ser guardada para futuro uso e manutenção; a

medição do progresso deverá atuar como base para novas estimativas de prazo e

custo para outros projetos. Um relatório deverá ser elaborado chamado de Relatório

de Fechamento (MARTINS, 2002), para comunicar o término do projeto aos

participantes, assim como o aceite formal do cliente deve ser documentado.

Planejamento

Verificação do Escopo

Mudanças de Escopo

Controle do Tempo

Controle do Custo

Controle da Qualidade

Monitoração e Controle

do Risco

Execução

Controle

Relatórios de Progresso

Controle Geral das mudanças

57

O sucesso no término de um projeto deverá ser conhecido antecipadamente

aos critérios de aceite do cliente, pelo fato de que a equipe poderá reproduzir os

testes dos produtos ou serviços antes da entrega.

2.6.1. Características básicas da gerência de projetos

Em um projeto devem ser definidos pontos claros do início ao fim, uma série

de atividades entre eles e um conjunto de objetivos. No ambiente empresarial

altamente competitivo nos dias atuais, é primordial reagir com rapidez e flexibilidade

às reais necessidades dos clientes. O gerenciamento de projeto permite focar

prioridades, monitorar desempenhos, superar dificuldades e adaptar-se a mudanças.

Ele lhe dá mais controle e fornece técnicas que ajudam a liderar equipes para atingir

metas no prazo e dentro do orçamento. Organizar as tarefas de um projeto pode

demandar tempo no início, mas em longo prazo economiza tempo e esforço, e reduz

o risco de erros (AMARU, 2003).

É necessário um planejamento para mensurar custos, tempo e riscos, tendo-

se em conta um orçamento e um cronograma. Neste contexto, tem-se as

ferramentas básicas que são: gerente, equipe, estrutura organizacional, preparação

e execução do plano do projeto; assim como devem ser analisadas as variáveis

críticas de desempenho: escopo (produto), prazo, custo, risco.

A gestão do projeto necessita de processos maduros, e para tal deve-se ter o

domínio ciclo de vida de software, ter uma metodologia de desenvolvimento clara,

além de pessoal bem-treinado e capacitado para que o resultado seja uma previsão

confiável (KERZNER, 2002).

Na gerência de projetos de software são necessários o conhecimento, as

técnicas e as ferramentas para executar e controlar o desenvolvimento de produtos

58

de software. A gerência de desenvolvimento de software deve objetivar a qualidade,

produtividade e redução de riscos através do planejamento e execução do

desenvolvimento do produto. A atividade mais crítica sob responsabilidade dessa

gerência é, sem dúvida nenhuma, a que envolve o fator humano. O software é

totalmente dependente da habilidade dos desenvolvedores, que devem estar

preparados e comprometidos com o processo (BRUCE; LANGDON, 2003).

2.6.2. Contexto da gerência de projetos de software

O gerenciamento de projetos de software tem características diferenciadas do

gerenciamento de outros tipos de projeto; pelo fato de que as etapas do processo de

desenvolvimento de software não se comparam a qualquer outro processo produtivo

porque não são tangíveis. O software não pode ser visto em produção; somente na

sua conclusão é que se tem o produto propriamente dito.

No trabalho de produção de software, não existe um processo de manufatura,

embora o objetivo seja o de fazê-lo ficar o mais próximo possível. O processo de

desenvolvimento termina com a utilização pelo usuário. Problemas que são

normalmente descobertos durante o uso deveriam ter sido encontrados na etapa do

desenvolvimento.

A seguir será executada a definição das áreas de conhecimento da gerência

de projetos, de acordo com as características de projetos de software citadas

anteriormente.

59

2.6.2.1. Gerência de requisitos

Os requisitos de projeto de software são freqüentemente classificados como

funcionais, não-funcionais ou de domínio. Os requisitos funcionais são as

declarações de funções que o sistema deve fornecer, como o sistema deve reagir a

entradas especificas e como deve se comportar em determinadas situações. Em

alguns casos, estes requisitos podem explicitar de forma clara o que o sistema não

deve fazer (SOMMERVILLE, 2003).

Os requisitos não-funcionais constituem as restrições sobre os serviços ou as

funções oferecidos pelo sistema. Entre eles destacam-se as restrições de tempo,

restrições sobre o processo de desenvolvimento, padrões, entre outros.

Os requisitos de domínio se originam do domínio da aplicação do sistema e

que refletem características desse domínio. Podem ser requisitos funcionais ou não-

funcionais.

Deve-se considerar como objetivos primários no gerenciamento de projetos

em software, a qualidade, a produtividade e a redução de riscos (CAJADO, 1999).

Existem alguns tipos de problemas que surgem durante o processo de

gerenciamento de requisitos que são resultados da ausência da separação entre os

diferentes níveis de descrição. Os requisitos podem ser classificados da seguinte

forma: (SOMMERVILLE, 2003).

• Requisitos de usuário, que podem ser definidos como declarações, e

diagramas sobre as funções que o sistema deve fornecer e as limitações

sobre as quais deve operar; o software deve oferecer um meio de representar

e acessar arquivos externos criados por outras ferramentas.

• Requisitos de Sistema, que detalham as funções e as restrições do sistema.

O documento de requisitos do sistema (especificação funcional) é necessário

60

para elucidar diversas questões. Serve como contrato entre o comprador do

sistema e o desenvolvedor do software;

• Especificação de projeto de software, que é uma descrição abstrata do projeto

de software, sendo a base para o projeto e implementação de forma mais

detalhada. As especificações acrescentam mais detalhes à especificação dos

requisitos do sistema.

2.6.2.2. Gerência da qualidade

A qualidade, segundo o Software Engineering Institute (SEI), só poderá ser

alcançada com a aderência dos processos de desenvolvimento ao modelo

estabelecido através de comprovadas técnicas de desenvolvimento e verificação

periódica do processo técnico. A gerência deve cooperar e coordenar as atividades

com a qualidade garantida estabelecida pela organização quando essas técnicas

existirem. A melhoria contínua da qualidade resulta em importantes lições para o

desenvolvimento de software.

Para a gerência de qualidade de software, são classificadas três atividades

principais: (SOMMERVILLE, 2003).

• Garantia de qualidade: são definidos procedimentos e padrões

organizacionais para que possa ser produzido software de alta qualidade;

• Planejamento da qualidade: são selecionados procedimentos e padrões que

sejam adequados a estrutura e a sua conseqüente adaptação para um projeto

específico de software.

61

• Controle de qualidade: a definição e a aprovação de processos que

assegurem que os procedimentos e os padrões de qualidade de projeto sejam

seguidos pela equipe de desenvolvimento de software.

O gerenciamento da qualidade fornece uma verificação independente sobre o

processo de desenvolvimento de software. Os produtos entregues a partir do

processo de software são entradas para o processo de gerenciamento de qualidade

e são verificados para assegurar que são consistentes, como os padrões e os

objetivos da organização. Este gerenciamento deve ser separado do gerenciamento

do projeto, de modo que a qualidade não seja comprometida pelas

responsabilidades de gerenciamento quanto ao orçamento e aos prazos de projeto.

2.6.2.3. Gerência de riscos

A gerência de desenvolvimento de software deve identificar as partes mais

difíceis de um desenvolvimento em particular e sistematicamente trazer soluções

eficientes. Requerimentos que podem comprometer o projeto devem ser tratados no

início do processo. Nesse particular, o papel do gerente de projetos de software é

fundamental para que os objetivos da gerência de projetos de software sejam

alcançados. O gerente trabalha com idéias, coisas, e, principalmente, pessoas. O

gerente deve também ter o comprometimento da equipe, a qual deve seguir e

manter prazos, custos e qualidade estipulados.

A atividade de gerenciar projetos é a etapa mais alta do processo de software.

Inclui pontos de conhecimento e organização que são pré-requisitos para essa

função, além do trabalho de ambientação do fator humano (PRESSMAN, 2000).

62

Pode-se classificar o gerenciamento e a monitoração dos riscos da seguinte

forma: inicialmente são levantados os possíveis riscos através de análise;

posteriormente estes dados servem para definir os passos para serem

administrados; é definido um Plano de Administração e Monitoração dos Riscos

(PAMR). Inicia-se a monitoração dos riscos que consiste em uma atividade de

rastreamento do projeto, com três objetivos principais:

• Avaliar se um risco previsto, de fato ocorre;

• Garantir que os passos de reversão definidos para o risco estejam

adequadamente aplicados;

• Coletar informações que possam ser usadas em análises de riscos futuras.

2.6.2.4. Gerência de recursos

O gerenciamento dos recursos não envolve somente os recursos tecnológicos

e financeiros de um projeto, deve ser considerado também o fator humano

(SOMMERVILLE, 2003).

Para uma tarefa na qual a estimativa dos recursos exigidos em que o

desenvolvimento do software tenha o efeito desejado, é necessário definir: as

ferramentas que serão utilizadas (hardware e software), e os recursos humanos

(pessoas). Para tal, cada tipo de recurso deve seguir uma especificação segundo

algumas características que consistem na descrição do recurso; uma declaração de

disponibilidade; tempo em que o recurso será alocado e por quanto tempo o recurso

será utilizado (PRESSMAN, 2000).

Para as especificações exigidas para cada tipo de recurso, devem ser

estabelecidas as seguintes atividades:

63

§ Para os Recursos Humanos: especificar as habilidades exigidas; a

disponibilidade; a duração das tarefas e a data de início das atividades;

§ Para as Ferramentas de Hardware e Software: especificar a descrição de

cada ferramenta; a disponibilidade; a duração do uso e a data da entrega.

2.6.2.5. Estimando custos e prazos

Para a criação, de orçamentos de projeto detalhados, o software precisa

aproximar-se do sistema de contabilidade de custo da companhia. Nessa categoria,

os usuários necessitam de ferramentas de avaliação de risco e devem considerar a

curva da aprendizagem. Esses produtos normalmente devem ter características

sofisticadas para fazer carga de dados e dos recursos, de modo a poder avaliar o

desempenho dos mesmos (CAJADO, 1999).

O custo, o cronograma e a qualidade são as três variáveis principais de um

projeto. Quando uma ou mais dessas variáveis se modifica, as restantes também

mudarão. Por exemplo, se a quantidade de tempo e dinheiro disponível em um

projeto diminuir muito certamente isso irá limitar a qualidade do produto. De maneira

similar, a produção da mesma qualidade em um período mais curto tem um custo

maior. O gerente de projeto tem como desafio, a ajustar essas variáveis para criar

um equilíbrio ideal entre custo, cronograma e qualidade.

Não existe uma maneira simplificada de estimar precisamente esforços

necessários para desenvolver um sistema de software. As estimativas iniciais talvez

precisem ser feitas com base em uma definição de alto nível de requisitos de

usuário. É possível que o software tenha de ser executado em computadores que

não sejam familiares, ou seja, utilizada uma tecnologia de desenvolvimento nova. As

64

pessoas envolvidas no projeto, e também suas habilidades, provavelmente não

serão conhecidas. Todos esses fatores significam que é difícil produzir uma

estimativa exata dos custos de desenvolvimento de sistema em um estágio muito

inicial do projeto.(SOMMERVILLE, 2003).

2.6.2.6. Gerenciamento de configuração e mudanças

O gerenciamento de configuração é o desenvolvimento e a aplicação de

padrões e procedimentos para gerenciar um produto de sistema em

desenvolvimento. É necessário gerenciar os sistemas em desenvolvimento porque, à

medida que eles evoluem, são criadas muitas versões diferentes de software. Essas

versões incorporam propostas de mudanças, correções de defeitos e adaptações

para diferentes hardwares e sistemas operacionais. É possível que haja várias

versões em desenvolvimento e em uso ao mesmo tempo. É necessário manter o

controle das mudanças que foram implementadas e de como essas mudanças foram

incluídas no software.

O gerenciamento de configuração é visto por algumas vezes, como parte de

um processo mais geral de gerenciamento de qualidade de software; o gerente pode

compartilhar responsabilidades pelo gerenciamento da qualidade e pelo

gerenciamento de configuração. O software é liberado pelos desenvolvedores para

uma equipe de controle de qualidade, que é responsável por conferir se o sistema é

de qualidade aceitável. Esse software é, então, passado para a equipe de

gerenciamento de configuração, que fica responsável por controlar as mudanças no

software. Os sistemas controlados são, algumas vezes, chamados de baselines,

quando são o ponto de partida para o desenvolvimento controlado.

(SOMMERVILLE, 2003)

65

2.6.2.7. Acompanhamento

Conforme o Software Engineering Institute (SEI), os pontos técnicos para o

gerenciamento de software podem incluir uma definição no modelo de ciclo de vida e

nos tipos de planos a serem utilizados para testes, documentação, desenvolvimento,

qualidade, gerenciamento, etc.

São requisitos técnicos indispensáveis para o gerenciamento de software:

métodos de documentação do plano, estruturas de divisão de trabalho, PERT / CPM,

tabelas de Gantt e padrões (BRUCE; LANGDON, 2003).

O planejamento para gerenciamento e controle de risco envolve critérios de

entradas e saídas, pontos de verificação intermediários, prognóstico e análises de

desempenho, protótipos e modelagens, inspeções e revisões, processo e avaliação

do processo, métodos de desenvolvimento, métricas, gerenciamento de

configuração, testes e garantia de qualidade, além de planejamento de capacidade.

2.7. Qualidade em software

A Qualidade de Software nos dias atuais tornou-se uma característica

essencial para uma fábrica de software que deseja posicionar o seu produto no

mercado global. Os mais experientes desenvolvedores de software são unânimes ao

concordar que a Qualidade de Software é uma meta que deve ser alcançada sempre

(PRESSMAN, 2000).

Definir qualidade é uma tarefa difícil tendo em vista a subjetividade aparente

do conceito e a impossibilidade de medi-la e evidenciá-la. Ainda assim a sua

ausência é notada ainda que não se tenha ferramentas específicas para detectá-la.

Segundo a ISO, qualidade é a totalidade das características de um produto ou

66

serviço que suportam a sua capacidade para satisfazer necessidades específicas ou

implícitas. Não é possível, portanto, afirmar que a qualidade é absoluta, pois é

multidimensional, está sujeita a oscilações, varia consoante os compromissos

aceites e é avaliada por critérios interdependentes.

(BARTIÉ, 2002) define Qualidade de Software como “um processo

sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de

garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos”.

Ou ainda, segundo (PRESSMAN, 2000), Qualidade de Software é “estar em

conformidade aos requisitos funcionais e de desempenho explicitamente declarados,

a padrões de desenvolvimento claramente documentados e a características

implícitas que são esperadas de todo software profissionalmente desenvolvido”.

De posse desta afirmativa, Pressman (2000) enfatiza três pontos básicos para

elucidar a sua teoria:

1. Os requisitos de software são a base a partir da qual a qualidade é medida: a

falta de conformidade aos requisitos significa falta de qualidade.

2. Padrões especificados definem um conjunto de critérios de desenvolvimento

que orientam a maneira segundo a qual o software passa pelo trabalho de

engenharia: se os critérios não forem seguidos, o resultado quase que

seguramente será a falta de qualidade.

3. Há um conjunto de requisitos implícitos que freqüentemente não são

mencionados (por exemplo, o desejo de uma boa manutenibilidade): se o

software se adequar aos seus requisitos explícitos, mas deixar de cumprir

seus requisitos implícitos, a qualidade de software será comprometida.

67

A qualidade de software é uma combinação de fatores complexos, que terá

variação de cliente para cliente e ainda entre as diferentes aplicações requisitadas

pelos mesmos, onde o produto final deve alcançar as condições mínimas, ou mesmo

exceder as expectativas do cliente (UPF, 2003).

Um produto de qualidade direciona para o aumento da produtividade e

permanentemente reduz custos, habilitando o gerenciamento para reduzir a correção

de defeitos dando ênfase à prevenção (UPF, 2003).

Mais qualidade aumenta a satisfação dos consumidores e assegura os que já

são clientes a permanecerem com a fábrica de software (UPF, 2003).

A qualidade de software sempre vai ser um processo de constante

aprimoramento, pois sempre será possível fazer softwares melhores e para isso

deve-se envolver pessoas, tecnologia, equipamentos, além do fato da fábrica de

software se adaptar às necessidades do cliente. Se o objetivo for produzir softwares

de qualidade, será necessário investir em qualidade em todas as etapas do

processo de desenvolvimento do software (BARTIÉ, 2002).

Da muiltidimensionalidade (custo, funcionalidade, portabilidade, exatidão,

oportunidade, sustentabilidade, flexibilidade) da qualidade do software resultam,

naturalmente, os vários pontos de vista por que pode ser observada. Assim, as

preocupações do gestor do projeto são diferentes das preocupações do analista, das

do programador, das do auditor, das do usuário final, das do gestor ou das do

sponsor. O gestor do projeto está preocupado com a produção de um produto que

satisfaça o cliente, respeitando os requisitos e prazos acordados, ainda que

constrangido pelo custo. O analista é o amigo do cliente, compreende suas

necessidades, dedica toda a sua competência na funcionalidade do software. O

programador é o dono do conhecimento técnico e raramente admite que a sua

68

solução não é a melhor para o utilizador. Ao auditor compete a avaliação da

qualidade, despista ineficiências, face aos compromissos assumidos. A sua ação,

quase sempre determina custos adicionais. O usuário final é o elemento mais crítico

do sistema, é preciso que esteja satisfeito, que use de fato o software, que encontre

nele o que idealizou para lhe facilitar ou valorizar o trabalho. A sua opinião é

determinante na aceitação da encomenda. O gestor, elemento acima do usuário

final, na cadeia de reporte, espera que o software mobilize os seus colaboradores e

seja estímulo para maior produtividade, evidência de inovação. O sponsor é quem

paga a conta e pretende ver o investimento rentabilizado, aumentando seu prestígio

institucional.

A avaliação da qualidade pode ser dependente dos atores acima

identificados, entre outros, atuando em circunstâncias como, por exemplo:

• Observações feitas por usuários e clientes.

• Assistência técnica ao usuário.

• Comunicação entre usuários e desenvolvedores.

• Ambiente utilizado.

• Organização da arquitetura e processos de execução do produto etc.

Para Basili (et al, 2004), qualidade é uma característica intrínseca e

multifacetada de um produto. A relevância de cada faceta pode variar com o

contexto e ao longo do tempo, pois as pessoas podem mudar seus posicionamentos

e atualizar suas referências com relação a um objeto de uma questão. Portanto a

qualidade não é absoluta, mas depende da perspectiva do avaliador. Por isso a

qualidade é um conceito complexo, porque possui significados diversos para

diferentes pessoas. Portanto a qualidade do software é um conjunto de propriedades

a serem satisfeitas, em determinado grau, de modo que o software satisfaça as

69

necessidades do usuário, e para isso acontecer é necessário que o gerente de

projeto tenha, de forma clara e definida, o objetivo daquele projeto de

desenvolvimento.

Como o mercado amadurece cada vez mais rápido, os usuários não querem

mais apenas que a empresa fale que tem qualidade, mas que mostre a todos a sua

qualidade através de Certificações Internacionais, tais como os modelos de

qualidade ISO e CMMi. Um modelo de qualidade é aquele onde se aplicam os

princípios da Qualidade de Software. A padronização ISO define e descreve o que é

requerido ou satisfatório em um sistema de qualidade. Além das padronizações ISO,

outras organizações nacionais e internacionais promovem padrões que descrevem

sistemas de qualidade para serem aplicados em sistema de desenvolvimento e

suporte em certas circunstâncias, como por exemplo o CMMI (Capability Maturity

Model Integration). A maioria das grandes organizações está reduzindo o número de

fornecedores, e um meio de escolher os fornecedores é verificando quais deles têm

certificações de qualidade (BARRETO, 2003).

2.7.1. Qualidade de software no contexto da gerência de projetos

Para o (PMBOK, 2000), como ferramenta de gerenciamento também da

qualidade, o gerenciamento da qualidade do projeto inclui os processos necessários

para assegurar que o projeto satisfaça as necessidades para as quais foi criado.

Os processos principais do gerenciamento da qualidade são:

• Planejamento da qualidade (identificar): identificação dos padrões de

qualidade relevantes para o projeto e determinação de como atender

esses padrões.

70

• Garantia da qualidade (avaliar o desempenho): avaliação regular do

desempenho geral do projeto para gerar confiança no sucesso do

projeto em alcançar os padrões relevantes de qualidade.

• Controle da qualidade (controlar os resultados): monitoração dos

resultados específicos do projeto, a fim de determinar se esses

resultados estão de acordo com os padrões relevantes de qualidade, e

identificação de maneiras para eliminar as causas de desempenho

insatisfatório.

Um padrão é efetivo se, quando usado apropriadamente, melhora a qualidade

dos resultados e reduz os custos dos produtos de software (BASILI, 1994).

71

3. MODELOS E MÉTODOS PARA A GESTÃO DA FÁBRICA DE

PROJETOS DE SOFTWARE

Para a implantação de um processo de software baseado na idéia de prover

uma linha de produção de soluções que atendam às necessidades específicas, três

estruturas serão abordadas neste trabalho: o processo de desenvolvimento,

baseado no estudo do modelo RUP; a gerência de projetos, através dos preceitos do

PMBOK; e a qualidade de software, embasada nas características do modelo CMMI.

Assim, neste capítulo, será executado um estudo dos 3 (três) modelos que

convergirá para a modelagem, no próximo capítulo, de processos operacionais e

gerenciais para a implantação de uma fábrica de projetos de software.

De acordo com o PMBOK (2000), os projetos são compostos de processos,

ou seja, uma série de ações que geram um resultado. Desta forma, devemos

estruturar a operação sedimentada nos grupos de processos conforme a execução

das fases dentro dos projetos.

3.1. O processo unificado Rational (RUP)

Tendo como meta a melhor e maior produtividade no que envolve a área

operacional da Fábrica de Software, ou seja, o desenvolvimento do produto

solicitado pelo cliente, foi utilizado para a construção do produto o método RUP de

desenvolvimento de software, provendo técnicas a serem seguidas pelos membros

da equipe de desenvolvimento de software.

Por ser o RUP um método extremamente adaptável a diversas situações e

necessidades, o fluxo operacional da Fábrica foi estudado e elaborado baseando-se

72

em seus princípios e customizações possíveis, bem como, aplicando-se a

combinação das melhores práticas utilizadas no RUP, conforme a seguir:

• Desenvolvimento iterativo;

• Gerenciamento de requisitos;

• Arquitetura componentizada;

• Modelagem visual (UML);

• Verificação contínua de qualidade; e,

• Gerenciamento de mudanças. (a ser implantado)

O RUP provê um framework de processos de software, e é utilizado pela

Fábrica em seus projetos de desenvolvimento de software, por meio da adaptação

desses processos à necessidade da fábrica.

Como mostrado na figura 3.1, o processo RUP tem duas dimensões:

• O eixo vertical representando as disciplinas que agrupam as atividades a

serem realizadas, está associado ao aspecto estático do processo, como ele

é descrito em termos de componentes do processo, atividades, fluxos de

trabalho, artefatos e papéis;

• O eixo horizontal representando o tempo e mostrando os aspectos do ciclo de

vida do processo à medida que se desenvolve. Está associado ao aspecto

dinâmico do processo quando ele é aprovado, e é expresso em termos de

fases, iterações e marcos.

Ainda na figura 3.1, o gráfico mostra a concentração de trabalho, por

disciplina, de acordo com a evolução das iterações. Percebe-se, por exemplo, que

nas iterações iniciais dedica-se mais tempo a disciplina de requisitos, tendo em vista

73

o foco na necessidade do cliente e a constante atualização e feedback dessas

informações/requisitos.

Figura 3.1 – Concentração de trabalho no Rational Unified Process(RUP)

(RUP, 2003)

Um processo de construção de produtos em uma fábrica de projetos de

software pode ser estruturado com base nas disciplinas do RUP para atribuir tarefas

e responsabilidades dentro da Fábrica, ou seja, estabelecendo o que deve ser feito,

como, quando e por quem, abrangendo o ciclo de vida de software de um projeto,

garantindo assim a produção de software de alta qualidade que atenda às

necessidades dos usuários dentro de um cronograma e de um orçamento previsível.

Para isso, ele deve conter subprocessos (abaixo relacionados) que

implementem e operacionalizem os objetivos gerais do processo. Assim, pode-se

dizer que eles foram estruturados de acordo com os princípios básicos das

disciplinas do RUP.

74

- Inclusão do Projeto no PCP – cronograma e check-list inicial para

planejamento;

- Elaboração o Projeto Lógico – estruturação do contexto lógico do produto;

- Execução a Demanda – implementação e criação do sistema;

- Executar os Testes – planejamento e execução de testes unitários e

integrados;

- Realizar a Implantação (BETA) – versão implantada dentro do site da fábrica

que emula o ambiente do cliente;

- Implantação em Ambiente de Produção – versão a ser implantada no site do

cliente.

Mais adiante será visto como funcionam esses processos detalhadamente na

implantação do processo de fábrica de software do próximo capítulo. Além disso,

será realizado um comparativo com as disciplinas do RUP de forma a propiciar um

melhor entendimento da aderência do modelo proposto. Antes disso, vale esclarecer

o funcionamento da estrutura do RUP, conforme o tópico a seguir.

3.1.1. Estrutura estática

Para melhor elucidação sobre o funcionamento tanto da Construção do

Produto na Fábrica de Software quanto da metodologia de desenvolvimento RUP, é

essencial que seja apresentada a estrutura utilizada, que tem como principal intuito

mostrar quem está fazendo o que, como e quando, através dos quatro elementos

utilizados no processo RUP, conforme a seguir:

• Papel – quem;

75

• Artefato – o que;

• Atividade – como; e,

• Fluxo de trabalho – quando.

O RUP define cada um destes elementos da seguinte maneira:

• Papel - é um mecanismo de agrupamento que define um conjunto de

responsabilidades em termos das atividades que esse papel pode realizar.

Um papel pode ser desempenhado por uma pessoa ou por um conjunto de

pessoas que trabalham juntas em equipe. Uma pessoa também pode

desempenhar diversos papéis. Há momentos em que um papel pode estar

diretamente relacionado a um cargo, mas isso não é obrigatório. O revisor de

requisitos, o analista de testes e o gerente de projeto são alguns exemplos de

papéis;

• Artefatos - são as elaborações e os documentos de modelagem que as

atividades desenvolvem, mantêm e usam como fonte de informações. Um

artefato pode ser um documento, como documento de arquitetura de

software, um modelo, como modelo de casos de uso, ou ainda, um elemento

de modelo, como uma classe;

• Atividade - é uma unidade de trabalho que um papel pode ser solicitado a

executar;

• Fluxo de trabalho - é uma seqüência das atividades que produzem um

resultado de valor observável.

76

Ao todo, são nove os fluxos de trabalho do RUP e eles representam a divisão

de todos os papéis e atividades, dentro de grupamentos lógicos conhecidos como

áreas de concentração ou disciplinas. Estão particionados em seis fluxos de

engenharia e três fluxos de apoio. Os de engenharia são: modelagem de negócios,

requisitos, analise e design, implementação, teste e implantação. E os de apoio:

gerenciamento de projeto, gerenciamento de configuração e mudança, e ambiente.

Para a modelagem do Processo de Construção do Software da Fábrica foram

utilizados como base somente os seis fluxos de engenharia do RUP, visto que, as

áreas de gestão da Fábrica aderiram a outras metodologias de trabalho mais

especializadas que os fluxos de apoio do RUP.

3.1.2. Estrutura dinâmica

Esta estrutura descreve desenvolvimento do ciclo de vida do processo RUP,

baseado em fases, marcos e iterações.

O ciclo de vida é dividido em quatro fases seqüenciais: iniciação, elaboração,

construção e transição. Como mostra a Figura 3.2, a conclusão de cada fase é

identificada por um marco principal e em cada final de fase é feita uma avaliação

para se verificar se os objetivos foram alcançados.

Figura 3.2 – Estrutura dinâmica do Processo Unificado Rational (RUP, 2003)

77

Ao final das quatro fases, conclui-se um ciclo de desenvolvimento e se produz

uma geração de software. Os ciclos subseqüentes são denominados ciclos de

evolução e acontecem a partir de melhorias sugeridas pelos usuários, mudanças de

contexto, de tecnologia, etc. À medida que se atravessa um novo ciclo, uma nova

geração de software é produzida.

Cada fase pode ser resumida da seguinte forma:

Iniciação - A fase de iniciação tem como meta principal estabelecer os objetivos do

ciclo de vida do projeto a partir do consenso de todos os envolvidos. É uma fase

onde os esforços devem ser extremamente focados, principalmente no que se refere

aos requisitos do sistema e ao entendimento do negócio.

A fase é considerada menos exigente, quando se trata de um software que

requer melhorias, pois as regras já são conhecidas e as adequações requerem

menos tempo de dedicação.

Nesta fase, procura-se também:

• Delimitar o escopo do projeto e os critérios de aceitação;

• Identificar os riscos do projeto;

• Identificar e detalhar os casos de uso críticos para arquitetura e para os

negócios;

• Definir uma arquitetura candidata e demonstrá-la minimamente, se

necessário;

• Preparar o ambiente de suporte para o projeto.

Elaboração - A fase de elaboração tem como meta principal criar uma base estável

para a fase de construção. Esta fase prioriza os casos de uso que oferecem riscos

78

de arquitetura e que já foram mapeados na fase de iniciação. O que se busca nesta

fase é principalmente:

• Buscar a estabilidade da arquitetura e a redução dos riscos;

• Produzir um protótipo evolutivo dos componentes e um ou mais protótipos

para diminuir os riscos e que são posteriormente descartados;

• Justificar a arquitetura, demonstrando que ela suportará os requisitos do

projeto.

Construção - A fase de construção tem como meta principal detalhar os requisitos

não vistos na fase de elaboração e concluir o desenvolvimento do sistema com base

na arquitetura definida. Os principais objetivos desta fase são:

• Buscar produtividade com qualidade e eficiência;

• Concluir análise, design, desenvolvimento e teste de todas as funcionalidades

pendentes;

• Atingir o desenvolvimento de um produto completo de maneira iterativa e

incremental;

• Buscar paralelismo entre o trabalho das equipes de desenvolvimento.

Transição - A fase de transição tem como meta principal assegurar que o software

esteja disponível para seus usuários finais. Seus objetivos principais são:

• Validar o novo sistema em confronto com as expectativas dos envolvidos;

• Realizar operação paralela caso exista um sistema para ser substituído;

• Promover a conversão de bancos de dados operacionais;

• Treinar usuários e equipe de manutenção;

• Corrigir erros e realizar ajustes;

• Obter aceitação do produto pelo usuário;

79

• Implantar o sistema.

3.1.2.1. Áreas de concentração

Como já foi visto, o RUP é composto por nove disciplinas, ou seja, coleções

de atividades relacionadas que estão ligadas à maior área de interesse dentro do

processo em geral, sendo seis voltadas para a engenharia e três para apoiar o

desenvolvimento do projeto.

O objetivo de cada disciplina pode ser resumido da seguinte forma:

Modelagem de negócios

• Entender a estrutura e a dinâmica da organização na qual o sistema será

entregue;

• Identificar problemas correntes na organização e possíveis aperfeiçoamentos;

• Assegurar que o cliente , o usuário final e os desenvolvedores possuam a

mesma compreensão da empresa; e,

• Produzir os requisitos de sistemas necessários para suportar os objetivos da

organização.

Requisitos

• Estabelecer e manter com os envolvidos o entendimento sobre o que o

sistema deve fazer;

• Permitir uma melhor compreensão dos requisitos aos desenvolvedores de

sistemas;

• Definir os limites do sistema;

80

• Fornecer as bases para o planejamento das iterações;

• Fornecer as bases para estimativa de custo e tempo de desenvolvimento;

• Definir as interfaces do sistema baseado nas necessidades e objetivos dos

usuários.

Análise e Design

• Transformar os requisitos dentro de um design do que será o sistema;

• Desenvolver uma arquitetura robusta para o sistema; e,

• Adaptar o design para combinar com o ambiente de implementação,

projetando-o para fins de desempenho.

Implementação

• Preparar a organização do código em termos de implementação de

subsistemas, organizados em camadas;

• Implementar classes e objetos em termos de componentes (código fonte,

binários, executáveis, etc);

• Testar os componentes desenvolvidos como unidades; e,

• Integrar os resultados obtidos por implementadores individuais (ou equipes)

em um sistema executável.

Teste

• Verificar a interação entre os objetos;

• Verificar a integração de todos os componentes de software;

• Verificar se todos os requisitos foram implementados corretamente,

• Identificar os possíveis defeitos; e,

81

• Assegurar que os defeitos identificados foram tratados antes da entrega do

software.

Implantação

• Descrever as atividades associadas à verificação de que o software esteja

disponível ao usuário final.

Vale enfatizar que as disciplinas do RUP detalhadas até o momento serão

utilizadas como base e adaptadas para a modelagem dos processos de construção

de software executados pela Fábrica de Software.

Abaixo estão detalhadas as disciplinas que não foram utilizadas na

modelagem dos processos da Fábrica de Software.

Para satisfazer a realização dessas disciplinas de apoio na Fábrica, foram

abordadas, bem como aplicadas, as áreas de conhecimento do Project Management

Body of Knowledge (PMBOK) e técnicas do Capability Maturity Model Integration

(CMMI).

Gerenciamento de Mudança e Configuração

• Identificar itens de configuração;

• Restringir alterações;

• Auditar alterações; e,

• Definir e gerenciar as alterações desses itens.

Ambiente

• Focar as atividades necessárias para configurar o processo para o projeto;

• Descrever as atividades requeridas para desenvolver as guias mestras ao

suporte do projeto e fornecer, para a organização de desenvolvimento de

82

software, o ambiente de processos e ferramentas que serão utilizados pela

equipe de desenvolvimento.

Gerenciamento de Projeto

A disciplina de apoio gerenciamento de projeto teve sua abordagem

influenciada pelo Project Management Body of Knowledge (PMBOK). Esta disciplina

fornece uma estrutura por meio da qual um projeto pode ser criado e gerenciado de

tal forma que tanto as seis disciplinas de engenharia quanto as outras duas

disciplinas de apoio possam estar referenciadas e controladas.

A disciplina de gerenciamento de projeto tem principalmente as seguintes

finalidades:

• Fornecer uma estrutura capaz de gerenciar o projeto;

• Orientar o planejamento, a montagem da equipe, a execução e a monitoração

do projeto; e,

• Fornecer uma estrutura para gerenciamento de riscos.

Não são cobertos aspectos referentes a:

• Gerenciar pessoal;

• Gerenciar orçamento; e,

• Gerenciar contratos.

3.2. O modelo de gerenciamento de projetos PMBOK (Project Management

Body of Knowledge)

Dentro desta seção, será executado um estudo do conjunto de processos

orientados para o gerenciamento de projetos, no sentido de viabilizar a gestão dos

83

processos de uma fábrica de software e buscar a customização do modelo para a

criação de uma estrutura operacional que entregue produtos confiáveis e de

qualidade, dentro do contexto competitivo do mercado de software. Para alcançar

este objetivo, abordar-se-á o Project Management Body of Knowledge (PMBOK), do

Project Management Institute (PMI), o qual pode ser perfeitamente utilizado para o

gerenciamento de projetos de software.

O modelo preconizado pelo Project Management Institute está fundamentado

no documento intitulado de: A Guide to the Project Management Body of Knowledge

ou, em sua forma abreviada, PMBOK Guide.

Conforme mencionado no capítulo 2, a gerência de projetos é um esforço

interativo, ou seja, uma ação, ou a falta dela, usualmente afeta também outras

áreas. As interações podem ser diretas e claras, ou podem ser incertas e sutis. Por

exemplo, uma mudança de escopo quase sempre afeta o custo do projeto.

Entretanto, ela pode ou não afetar o moral da equipe e a qualidade do produto.

Estas interações freqüentemente exigem balanceamento entre os objetivos do

projeto – consegue-se uma melhoria numa área somente através do sacrifício de

desempenho em outra.

3.2.1. Estrutura do modelo de gestão

Para auxiliar no entendimento da natureza da integração na gerência de

projetos, e para enfatizar a importância da própria integração, esta seção descreverá

a gerência de projetos em termos de seus processos e de suas interações.

84

O modelo é formado por processos, os quais são agrupados em processos de

iniciação, processos de planejamento, processos de controle, processos de

execução e processos de encerramento, conforme mostra a figura 3.3.

Figura 3.3 – Ligação entre os grupos de processo em cada fase (PMBOK, 2000)

Cada um dos processos no modelo é descrito por suas entradas, ferramentas

ou técnicas empregadas e suas saídas. Além disso, eles são implementados por

áreas de conhecimento que o representam. Estes processos foram organizados em

nove áreas de conhecimentos, como descrito abaixo: Integração, Escopo, Tempo,

Custo, Qualidade, Recursos Humanos, Comunicações, Risco e Aquisições.

A seguir, será feita uma descrição mais pormenorizada dos grandes grupos

de processos e das áreas de conhecimento da gestão de projetos, as quais estão

implícitas nos grupos.

85

3.2.1.1. Os grupos de processos

Os processos de gerência de projetos podem ser organizados em cinco

grupos, cada um deles contendo um ou mais processos:

• Processos de iniciação – autorização do projeto ou fase.

• Processos de planejamento – definição e refinamento dos objetivos e seleção

da melhor das alternativas de ação para alcançar os objetivos que o projeto

estiver comprometido em atender.

• Processos de execução – coordenar pessoas e outros recursos para realizar

o plano.

• Processos de controle – assegurar que os objetivos do projeto estão sendo

atingidos, através da monitoração regular do seu progresso para identificar

variações do plano e portanto ações corretivas podem ser tomadas quando

necessárias.

• Processos de encerramento – Formalizar a aceitação do projeto ou fase e

encerrá-lo(a) de uma forma organizada.

Os grupos de processos se ligam pelos resultados que produzem – o

resultado ou saída de um grupo torna-se entrada para outro. Entre grupos de

processos centrais, as ligações são iterativas - o planejamento alimenta a execução,

no início, com um plano do projeto documentado, fornecendo, a seguir, atualizações

ao plano, na medida em que o projeto progride.

Além disso, os grupos de processos da gerência de projetos não são

separados ou descontínuos, nem acontecem uma única vez durante todo o projeto;

86

eles são formados por atividades que se sobrepõem, ocorrendo em intensidades

variáveis ao longo de cada fase do projeto. A Figura 3.4 ilustra como os grupos de

processos se sobrepõem e variam dentro de uma fase.

Figura 3.4 – Sobreposição dos grupos de processos em cada fase

(PMBOK, 2000)

Finalmente, as interações dos grupos também atravessam as fases, de tal

forma que o encerramento de uma fase fornece uma entrada para o início da

próxima. Por exemplo, a finalização de uma fase de design requer uma aceitação,

pelo cliente, do documento projetado. Ao mesmo tempo, o documento de design

define a descrição do produto para a fase de implementação subseqüente. Esta

interação está ilustrada na Figura 3.5.

87

Figura 3.5 – Interação entre as fases (PMBOK, 2000)

3.2.1.1.1. Processos de iniciação

A figura 3.6 apresenta o relacionamento do processo de iniciação.

Figura 3.6 – Relacionamento entre os processos de iniciação (PMBOK, 2000)

• Iniciação – relacionado ao escopo das atividades (projeto).

88

3.2.1.1.2. Processos de planejamento

O planejamento é de fundamental importância num projeto, porque executar

um projeto implica em realizar algo que não tinha sido feito antes. Como

conseqüência, existem relativamente mais processos nessa seção.

A figura 3.7 apresenta o relacionamento entre os processos de planejamento.

Figura 3.7 – Relacionamento entre os processos de planejamento (PMBOK,

2000)

89

Estes processos básicos podem interagir várias vezes durante qualquer fase

de um projeto. Eles são desenvolvidos pelos seguintes conjuntos de processos

(sempre inseridos no contexto das nove áreas de conhecimento, as quais são

mostradas entre parênteses):

• Planejamento do Escopo (5.2)

• Detalhamento do escopo (5.3)

• Definição das Atividades (6.1)

• Seqüenciamento das Atividades (6.2)

• Estimativa da Duração das Atividades (6.3)

• Desenvolvimento do Cronograma (6.4)

• Planejamento da Gerência de Risco (11.1)

• Planejamento dos Recursos (7.1)

• Estimativa dos Custos (7.2)

• Orçamento dos Custos (7.3)

• Desenvolvimento do Plano do Projeto (4.1)

A seguir os processos facilitadores do conjunto de processos de planejamento

do modelo, os quais são realizados intermitentemente, e à medida que são

necessários, durante o planejamento do projeto (não são opcionais).

• Planejamento da Qualidade (8.1)

• Planejamento Organizacional (9.1)

• Montagem da Equipe (9.2)

• Planejamento das Comunicações (10.1)

90

• Identificação dos Riscos (11.2)

• Análise Qualitativa dos Riscos (11.3)

• Análise Quantitativa dos Riscos (11.4)

• Planejamento de Resposta a Riscos (11.5)

• Planejamento das Aquisições (12.1)

• Preparação das Aquisições (12.2)

3.2.1.1.3. Processos de execução

Os processos de execução incluem os processos essenciais e os

facilitadores. A Figura 3.8 ilustra como interagem os seguintes processos:

• Execução do Plano do Projeto(4.2)

• Garantia da Qualidade (8.2)

• Desenvolvimento da Equipe (9.3)

• Distribuição das Informações (10.2)

• Pedido de propostas (12.3)

• Seleção de Fornecedores (12.4)

• Administração dos Contratos (12.5)

91

Figura 3.8 – Relacionamentos entre os processos de execução (PMBOK, 2000)

3.2.1.1.4. Processos de controle

O desempenho do projeto deve ser monitorado e medido regularmente para

identificar as variações do plano. Estes desvios são analisados, dentro dos

processos de controle, nas diversas áreas de conhecimento. Na medida em que são

identificados desvios significativos (aqueles que colocam em risco os objetivos do

projeto), realizam-se ajustes ao plano através da repetição dos processos de

planejamento que sejam adequados àquele caso.

Os grupos de processos de controle, também, incluem processos essenciais

e facilitadores. A Figura 3.9 ilustra como os seguintes processos essenciais e

facilitadores interagem:

• Controle Integrado de Mudanças (4.3)

• Verificação do Escopo (5.4)

92

• Controle de Mudanças do Escopo (5.5)

• Controle do Cronograma (6.5)

• Controle dos Custos (7.4)

• Controle da Qualidade (8.3)

• Relato de Desempenho (10.3)

• Controle e Monitoração de Riscos (11.6)

Figura 3.9 – Relacionamento entre os processos de controle (PMBOK, 2000)

3.2.1.1.5. Processos de encerramento

A Figura 3.10 ilustra como interagem os processos que se seguem:

• Encerramento dos Contratos (12.6)

• Encerramento Administrativo (10.4)

93

Figura 3.10 – Relacionamento entre os processos de encerramento (PMBOK, 2000)

3.2.1.2. Mapeamento dos processos de gestão de projeto

O quadro 3.1 apresenta o mapeamento dos trinta e nove processos de

gerência de projeto em cinco grupos de processos de gerencia de projeto: iniciação,

planejamento, execução, controle e encerramento e nas nove áreas de

conhecimento de gerência de projeto.

94

Quadro 3.1 – Mapeamento dos processos de Gerência de projeto em grupos de

processos e áreas de conhecimento

Fonte: (PMBOK, 2000)

3.2.1.3. As áreas de conhecimento do modelo

As áreas de conhecimento da Gerência de Projetos descrevem os

conhecimentos e práticas em gerência de projetos em termos dos processos que as

compõem. A seguir será executado o estudo de cada uma das áreas.

95

3.2.1.3.1. Integração

O gerenciamento da integração do projeto inclui os processos requeridos para

assegurar que os diversos elementos do projeto estão adequadamente

coordenados. Ela envolve fazer compensações entre objetivos e alternativas

eventualmente concorrentes, a fim de atingir ou superar as necessidades e

expectativas. Abaixo são mostrados os principais processos da gerência de

integração do projeto:

(4.1) - Desenvolvimento do Plano do Projeto - agregar os resultados dos outros

processos de planejamento construindo um documento coerente e consistente.

(4.2) - Execução do Plano do Projeto - levar a cabo o projeto através da realização

das atividades nele incluídas.

(4.3) - Controle Integrado de Mudanças – coordenar as mudanças através do

projeto inteiro.

3.2.1.3.2. Escopo

A gerência do escopo do projeto abrange os processos requeridos para

assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho

necessário, para complementar de forma bem sucedida o projeto. A preocupação

fundamental compreende definir e controlar o que está, ou não, incluído no projeto.

Abaixo são mostrados os principais processos da gerência do escopo do projeto:

(5.1) Iniciação – autorizar o projeto ou fase.

96

(5.2) Planejamento do Escopo – desenvolver uma declaração escrita do escopo

como base para decisões futuras do projeto.

(5.3) Detalhamento do escopo – subdividir os principais subprodutos do projeto em

componentes menores e mais manejáveis.

(5.4) Verificação do Escopo – formalizar a aprovação do escopo do projeto.

(5.5) Controle de Mudanças do Escopo – controlar as mudanças no escopo do

projeto.

No contexto de projeto, o termo escopo deve se referir a:

• Escopo do produto – aspectos e funções que caracterizam um produto ou serviço.

• Escopo do projeto – o trabalho que deve ser feito com a finalidade de fornecer um

produto de acordo com os aspectos e as funções especificados.

3.2.1.3.3. Tempo

O gerenciamento do prazo do projeto inclui os processos necessários para

assegurar que o projeto será implementado no prazo previsto. Abaixo são mostrados

os principais processos para criar o cronograma do projeto:

(6.1) Definição das Atividades – identificar as atividades específicas que devem

ser realizadas para produzir os diversos subprodutos do projeto.

(6.2) Seqüenciamento das Atividades – identificar e documentar as relações de

dependência entre as atividades.

(6.3) Estimativa da Duração das Atividades - estimar a quantidade de períodos de

trabalho que serão necessários para a implementação de cada atividade.

97

(6.4) Desenvolvimento do Cronograma - analisar a seqüência das atividades, sua

duração, e os requisitos de recursos para criar o cronograma do projeto.

(6.5) Controle do Cronograma - controlar as mudanças no cronograma do projeto.

3.2.1.3.4. Custo

O gerenciamento do custo do projeto inclui os processos necessários para

assegurar que o projeto será concluído dentro do orçamento aprovado. Abaixo são

mostrados os principais processos da área de conhecimento do custo:

(7.1) Planejamento dos Recursos – determinar quais recursos (pessoas,

equipamentos, materiais) e em quais quantidades devem ser usados para executar

as atividades do projeto.

(7.2) Estimativa dos Custos – desenvolver uma aproximação (estimativa) dos

custos dos recursos necessários para executar as atividades do projeto.

(7.3) Orçamentação dos Custos – alocar as estimativas de custos globais aos itens

individuais de trabalho.

(7.4) Controle dos Custos – controlar as mudanças no orçamento do projeto.

3.2.1.3.5. Qualidade

O gerenciamento da qualidade do projeto inclui os processos necessários

para garantir que o projeto irá satisfazer as necessidades para as quais ele foi

empreendido. Abaixo são mostrados os principais processos do gerenciamento da

qualidade do projeto:

98

(8.1) Planejamento da Qualidade – identificar que padrões de qualidade são

relevantes para o projeto e determinar a forma de satisfazê-los.

(8.2) Garantia da Qualidade – avaliar periodicamente o desempenho geral do

projeto buscando assegurar a satisfação dos padrões de qualidade relevantes.

(8.3) Controle da Qualidade – monitorar os resultados específicos do projeto para

determinar se eles estão de acordo com os padrões de qualidade relevantes e

identificar as formas para eliminar as causas de desempenhos insatisfatórios.

A equipe de gerenciamento do projeto deve também estar atenta ao fato de

que a moderna gerência da qualidade complementa a gerência de projeto. Por

exemplo, ambas reconhecem a importância de:

• Satisfação do cliente - entender, gerenciar e influenciar as necessidades de forma

que as expectativas do cliente sejam atendidas. Isso requer a combinação de

conformidade com requisitos (o projeto deve produzir o que foi dito que produziria)

com adequação ao uso (o produto ou serviço produzido deve satisfazer as reais

necessidades).

• Prevenção ao invés de inspeção - o custo da prevenção de erros é sempre muito

menor que o custo para corrigi-los, como demonstrado pela inspeção.

• Responsabilidade da gerência - o sucesso exige a participação de todos os

membros da equipe, mas permanece como responsabilidade da gerência fornecer

os recursos necessários para sua efetivação.

• Processos dentro de fases – o ciclo repetitivo de planejar-desenvolver,-checar-agir

(PDCA) descrito por Deming e outros é bastante similar à combinação de fases e

processos discutidos anteriormente, Gerenciamento dos Processos do Projeto.

99

3.2.1.3.6. Recursos Humanos

O gerenciamento dos recursos humanos do projeto inclui os processos

necessários para tornar mais efetivo o uso dos recursos humanos envolvidos no

projeto. Isto inclui todas as partes envolvidas no projeto – patrocinadores, clientes,

contribuintes individuais. Abaixo são mostrados os principais processos gerenciais

no contexto de recursos humanos:

(9.1) Planejamento Organizacional – identificar, documentar e designar os papéis,

as responsabilidades e os relacionamentos de reporte dentro do projeto.

(9.2) Montagem da Equipe – conseguir que os recursos humanos necessários

sejam designados e trabalhem no projeto.

(9.3) Desenvolvimento da Equipe – desenvolver competências individuais e de

grupo para elevar o desempenho do projeto.

3.2.1.3.7. Comunicações

O gerenciamento das comunicações do projeto inclui os processos

necessários para garantir a regular e apropriada geração, coleta, disseminação,

armazenamento e descarte final das informações do projeto. Fornece os importantes

relacionamentos entre pessoas, idéias e informações necessárias para o sucesso do

projeto. Todos os envolvidos no projeto devem estar preparados para enviar e

receber comunicações e devem compreender como as suas comunicações afetam o

projeto como um todo. Abaixo são mostrados os principais processos da área de

comunicações:

100

(10.1) Planejamento das Comunicações – determinar as informações e

comunicações necessárias às partes envolvidas no projeto: quem precisa de que

informação, quando serão necessárias e como devem ser fornecidas.

(10.2) Distribuição das Informações - tornar disponível, de forma regular, as

informações necessárias às partes envolvidas do projeto.

(10.3) Relato de Desempenho – coletar e disseminar as informações de

desempenho. Inclui relatórios de posicionamento, medidas de progresso e

previsões.

(10.4) Encerramento Administrativo – gerar, reunir e disseminar informações para

formalizar a conclusão de uma fase ou do projeto.

3.2.1.3.8. Riscos

O gerenciamento dos riscos do projeto é um processo sistemático de

identificar, analisar e responder aos riscos do projeto. Isso inclui maximizar a

probabilidade e conseqüência de eventos positivos e minimizar a probabilidade e

conseqüência de eventos adversos aos objetivos do projeto. Abaixo são mostrados

os principais processos da gestão de riscos no projeto:

(11.1) Planejamento da Gerência de Risco – Decidir como abordar e planejar a

gerência de risco no projeto.

(11.2) Identificação dos Riscos – determinar os riscos prováveis do projeto e

documentar as características de cada um.

(11.3) Analise Qualitativa de Riscos – analisar qualitativamente os riscos e

condições para priorizar seus efeitos nos objetivos do projeto.

101

(11.4) Analise Quantitativa de Riscos – mensurar a probabilidade e impacto dos

riscos e estimar suas implicações nos objetivos do projeto.

(11.5) Planejamento de Resposta a Riscos – desenvolver procedimentos e

técnicas para aumentar oportunidades e para reduzir ameaças de riscos para os

objetivos do projeto.

(11.6) Controle e Monitoração de Riscos – monitorar os riscos residuais, identificar

novos riscos, executar os planos de redução de risco e avaliar sua efetividade

durante todo o ciclo de vida do projeto.

3.2.1.3.9. Aquisições

O gerenciamento das aquisições do projeto inclui os processos necessários à

obtenção de bens e serviços externos à organização executora. Para simplificação,

os bens e serviços, seja um ou vários, serão geralmente referidos como um

“produto”. Abaixo são mostrados os principais processos relacionados à área de

conhecimento de aquisições no projeto:

(12.1) Planejamento das Aquisições – determinar o que contratar e quando.

(12.2) Preparação das Aquisições – documentar os requerimentos do produto e

identificar os fornecedores potenciais.

(12.3) Obtenção de Propostas – obter propostas de fornecimento conforme

apropriado a cada caso (cotações de preço, cartas-convite, licitação).

(12.4) Seleção de Fornecedores – escolher entre os possíveis fornecedores.

(12.5) Administração dos Contratos – gerenciar os relacionamentos com os

fornecedores.

102

(12.6) Encerramento do Contrato – completar e liquidar o contrato incluindo a

resolução de qualquer item pendente.

3.3. O modelo de qualidade CMMI (Capability Maturity Model Integration)

Desde 1991, a estrutura de maturidade de processo para modelos CMMs foi

evoluída para múltiplas disciplinas. Algumas das mais utilizadas são: engenharia de

sistemas, engenharia de software, aquisição de software, gerenciamento e

desenvolvimento da força de trabalho, e desenvolvimento do processo. A principal

finalidade é beneficiar as organizações no desenvolvimento da melhoria contínua do

processo de qualidade de software.

Neste sentido, a equipe decidiu utilizar o modelo CMMi como parâmetro para

a criação dos processos da fábrica de projetos de software, de forma a estruturar o

framework em duas premissas básicas:

• a qualidade de um produto de software é fortemente dependente da

qualidade do processo pelo qual ele é construído e mantido;

• o processo de software pode ser definido, gerenciado, medido e melhorado;

o Um processo definido está descrito em detalhes de forma a poder ser

usado de forma consistente;

Visando aperfeiçoar o CMM para amenizar os problemas causados pelo

modelo, através das experiências adquiridas neste longo tempo de uso, o SEI

desenvolveu o modelo Integrado de Maturidade de Capabilidade de Software

(CMMI).

103

3.3.1. O modelo CMMI

O Modelo Integrado de Maturidade de Capabilidade de Software (CMMI, em

inglês) surgiu de uma nova versão do CMM que tinha por objetivo resolver os

problemas que as organizações enfrentavam para obter melhorias no processo de

desenvolvimento de seus projetos. Como o nome sugere, a primeira idéia foi

integrar os diversos CMMs numa única estrutura, (terminologia e processos de

avaliação com maior flexibilidade) de modo que as avaliações fossem reconhecidas

como equivalentes aos do outro modelo.

Tal como o CMM, o CMMI é um modelo que define e melhora a capacidade e

a maturidade dos processos das organizações desenvolvedoras de software, e

descreve as áreas de processo que a organização deve contemplar, mas não indica

como. Cada organização terá que implementar e adaptar as áreas de processos

conforme a sua realidade.

O CMMI possui uma proposta mais ampla para o amadurecimento dos

processos de construção de software incluindo uma comunicação mais delimitada

com os processos de gerenciamento do projeto.

Modelos CMMI são abstrações da realidade e devem ser escolhidos e

adaptados a necessidades e objetivos das organizações.

3.3.1.1. Objetivos do modelo

O modelo CMMI tem com objetivos reduzir custos, estabelecer e manter

esforços de processos em um empreendimento que usa disciplinas múltiplas para

produzir produtos ou serviços.

104

O CMMI também engloba outros propósitos a ser considerados pelas

organizações:

§ Suprimentos das limitações do modelo CMM, com a criação de um

framework comum, eliminando inconsistências e permitindo a

inclusão de novos modelos ao longo do tempo, sempre que

surgirem necessidades específicas;

§ Redução de duplicações de processos;

§ Estabelecimento de regras de construção uniformes;

§ Aumento da clareza e entendimento dos processos e atenção a

implicações de esforços já existentes.

O CMMI contempla o desenvolvimento multidisciplinar, cobrindo outras áreas

do desenvolvimento de sistemas de software. As organizações podem usar o

modelo CMMI para auxiliar nos objetivos de melhorar os seus processos, fixar

prioridades de melhorias no processo de qualidade e prover orientação para

assegurar estabilidade de processos capazes e maduros.

3.3.1.2. Os tipos de modelos da estrutura

Com um framework comum, o CMMI acomoda múltiplas disciplinas de forma

a tornar o modelo suficientemente flexível, para adaptar duas formas de

representação -por estágio e contínua - além de gerar vários modelos baseados nas

necessidades das organizações:

- CMMI – SW – Modelo que contém a disciplina engenharia de software.

- CMMI – SE – Modelo que contém a disciplina engenharia de sistema.

105

- CMMI-SE/SW – Modelo que integra a disciplina engenharia de sistema e

engenharia de software.

- CMMI-SE/SW/IPPD – Modelo que integra a disciplina engenharia de sistema,

engenharia de software e desenvolvimento de produto e processo integrado

(DPPI).

- CMMI-SE/SW/IPD/SS - Modelo que integra a disciplina engenharia de

sistema, engenharia de software e desenvolvimento de produto, processo

integrado (DPPI) e desenvolvimento com subcontratação.

Segundo a equipe de desenvolvimento de CMMI a escolha correta de qual

modelo a organização deve usar depende da (s) disciplina (s) e finalidade de

atuação dentro do processo. Se a organização tem atividades relacionadas com

Engenharia de Software ou com atividades de Engenharia de Sistema, os modelos

apropriados são CMMI-SW e com CMMI-SE respectivamente. No entanto, se a

organização está preocupada com ambos os sistemas, então deve usar um modelo

combinado CMMI-SW/SEI que irá encorajar a melhoria de práticas integradas,

reduzindo repetições e problemas administrativos que são comuns quando usa mais

de um modelo. Se a organização emprega o desenvolvimento de produto e processo

integrado em suas atividades, então um modelo IPPD será mais apropriado. E se a

organização está preocupada com seus fornecedores será o mais apropriado um

modelo que inclua Desenvolvimento com Subcontratação (SS – Supplier Sourcing).

Dentro deste contexto, a equipe observou que uma fábrica de software deve

prover serviços de desenvolvimento de sistemas com qualidade, a baixo custo e de

forma rápida, utilizando um processo de desenvolvimento de software bem definido

e com apoio de tecnologias de mercado, além de reconhecer e lidar com

106

oportunidades de melhoria do processo. Ou seja, ela está preocupada com

atividades de engenharia de software e de sistemas e deverá utilizar o modelo

combinado CMMI-SW/SE.

Além disso, a organização deve decidir qual representação melhor se adapta

às suas necessidades. Deve-se selecionar entre a contínua ou a estagiada, e

determinar as disciplinas a serem incluídas no modelo que a organização irá utilizar.

As duas representações do modelo CMMI, ambas contém essencialmente a

mesma informação, entretanto, cada uma delas fornece benefícios que serão

avaliados diferentemente pelas organizações.

A representação por estágio provê uma sucessão de melhorias, iniciando com

práticas básicas de administração e provê um caminho evolutivo para melhoria do

processo de desenvolvimento de software. Esta representação tem como foco a

maturidade organizacional em que as áreas de processos são agrupadas em níveis

de maturidades, onde cada etapa é uma base para o próximo nível, para viabilizar

um estágio definido de melhorias. Cada nível de maturidade satisfeito estabiliza uma

parte importante dos processos.

A representação contínua permite que as organizações escolham as áreas de

processos que mais se identifique com as estratégias de negócios e amenize as

áreas de riscos tendo como base comparações de resultados de organizações

equivalentes. Essa representação tem como foco a capabilidade do processo e

apresenta maior flexibilidade na implantação de melhorias continua para

desenvolvimento de software de acordo com os objetivos organizacionais.

A representação contínua usa nível de capabilidade para medir a melhoria do

processo, enquanto a representação por estágio usa nível de maturidade. A

107

diferença principal entre níveis de maturidade e níveis de capabilidade é a

representação a que eles pertencem e como eles são aplicados.

Na representação contínua existem seis níveis de capacidade, designados

pelos números de 0 (zero) até 5 que correspondem a: nível 0– Incompleto, 1-

Executado, 2-Gerenciado, 3- Definido, 4-Gerenciado Quantitativamente e 5-

Otimizado. Enquanto que na representação por estágio existem 5 níveis de

maturidade numerados de 1 a 5. Cada nível de maturidade compreende um conjunto

predefinido de áreas de processo do modelo CMM.

Todo modelo CMMI provê um conjunto de critérios disponíveis que descrevem

as características da organização que implementaram melhoria de processo com

sucesso. Esses critérios podem ser utilizados por outras organizações para melhorar

seus processos, desenvolver, adquirir e manter seus produtos/serviços no mercado

global de forma mais competitiva.

Assim, a necessidade de implantação do modelo de construção de software

utilizando características e técnicas fabris induziram a escolha do modelo estagiado,

pois se deve buscar:

Ø Fornecer a melhor seqüência de maximização de maturidade, iniciando

por práticas básicas de gerenciamento e evoluindo através de um caminho

pré-definido de níveis sucessivos, onde cada nível serve como base para

o posterior;

Ø Permitir a execução de comparações com outras organizações que

utilizam os níveis de maturidade;

108

3.3.2. Estrutura do modelo estagiado

Este subtópico descreve como o modelo CMMI por estágios é organizado e

qual a finalidade que cada item tem no processo de melhoria contínua de

desenvolvimento de qualidade e avaliação da maturidade organizacional ou

capabilidade da área de processo, nas empresas que estabelecem prioridades na

implementação destas melhorias.

O CMMI por estágios é caracterizado pelas escalas de níveis de maturidade

como descrito a seguir:

• Nível 1 (inicial): processo mínimo de desenvolvimento, capaz de

orientar as macro-tarefas no nível operacional;

• Nível 2 (gerenciado): capacidade de gerenciar um ciclo de

desenvolvimento, ou seja, um projeto.

• Nível 3 (definido): além dos fluxos de atividades, gerenciam aspectos

organizacionais, técnicos e de integração de equipes e fornecedores

em função da definição do processo;

• Nível 4 (gestão quantitativa): gestão do processo por meio de métricas

quantitativas através do tempo. Capacidade de avaliar o desempenho

dos vários ciclos de desenvolvimento e comparar seus indicadores,

obtendo previsibilidade;

• Nível 5 (otimização): controle e avaliação do processo

quantitativamente, podendo intervir em sua especificação para otimizá-

lo continuamente.

109

A estrutura do CMMI na representação por estágio (o foco deste estudo após

explanações nos parágrafos anteriores) pode ser observada detalhadamente na

figura a seguir:

Figura 3.11 – Estrutura por estágio do CMMI (SEI, 2004)

De acordo com a figura 3.11 os níveis de maturidade na representação por

estágio do CMMI consistem em um conjunto predefinido de áreas de processo e são

medidos pela satisfação das metas específicas e genéricas que se aplicam a cada

conjunto de áreas de processo.

Essas áreas de processo estabelecem grandes temas a serem endereçados

e cada área é detalhada em práticas genéricas e específicas, que são os quesitos a

serem cumpridos na implantação do modelo.

110

As práticas especificam o que deve ser cumprido, exigindo documentos,

treinamentos ou políticas definidas para as atividades, mas nunca especificam como

elas devem ser implementadas.

Dentro de cada área de processo, as metas e práticas específicas são

listadas primeiras, seguidas pelas metas e práticas genéricas. A representação por

estágio organiza as práticas genéricas em características comuns.

As características comuns são componentes não classificados do modelo,

apenas constituem um grupo que fornece uma maneira de apresentar as práticas

genéricas.

É importante que a organização antes de começar a usar um modelo CMMI,

tenha um entendimento total da funcionalidade de sua estrutura e qual

representação escolher, para depois mapear seus processos para as áreas de

processo do CMMI. Este mapeamento permite controlar o processo de melhoria na

organização ajudando a determinar o nível da organização em conformidade com o

modelo em uso. Não é esperado que toda área de processo CMMI seja mapeada

uma a uma para os processos da organização.

Essa representação focaliza as melhores práticas que as organizações

podem usar para melhorar seus processos nas áreas de processo e alcançar os

níveis de maturidade desejados. Porém requer por parte dessas empresas o

cuidado de focalizar todos seus esforços em um número manejável de área de

processo para obter sucesso crescentemente sofisticado como a melhoria da

organização.

111

3.3.3. Componentes do modelo

Os componentes de um modelo CMMI são agrupados em três categorias que

refletem como eles devem ser interpretados:

Ø Componentes Requeridos: As metas específicas e genéricas são

componentes requeridos do modelo. Estes componentes devem ser

estabelecidos pelos processos planejados e implementados pela organização

e utilizados para avaliar a satisfação de uma área de processo.

Ø Componentes Esperados: As práticas específicas e genéricas são

componentes esperados do modelo. Estes componentes descrevem o que

uma organização tipicamente irá implementar para satisfazer um componente

requerido. Servem como guia para aqueles que implementam melhorias e ou

executam avaliações.

Ø Componentes Informativos: As sub-práticas, produtos de trabalho típicos,

particularidades da disciplina, elaborações de práticas genéricas, títulos,

notas e referências são componentes informativos do modelo. Estes

componentes ajudam o usuário do modelo a entender as metas e práticas e

como elas podem ser estabelecidas, fornecendo detalhes para ajudar a

começar a pensar em como estabelecer as práticas e metas.

Quando se usa um modelo CMMI como guia, processos são planejados e

implementados em conformidade com os componentes esperados e requeridos das

áreas de processo. A área de processo é um agrupamento de práticas relacionadas

em uma área que, quando executada coletivamente, satisfaz um conjunto de metas

112

consideradas importantes com objetivo de obter melhorias significativas naquela

área escolhida.

As áreas de processo do CMMI se subdividem em quatro categorias e em

grupos de áreas básica e avançada: Gerência de Processo, Gerência de Projeto,

Engenharia e Apoio.

Quadro 3.2 - Distribuição das áreas de processos no CMMI

O quadro 3.2 mostra as áreas de processos dentro das categorias do CMMI.

Os grupos de áreas de processo básicos são os que estão no nível 2 em relação ao

Categorias de processo

Grupo de área de

processo

Processos

Gerência de Processo

Básico § Foco no processo organizacional § ????????????Definição do processo

organizacional § ?????????????????Treinamento organizacional

Avançado § Execução do processo organizacional

§ Desenvolvimento e inovação organizacional

Gerência de Projeto

Básico § ?Planejamento de projeto § ??Acompanhamento e controle de

projeto § Gerência de Acordo com

fornecedores Avançado § ?Gerência integrada de projeto

§ ?????????????????Gerência de risco § ?????????????????Gerência quantitativa de projeto

Engenharia

§ ?Desenvolvimento de requisitos § ?Gerência de requisitos § ?Solução técnica § ?Integração de produto § ?Verificação § ?Validação

Processos de apoio

Básico § Gerência de configuração § Garantia de qualidade de produto

e processo § Medição e Análise

Avançado § Resolução e análise de decisão § ????????????????Resolução e análise de causa

113

CMMI por estágio. As áreas avançadas estão presentes a partir do nível 2. Por

exemplo, a Gerência de Risco pode iniciar no nível 2 e dentro da área de processo

de Planejamento e Projeto e Acompanhamento e Controle de Projeto, com a simples

identificação dos riscos tendo como objetivo a antecipação de riscos para redução

de seus impactos no projeto.

A evolução das atividades se faz de acordo com a movimentação da

organização através dos níveis de maturidade.

Por exemplo, quanto à atividade de gerência de projetos, no nível de

maturidade 1, ela é tão importante quanto o gerente de projeto; no nível de

maturidade 2, os planos são reais e documentados e servem de base para o

gerenciamento do projeto; no nível de maturidade 3, a gerência de projetos está

baseada em um processo definido e é derivada do arquivo da organização; no nível

de maturidade 4, técnicas estatísticas e quantitativas são usadas para gerenciar a

execução do processo e a garantia de qualidade do produto; e o nível de maturidade

5, a gerência é executada dentro de um ambiente para melhoria contínua.

A seguir serão ilustradas as áreas de processos (PA) que a organização deve

focar para melhorar o seu processo de desenvolvimento de software. Elas são um

conjunto de práticas relacionadas que, quando executadas corretamente, satisfazem

um conjunto de metas consideradas importantes para realizar a melhoria na área, a

qual ela está inserida.

O quadro 3.3 é composta de três colunas que mostram o nível de maturidade

envolvido, o foco relacionado às práticas e as áreas de processo existentes para

implementar os preceitos e conceitos implícitos no método.

114

Quadro 3.3 – Tabela de níveis de maturidade do CMMI

Nível CMMi Foco Área do processo 1) Inicial Pessoas competentes e

heróis § Nenhuma

2) Gerenciado Processos de gerenciamento de projetos

§ Gerenciamento de requisitos;

§ Planejamento do projeto;

§ Controle e monitoramento do projeto;

§ Gerenciamento de Acordos com Fornecedores;

§ Medição e Análise; § Garantia de qualidade

do produto e do processo;

§ Gerenciamento de Configuração;

3) Definido Processos de Engenharia e Apoio

§ Desenvolvimento de requisitos;

§ Solução técnica; § Integração do produto; § Verificação; § Validação; § Foco no processo

organizacional; § Definição do processo

organizacional; § Treinamento

organizacional; § Gerenciamento de

projeto integrado; § Gerenciamento de

risco; § Integração da equipe; § Análise de decisão e

resolução; § Ambiente

organizacional para a integração;

4) Quantitativamente Gerenciado

Qualidade do produto e do processo

§ Desempenho do processo organizacional;

§ Gerência Quantitativa do projeto;

5) Otimizado Melhoramento contínuo do processo

§ Inovação e Deployment Organizacional;

§ Análise e resolução de causas.

Fonte: (SEI, 2004)

115

3.3.4. Mapeamento dos níveis de maturidade do modelo

Após a contextualização do modelo CMMi, a partir deste momento, será

executado um mapeamento das PA´s da estrutura estagiada, no sentido de se

identificar o propósito e os objetivos específicos, além da interação entre eles.

Assim, poder-se-á inferir sobre o modelo no sentido de identificar a estrutura

necessária para a implantação dos processos da fábrica. Desta forma, os processos

se tornarão aderentes ao modelo, ou seja, será executado o mapeamento da

operação e gestão privilegiando as melhores práticas existentes em cada área do

processo.

A forma de apresentação será: inserção do nível, identificação da área de

processo envolvida (sendo formada pelo nível e seqüência – exemplo: PA 2.1, nível

dois como primeira da lista), colocação do propósito, dos objetivos específicos e uma

figura que ilustrará a interação das práticas específicas dos objetivos. A seguir,

temos um exemplo:

Nível: 2 – Gerenciado

PA (2.1): Gerenciamento de requisitos

• Propósito: gerenciar os requisitos dos produtos do projeto.

• Objetivos específicos:

1) Os requisitos são gerenciados.

• Interação entre as práticas específicas da PA

116

Figura 3.12 – Exemplo de interação entre PA´s

• Inferências sobre a PA: Deve-se criar um processo de planejamento e

gerenciamento de projetos que seja capaz de manter os requisitos aderentes

às necessidades dos stakeholders.

3.3.4.1. Nível 2 (gerenciado)

Esta seção descreverá todas as áreas de processos que pertencem ao nível 2

de maturidade. São elas:

§ Gerenciamento de requisitos (PA 2.1);

§ Planejamento do projeto (PA 2.2);

§ Controle e monitoramento do projeto (PA 2.3);

§ Gerenciamento de Acordos com Fornecedores (PA 2.4);

117

§ Medição e Análise (PA 2.5);

§ Garantia de qualidade do produto e do processo (PA 2.6);

§ Gerenciamento de Configuração (PA 2.7);

(PA 2.1) Gerenciamento de requisitos

• Propósito: gerenciar os requisitos dos produtos do projeto e dos

componentes do produto; identificar inconsistências entre estes

requisitos, os planos do projeto e produtos de trabalho.

§ requisitos funcionais e não funcionais.

• Objetivos específicos:

§ Os requisitos são gerenciados e inconsistências entre os planos

do projeto e os produtos de trabalho são identificadas;

• Interação entre as práticas específicas

Figura 3.13 – Interação entre práticas (PA.2.1)

118

• Inferências sobre a PA:

o Deve-se criar um processo de planejamento e gerenciamento de

projetos que seja capaz de manter os requisitos aderentes às

necessidades dos stakeholders;

o Controle de requisitos – escopo da ordem de serviço;

o Torna-se necessária uma área de entendimento e aceite que maximize

o processo de identificação dos requisitos junto aos usuários finais.

(PA 2.2) Planejamento do projeto

• Propósito: Estabelecer e manter planos que definam as atividades do projeto.

• Objetivos específicos:

o Estimativas dos parâmetros para planejamento do projeto são

estabelecidas;

o O Plano do projeto é estabelecido e mantido como base para o

gerenciamento do projeto;

o Aceites/comprometimentos para o plano do projeto são estabelecidos e

mantidos.

• Interação entre as práticas específicas

119

Figura 3.14 – Interação entre práticas (PA.2.2)

• Inferências sobre a PA:

o Deve-se criar um processo de planejamento e gerenciamento de

projetos que construa um plano e o monitore para a execução das

tarefas definidas;

o Além disso, deve-se criar alguns procedimentos e passos que

descrevem a forma de interação do cliente (ponto de contato) com a

equipe da fábrica de projetos.

(PA 2.3) Monitoração e controle do projeto

• Propósito: Fornecer entendimento sobre o andamento e progresso do projeto

de forma que ações corretivas adequadas possam ser tomadas quando o

projeto se desvia de forma significativa do plano.

• Objetivos específicos:

o O desempenho atual e o progresso do projeto são monitorados com

relação ao plano do projeto;

120

o Ações corretivas são gerenciadas quando o desempenho ou resultados

do projeto desviam significativamente do plano.

• Interação entre as práticas específicas

Figura 3.15 – Interação entre práticas (PA.2.3)

• Inferências sobre a PA:

o Deve-se criar um processo de planejamento e garantia da qualidade

que, através de revisões conjuntas seja capaz de assegurar a

construção do produto conforme as definições dos padrões

estabelecidos no planejamento da qualidade;

o Tratamento de informações sobre a qualidade, análise e identificação

de causas para a variação.

(PA 2.4) Gerência de acordos com fornecedores

• Propósito: Gerenciar a aquisição de produtos e serviços de fornecedores

externos ao projeto para os quais existe um acordo formal.

121

• Objetivos específicos:

o Acordos com os fornecedores são estabelecidos e mantidos;

o Acordos com os fornecedores são satisfeitos pelo projeto e pelo

fornecedor.

• Interação entre as práticas específicas

Figura 3.16 – Interação entre práticas (PA.2.4)

• Inferências sobre a PA:

o O processo de planejamento da fábrica deve possuir um conjunto de

atividades que gerencie todo o relacionamento das aquisições durante

a execução do projeto;

122

o Por se tratar de um processo de gestão, a equipe efetuará a avaliação

das áreas de conhecimento do PMBOK para comparar a melhor

implementação para a operação.

(PA 2.5) Medição e análise

• Propósito: Desenvolver e manter capacidade de medição que é usada para

apoiar a necessidade de informações gerenciais e tomada de decisões,

através da especificação e implementação das medições, coleta de dados e

mecanismos de armazenamento, técnicas de análise, e mecanismos de

feedback.

• Objetivos específicos:

o Objetivos de medições e práticas estão alinhados com as

necessidades de informações e objetivos;

o São fornecidos resultados de medições direcionados a necessidades

de informação e objetivos.

• Interação entre as práticas específicas

123

Figura 3.17 – Interação entre práticas (PA.2.5)

• Inferências sobre a PA:

o Necessidade de um processo de gestão da qualidade e produtividade

que realize a análise e a identificação de causas de variação,

proposição de ações corretivas, monitoramento de indicadores e

realização de auditorias.

(PA 2.6) Garantia da qualidade do processo e do produto

• Propósito: Fornecer à equipe e à gerência insight objetivo sobre o processo e

produtos de trabalho.

o Avaliar objetivamente o desenvolvimento dos processos, produtos de

trabalhos, e serviços efetuando a comparação com os padrões e

procedimentos;

o Identificar e documentar não conformidades;

124

o Fornecer feedback para a equipe e a gerência do projeto sobre as

tarefas de qualidade;

o Garantir o endereçamento das não conformidades identificadas.

• Objetivos específicos:

o A aderência do processo executado e dos produtos do trabalho, assim

como serviços associados a descrições do processo, padrões e

procedimentos aplicáveis são objetivamente avaliados;

o Aspectos com não conformidades são seguidos de forma objetiva e

comunicados, e a resolução é assegurada.

• Interação entre as práticas específicas

Figura 3.18 – Interação entre práticas (PA.2.6)

• Inferências sobre a PA:

o Necessidade de um processo de gestão da qualidade e produtividade:

planejamento da qualidade do projeto, gestão de sistemas de

125

qualidade, tratamento das informações sobre a qualidade dos

processos e dos produtos.

(PA 2.7) Gerenciamento de configuração

• Propósito: Estabelecer e manter a integridade dos produtos de trabalho

usando identificação de configuração, controle de configuração, contabilidade

do status de configuração e auditoria de configuração.

• Objetivos específicos:

o São estabelecidos e mantidos baselines de produtos de trabalho

identificados;

o Mudanças nos produtos de trabalho sob gerência de configuração são

seguidos e controlados;

o A integridade dos baselines é estabelecida e mantida.

• Interação entre as práticas específicas

126

Figura 3.19 – Interação entre práticas (PA.2.7)

• Inferências sobre a PA:

o Área específica de controle de configuração e mudanças, para

estabelecimento de baselines e integridade dos artefatos que são

modificados no decorrer do projeto.

3.3.4.2. Nível 3 (definido)

Esta seção descreverá todas as áreas de processos que pertencem ao nível 3

de maturidade. São elas:

§ Desenvolvimento de requisitos (PA 3.1);

§ Solução Técnica (PA 3.2);

127

§ Integração do produto (PA 3.3);

§ Verificação (PA 3.4);

§ Validação (PA 3.5);

§ Foco no processo organizacional (PA 3.6);

§ Definição do processo organizacional (PA 3.7);

§ Treinamento organizacional (PA 3.8);

§ Gerenciamento de projeto integrado (PA 3.9);

§ Gerenciamento de riscos (PA 3.10);

§ Integração da equipe (PA 3.11);

§ Análise e resolução de decisão (PA 3.12);

§ Ambiente organizacional para a integração (PA 3.13);

(PA 3.1) Desenvolvimento de requisitos

• Propósito: Produzir e analisar os requisitos do cliente, do produto e dos

componentes do produto.

• Objetivos específicos:

o Elicitação, análise, validação, e comunicação das necessidades,

expectativas e restrições do cliente para o entendimento que satisfará

estas regras;

o Coleção e coordenação das necessidades;

o Desenvolvimento do ciclo de vida do produto;

o Estabelecimento dos requisitos do sistema e de um produto inicial

consistente.

• Interação entre as práticas específicas

128

Figura 3.20 – Interação entre práticas (PA.3.1)

• Inferências sobre a PA:

o Elaboração de projeto lógico que valide os requisitos e os implemente

de forma conceitual;

o Processo de execução da demanda, ou seja, desenvolvimento do

projeto lógico estruturado anteriormente por outro processo.

(PA 3.2) Solução técnica

• Propósito: Projetar, desenvolver e implementar soluções para os requisitos.

• Objetivos específicos:

o Avaliar e selecionar soluções que potencialmente satisfarão a alocação

de um conjunto de requisitos;

o Desenvolver projetos detalhados para a seleção das soluções;

o Implementar o projeto em produto ou componentes.

• Interação entre as práticas específicas

129

Figura 3.21 – Interação entre práticas (PA.3.2)

• Inferências sobre a PA:

o Elaboração de projeto lógico que valide os requisitos e os implemente

de forma conceitual.

(PA 3.3) Integração do produto

• Propósito: Realizar o agrupamento dos componentes do produto, de forma a

garantir que ele, quando integrado, funciona adequadamente e entregá-lo.

• Objetivos específicos:

o Preparar o produto para a integração;

o Garantir a compatibilidade das interfaces;

130

o Integrar os componentes e entregar o produto.

• Interação entre as práticas específicas

Figura 3.22 – Interação entre práticas (PA.3.3)

• Inferências sobre a PA:

o Um conjunto de atividades que implemente o projeto lógico do sistema,

de forma a integrá-lo em um produto aderente aos requisitos

esperados.

(PA 3.4) Verificação

• Propósito: Garantir que os produtos de trabalho selecionados estejam

aderentes aos requisitos e ao processo definido.

131

• Objetivos específicos:

o Preparar a equipe e os artefatos para verificação;

o Desenvolver revisão por pares;

o Verificar os produtos selecionados contra os requisitos definidos.

• Interação entre as práticas específicas

Figura 3.23 – Interação entre práticas (PA.3.4)

• Inferências sobre a PA:

o Realização de revisão por pares que verifique a utilização do processo

de desenvolvimento durante a execução dos projetos.

(PA 3.5) Validação

132

• Propósito: Demonstrar que um produto ou componente é aderente a sua

definição de utilização quando alocado no ambiente que foi projetado.

• Objetivos específicos:

o Preparar para a validação;

o Validar o produto ou componente.

• Interação entre as práticas específicas

Figura 3.24 – Interação entre práticas (PA.3.5)

• Inferências sobre a PA:

o Avaliação dos artefatos produzidos nas diversas fases do ciclo de vida

do produto (área de qualidade).

(PA 3.6) Foco no processo organizacional

• Propósito: Planejar e implementar processos de melhoria organizacional

baseados nos problemas e dificuldades do processo endereçado.

133

• Objetivos específicos:

o Determinar as oportunidades de melhoria do processo;

o Planejar e implementar atividades de melhoria.

• Interação entre as práticas específicas

Figura 3.25 – Interação entre práticas (PA.3.6)

• Inferências sobre a PA:

o Área de planejamento estratégico que estabeleça objetivos de longo

prazo para a operação;

o Além disso, execute a gestão de melhorias, do desempenho através da

realização de experimentos que contribuam para a melhoria dos

processos e implemente uma operação de baixo custo e competitiva.

134

(PA 3.7) Definição do processo organizacional

• Propósito: Estabelecer e manter um conjunto implementável de valores e

princípios do processo organizacional.

• Objetivos específicos:

o Estabelecer qualidades e experiências úteis no processo

organizacional.

• Interação entre as práticas específicas

Figura 3.26 – Interação entre práticas (PA.3.7)

• Inferências sobre a PA:

o Estruturação de uma equipe de SEPG que avalie o melhor fluxo

operacional para a operação, de acordo com estudos de tempo e prazo

solicitados pelo planejamento estratégico.

135

(PA 3.8) Treinamento organizacional

• Propósito: Desenvolver as habilidades e conhecimentos (experiências) nos

recursos humanos, de formar a possibilitar a realização das tarefas de um

modo efetivo e eficaz.

• Objetivos específicos:

o Identificar as necessidades de treinamento;

o Obter e fornecer treinamento para suprir as necessidades;

o Estabelecer e manter uma capacidade de treinamento contínuo;

o Manter registros;

o Decidir o endereçamento do treinamento.

• Interação entre as práticas específicas

136

Figura 3.27 – Interação entre práticas (PA.3.8)

• Inferências sobre a PA:

o Avaliação estratégica de recursos humanos dentro de uma estrutura

que faça o gerenciamento do plano estratégico e acompanha a

instanciação no plano tático.

(PA 3.9) Gerenciamento do projeto integrado

• Propósito: Iniciar e gerenciar o projeto e o envolvimento com os stakeholders

sobre um processo definido e integrado, o qual foi customizado do conjunto

de processos padrão da organização.

137

• Objetivos específicos:

o Utilizar um processo definido de projeto;

o Coordenar e colaborar com os stakeholders relevantes;

o Usar visão compartilhada de projeto com desenvolvimento integrado de

produto e processo.

• Interação entre as práticas específicas

Figura 3.28 – Interação entre práticas (PA.3.9)

• Inferências sobre a PA:

o Inclusão de uma área de PMO que faça a integração entre os diversos

projetos em andamento, além de se utilizar as melhores práticas de

gerência do PMBOK que, implicitamente, já possui o conceito de

integração.

138

(PA 3.10) Gerenciamento de riscos

• Propósito: Identificar os potenciais problemas antes da ocorrência

(previsibilidade com plano de contingenciamento). Assim, as atividades de

manipulação de riscos poderão ser planejadas e invocadas quando

necessárias para mitigar impactos adversos.

• Objetivos específicos:

o Preparar um plano de gerenciamento de riscos;

o Identificar e analisar os riscos;

o Mitigar riscos.

• Interação entre as práticas específicas

Figura 3.29 – Interação entre práticas (PA.3.10)

• Inferências sobre a PA:

o Gerência de projetos;

o Gestão estratégica.

139

(PA 3.11) Integração da equipe

• Propósito: Formar e sustentar uma equipe integrada para o desenvolvimento

dos produtos de trabalho.

• Objetivos específicos:

o Fornecer habilidades e conhecimentos necessários realizar as tarefas

da equipe;

o Fornecer representação necessária para endereçar todas as fases do

ciclo de vida do processo;

o Colaborar com outras equipes, internamente e externamente;

o Compartilhar um entendimento comum de tarefas e objetivos;

o Conduzir a equipe sobre os princípios e regras operacionais.

• Interação entre as práticas específicas

Figura 3.30 – Interação entre práticas (PA.3.11)

• Inferências sobre a PA:

o Estruturação de uma área de PMO fortemente ligada com a gestão

estratégica.

140

(PA 3.12) Análise de decisão e resolução

• Propósito: Analisar possíveis soluções utilizando um processo de avaliação

formal que fará a comparação com critérios estabelecidos.

• Objetivos específicos:

o Estabelecer os critérios das alternativas de avaliação;

o Identificar alternativas de solução;

o Selecionar métodos de avaliação;

o Avaliar alternativas baseando-se em métodos e definições;

o Selecionar soluções recomendadas pelos critérios.

• Interação entre as práticas específicas

Figura 3.31 – Interação entre práticas (PA.3.12)

• Inferências sobre a PA:

o Realização de revisões conjuntas dentro de uma área estratégica,

através de equipes multidisciplinares.

141

(PA 3.13) Ambiente organizacional para a integração

• Propósito: Fornecer a infra-estrutura para o processo de desenvolvimento e

produto integrados e gerenciar pessoas para garantir a execução e que ele é

seguido pela operação.

• Objetivos específicos:

o Fornecer infra-estrutura para maximizar a produtividade;

o Gerenciar as pessoas para garantir o conceito integrativo do processo;

• Interação entre as práticas específicas

Figura 3.32 – Interação entre práticas (PA.3.13)

• Inferências sobre a PA:

o Decisão por uma estrutura integrativa do ambiente organizacional.

142

3.3.4.3. Nível 4 (gerenciado quantitativamente)

Esta seção descreverá todas as áreas de processos que pertencem ao nível 4

de maturidade. São elas:

§ Performance do processo organizacional (PA 4.1);

§ Gerenciamento quantitativo do projeto (PA 4.2);

(PA 4.1) Performance do processo organizacional

• Propósito: Estabelecer e manter o entendimento quantitativo de performance

do conjunto de processos da organização, através dos conceitos da qualidade

e objetivos iniciais. Além disso, fornecer dados de performance, baselines e

modelos para tomada de decisões.

• Objetivos específicos:

o Determinar se os processos estão se comportando consistentemente

ou se eles são estáveis;

o Identificar e comparar as definições dos processos com a instanciação

pelas equipes dos projetos;

o Estabelecer critérios, técnicas e ferramentas para o gerenciamento do

processo;

o Identificar processos com comportamento inadequado em momentos

específicos;

o Avaliar qualquer aspecto de melhoria possível;

o Estudar a implementação e o melhor desenvolvimento.

• Interação entre as práticas específicas

143

Figura 3.33 – Interação entre práticas (PA.4.1)

• Inferências sobre a PA:

o Gestão de melhorias e performance.

(PA 4.2) Gerenciamento quantitativo do projeto

• Propósito: Gerenciar quantitativamente os processos definidos do projeto para

incrementar a qualidade e objetivos de execução.

• Objetivos específicos:

o Manutenção de qualidade e objetivos do projeto;

o Identificar subprocessos adequados com relação à estabilidade e à

maturidade operacional;

o Selecionar os subprocessos para avaliação estatística;

o Monitorar o projeto para determinar o alcance dos objetivos e propor

melhorias necessárias (plano de ação corretiva ou preventiva);

o Selecionar medidas e técnicas para a avaliação;

o Realizar o empacotamento dos resultados na base de conhecimentos.

144

• Interação entre as práticas específicas

Figura 3.34 – Interação entre práticas (PA.4.2)

• Inferências sobre a PA:

o Estruturação de uma equipe de SQA.

3.3.4.4. Nível 5 (otimizado)

Esta seção descreverá todas as áreas de processos que pertencem ao nível 5

de maturidade. São elas:

§ Inovação e Deployment Organizacional (PA 5.1);

§ Análise de Causas e resolução (PA 5.2);

(PA 5.1) Inovação e Deployment Organizacional

• Propósito: Selecionar e julgar melhorias incrementais e de inovação que

possam melhorar os aspectos de processos e tecnologias da organização. O

145

suporte para a execução deste processo deriva dos objetivos de negócios de

longo prazo da organização.

• Objetivos específicos:

o Melhorar a qualidade do produto;

o Incrementar a produtividade;

o Diminuir o ciclo de vida do produto;

o Aumentar a satisfação do cliente e do usuário final;

o Diminuir o tempo de desenvolvimento alterando funcionalidades,

adicionando características, ou adaptando novas tecnologias.

• Interação entre as práticas específicas

Figura 3.35 – Interação entre práticas (PA.5.1)

• Inferências sobre a PA:

o Gestão estratégica.

(PA 5.2) Análise causal e resolução

• Propósito: Identificar causas de defeitos e outros problemas, além de

implementar planos de ação para que não ocorra futuramente.

146

• Objetivos específicos:

o Identificar e analisar causas de defeitos e outros problemas;

o Realizar ações específicas para remover as causas e prevenir a

ocorrência de outros tipos de defeitos no futuro.

• Interação entre as práticas específicas

Figura 3.36 – Interação entre práticas (PA.5.2)

• Inferências sobre a PA:

o Gestão do conhecimento.

147

4. OS PROCESSOS GERENCIAIS E OPERACIONAIS DA FÁBRICA

DE PROJETOS DE SOFTWARE

Os processos foram definidos como atividades ordenadas que caracterizam o

ciclo de vida de um produto de software, onde cada ator garante a produtividade da

etapa de produção em que está engajado e a qualidade do artefato produzido para a

etapa seguinte; a gerência de projetos como a padronização e controle das diversas

atividades; e a qualidade como fator relevante para que o processo atinja os

objetivos propostos.

Contudo, para o perfeito funcionamento das atividades de uma Fábrica de

Software é fundamental a adoção de um processo de desenvolvimento que defina

as tarefas, produtos e responsáveis pelas etapas do ciclo de vida do software. Desta

forma, este trabalho apresentará uma sugestão de um possível mapeamento dos

processos no desenvolvimento de software, quanto à sua execução, de acordo com

os tipos de Fábrica de Software, classificadas por Fernandes (2004), porém com

uma análise tendenciosa para a fábrica de projetos.

Dentro deste contexto, é proposto um modelo de fábrica de software que

privilegia a normatização, a execução faseada das tarefas e a garantia da aderência

aos requisitos. Procurar-se-á de forma simplificada, demonstrar os processos

relevantes para implantação da estrutura estudada.

A estruturação dos processos foi executada acerca dos resultados do estudo

realizado em cada modelo do capítulo anterior, ou seja, foram identificados os

requisitos e conceitos relevantes, além da sistemática de funcionamento, dos

processos inseridos no contexto de uma operação consistente, a qual fosse

centralizada na arquitetura, controlada por ferramentas de qualidade disseminadas

148

institucionalmente e gerida por um grupo de processos (e áreas de conhecimento)

que dariam o suporte estratégico e logístico.

Assim, pode-se citar que os grupos de processos podem ser estruturados em:

Gestão estratégica, Gestão da Qualidade, Gestão de Projetos, Entendimento e

Aceite, Construção do Produto e Homologação. Estes grupos serão detalhados nas

próximas seções deste trabalho e podem ser vistos na figura 4.1 abaixo, a qual

mostra o relacionamento entre os processos no contexto de negócios.

Figura 4.1 – Visão geral do relacionamento dos processos no contexto de negócios

4.1. Demonstração do workflow operacional

Para o funcionamento adequado dos processos que serão detalhados

posteriormente, torna-se latente a estruturação operacional dos fluxos de atividades

149

em um workflow, no sentido de normatizar a execução das tarefas envolvidas em

cada um dos processos gerais (e seus respectivos subprocessos).

O modelo que será apresentado é uma proposta concebida com

embasamento em pesquisas bibliográficas e documentais sobre os aspectos

essenciais para a produção de software de qualidade. O fluxo operacional da

fábrica, o qual pode ser visto na Figura 4.2 mostra a instanciação dos processos

criados dentro de um conjunto de atividades executados nos subprocessos. Esta

estrutura demonstra todo o fluxo da construção do produto de Software Específico

mediante uma solicitação (entradas do processo), seu inter-relacionamento com

outros processos, subprocessos e/ou atividades até a saída do processo (Carta de

encerramento do projeto com o aceite do cliente).

150

151

A figura mostrada acima ilustra o fluxo operacional e gerencial da fábrica de

projetos, como foi denominado o inter-relacionamento dos processos e

subprocessos, o qual foi definido de maneira que pudesse ser instanciado de acordo

com as necessidades específicas de cada projeto.

4.1.1. Entradas

- Solicitação ou Especificação do Cliente

4.1.2. Saídas

- Produto Elaborado e com Aceite

- Carta de Encerramento do Projeto

- Atualização da base de conhecimentos

4.1.3. Processos e subprocessos estruturados no workflow

O workflow da fábrica de projetos de software está dividido em 6 grupos de

processos os quais são executados por 18 subprocessos a serem detalhados nas

próximas seções. Cada subprocesso possui uma nomenclatura formada pelo

número do processo que ele está alocado (Px) seguido pelo seu posicionamento de

execução (SPx). Exemplo: O processo de Gestão da Qualidade (P2) possui 3 (três)

subprocessos que o implementa. Assim, o primeiro subprocesso seria descrito

como: P2.SP1 e os conjuntos de atividades inseridos nele como P2.SP1.#1,

P2.SP1.#2 etc. Seguem abaixo os subprocessos existentes:

152

- P4.SP1: Avaliar a necessidade;

- P4.SP2: Verificar a viabilidade (tecnológica);

- P4.SP3: Elaborar a proposta técnica;

- P3.SP1: Formalizar o projeto;

- P5.SP1: Incluir o projeto no PCP;

- P3.SP2: Realizar o planejamento do projeto;

- P2.SP1: Planejar a qualidade do projeto;

- P5.SP2: Elaborar o projeto lógico;

- P5.SP3: Executar a demanda;

- P5.SP4: Executar os testes;

- P5.SP5: Realizar a implantação (BETA);

- P6.SP1: Realizar a implantação (ambiente de produção);

- P3.SP3: Finalizar a demanda;

- P2.SP2: Garantir a qualidade;

- P2.SP3: Registrar as lições aprendidas;

- P1.SP1: Gerenciar os recursos estratégicos;

- P1.SP2: Inferir sobre os recursos;

- P6.SP2: Realizar o aceite do cliente.

Assim, o documento apresenta uma visão consolidada dos fluxos de

atividades considerando o seguinte contexto de funcionamento:

Com a entrada de uma especificação e/ou solicitação do cliente é

estabelecido um ponto de contato entre o consumidor e o fornecedor da solução

através do subprocessos P6.SP2: Realizar aceite do cliente. Este conjunto de

atividades irá analisar o documento, entendê-lo e encaminhá-lo para a célula

153

adequada; no caso, P4.SP1 (avaliar a necessidade – para solicitação) ou P4.SP2

(verificar a viabilidade – tecnológica da especificação). A partir deste momento, será

encaminhada a necessidade aprovada, no sentido de elaborar a proposta técnica

(P4.SP3) que deverá passar pelo sign-off do cliente no P6.SP2 (realizar aceite do

cliente). Caso a proposta não seja aceita, ela deverá retornar para o mesmo

subprocessos para ajustes; para o documento aprovado, o mesmo será

encaminhado para o P3.SP1 (formalizar o projeto) que produzirá o Project Charter

para o planejamento do projeto (P3.SP2) e a inclusão da OS no PCP da operação

(P5.SP1).

Dando prosseguimento, o P3.SP1 realiza o planejamento do projeto e, após o

retorno do plano de qualidade (P2.SP1) cria a EAP (estrutura analítica do projeto).

Com este documento e a especificação, o P5.SP2 executa a elaboração do projeto

lógico com o objetivo de entender e realizar o design das interfaces, executar o

detalhamento dos casos de uso, diagrama de classes e de seqüência. Após a

aprovação deste artefato, pelo cliente, segue-se o P5.SP4 na elaboração do plano

de testes e o P5.SP3 com a execução da demanda, ou seja, implementação do

modelo lógico da disciplina de especificação de software, ou seja, de posse dos

casos de uso detalhados e realizados, diagrama de classes e seqüência, juntamente

com o plano de testes, o implementador realizará as atividades pertinentes à criação

de builds a serem integrados no subsistema e, posteriormente, no sistema.

Com a disponibilização de subsistemas e sistemas da atividade anterior,

deve-se executar os testes para validação da execução (P5.SP4). De posse do

produto testado, realiza-se o planejamento e a execução da implantação no

ambiente (BETA) – P5.SP5 e, posteriormente, a implantação do ambiente de

produção (P6.SP1) – ambos com o aceite do cliente.

154

Paralelamente, o P2.SP2 executa as atividades de garantia da qualidade

através da estruturação e do acompanhamento de revisões e avaliações,

coordenadas pelo processo de gerenciamento do projeto, as quais forem

necessárias (conforme o planejamento da qualidade). Estas atividades alimentam o

plano de qualidade e o registro de lições aprendidas (P2.SP3). Além disso, deve-se

mencionar que a operação possui um subprocessos de gerenciamento de recursos

estratégicos (P1.SP1), o qual envolve o planejamento da tecnologia, dos riscos, a

gestão financeira, de desempenho, RH, treinamento e gestão do conhecimento, no

sentido de criar um plano estratégico que sustente o negócio no longo prazo.

Após a implantação, o cliente deverá realizar o aceite da carta de

encerramento que alimentará o P3.SP3 de finalização de demanda. Para a

conclusão final, existe um subprocessos P1.SP2 que realiza a inferência sobre os

recursos estratégicos, planejados anteriormente, visando a avaliação do workflow do

processo para o aproveitamento ótimo dos recursos e manutenção de uma base de

conhecimento da operação na execução de todos os projetos.

4.2. Grupos de processos

Conforme mencionado na seção 3 deste trabalho, e com base no PMBOK

(2000), os processos de gerência de projetos podem ser organizados em cinco

grupos, cada um deles contendo um ou mais subprocessos. Desta forma, efetuar-se-

á a alocação de cada processo no contexto da transformação de uma solicitação em

um produto elaborado.

1) Processos de iniciação: autorização do projeto ou fase (comprometimento);

a. Entendimento e Aceite (P4):

155

i. Avaliar a necessidade

ii. Verificar a viabilidade

iii. Elaborar a proposta técnica

b. Homologação (P6):

i. Aceite do cliente

c. Construção de Produto (P5)

i. Elaborar projeto lógico (prova conceitual, quando necessário)

ii. Incluir PRT no cronograma

d. Gestão Estratégica (P1)

i. Gerenciar recursos estratégicos

e. Gestão de Projetos (P3)

i. Formalizar o projeto

f. Gestão da Qualidade (P2)

i. Planejar a qualidade

ii. Garantir a qualidade

iii. Registrar as lições aprendidas

2) Processos de planejamento da execução: definição e refinamento dos

objetivos e seleção da melhor das alternativas de ação para alcançar os

objetivos que o projeto estiver comprometido em atender;

a. Gestão de Projetos (P3):

i. Realizar o planejamento do projeto

b. Entendimento e Aceite (P4):

i. Elaborar a proposta técnica

c. Homologação (P6):

156

i. Aceite do cliente

ii. Implantação (ambiente: Produção)

d. Construção de Produto (P5):

i. Executar testes (planejamento)

ii. Implantação (ambiente BETA)

e. Gestão da Qualidade (P2):

i. Planejar a qualidade do projeto

ii. Garantir a qualidade

iii. Registrar as lições aprendidas

f. Gestão Estratégica (P1):

i. Gerenciar os recursos estratégicos

ii. Inferir sobre os recursos

3) Processos de execução (desenvolvimento): coordenar pessoas e outros

recursos para realizar o plano do processo anterior.

a. Gestão de Projetos (P3)

i. Realizar o planejamento do projeto (contexto: gerenciamento)

b. Homologação (P6)

i. Implantação (ambiente: Produção)

ii. Aceite do cliente

c. Construção de Produto (P5)

i. Elaborar o projeto lógico

ii. Executar a demanda

iii. Executar os testes

iv. Implantação (ambiente: BETA)

d. Gestão da Qualidade (P2)

157

i. Garantir a qualidade

ii. Registrar as lições aprendidas

e. Gestão Estratégica (P1)

i. Inferir sobre os recursos estratégicos

4) Processos de monitoramento e controle: assegurar que os objetivos do

projeto estão sendo atingidos, através da monitoração regular do seu

progresso para identificar variações do plano e, portanto ações corretivas

podem ser tomadas quando necessárias.

a. Gestão de Projetos (P3)

i. Realizar o planejamento do projeto (contexto: gerenciamento)

b. Homologação (P6)

i. Aceite do cliente

c. Gestão da Qualidade (P2)

i. Garantir a qualidade (monitoramento)

d. Gestão Estratégica (P1)

i. Gerenciar os recursos estratégicos

ii. Inferir sobre os recursos estratégicos

5) Processos de transição: formalizar a aceitação do projeto ou fase e encerrá-

lo(a) de uma forma organizada.

a. Gestão de Projetos (P3)

i. Finalizar a demanda

b. Homologação (P6)

i. Implantação (ambiente: PRODUÇÃO)

c. Gestão da Qualidade (P2)

i. Registrar as lições aprendidas

158

d. Gestão Estratégica (P1)

i. Inferir sobre os recursos estratégicos

Os grupos de processos se ligam pelos resultados que produzem – o

resultado ou saída de um grupo torna-se entrada para outro. Entre grupos de

processos centrais, as ligações são iterativas - o planejamento alimenta a execução,

no início, com um plano do projeto documentado, fornecendo, a seguir, atualizações

ao plano, na medida em que o projeto progride. Além disso, os grupos de processos

da gerência de projetos não são separados ou descontínuos, nem acontecem uma

única vez durante todo o projeto; eles são formados por atividades que se

sobrepõem, ocorrendo em intensidades variáveis ao longo de cada fase do projeto.

Finalmente, as interações dos grupos também atravessam as fases, de tal forma que

o encerramento de uma fase fornece uma entrada para o início da próxima.

Já o Rational Unified Process (2003), demonstra o ciclo de vida de software

em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja,

cada fase é basicamente um intervalo de tempo entre dois marcos principais. Além

disso, uma passagem pelas quatro fases: iniciação, elaboração, construção e

transição, é um ciclo de desenvolvimento; cada passagem pelas quatro fases

produz uma geração do software. A menos que produto "desapareça", ele irá se

desenvolver na próxima geração, repetindo a mesma seqüência de fases de

iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas

diversas fases. Esses ciclos subseqüentes são chamados de ciclos de evolução. À

medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Neste trabalho, os processos da fábrica também foram mapeados de acordo com as

fases do RUP e podem ser observados no gráfico da figura 4.4, na seção 4.4, ou

seja, a execução das atividades que objetivam a saída de um produto elaborado

159

conforme as necessidades do cliente seguem o processo unificado no contexto da

construção.

Seguindo esta linha de raciocínio, o modelo CMMi agrupa práticas comuns

para uma determinada área do processo (uma vez implementadas em conjunto na

organização, contribuirão para a melhoria daquela área), sendo cada uma delas

relacionadas com métricas de avaliação e garantia de maturidade na execução dos

processos de construção de produtos. Cada área de processo, por sua vez, é

composta por metas específicas (objetivos restritos a uma determinada área, e

implementados através de práticas especificas sugeridas) e metas genéricas

(objetivos comuns a várias áreas abordadas no CMMi, e implementadas através de

práticas genéricas sugeridas).

Assim, os processos da fábrica de projetos foram definidos através do

entendimento e mapeamento do contexto organizacional e das áreas de processos

do nível de maturidade do modelo, no caso o nível 4 (gerenciado quantitativamente),

possibilitando atingir o objetivo de certificação da operação conforme a estrutura do

modelo estudado na seção 3, ou seja, os processos são institucionalizados e podem

ser confrontados com as expectativas do nível de maturidade ou capacidade do

modelo estabelecido como alvo (alinhamento dos processos e o comprometimento

de melhoria contínua da qualidade na organização).

Desta forma, a operação estruturada da fábrica de projetos busca estar

centrada na execução de atividades que podem realizar a construção de produtos

baseados no contexto dinâmico dos dois modelos de gestão e construção, além de

possuir características de melhoria contínua do modelo de qualidade: CMMi.

160

4.3. Interação entre os processos

Fernandes (2004) menciona que para o melhor entendimento do modelo de

Fábrica a ser estruturado, faz-se importante a ilustração de um framework que nos

mostre os componentes e a interação dos subprocessos, conforme cada camada do

modelo (ou processo). Desta forma, serão ilustrados, na figura 4.3, os componentes

existentes na implantação de cada processo existente no modelo de fábrica de

projetos proposto neste trabalho.

Na observação da figura, pode-se verificar que existem camadas de

componentes, denominadas processos: Gestão estratégica, Garantia da Qualidade,

Gestão de Projetos, Entendimento e Aceite, Desenvolvimento e Homologação. Cada

camada é instanciada por subprocessos que executam um conjunto de atividades

com o objetivo de criar artefatos para a implementação de cada área de

conhecimento. Num grupo de subprocessos, as atividades individuais são ligadas

por suas entradas e saídas. PMBOK (2000) Considerando-se estas ligações pode-se

descrever cada subprocessos em termos de:

• Entradas: documentos ou itens documentáveis que influenciarão o processo.

• Ferramentas e técnicas: mecanismos aplicados às entradas para criar as

saídas (passos);

• Saídas: documentos ou itens documentáveis resultantes do processo.

Nas sub-seções seguintes será efetuado o detalhamento de cada

componente do framework em termos de objetivos e sistemática de interação.

161

Figura 4.3 – Framework dos componentes da fábrica de projetos

4.3.1. Gestão estratégica

De acordo com Fernandes (2004), os subprocessos de gestão estratégica

devem possuir os seguintes aspectos:

1. Planejamento estratégico: visa estabelecer objetivos de longo prazo para a

operação;

162

2. Planejamento de Tecnologia e Processos: deve, a partir do planejamento

estratégico, definir quais tecnologias e processos devem ser prospectados e,

se possível, testados;

3. Planejamento de riscos: provém estratégias de ação e de resposta ao risco

em virtude da ocorrência de um evento de risco;

4. Gestão Financeira: objetiva a manutenção do equilíbrio financeiro, garantindo

os retornos aos investimentos e as margens do negócio;

5. Gestão de Mudança: planejamento de mudanças nas tecnologias em termos

de software, implementação de novas linguagens de programação,

dispositivos de segurança, servidores, softwares especiais etc.

6. Gestão de Melhoria: objetiva promover as melhorias nos processos, no

âmbito da Fábrica de Projetos, em todos os níveis.

7. Gestão de Desempenho: medir o comportamento dos indicadores da

operação, conhecer tendências do desempenho, promover ações gerenciais e

avaliar o resultados em longo prazo.

8. Recursos Humanos: gestão dos recursos humanos da fábrica – seleção e

contratação, políticas de benefícios, plano de carreira, análise de

produtividade, projetos motivacionais etc.

9. Treinamento: melhorias de produtividade e absorção de novos integrantes.

10. Segurança: deve planejar e monitorar as políticas de segurança e

responsabilidades dos membros.

11. Gestão do conhecimento: controle e a disposição de todo o acervo de

conhecimento gerado pela operação.

163

4.3.2. Gestão da qualidade

De acordo com Fernandes (2004), os subprocessos de gestão da qualidade

devem possuir os seguintes aspectos:

1. Revisão conjunta: são revisões sobre o desempenho da operação;

2. Controle da qualidade: assegurar que o produto (ou produtos) que está sendo

gerado na execução da OS esteja sendo construído de acordo com os

padrões estabelecidos no planejamento da qualidade e aderentes aos

requisitos solicitados.

3. Planejamento do teste: define os objetivos, quais testes serão realizados,

quem e quando irá executar, definição de recursos necessários e condições

de tratamento e encerramento.

4. Gestão do Teste: controle do planejamento e de sua execução,

principalmente quanto aos testes integrados, de sistemas e de aceitação.

5. Gestão da qualidade e produtividade: planejamento da qualidade do projeto,

gestão de sistemas de qualidade, tratamento das informações sobre a

qualidade dos processos e dos produtos, análise e identificação de causas de

variação, proposição de ações corretivas, monitoramento de indicadores e

realização de auditorias.

6. Compliance: assegurar que os padrões estabelecidos para a Fábrica de

projetos estejam sendo seguidos;

164

4.3.3. Gestão de projetos

De acordo com Fernandes (2004), os subprocessos de gestão de projetos

devem possuir os seguintes aspectos:

1. Controle da Mudança: trata de todas as mudanças da OS, avalia o impacto

em todos os aspectos e comanda a atualização.

2. Gestão da Demanda: monitoramento de todas as demandas que entram na

fábrica e o controle da capacidade produtiva.

3. Planejamento e Aceitação: processo auxiliar ao processo de entendimento e

aceite.

4. Gestão de Problemas: resolução de problemas que ocorrem no âmbito da

operação e na execução das OS.

5. Controle do Risco: controla o risco da operação baseado no planejamento de

risco da Gestão Estratégico.

6. Controle de Requisitos: controle do escopo da ordem de serviço.

7. Gestão dos SLA´s e contratos: gestão de acordos de níveis de serviço com os

diversos clientes e usuários.

8. Controle de Recursos: monitora os recursos da operação.

9. Controle do prazo: determina a medição do progresso físico do projeto.

10. Gestão de Sub-contratados: gestão dos contatos com os fornecedores da

fábrica de projetos.

165

4.3.4. Entendimento e aceite

De acordo com Fernandes (2004), os subprocessos de entendimento e aceite

devem possuir os seguintes aspectos:

1. Planejamento e aceitação: definição do escopo de atendimento, estimativa de

tamanho do software, prazo, esforço, custo, qualidade e recursos.

2. Análise da OS: avaliar e decidir se aceita completamente o documento.

3. Atendimento a ajustes: resolução de defeitos encontrados na operação.

4.3.5. Construção do produto

De acordo com Fernandes (2004), os subprocessos de construção do produto

devem possuir os seguintes aspectos:

1. Planejamento e controle da produção: responsável por colocar a OS no plano

de produção e encaminhá-la para a produção.

2. Projeto de implementações: planejar o modelo de implementação

(construção).

3. Especificação de requisitos: define os requisitos funcionais e não-funcionais

do projeto.

4. Desenvolvimento do projeto: trata do detalhamento das especificações no

contexto físico do processo.

5. Teste unitário: de cada programa ou componente.

166

6. Teste integrado: teste que integra os programas codificados em partes

funcionais do software.

7. Preparação de teste: disponibilização dos recursos para a execução.

8. Testes de Sistema: é o teste do software e de suas interfaces com outros

softwares e dispositivos computacionais.

9. Construção: elaboração de códigos de programas.

4.3.6. Homologação

De acordo com Fernandes (2004), os subprocessos de homologação devem

possuir os seguintes aspectos:

1. Recebimento e liberação: gestão de todo o interfaceamento operacional da

fábrica com os clientes e usuários.

2. Homologação da OS: objetiva obter o sign-off da OS e liberar o produto

resultante para o cliente.

3. Instalação: planejamento da instalação (implantação) no ambiente de

produção.

4. Implantar: fazer com que as funcionalidades produzidas se integrem nos

processos de negócio da organização do cliente.

5. Teste de Aceitação: teste executado em ambiente controlado de

homologação.

167

4.4. Áreas de concentração dos processos (mapeamento)

O quadro 4.1 apresenta um mapeamento dos subprocessos de gerência

alocados nos cinco grupos de processos do PMBOK: iniciação, planejamento,

execução, controle e encerramento. Este diagrama indica geralmente onde o

processo de gestão da construção de software encaixa os grupos de processos e

áreas de conhecimento, além de demonstrar as entradas e saídas dos subprocessos

que implementam a operação.

Quadro 4.1 – Área de concentração dos processos conforme o PMBOK (Project

Management Body of Knowledge)

Além disso, pode-se observar a figura 4.4 que distribui os processos

mapeados dentro das fases de construção de software do processo unificado, no

sentido de melhorar o entendimento das atividades no ciclo de desenvolvimento e

geração do produto elaborado.

168

Figura 4.4 – Área de concentração dos processos conforme o RUP (Rational Unified

Process)

Seguindo a linha de raciocínio do PMBOK (2000), cada fase do projeto é

marcada pela conclusão de um ou mais produtos da fase (deliverables). Um

subproduto é resultado do trabalho, tangível e verificável. Desta forma os gráficos

das áreas de concentração estão delineados para mostrar a fronteira existente em

cada subprocesso dentro das fases do projeto.

4.5. Detalhamento dos sub-processos distribuídos nos processos

4.5.1. Processo de gestão estratégica (P1)

4.5.1.1. Objetivos

169

O processo de gestão estratégica visa estabelecer objetivos de longo prazo

para a operação, através da execução do planejamento estratégico, de tecnologia e

processos, riscos, compliance, financeira, mudança, melhoria, desempenho,

recursos humanos, segurança e conhecimento. Todas as decisões deste processo

focam sua melhoria contínua e seu alinhamento constante com o negócio,

principalmente no que tange à implementação de melhorias nos processos ou a

novos processos e novas tecnologias, visando à entrega de funcionalidades com

melhor qualidade e de forma mais rápida.

4.5.1.2. Políticas

A Gerência Estratégica da Fábrica de Projetos de Software, abaixo define e

faz cumprir, as seguintes políticas que orientam as atividades relacionadas à

execução do Processo Gestão Estratégica.

Descrição das Políticas

• Na execução do planejamento, deve-se realizar a avaliação das

interfaces dos projetos no contexto organizacional, técnico e

interpessoal;

• A fábrica deve possuir um procedimento de busca de conhecimento em

modelos de projetos anteriores e materiais teóricos referentes ao

gerenciamento de recursos humanos;

• Os documentos gerados na atividade de planejamento deverão ser

registrados nos sub-processo: Inferir sobre os recursos estratégicos do

processo de Gestão Estratégica;

• O Gerente Sênior deve manter um atualizado plano estratégico da

170

operação;

• A atividade de negociação na montagem da equipe deve possuir a

criação de um contrato com nível de serviço, quando da utilização de

alocação de terceiros;

• A política de incentivos e prêmios da organização deve ser disseminada

em todos os níveis da estrutura organizacional, utilizando como

ferramenta um eficaz processo de comunicação;

• A criação do plano de treinamento deve possuir o aceite do Gerente

Sênior que deverá garantir a melhoria da performance de acordo com o

plano de ação.

• O detalhamento da estratégia está condicionado e atrelado aos

artefatos gerados pelo processo de Gestão de Práticas e Recursos e

também do Planejamento de Recursos Estratégicos;

• Este processo deve detalhar as definições do Planejamento estratégico,

de forma a criar um plano de ação tático que implemente os objetivos e

metas estratégicas da operação.

• Todo o patrimônio da fábrica deve ser inventariado e registrado em um

relatório de ativos a fim de garantir a proteção apropriada;

• Os funcionários devem estar orientados e bem informados sobre a

expectativa da empresa para com eles, com relação a assuntos

confidenciais e de segurança, e como sua função na segurança se

enquadra na operação geral da empresa;

• Este processo deve elaborar um plano de relatório de incidentes;

• Deve ser garantida a segurança Física e Ambiental da Fábrica;

• O controle de acesso a recursos da rede e de aplicativos deve ser

monitorado para proteger abusos internos e intrusões externas;

• A fábrica de projetos deve elaborar e implementar, neste processo, um

Plano de Gerenciamento de Continuidade dos Negócios. Além disso,

necessita providenciar um Plano de Contingência para mitigar os

possíveis riscos da operação;

• Todo o planejamento de segurança deve, regularmente, ser revisto e

atualizado.

• A base para a construção do Workflow deve utilizar as atividades

171

definidas para um projeto genérico e as experiências de projetos

anteriores.

• Dentro deste contexto, deve utilizar como ferramentas: o escopo e as

premissas do projeto.

• Todas as variações devem ser registradas em lições aprendidas para

uso em projetos futuros.

• Após a homologação do project charter pelo cliente, a especificação

deverá ter seu escopo detalhado para a elaboração do Planejamento de

Compliance.

• Devem ser consideradas lições aprendidas e base de conhecimento

dos stakeholders, fatores ambientais e externos como política

econômica e questões políticas.

• A equipe designada para o detalhamento deverá suprir este processo

com a declaração do escopo (justificativa, produto e sub-produto do

projeto), restrições (definidas pelas cláusulas contratuais das SLA´s),

premissas e informações históricas;

• Deverá gerar os seguintes produtos:

o Planejamento de Compliance;

o Relatórios de auditoria de processo e operação;

o Relatórios de controle de não-conformidade;

o Mudanças solicitadas.

• Todas as saídas dos processos de outras áreas de conhecimento

deverão ser revistas quanto à identificação de possíveis riscos.

• Deverá haver um repositório com todo histórico de compliance para

avaliação, correção e melhoria dos processos.

• Toda e qualquer mudança relacionada à tecnologia deve ser analisada,

planejada e implantada de acordo com a viabilidade e/ou necessidade

do negócio, bem como, todo o processo relacionado a essa mudança

deve ser adequado;

• Todo o fluxo de capital e investimentos deve ser controlado;

• Melhoria em processos deve ser analisada e implementada de acordo

com as necessidades de melhoria de resultados.

• O processo deve realizar o seu conjunto de atividades a fim de

172

monitorar e manter o desempenho da fábrica conforme metas e

objetivos estabelecidos.

• O Planejamento de Recursos Estratégicos deve ser elaborado com

base no Plano Diretor (PD) e nas Estratégias da Corporação.

• A alta direção da corporação e a gerência sênior da Fábrica de Projetos

deverão dispor de recursos intelectuais (internos e externos –

consultoria empresarial) para o auxílio na elaboração dos artefatos do

planejamento estratégico.

• Além da Alta Direção da Corporação, a Gestão de Práticas e Recursos

também poderá fornecer artefatos, bem como efetuar solicitações, que

serão analisadas e utilizadas na elaboração do Planejamento de

Recursos Estratégicos.

• Todos os estudos das características da operação da fábrica deverão

ser apoiados pelo processo de pesquisa e acompanhamento da gestão

do conhecimento;

• Para apoiar a instanciação do processo, o gerente de operações

buscará continuamente a melhoria dos processos, verificando as

estratégias do mercado concorrente e nomeando uma equipe

multidisciplinar para apoiar a alimentação, o estudo e os planos de ação

da base de experiências;

• Todas as lições aprendidas dentro e fora da operação, deverão ser

divulgadas e mantidas na base de experiências, seguindo as atividades

para a obtenção das metas;

• A interação entre a organização do projeto e a fábrica de experiências

deverá ocorrer sobre dois ciclos de realimentação. São eles: passo de

execução do processo (aprendizado ao nível de projeto) e o

empacotamento da experiência no final do projeto e a utilização para

execução do plano de ação;

• As metas organizacionais determinarão o tipo de conhecimento a ser

coletado por este processo.

• Todas as solicitações de mudança da estrutura do Workflow deverão

passar por este processo de revisão e aceite;

• Para cada solicitação deverá ser criado um pacote de inspeção por

173

conta da SEPG;

• As revisões serão executadas nas áreas em que a SEPG definir como

críticas para a operação, conforme avaliação do fluxo de trabalho;

• O time a ser criado para a validação será composto de, no mínimo, 3

membros. Além disso, a SPA selecionará os inspetores com

conhecimento compatível aos objetivos.

• O plano de trabalho, bem como o resumo gerencial, deverão ser

validados pelo gerente sênior. Além disso, a SPA ficará responsável por

redigir toda a documentação dos logs;

Figura 4.5 – Quadro de políticas do processo de Gestão Estratégica

4.5.1.3. Sub-processos do processo (P1)

4.5.1.3.1. Sub-processo 1 (SP1): gerenciar recursos estratégicos

(P1.SP1)

4.5.1.3.1.1. Descrição e objetivos

Este subprocesso realiza as atividades pertinentes ao planejamento dos

recursos estratégicos e o seu monitoramento visando o cumprimento das metas e

objetivos da organização.

Objetivo: planejamento estratégico.

174

4.5.1.3.1.2. Papéis envolvidos

Papéis Responsabilidades

Gerente Sênior da Fábrica

de Projetos

1. Identificar restrições e documentar

necessidades no sentido de preparar

um plano de ação para a operação

(curto, médio e longo prazo).

2. Monitorar a realização do plano de

desenvolvimento da equipe e garantir

a melhoria da performance.

3. Traçar um plano tático para a

estratégia definida pela direção da

fábrica (planejamento de recursos)

4. Elaborar e manter o inventário

atualizado.

5. Aprovações, firmar contratos, realizar

pagamentos, liberar de verba.

6. Verificar necessidades de mudanças

com relação à tecnologia e avaliar os

impactos das mudanças pretendidas

e/ou efetuadas.

7. Elaborar Plano de Melhorias;

8. Elaborar Relatório de Desempenho e

de Indicadores.

9. Elaborar Plano de Mudança e de

Ação;

10. Garantir que toda a mudança seja

perfeitamente adequada ao processo e

vice-versa.

175

Diretor da Fábrica de

Projetos

1. Analisar Plano Diretor.

2. Analisar Estratégias da Corporação

3. Avaliar recursos

4. Elaborar Planejamento de Recursos

Estratégicos

Gestor financeiro 1. Gerenciar todo o orçamento da

Fábrica.

Gerente de Compliance

1. Deverá realizar reuniões para

desenvolver o planejamento de

compliance.

2. Deverá desenvolver metodologia de

controle de processo, sua aplicação e

controle.

3. Deverá desenvolver, planejar, aplicar e

controlar processos de auditoria

identificando e sanando não-

conformidades; facilitar a atribuição

clara de responsabilidades.

Gerente de RH

1. Realizar o enquadramento nas

práticas de recursos humanos,

executando um manual de práticas de

recrutamento e um plano de gerência

de pessoal.

2. Estruturar um modelo de montagem da

equipe, efetuando comparações no

sentido de elaborar um plano de

treinamento.

176

Gerente de Projetos

1. Deverá designar o Gerente da equipe

de Compliance e acompanhar as fases

de tomada de decisão.

2. Executar a inclusão do Planejamento

de Compliance no repositório de

modelos;

SPA (Software Process

Authority)

1. Avaliar os processos para construção

do software.

2. Analisar os recursos disponíveis para

construção do software.

3. Definir o melhor caminho para

realização dos processos.

Gerente de TI

1. Elaborar Plano de Contingência;

2. Elaborar Plano de Segurança e

Cartilha de Segurança;

3. Elaborar Plano de Gerenciamento de

Continuidade dos Negócios.

4. Elaborar Documento de respostas de

incidentes;

5. Garantir a execução do planejamento

das características tecnológicas e do

processo.

6. Elaborar Documento de respostas de

incidentes.

7. Realizar o processo de comunicação

aos colaboradores da empresa sob

aspectos de segurança, em especial

sobre engenharia social.

8. Elaborar Relatório de Medidas de

Segurança;

Figura 4.6 – Quadro de papéis do subprocesso P1.SP1

177

4.5.1.3.1.3. Detalhamento do sub-processo

Os conjuntos de atividades do sub-processo P1.SP1 são: planejar os recursos

estratégicos (P1.SP1.#1), detalhar a estratégia (P1.SP1.#2), planejar o Workflow

da operação (P1.SP1.#3), gerenciar práticas e recursos (P1.SP1.#4), avaliação

de recursos humanos (P1.SP1.#5), realização de Compliance (P1.SP1.#6) e

monitoramento de segurança (P1.SP1.#7), os quais serão detalhados abaixo.

178

Figura 4.7 – Quadro de detalhamento do subprocesso P1.SP1

179

Subprocesso P1.SP1.#1: Planejar os Recursos Estratégicos

Atividade: Elaborar Planejamento de Recursos Estratégicos Propósito: Alinhar operação da Fábrica de Software com a estratégia de negócios da corporação, estabelecendo objetivos de longo prazo para a operação. Passos:

- Analisar Plano Diretor - Identificar metas da operação - Analisar, ampliar e criar novas linhas de serviços - Estudar e avaliar novas tecnologias - Decidir sobre políticas de certificações internacionais de qualidade - Decidir sobre políticas de desenvolvimento e programas de certificação de recursos humanos - Desenvolver parcerias - Desenvolver novos mercados Artefatos de Entrada: - Solicitações da Alta Direção - Plano Diretor - Análise de Mercado - Previsão de Demanda - Análise de Novas Tecnologias - Histórico dos Projetos

Artefatos de Saída: - Planejamento de Recursos Estratégicos - Relatório de aquisições - Solicitação de treinamentos

Freqüência: Anual Ator: Diretor da Fábrica de Projetos e Gerente Sênior

Figura 4.8 – Conjunto de Atividades do subprocesso P1.SP1.#1

180

Subprocesso P1.SP1.#2: Detalhar a estratégia

Atividade: Detalhar Estratégia

Propósito: Obter uma visão ampla do passos necessários para cumprir o planejamento estratégico. Passos:

- Definir prioridades - Solicitar e obter cronograma de Treinamentos junto ao RH da corporação. - Elaborar cronograma de aquisição e implantação de novos recursos tecnológicos - Detalhar e Avaliar Riscos - Detalhar custos da operação. - Avaliar Cases (benchmarking) - Identificar mecanismos para acompanhamento de Atividades X Metas Artefatos de Entrada: - Estratégias e Políticas da Corporação - Planejamento de Recursos Estratégicos - Plano Diretor

Artefatos de Saída: - Detalhamento da estratégia - Cronograma de Treinamentos - Relatório de Risco - Solicitação de Aquisições

Freqüência: Anual Ator: Gerente Sênior da Fábrica de Projetos

Figura 4.9 - Conjunto de Atividades do subprocesso P1.SP1.#2

181

Subprocesso P1.SP1.#3: Planejar o Workflow da operação

Atividade: Selecionar processos

Propósito: Identificar processos pertinentes ao projeto em questão. Utilizar somente processos cabíveis. Passos: - Avaliar os processos pertinentes - Comparar com projetos anteriores e lições aprendidas Artefatos de Entrada: - Lista de processos - Lições aprendidas - Projeto modelo

Artefatos de Saída: - Lista de processos (atualizada)

Freqüência: a cada início de projeto Ator: SPA

Atividade: Definir seqüência de atividades Propósito: Verificar a seqüência que cada atividade deve ser executada. Avaliar pré-requisitos para as atividades e definir a melhor ordem que devem ser executadas. Passos: - Selecionar as atividades de cada processo - Verificar seqüência e prioridades - Verificar correlação com outros processos - Traçar melhor fluxo de atividades Artefatos de Entrada: - Lista de processos (atualizada) - Lições aprendidas - Projeto modelo

Artefatos de Saída: - Lista de atividades

Freqüência: a cada início de projeto Ator: SPA

Atividade: Analisar caminhos críticos Propósito: Definir pontos de risco ao controle de custos, prazos, qualidade

182

entre outros pontos definidos no plano de controle. Destacar os pontos de atenção. Passos: - Avaliar tempo necessário para execução de cada atividade - Relacionar atividades que podem ser executadas em paralelo - Comparar com o cronograma do projeto - Verificar se as premissas estão sendo atendidas - Definir pontos de atenção e de controle Artefatos de Entrada: - Lista de atividades - Cronograma - Premissas

Artefatos de Saída: - Marcos - Pontos de controle

Freqüência: a cada início de projeto Ator: SPA

Atividade: Analisar recursos Propósito: Verificar a disponibilidade dos recursos para execução do Workflow. Atualizar os pontos de controle tendo em vista os recursos disponíveis. Passos: - Avaliar recursos disponíveis para execução das atividades - Atualizar pontos de atenção e controle Artefatos de Entrada: - Marcos - Pontos de controle - Lista de recursos

Artefatos de Saída: - Pontos de controle (atualizado)

Freqüência: a cada início de projeto Ator: SPA

Atividade: Definir fluxo das atividades Propósito: Gerar o Workflow para execução dos projetos da fábrica. Passos: - Traçar o melhor fluxo de atividades para execução dos processos da fábrica. Artefatos de Entrada: - Premissas - Marcos - Pontos de controle

Artefatos de Saída: - Workflow

Freqüência: a cada início de projeto Ator: SPA

Figura 4.10 - Conjunto de Atividades do subprocesso P1.SP1.#3

183

Subprocesso P1.SP1.#4: Gerenciar práticas e recursos

Atividade: Analisar Necessidades

Propósito: Avaliar quais são as necessidades de mudança em se tratando de tecnologias da fábrica, implementação de novas linguagens de programação, dispositivos de segurança, servidores, etc. Passos: - Verificar as mudanças necessárias; Artefatos de Entrada:

Artefatos de Saída: - Lista de Necessidades.

Freqüência: no decorrer de cada projeto. Ator: Gerente de TI

Atividade: Planejar Mudanças Propósito: Fazer todo o planejamento das mudanças para que não ocorram desarmonias nos processos da fábrica. Passos: - Planejar mudanças necessárias; - Planejar adequação dos processos às mudanças; Artefatos de Entrada: - Lista de Necessidades.

Artefatos de Saída: - Plano de Ação; - Plano de Mudança.

Freqüência: no decorrer de cada projeto. Ator: Gerente de TI

Atividade: Adequar Processos / Tecnologia Propósito: Realizar as mudanças necessárias tanto em tecnologias quanto em processos. Passos: - Executar mudanças; - Adequar processos. Artefatos de Entrada: - Plano de Ação; - Plano de Mudança.

Artefatos de Saída: - Relatório de Mudanças.

Freqüência: ao final de cada projeto. Ator: Gerente de TI

Atividade: Avaliar Resultados

184

Propósito: Avaliar os resultados após todas as mudanças efetuadas. Passos: - Avaliar os resultados obtidos. Artefatos de Entrada: - Lista de Necessidades; - Relatório de Mudanças.

Artefatos de Saída: - Resultados.

Freqüência: no decorrer de cada projeto. Ator: Gerente de TI

Atividade: Analisar Finanças

Propósito: Avaliar todos os gastos, receitas e investimentos. Passos: - Contabilização de receitas; - Contabilização de despesas; - Avaliar investimentos. Artefatos de Entrada:

Artefatos de Saída: - Receitas; - Despesas; - Investimentos.

Freqüência: sempre. Ator: Gestor Financeiro.

Atividade: Planejar Orçamento Propósito: Fazer todo o planejamento orçamentário da fábrica visando a manutenção do equilíbrio financeiro e garantindo os retornos aos investimentos e as margens do negócio. Passos: - Estabelecer diretrizes de gestão de ativos; - Obtenção de fundos para investimentos em expansão; - Planejamento tributário. Artefatos de Entrada: - Receitas; - Despesas; - Investimentos.

Artefatos de Saída: - Orçamento.

Freqüência: sempre. Ator: Gestor Financeiro.

185

Atividade: Avaliar Comportamento

Propósito: Analisar e medir o comportamento de indicadores da operação. Passos: - Identificar os motivadores de melhorias; - Conhecer tendências do Desempenho; Artefatos de Entrada:

Artefatos de Saída: - Indicadores de Desempenho.

Freqüência: ao longo de todo projeto. Ator: Gerente de TI.

Atividade: Promover Ações Propósito: Promover ações gerenciais para a melhoria do desempenho da operação. Passos: - Executar ações gerenciais. Artefatos de Entrada: - Indicadores de Desempenho.

Artefatos de Saída: - Plano de Melhorias; - Relatório de Desempenho.

Freqüência: ao longo do projeto. Ator: Gerente de TI.

Atividade: Avaliar Resultados Propósito: saber quão longe ou perto os valores dos indicadores estão das metas. Passos: - Avaliar o resultado das ações de melhoria na operação. Artefatos de Entrada: - Indicadores de Desempenho; - Plano de Melhorias; - Relatório de Desempenho.

Artefatos de Saída: - Resultados.

Freqüência: ao final de cada projeto. Ator: Gerente de TI.

Figura 4.11 - Conjunto de Atividades do subprocesso P1.SP1.#4

186

Subprocesso P1.SP1.#5: Avaliação de Recursos humanos

Atividade: Efetuar o planejamento

Propósito: Identificar, documentar e designar as funções, responsabilidades e relacionamentos de reporte dentro da fábrica. Passos: - Identificar restrições; - Documentar necessidades de pessoal no contexto de variações da demanda (ou utilização de novas tecnologias) - Avaliar estrutura dos recursos com base em modelos; - Realizar o enquadramento nas práticas de recursos humanos, através da utilização de políticas, manuais e procedimentos; - Executar um manual de práticas de recrutamento e um plano de gerência de pessoal. - Criar um plano de ação visando o curto, o médio e o longo prazo da operação. Artefatos de Entrada: - Restrições; - Necessidades de pessoal; - Interfaces de projetos.

Artefatos de Saída: - Detalhes de suporte; - Plano de gerência de pessoal.

Freqüência: a cada iteração do projeto Ator: Gerente Sênior e de RH

Atividade: Montar a equipe Propósito: Conseguir que os recursos humanos necessários (indivíduos ou grupos) sejam alocados aos projetos, ou seja, certificar que os recursos estejam disponíveis para qualquer requisito dos projetos (dentro do escopo da fábrica). Passos: - Avaliar o documento de plano de ação proposto no planejamento; - Efetuar a negociação para a alocação da equipe de acordo com a solicitação do gerente do projeto, criando uma política de prêmios e incentivos na utilização de recursos disponíveis;

187

- Estudar uma forma de montagem da equipe, seja através do desenvolvimento do pessoal interno ou na contratação externa; - Entender aspectos positivos e negativos de cada uma das possibilidades; - Realizar a tomada de decisão na criação do documento que descreve a ação de pessoal designado; Artefatos de Entrada: - Plano de gerência de pessoal; - Práticas de recrutamento; - Diretório de equipe.

Artefatos de Saída: - Pessoal da equipe designado.

Freqüência: a cada iteração do projeto Ator: Gerente de RH

Atividade: Desenvolver a equipe Propósito: Envolve o aumento das capacidades das partes envolvidas para contribuir individualmente, quanto o aumento da capacidade da equipe para funcionar como um time. Passos: - Avaliar a documentação que descreve os recursos necessários; - Efetuar a comparação da necessidade com o recurso existente; - Elaborar um plano de treinamento; - Monitorar a execução do plano; - Garantir a melhoria da performance e a sua adequação à necessidade do projeto. Artefatos de Entrada: - Plano do projeto; - Relatórios de performance

Artefatos de Saída: - Entrada para a avaliação; - Relatório de melhorias de performance.

Freqüência: a cada evento de necessidade Ator: Gerente de RH e Gerente Sênior

Figura 4.12 - Conjunto de Atividades do subprocesso P1.SP1.#5

188

Subprocesso P1.SP1.#6: Realização de Compliance

Atividade: Planejamento de compliance

Propósito: Decidir como abordar e executar as atividades de compliance de um projeto. Passos: - Análise e reuniões de planejamento Artefatos de Entrada: - Fatores ambientais da empresa; - Ativos de processos organizacionais; - Project charter - Plano de gerenciamento do projeto - Padrões de procedimentos e diretrizes da empresa.

Artefatos de Saída: - Planejamento de compliance

Freqüência: a cada início de projeto Ator: Gerente de projetos e gerente de compliance

Atividade: Realizar auditoria Propósito: Identificar e sanar não-conformidades (desacordos com os padrões da fábrica de software). Passos: - Planejamento de auditoria; - Verificar documentação existente; - Confrontar procedimento escrito versus execução do processo. - Apontar não-conformidades; - Gerar relatório/alimentar repositório - Encaminhar ao Gerente responsável

189

Artefatos de Entrada: - Fatores ambientais da empresa; - Ativos de processos organizacionais; - Project Charter - Padrões de procedimentos e diretrizes da empresa - Planejamento de compliance

Artefatos de Saída: - Relatório de auditoria (detalhado). - Repositório com histórico. - Relatórios de controle de não-conformidade. - Solicitação de mudanças.

Freqüência: durante o projeto Ator: Equipe de compliance, especialistas no assunto e/ou stakeholders.

Figura 4.13 - Conjunto de Atividades do subprocesso P1.SP1.#6

Subprocesso P1.SP1.#7: Monitoramento de Segurança

Atividade: Elaborar Inventário

Propósito: manter relacionado o bem patrimonial da empresa. Passos: - Identificar todo o patrimônio da fábrica; - Relacionar no inventário todo o Bem Patrimoniado (BP) da Fábrica; - Providenciar numeração de patrimônio caso não esteja numerado; Artefatos de Entrada: - Relação de patrimônio; - Inventário

Artefatos de Saída: - Inventário (atualizado)

Freqüência: periodicamente o inventário deve ser checado e atualizado.

190

Ator: Gerente de TI Atividade: Planejar Segurança

Propósito: elaborar o planejamento de a segurança física e ambiental da fábrica, analisando todos os possíveis focos de risco. Passos: - Planejar a segurança física e ambiental, ou seja, instalações e pessoal; - Garantir que o plano pode se adaptar a diferentes situações de quebra de segurança; - Fazer planejamentos para certas constantes: fornecimento de energia, backup; - Assegurar que somente aqueles com responsabilidade apropriada possuem acesso à informação nas redes. Artefatos de Entrada: - Inventário (atualizado); - Documento de respostas de incidentes; - Plano de Contingência; - Plano de Gerenciamento de Continuidade dos Negócios;

Artefatos de Saída: - Plano de Segurança; - Cartilha de Segurança.

Freqüência: uma vez elaborado, o Plano de Segurança deve ser revisto e atualizado periodicamente. Ator: Gerente de TI

Atividade: Criar Equipe e Documento de respostas de incidentes Propósito: O documento de reposta a incidentes determina as "regras de lei" sob procedimentos de emergência. No evento de uma quebra de segurança, os membros da equipe devem estar familiarizados com suas responsabilidades. Passos: - Familiarizar membros da equipe; - Elaborar Documento de respostas de incidentes; - Relacionar todo o pessoal e descrever os cargos, definindo papeis e responsabilidades em segurança. Artefatos de Entrada: - Cartilha de Segurança.

Artefatos de Saída: - Documento de respostas de incidentes.

Freqüência: uma vez elaborado, o Documento de Respostas de Incidentes deve ser revisto e atualizado periodicamente. Ator: Gerente de TI

Atividade: Elaborar plano de Contingência Propósito: elaborar plano para situações emergenciais, identificando os processos vitais da Fábrica e garantir o funcionamento destes. Passos: - Analisar o que deve ser protegido em caso de emergência; - Identificar as operações comerciais que devem ser mantidas em caso de emergência; - Avaliação dos danos financeiros, técnicos, legais e operacionais que podem ocorrer como resultado de uma quebra da segurança; - determinar os recursos que devem ser protegidos primeiro em caso de emergência.

191

Artefatos de Entrada: - Inventário

Artefatos de Saída: - Plano de Contingência - Plano de Gerenciamento de Continuidade dos Negócios

Freqüência: uma vez elaborado, o Plano de Contingência deve ser revisto e atualizado periodicamente. Ator: Gerente de TI

Atividade: Definir Medidas de Segurança Propósito: definir que medidas serão tomadas para garantir a segurança e o funcionamento de processos vitais da Fábrica em situações emergenciais, bem como, garantir que o menor custo seja o resultante de situações desastrosas. Passos: - Contratar uma boa seguradora para que no caso de uma quebra de segurança, o seguro ajudar a cobrir os custos resultantes da perda de dados, interrupção de negócios, despesas, processos judiciais contra a empresa devido à negligência com a segurança; - Aplicações de segurança, bem como, antivírus atualizado e instalado em todos os computadores, detecção de intrusão, filtragem de e-mail e conteúdo da Internet. Artefatos de Entrada: - Plano de Segurança

Artefatos de Saída: - Relatório de Medidas de Segurança; - Contratos firmados com terceiros; - Plano de Segurança (atualizado).

Freqüência: uma vez executada a atividade, deve ser revista e atualizada periodicamente. Ator: Gerente de TI

Figura 4.14 - Conjunto de Atividades do subprocesso P1.SP1.#7

4.5.1.3.2. Sub-processo 2 (SP2): inferir nos recursos (P1.SP2)

4.5.1.3.2.1. Descrição e objetivos

Este subprocesso realiza as atividades de inferência nos indicadores da

fábrica e efetua o armazenamento das lições aprendidas, na linha do tempo, com a

operação.

Objetivo: dirimir dúvidas e mitigar riscos no planejamento estratégico através

da evolução da operação.

192

4.5.1.3.2.2. Papéis envolvidos

Papéis Responsabilidades

Gerente Sênior da Fábrica

de Projetos

1. Apoiar a melhoria contínua do processo da

operação através da realimentação;

2. Decidir pela manutenção do processo ou

modificações sugeridas pelo estudo das

operações estratégicas.

3. Deve gerenciar o processo, através da

verificação dos critérios de entrada e

objetivos a serem alcançados;

4. Atuar como facilitador das reuniões;

5. Coordenar a estruturação da solução, ou

preparar a sua aprovação;

6. Avalizar o plano de trabalho ou workflow;

7. Realizar acompanhamento dos planos de

trabalho, com a programação de reuniões de

follow-up;

SEPG (Software

Engineering Group)

1. Deve prover a montagem do pacote de

inspeção;

2. Estruturar a apresentação da solicitação de

mudança;

3. Redigir o documento de resumo gerencial;

193

SPA (Software Process

Authority)

1. Controlar o fluxo de processos para garantir

o melhor aproveitamento dos recursos.

2. Programar as reuniões;

3. Entender como realizar a revisão da

estrutura;

4. Encontrar e registrar possíveis soluções para

as solicitações, criando planos de trabalho;

5. Redigir o documento de resumo gerencial;

Gerente de operações

estratégicas

1. Realizar o estudo de viabilidade técnica das

sugestões do projeto ou mudanças

características no mercado concorrente;

2. Acompanhar a prospecção dos dados pela

sua equipe multidisciplinar, garantindo o

processo de aprendizagem organizacional;

3. Controlar e divulgar o conhecimento

adquirido durante o projeto ou operação.

Figura 4.15 – Quadro de papéis do subprocesso P1.SP2

4.5.1.3.2.3. Detalhamento do sub-processo

Os conjuntos de atividades do subprocesso P1.SP2 são: avaliação da

operação - workflow (P1.SP2.#1), realização de revisão conjunta com o processo de

gestão estratégica (P1.SP2.#2) e registrar lições aprendidas (P1.SP2.#3), os quais

serão detalhados abaixo.

194

Figura 4.16 – Quadro de detalhamento do subprocesso P1.SP2

Subprocesso P1.SP2.#1: Avaliação da operação - workflow

Atividade: Avaliar pontos de controle

Propósito: Comparar os resultados dos processos com as métricas estabelecidas garantindo um Workflow ótimo.

195

Passos: - Analisar resultados - Alimentar a base de lições aprendidas - Gerar relatório Artefatos de Entrada: - Workflow - Pontos de controle - Marcos - Cronograma - Lista de recursos

Artefatos de Saída: - Lições aprendidas - Relatório de desempenho

Freqüência: durante todo o projeto Ator: SPA

Atividade: Revisar Workflow (opcional) Propósito: Caso seja necessário, fazer alterações no Workflow para adequá-lo a realidade atual e garantir um Workflow ótimo. Passos: - Reavaliar o fluxo das atividades - Revisar Workflow Artefatos de Entrada: - Relatórios de desempenho

Artefatos de Saída: - Workflow (revisado)

Freqüência: durante todo o projeto Ator: SPA

Figura 4.17 - Conjunto de Atividades do subprocesso P1.SP2.#1

Subprocesso P1.SP2.#2: Realização de Revisão Conjunta

Atividade: Analisar solicitação

Propósito: Preparar o pacote de inspeção, através do entendimento e compreensão da solicitação de a lteração na estrutura. Passos: - Coletar o material a ser analisado;

196

- Selecionar o time e agendar a reunião; - Verificar os critérios de entrada; - Definir os objetivos (montar o pacote); - Estabelecer os critérios de saída; - Explicar o propósito e o conteúdo da alteração; Artefatos de Entrada: - Solicitação de Mudança (workflow); - Estrutura do Workflow; - Documento de Suporte.

Artefatos de Saída: - Padrões e Guidelines (externos); - Pacote de Inspeção; - Dados da preparação.

Freqüência: a cada iteração de revisão Ator: SEPG e SPA

Atividade: Realizar Revisão Propósito: Efetuar a revisão da estrutura coletivamente com a utilização de melhores práticas e brainstorming. Além disso, avaliar os impactos de modo a propor modificações, quando necessário; e criar um log com as alterações. Passos: - Compreender os itens e as características do problema; - Evidenciar dados do log de preparação; - Facilitar o ambiente para moderar a reunião; - Executar uma discussão com utilização dos padrões e brainstorming; - Avaliar a necessidade de mudança; - Registrar os itens; - Criar o log de alterações. Artefatos de Entrada: - Padrões e Guidelines (externos); - Pacote de Inspeção; - Dados da preparação.

Artefatos de Saída: - Log das alterações

Freqüência: a cada iteração de revisão Ator: SEPG / SPA / Gerente de operações estratégicas

Atividade: Endereçar itens Propósito: Atualizar o documento, criar um plano de trabalho para a realização da mudança e elaborar um resumo gerencial para o acompanhamento dos endereçamentos dos itens verificados. Passos: - Esboçar a atualização da estrutura do workflow; - Endereçar os itens validados; - Identificar um plano de ação com os responsáveis; - Criar o plano de trabalho; - Montar o resumo gerencial; - Efetuar a validação (concordância) com os critérios de saída; - Atualizar o documento. Artefatos de Entrada: - Log das alterações.

Artefatos de Saída: - Plano de trabalho; - Estrutura do workflow (atualizada); - Resumo gerencial.

Freqüência: a cada iteração de revisão Ator: SEPG e Gerente de operações estratégicas

Figura 4.18 - Conjunto de Atividades do subprocesso P1.SP2.#2

197

Subprocesso P1.SP2.#3: Registrar lições aprendidas

Atividade: Avaliar o processo

Propósito: Caracterizar o processo corrente e criar uma estrutura para o endereçamento da lição aprendida; Passos: - Receber o(s) documento(s) a ser(em) avaliado(s); - Analisar o documento em termos comparativos a base; - Escolher o modelo de processo, os métodos e as ferramentas de apoio apropriadas; - Criar o plano estratégico para avaliação; Artefatos de Entrada: - Relatório de Compliance; - Relatório de RH; - Relatório de Segurança; - Relatório de Práticas e Recursos; - Base de Experiência.

Artefatos de Saída: - Plano Estratégico.

Freqüência: a cada iteração do registro Ator: Gerente Sênior da fábrica de projetos

Atividade: Executar a definição Propósito: Criar um relatório de práticas e recursos com a categorização do objeto, tipo de lição aprendida, categoria do problema ou solução contextualizada. Passos: - Identificar o tipo de lição aprendida (positiva ou negativa); - Estudar a categoria do processo; - Avaliar a solução contextualizada internamente. Artefatos de Entrada: - Plano Estratégico.

Artefatos de Saída: - Relatório de Práticas e Recursos (atualizado).

Freqüência: a cada iteração do registro Ator: Gerente de operações estratégicas

Atividade: Revisar os dados Propósito: Analisar os dados para avaliar as práticas correntes, determinar

198

problemas, registrar descobertas e recomendar melhorias. Passos: - Comparar com as melhores práticas; - Determinar problemas; - Registrar descobertas; - Registrar no relatório de práticas. Artefatos de Entrada: - Relatório de Práticas e Recursos (atualizado).

Artefatos de Saída: - Relatório dos aspectos estratégicos;

Freqüência: a cada iteração do registro Ator: Gerente de operações estratégicas

Atividade: Empacotar a experiência Propósito: Armazenar o conhecimento em uma base de experiência no formato de lições aprendidas, ou seja, modelos refinados e atualizados para o reuso em futuros projetos ou inovações. Apoiar a melhoria contínua através da realimentação. Passos: - Avaliar o relatório do estudo da experiência; - Armazenar o escopo do problema e a solução; - Alimentar a base de experiência; - Criar o registro de revisão; Artefatos de Entrada: - Relatório dos aspectos estratégicos;

Artefatos de Saída: - Base de experiência; - Registro de revisão.

Freqüência: a cada solicitação de algum processo da GE Ator: Gerente Sênior e de Operações Estratégicas

Figura 4.19 - Conjunto de Atividades do subprocesso P1.SP2.#3

4.5.2. Processo de garantia da qualidade (P2)

4.5.2.1. Objetivos

O processo de qualidade está subdividido em: Processo de “Planejamento da

Qualidade do projeto e da iteração”; “Garantir qualidade do projeto” e “Registrar

Lições Aprendidas”. Os subprocessos possuem a finalidade de prover evidências

sobre a capacidade do processo em produzir determinado produto, identificando

falhas neste processo e buscando resolvê-las antes que impactem no produto. Além

disso, visa garantir que o software produzido esteja em conformidade com requisitos

funcionais e de desempenhos especificados pela demanda; atenda aos padrões de

199

desenvolvimento documentados; seja o mais isento possível de erros; e atenda às

características implícitas esperadas pelo usuário.

Cada uma das atividades constantes do processo de Gerenciamento da

Qualidade é detalhada em termos de propósitos, passos, artefatos de entrada e de

saída, freqüência de execução da atividade, e atores envolvidos.

Este processo tem por objetivo estruturar os procedimentos de Qualidade de

Software, tanto do produto quanto do processo, alinhado às políticas definidas pela

Gerência de Qualidade da Fábrica de Software, de forma a acompanhar se o

processo de software definido está sendo realmente utilizado e quão aderentes

estão as práticas dos projetos aos processos estabelecidos.

4.5.2.2. Políticas

A Gerência de Qualidade da Fábrica de Software, abaixo define e faz cumprir,

as seguintes políticas que orientam as atividades relacionadas à execução do

Processo de Qualidade de Software.

Descrição das Políticas

• A qualidade de software deverá ser de responsabilidade de todos os

envolvidos direta ou indiretamente com o processo de software da

organização;

• As atividades de qualidade do processo de software compreenderão a

definição do processo, a verificação da utilização do processo definido

e a preocupação com a melhoria do processo utilizado;

• Todo programa alterado/ou desenvolvido deve, necessariamente

possuir uma equipe de processo de engenharia de software (SEPG)

que será a responsável pelo processo, enquanto o Software Quality

200

Assurement (SQA) deve verificar a aderência das práticas de

engenharia de software dos projetos ao processo definido;

• Em todas as demandas serão utilizadas técnicas de SQA para verificar

se o processo definido está sendo seguido, para encontrar defeitos

diretamente no produto, ou para indicar a necessidade de um exame

mais detalhado no mesmo. As principais técnicas utilizadas serão: as

Revisões de Software, que são classificadas como Auditorias,

Inspeções, Walkthroughs, Revisões Técnicas e Revisões Gerenciais.

As Revisões de Software avaliarão o processo de desenvolvimento,

seu gerenciamento e o produto de software.

• Além das Revisões, serão também realizados Testes, os quais

constituirão um dos elementos críticos da garantia de qualidade de

software e representarão a última revisão das especificações de projeto

e código do produto de software.

• Para a melhoria do processo estabelecido, serão utilizadas as

Avaliações (Assessment), que examinarão um processo para

determinar a sua capacidade, por meio da comparação desse processo

em relação a um padrão de melhores práticas.

• Todo processo deverá aderir a definição dos objetivos de qualidade e

de políticas de qualidade para a organização, existindo uma clara

especificação de papéis e da função.

• Em momentos a serem definidos pela SEPG serão realizados

treinamentos para os envolvidos no processo, para a disseminação dos

conceitos de qualidade para a organização;

• O gerente de qualidade deverá estabelecer os controles sobre o custo

das atividades de qualidade nos projetos.

• A equipe de atendimento das demandas deverá sistematizar e

formalizar ações de qualidade do processo de software, executadas

mediante o planejamento da qualidade realizado em paralelo com o

planejamento do projeto. Serão estabelecidas as principais técnicas de

SQA, conforme o padrão IEEE Std. 1028-1997, que são utilizadas

durante as iterações para verificar a qualidade do processo de

software.

201

• O processo de qualidade abordará a operação através de um

tratamento sistemático das não conformidades, facilitando sua

identificação, seu relato aos envolvidos, e a identificação de ações

corretivas e preventivas (quando possível).

• Todos os defeitos descobertos durante a execução do processo de

testes devem ser documentados em um repositório de erros;

• O analista de qualidade deverá possibilitar que as ações de qualidade

estejam alinhadas aos objetivos de qualidade especificados para a

organização. A execução das atividades de SQA será realizada de

acordo com o planejamento da qualidade de software para o projeto e

para a iteração. O planejamento da qualidade, por sua vez, considera

os objetivos de qualidade especificados para a organização, para o

projeto e ainda para a iteração. Isso possibilita que as ações em prol da

qualidade sejam realizadas de forma contínua, estritamente alinhada

aos objetivos estabelecidos, e tendo seu alcance monitorado.

• O ambiente organizacional deverá permitir a utilização de métricas de

processo relacionadas aos objetivos de qualidade para a iteração, para

o projeto e para a organização.

• O ambiente organizacional providenciará a contribuição para as ações

de melhoria do processo de software na FSW. O processo proposto

estabelecerá o registro das lições aprendidas ao longo do processo.

Esta atividade, aliada ao uso sistemático de métricas, deve facilitar a

identificação da aderência de boas práticas de engenharia de software

do projeto em relação ao processo configurado a partir do framework

da fábrica de projetos e serviços operacionais, municiando a

organização e, especialmente, o SEPA (Software Engineering Process

Authority) e o Engenheiro de Processos com as informações

necessárias para propor a instância de processo mais adequada às

necessidades do projeto.

Figura 4.20 – Quadro de políticas do processo de Gestão da Qualidade

202

4.5.2.3. Sub-processos do processo (P2)

4.5.2.3.1. Sub-processo 1 (SP1): qualidade do projeto (P2.SP1)

4.5.2.3.1.1. Descrição e objetivos

Este subprocesso: Planejar Qualidade do Projeto deve ser executado em

paralelo com as atividades de planejamento do próprio projeto. Nesse fluxo, são

definidos os objetivos de qualidade de software para o projeto, com base nos

requisitos do projeto, plano de desenvolvimento e padrões de qualidade da

organização. São estabelecidas as métricas de qualidade associadas a cada

objetivo de qualidade especificado, para que seja possível monitorar se as metas

foram atingidas.

O Engenheiro de qualidade planeja, a partir dos objetivos de qualidade, que

atividades de qualidade serão executadas ao longo do projeto e constrói o

cronograma dessas atividades. Estas informações devem ser registradas no Plano

de Garantia de Qualidade de Software do projeto. Ele também pode orientar

integrantes do projeto a respeito dos padrões de qualidade adotados e das práticas

de engenharia de software aplicáveis.

Além disso, ele deve ser realizado, ao se iniciar uma iteração, o planejamento

da qualidade dela onde são identificados, dentre os objetivos de qualidade do

projeto levantados anteriormente, quais aqueles que serão abordados durante a

iteração. Em seguida, devem ser elencadas as atividades de qualidade de software

a serem realizadas durante a iteração, atualizando-se o Plano de Garantia de

Qualidade.

A partir da segunda iteração, com os dados provenientes do subprocesso:

Garantir a Qualidade, será possível realizar a especificação das ações preventivas

para as não conformidades (reconhecimento da falta de aderência de determinado

203

item sob garantia de qualidade em relação aos padrões de qualidade) identificadas

na iteração anterior, minimizando assim a ocorrência de não conformidades.

Objetivo: planejar a qualidade global do projeto (requerida) e estruturar a

abordagem de qualidade em cada iteração.

4.5.2.3.1.2. Papéis envolvidos

Papéis Responsabilidades

Gerente de Qualidade

1. Administrar a função de qualidade de

software da organização, mantendo os

objetivos organizacionais da qualidade

alinhados aos objetivos de negócios

organizacionais;

Engenheiro de Qualidade

1. Deve ter forte embasamento em engenharia

de software, mormente em modelos,

padrões e técnicas de SQA;

2. Avaliar como os elementos descritos estão

relacionados com o processo de

desenvolvimento de software.

Figura 4.21 – Quadro de papéis do subprocesso P2.SP1

4.5.2.3.1.3. Detalhamento do sub-processo

Os dois conjuntos de atividades do subprocesso P2.SP1 são: Planejar

qualidade do projeto (P2.SP1.#1) e planejar a qualidade na iteração (P2.SP1.#2).

204

Figura 4.22 – Quadro de detalhamento do subprocesso P2.SP1

Subprocesso P2.SP1.#1: Planejar qualidade do projeto

Atividade: Definir objetivos de qualidade do projeto

Propósito: estabelece os objetivos de qualidade de software para o projeto, observando as definições organizacionais para a qualidade e as características específicas do projeto (requisitos legais, padrões do cliente do projeto, normas e padrões de qualidade). Passos: - verificar os padrões organizacionais de qualidade (Políticas, padrões, procedimentos); - identificar requisitos de qualidade do projeto (requisitos do cliente, legislação); - definir os objetivos de qualidade de software do projeto, orientando os projetos quanto às suas necessidades de qualidade de software. Artefatos de Entrada: - Padrões organizacionais de qualidade;

Artefatos de Saída: - Plano de Garantia de Qualidade de Software.

205

- Plano de Desenvolvimento de Software; - Especificação de Requisitos de Software; e FURPS+.

Freqüência: a cada reunião de planejamento do projeto. Ator: Gerente de Qualidade

Atividade: Estabelecer métricas de qualidade para o projeto Propósito: define as métricas utilizadas para permitir a quantificação do grau em que as características estarão presentes em um determinado produto de software. Passos: - Métricas subjetivas e objetivas (padrões e quantificações de padrões no âmbito organizacional); - Métricas diretas e indiretas (revisões, avaliações e pessoas). - Métricas do produto e do processo (pedidos de alterações no software, número de relatórios pendentes, especificações e aderência de requisitos). Artefatos de Entrada: - Plano de garantia de qualidade de software

Artefatos de Saída: - Plano de métricas

Freqüência: a cada reunião de planejamento do projeto. Ator: Gerente de Qualidade

Atividade: Planejar atividades de qualidade para o projeto Propósito: definir uma visão comum de todo o esforço de garantir a qualidade que será executado durante todo o ciclo de desenvolvimento do software. Passos: - propósito do documento; - apresentação do processo de verificação e validação - definir equipe de revisões e auditorias; - definir equipe de teste de software; - avaliar as principais referências de ferramentas, padrões, técnicas e metodologias; - criar uma política de gerenciamento de riscos; - formular estimativas e macro-cronograma. Artefatos de Entrada: - Plano de desenvolvimento de software

Artefatos de Saída: - Plano de garantia de qualidade do software

Freqüência: a cada reunião de planejamento do projeto. Ator: Engenheiro de Qualidade

Atividade: Orientar projeto sobre padrões de qualidade Propósito: Manter o projeto adequado aos padrões de qualidade da organização Passos: - avaliar os padrões organizacionais sedimentados em normas de qualidade; - criar uma visão comum das atividades de qualidade para o projeto. Artefatos de Entrada: - Padrões organizacionais de qualidade

Artefatos de Saída: - Plano de garantia de qualidade de software

206

Freqüência: a cada reunião de planejamento do projeto. Ator: Engenheiro de Qualidade

Figura 4.23 - Conjunto de Atividades do subprocesso P2.SP1.#1

Subprocesso P2.SP1.#2: Planejar qualidade da iteração

Atividade: Identificar objetivos de qualidade da iteração

Propósito: identificar os objetivos de qualidade, definidos anteriormente, no escopo da iteração atual do projeto. Passos: - definir equipe de revisões e auditorias, bem como a sua abordagem; - definir equipe de testes de software; - manter as principais documentações a serem empregadas; - referenciar ferramentas, métricas, práticas e padrões; - gerenciar o testware; - avaliar riscos Artefatos de Entrada: - Plano de garantia de qualidade de software

Artefatos de Saída: - Plano de Garantia de Qualidade de Software.

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade

Atividade: Planejar atividades de qualidade da iteração Propósito: definir uma visão comum de todo o esforço de garantir a qualidade que será executado na iteração. Passos: - propósito do documento; - apresentação do processo de verificação e validação - definir equipe de revisões e auditorias; - definir equipe de teste de software; - avaliar as principais referências de ferramentas, padrões, técnicas e metodologias; - criar uma política de gerenciamento de riscos; - formular estimativas e cronograma. Artefatos de Entrada: - Plano de garantia de qualidade de software

Artefatos de Saída: - Plano de Garantia de Qualidade de Software.

207

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade

Atividade: Identificar ações preventivas Propósito: Definir e estruturar o processo de verificação, estabelecendo a visão da equipe de verificação, uniformizando os conhecimentos, experiências e expectativas dos diversos grupos. Passos: - Identificar detalhes do ciclo do processo de verificação; - definir as principais atividades de verificação (auditorias, inspeções, avaliações); - explicitar papéis e responsabilidades; - manter os principais documentos a serem empregados e gerados; - montar os relatórios a serem produzidos e criar um cronograma das etapas de verificação. Artefatos de Entrada: - Relatório de avaliação de qualidade

Artefatos de Saída: - Plano de garantia de qualidade do software

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade

Figura 4.24 - Conjunto de Atividades do subprocesso P2.SP1.#2

4.5.2.3.2. Subprocesso 2 (SP2): garantir a qualidade (P2.SP2)

4.5.2.3.2.1. Descrição e objetivos

Este subprocesso deve ser realizado através de revisões de atividades do

processo, por meio da avaliação de artefatos. As revisões e avaliações são

conduzidas a partir do padrão IEEE 1028. O Relatório de avaliação da qualidade do

projeto registra as informações sobre as revisões e avaliações realizadas, os itens

avaliados, as não conformidades identificadas, o grau de severidade a elas

associadas, o responsável pela resolução da não conformidade, assim como os

prazos para que isso seja executado. Esse relatório formaliza o Registro de Revisão

do processo de construção. As não conformidades identificadas e reportadas devem

ser acompanhadas pelo Engenheiro de Qualidade até seu desfecho. Ainda são

208

coletadas métricas de qualidade do projeto, e são fornecidas orientações (quando

necessário) sobre padrões e práticas de engenharia de software.

Objetivo: Monitorar e garantir os requisitos da qualidade definidos

anteriormente para o projeto.

4.5.2.3.2.2. Papéis envolvidos

Papéis Responsabilidades

Gerente de Qualidade

1. Avaliar se os projetos estão alcançando os

objetivos de qualidade;

2. Deve possuir experiência com gestão de

processos e pessoas, conhecimento da

organização e dos modelos de qualidade.

Engenheiro de Qualidade

1. Deve ter forte embasamento em engenharia

de software, mormente em modelos, padrões

e técnicas de SQA;

2. Avaliar como os elementos descritos estão

relacionados com o processo de

desenvolvimento de software.

3. Garantir a qualidade dos artefatos realizados

nos processos de forma a manter o

alinhamento aos objetivos (monitoramento).

209

SQA (Software Quality

Assurement)

1. Revisar e completar os Planos de testes;

2. Analisar a aplicação dos Planos de Testes

pelos programadores;

3. Aplica plano de testes para homologação nos

componentes produzidos ou alterados.

Analista de Sistemas

1. Deverá analisar, planejar, executar e

acompanhar o envio dos produtos gerados no

processo para as revisões de software;

2. Prepara o conjunto de processos a serem

avaliados através das avaliações de software.

Figura 4.25 – Quadro de papéis do subprocesso P2.SP2

210

4.5.2.3.2.3. Detalhamento do sub-processo

Os dois conjuntos de atividades do subprocesso P2.SP2 são: Garantir a

qualidade na iteração (P2.SP2.#1) e monitorar a qualidade (P2.SP2.#2).

Figura 4.26 – Quadro de detalhamento do subprocesso P2.SP2

211

Subprocesso P2.SP2.#1: Garantir a qualidade na iteração

Atividade: Revisar atividades

Propósito: Implementar o cronograma de atividades mantenedoras do processo de qualidade, as quais foram definidas no plano de qualidade da iteração – verificação; Passos: - lista de documentos revisados; - objetivo de cada documento; - técnicas e atividades executadas; - número de participantes e de reuniões; - tamanho do material inspecionado; - tempo total de realização da inspeção; - lista de defeitos identificados; - sumário de defeitos (por categorias); Artefatos de Entrada: - Plano de garantia de qualidade do software

Artefatos de Saída: - Relatório de avaliação de qualidade

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade / Analista de Sistemas

Atividade: Avaliar artefatos Propósito: Implementar o cronograma de atividades mantenedoras do processo de qualidade, as quais foram definidas no plano de qualidade da iteração – escopo de validação. Passos: - data de execução e escopo do processamento; - condições de processamento; - lista de itens processados; - itens processados (%) - itens reprocessados (%) - tempo de processamento; - lista de itens não processados; - comentários Artefatos de Entrada: - Plano de garantia de qualidade do software

Artefatos de Saída: - Relatório de avaliação de qualidade

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade / Analista de Sistemas

Atividade: Tratar não conformidades

212

Propósito: Efetivar uma política de tratamento de não conformidades identificadas nas atividades anteriores a esta, por um processo de contingência. Passos: - resumo dos principais fatos do processo de validação - resumo dos resultados obtidos; - comparação com resultados esperados; - avaliação crítica do processo; - recomendações para melhorias; Artefatos de Entrada: - Plano de garantia de qualidade de software

Artefatos de Saída: - Relatório de avaliação de qualidade

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade

Atividade: Coletar métricas de qualidade Propósito: efetuar um processo de coleta de medidas que gerem uma massa de dados e possibilitem a realização de inferências nas iterações do projeto, ou em trabalhos futuros da organização. Passos: - Medir determinadas etapas do processo; - Definir os indicadores de cobertura, eficiência dos testes e indicadores de defeitos; Artefatos de Entrada: - Plano de garantia de qualidade de software; - Plano de métricas.

Artefatos de Saída: - Repositório de métricas

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade / Analista de Sistemas

Atividade: Orientar projetos Propósito: Realizar atividades de planejamento de ações que minimizem os problemas identificados nas métricas, ou seja, melhorem a produtividade organizacional, no que tange ao processo e maturidade de construção de software. Passos: - avaliar comportamento dos defeitos; - estudar a presteza na resolução dos defeitos; - estabelecer um processo maturidade organizacional de melhores práticas. Artefatos de Entrada: - Plano de garantia de qualidade

Artefatos de Saída: - Padrões organizacionais de qualidade

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade

Figura 4.27 - Conjunto de Atividades do subprocesso P2.SP2.#1

213

Subprocesso P2.SP2.#2: Monitorar a qualidade

Atividade: Analisar dados sobre atividades de qualidade

Propósito: Realizar o monitoramento das atividades de revisões de software, técnicas e gerenciais. Passos: - estruturar o relatório das avaliações; - realizar inferências na massa de dados (diagramas causa-efeito, paretto). Artefatos de Entrada: - Relatório de avaliação de qualidade; - Plano de garantia de qualidade do software.

Artefatos de Saída: - Relatório de garantia de qualidade

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade

Atividade: Analisar dados sobre métricas de qualidade Propósito: Realizar o monitoramento das métricas das atividades de revisões de software, técnicas e gerenciais. Passos: - estruturar o relatório das avaliações; - realizar inferências na massa de dados (diagramas causa-efeito, paretto); Artefatos de Entrada: - Plano de métricas; - Plano de garantia de qualidade de software

Artefatos de Saída: - Relatório de garantia de qualidade.

Freqüência: a cada iteração do projeto Ator: Engenheiro de Qualidade

Atividade: Avaliar atendimento dos objetivos da qualidade Propósito: Comparar os objetivos da qualidade do planejamento com a execução dos processos de controle da qualidade. Passos: - comparar os dados do plano de garantia com a execução das tarefas. Artefatos de Entrada: - Plano de garantia de qualidade do software

Artefatos de Saída: - Relatório de garantia de qualidade.

Freqüência: a cada iteração do projeto Ator: Gerente de Qualidade

214

Atividade: Avaliar equipe de qualidade Propósito: Estruturar um modelo de avaliação da equipe de desenvolvimento do software para a possível realização de mudanças no escopo do trabalho. Passos: - levantar informações das métricas; - estruturar os defeitos; - categorizar a produtividade de cada equipe; - realizar inferências na massa de dados; - recomendar melhorias futuras; - comentários. Artefatos de Entrada: - Plano de garantia de qualidade do software

Artefatos de Saída: - Relatório de garantia de qualidade.

Freqüência: a cada iteração do projeto Ator: Gerente de Qualidade

Figura 4.28 - Conjunto de Atividades do subprocesso P2.SP2.#2

4.5.2.3.3. Subprocesso 3 (SP3): registrar lições aprendidas

(P2.SP3)

4.5.2.3.3.1. Descrição e objetivos

Este subprocesso deve ser executado ao final de iterações e do projeto, onde

são registradas as lições aprendidas do processo de qualidade. Essas lições

contemplam:

• Identificar tipos de não conformidades mais comuns e como elas

podem ser prevenidas e corrigidas;

• Possibilitar avaliar como determinados tipos de não conformidades

podem ser resolvidos e em que espaço de tempo;

• Ajudar a quantificar a equipe de qualidade adequada por tipo de

projeto, dentre outras informações válidas.

Objetivo: criar uma base conhecimento para inferência no contexto da

qualidade para as lições do projeto.

215

4.5.2.3.3.2. Papéis envolvidos

Papéis Responsabilidades

SQA (Software Quality

Assurance)

1. Registra as ocorrências de erros em

componentes produzidos pela Fábrica, no

repositório de erros, durante o processo de

homologação;

2. Registra as ocorrências de erros

detectados pelo cliente, após a liberação da

demanda pela Fábrica, no repositório de erros.

Engenheiro de Qualidade

1. Avaliar evidências críticas para registro

e gerenciar os dados para aplicações futuras

de boas práticas.

Figura 4.29 – Quadro de papéis do subprocesso P2.SP3

4.5.2.3.3.3. Detalhamento do sub-processo

O conjunto de atividades do subprocesso P2.SP3 é: Registrar lições

aprendidas (P2.SP3.#1), o qual será detalhado abaixo.

216

Figura 4.30 – Quadro de detalhamento do subprocesso P2.SP3.#1

Subprocesso P2.SP3.#1: Registrar lições aprendidas

Atividade: Registrar lições aprendidas

Propósito: Manter um repositório de dados que permita a sedimentação de um ambiente de melhorias no processo de construção de software, dentro do escopo de melhores práticas. Passos: - avaliar o relatório de qualidade do projeto; - manter as principais ações executadas no curso do projeto; - gerenciar os dados para aplicações futuras de boas práticas - aprovação.

217

Artefatos de Entrada: - Relatório de garantia de qualidade

Artefatos de Saída: - Lições aprendidas de qualidade.

Freqüência: a cada reunião de avaliação do projeto (ponto de controle) Ator: Engenheiro da qualidade / SQA

Figura 4.31 - Conjunto de Atividades do subprocesso P2.SP3.#1

4.5.3. Processo de gestão de projetos (P3)

4.5.3.1. Objetivos

No processo de gestão de projetos é efetuado todo o planejamento do

projeto, de forma a obter estimativas e também o planejamento e gerenciamento de

recursos, riscos, comunicação, requisitos, escopo e cronograma. Além dos

planejamentos citados, também é elaborada a Estrutura Analítica do Projeto, que

utiliza como artefatos os planos destes planejamentos, juntamente com o plano de

qualidade.

O Gerenciamento de Escopo do Projeto abrange atividades requeridas para

assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho

necessário, para complementar de forma bem sucedida o projeto. A preocupação

fundamental compreende definir e controlar o que está, ou não, incluído no projeto.

O Gerenciamento de Comunicações tem como finalidade, garantir que todas as

informações desejadas cheguem às pessoas corretas no tempo certo e de uma

maneira economicamente viável. Além de assegurar que o time do projeto trabalhe

de maneira integrada para resolver os problemas do projeto.

O Gerenciamento de Recursos determina as quantidades, disponibilidade e

período de utilização dos recursos humanos e materiais ao longo do projeto.

O Gerenciamento de Riscos trata da realização de análise, respostas,

monitoramento e controle e planejamento do gerenciamento de riscos do projeto.

218

O Gerenciamento de Requisitos tem como principal finalidade, identificar os

requisitos não funcionais e não técnicos do projeto a fim de evidenciar,

principalmente, as necessidades para a execução do projeto, além de identificar

inconsistências entre estes requisitos e o plano do projeto.

O processo abrange os requisitos abaixo relacionados, entre outros:

- Funcionalidades esperadas para o software;

- Onde o software vai ser usado;

- Por quem vai ser usado;

- Restrições de uso do software;

- Legislação que o software deve seguir;

- Desenho da arquitetura preliminar do software;

- Normas internacionais ou outras que deve seguir;

- Requisitos que o software deve atender em termos de desempenho, estética,

usabilidade, facilidade de manutenção, tecnologia, hardware, etc.

- Requisitos não técnicos do projeto, como prazo, custo, recursos, e outras

restrições.

Para a realização desse processo, as seguintes subdivisões deverão ser

executadas:

P3.SP1 – Formalizar Projeto

P3.SP2 – Realizar Planejamento do Projeto

P3.SP3 – Finalizar Demanda

219

4.5.3.2. Políticas

A Gerência de Gestão de Projetos da Fábrica de Projetos de Software,

abaixo define e faz cumprir, as seguintes políticas que orientam as atividades

relacionadas à execução do Processo de Gestão de Projetos de Software.

Descrição das Políticas

• Deve conter na Especificação do Projeto todas as características do projeto

já elaborado pelo cliente (Gerente Externo).

• Não é permitido que o Project Charter sofra alterações após aprovação do

cliente;

• A formalização do projeto somente poderá ser realizada após a aprovação

do Project Charter;

• O gerenciamento de escopo deve definir e controlar os trabalhos a serem

realizados pelo projeto de modo a garantir que o produto, ou serviço,

desejado seja obtido através da menor quantidade de trabalho possível,

sem abandonar nenhuma premissa estabelecida no objetivo do projeto;

• Características ou detalhes que não constam na declaração de escopo,

devem ser automaticamente excluídas.

• Após a homologação do project charter pelo cliente, a especificação deverá

ter seu escopo detalhado para a elaboração do Planejamento de

Gerenciamento de Recursos;

• A equipe designada para o detalhamento deverá suprir este processo com a

declaração do escopo (justificativa, produto e sub-produto do projeto),

restrições (definidas pelas cláusulas contratuais das SLA´s), premissas e

informações históricas;

• Deverá gerar os seguintes produtos:

o Definição dos recursos necessários às atividades

o Estrutura analítica dos recursos

o Calendário de recursos e suas atualizações

o Mudanças solicitadas.

220

• Todas as saídas dos processos de outras áreas de conhecimento deverão

ser revisadas quanto a possíveis restrições de recursos.

• Deverá haver um repositório com todo histórico do gerenciamento de

recursos para avaliação, correção e melhoria dos processos desta e de

outras áreas de conhecimento.

• Para as definições das datas prováveis de início e fim das atividades deve

ser utilizado o método de caminho crítico.

• Para redução máxima da duração total do projeto, técnicas de caminho

rápido deverão ser utilizadas para realização de atividades em paralelo.

• Simulações deverão ser feitas e estudadas utilizando a técnica de Monte

Carlo para vários grupos de premissas definidas pela equipe envolvida no

projeto.

• Recursos escassos deverão ser alocados prioritariamente para atividades

do caminho crítico.

• O cronograma geral deve ser aprovado pelos stakeholders do projeto.

• Após a homologação do project charter pelo cliente, a especificação deverá

ter seu escopo detalhado para a elaboração da EAP;

• A equipe designada para o detalhamento deverá suprir este processo com a

declaração do escopo (justificativa, produto e sub-produto do projeto),

restrições (definidas pelas cláusulas contratuais das SLA´s), premissas e

informações históricas;

• Deverá gerar os seguinte produtos:

o Estrutura Analítica do projeto;

o Atualizações na declaração do escopo;

• Todas as saídas dos processos de outras áreas de conhecimento deverão

ser revistas quanto a possíveis impactos no detalhamento do escopo.

• O gerente de projetos deverá avaliar a possibilidade de reutilizar a EAP de

um projeto anterior como modelo;

• Deverão ser utilizados modelos de EAP (templates) e ferramenta de

decomposição a fim de prestar suporte as atividades de planejamento do

projeto.

• Todas as EAP’s deverão ser armazenadas no dicionário de EAP´s.

• O escopo original definido e o baseline integrado devem ser mantidos por

221

contínua gerência de mudanças no baseline mesmo pela rejeição de novas

mudanças ou por aprovação de mudanças e a incorporação delas em um

baseline revisado.

• Mudanças em uma área de conhecimento devem passar por uma análise

em todas as outras áreas.

• Os processo de Gerenciamento das Comunicações deve, obrigatoriamente,

interagir entre si e com os processos das demais áreas de conhecimento.

• Após a homologação do project charter pelo cliente, a especificação deverá

ter seu escopo detalhado para a elaboração do Planejamento de

Gerenciamento de Riscos;

• Devem ser consideradas lições aprendidas e base de conhecimento dos

stakeholders, fatores ambientais e externos como política econômica e

questões políticas.

• A equipe designada para o detalhamento deverá suprir este processo com a

declaração do escopo (justificativa, produto e sub-produto do projeto),

restrições (definidas pelas cláusulas contratuais das SLA´s), premissas e

informações históricas;

• Deverá gerar os seguinte produtos:

o Planejamento do Gerenciamento de Riscos;

o Identificação de Riscos:

o Análise Qualitativa de Riscos:

o Análise Quantitativa de Riscos:

o Planejamento de Respostas a Riscos

o Monitoramento e Controle de Riscos

• Todas as saídas dos processos de outras áreas de conhecimento deverão

ser revistas quanto a identificação de possíveis riscos.

• Deverá haver um repositório com todo histórico do gerenciamento de riscos

para avaliação, correção e melhoria dos processos desta e de outras áreas

de conhecimento.

• Após serem descritas as regras de negócios e homologado do Project

charter pelo cliente, o projeto deve ser analisado pelo Gerente do Projeto e

equipe SEPG para identificação dos requisitos e as necessidades dos

envolvidos;

222

• A cada atividade executada, o documento de requisitos deve ser atualizado;

• A reunião de aceitação projeto, somente poderá ser realizada, após uma

análise detalhada do contrato e produto entregue, sendo essa de

responsabilidade do Gerente de projetos.

• Após o aceite e encerramento de contrato, o projeto deve ser finalizado

internamente em reunião com os membros da equipe.

• Todos artefatos gerados durante as fases do projeto devem ser arquivados.

Figura 4.32 – Quadro de políticas do processo de Gestão de projetos

4.5.3.3. Subprocessos do processo (P3)

4.5.3.3.1. Subprocesso 1 (SP1): formalizar o projeto (P3.SP1)

4.5.3.3.1.1. Descrição e objetivos

Este processo tem como principais finalidades obter uma visão geral sobre o

projeto, identificar o gerente de projeto, obter o comprometimento da organização

(Gerente Externo) e Gerência Sênior e gerar artefatos para o início das fases de

Gerenciamento de Projetos e Especificação de Projetos.

4.5.3.3.1.2. Papéis envolvidos

Papéis Responsabilidades

Cliente (Gerente

externo)

1. Elaborar/Atualizar Especificação do Projeto

2. Avaliar Project Charter

3. Aprovar Project Charter

Gerente Sênior da

fábrica de projetos

1. Analisar o Especificação do Projeto, a fim de

identificar de constatar que o mesmo possui todas

as informações relevantes para a formalização do

projeto.

223

2. Elaborar Project Charter

3. Obter aprovação do Project charter

4. Identificar Gerente de Projetos

Figura 4.33 – Quadro de papéis do subprocesso P3.SP1

4.5.3.3.1.3. Detalhamento do sub-processo

A atividade do subprocesso P3.SP1 é a elaboraçao do Project Charter (P3.SP1.#1) .

Figura 4.34 – Quadro de detalhamento do subprocesso P3.SP1

224

Subprocesso P3.SP1.#1: Elaborar Project Charter

Atividade: Avaliar Especificação do Projeto

Propósito: Certificar se a especificação do projeto possui todas as informações necessárias para a criação do Project Charter. Passos: - Verificar se a Especificação do Projeto descreve uma visão geral das metas e objetivos, resultados práticos do projeto, o trabalho ou necessidade de negócio do projeto, estimativas de recursos e custos; - Solicitar alterações da Especificação do Projeto; - Analisar a viabilidade do projeto; - Transcrever informações da Especificação do Projeto para a Project Charter; - Obter aprovação do Project Charter juntamente com o Gerente Externo. Artefatos de Entrada: - Descrição do Produto - Especificação do Especificação do Projeto - Proposta Aprovada

Artefatos de Saída: - Solicitação de alteração da Especificação do Especificação do Projeto. - Project Charter - Premissas - Restrições - Documento de Formalização do Projeto - Identificação do Gerente de Projetos

Freqüência: a cada recebimento de Especificação do Projeto Ator: Gerência Sênior

225

Atividade: Elaborar Project Charter Propósito: Identificar todas as informações necessárias para a Formalização do Projeto, bem como o aceite do Gerente Externo. Passos: - Identificar o objetivo, metas e resultados práticos - Identificar as necessidades básicas do trabalho a ser realizado; - Descrever o produto do projeto; - Elaborar um cronograma básico do projeto; - Obter uma estimativa inicial de custo; - Identificar necessidades iniciais de recursos; - Obter aprovação do Project Charter do Gerente de Projeto. Artefatos de Entrada: - Projeto Contratado - Descrição do Produto - Informações histórias

Artefatos de Saída: - Project Charter - Premissas - Restrições - Identificação do Gerente de Projetos - Documento de Formalização do Projeto

Freqüência: todo início de projeto Ator: Gerência Sênior

Figura 4.35 - Conjunto de Atividades do subprocesso P3.SP1.#1

4.5.3.3.2. Subprocesso 2 (SP2): realizar o planejamento do projeto

(P3.SP2)

4.5.3.3.2.1. Descrição e objetivos

Este processo tem como principais finalidades realizar o planejamento da

execução do projeto através das melhores práticas do modelo PMBOK e elaborar a

estrutura analítica da demanda como forma de identificar e orientar a equipe na

execução.

226

4.5.3.3.2.2. Papéis envolvidos

Papéis Responsabilidades

Cliente (Gerente

externo)

1. Elaborar/Atualizar Especificação do Projeto

2. Avaliar Project Charter

3. Aprovar Project Charter

Gerente Sênior da

fábrica de projetos

1. Analisar o Especificação do Projeto, a fim de

identificar de constatar que o mesmo possui

todas as informações relevantes para a

formalização do projeto.

Gerente de Projetos

1. Elaborar Projet Charter;

2. Obter aprovação do Project charter;

3. Identificar Gerente de Projetos;

4. Deverá designar o Gerente da equipe de

Gerenciamento de Recursos e acompanhar

as fases de tomada de decisão;

5. Deverá efetuar o detalhamento do escopo

com a subdivisão dos principais subprodutos

(decomposição); Identificar os principais

subprodutos do projeto; decidir se as

estimativas de custo e duração podem ser

estabelecidas nos níveis de detalhe;

6. Executar o inclusão da EAP no repositório de

modelos;

7. Melhorar a precisão das estimativas de custo,

tempo e recursos; definir um baseline para

medir e controlar o desempenho; Facilitar a

atribuição clara de responsabilidades;

8. Deverá designar o Gerente da equipe de

Gerenciamento de Recursos e acompanhar

as fases de tomada de decisão;

227

9. Executar a inclusão da EAR (Estrutura

Analítica de Recursos) no repositório de

modelos;

10. Elaborar Planejamento das Comunicações;

11. Distribuir informações;

12. Acompanhar desempenho ou performance do

projeto;

13. Efetuar encerramento administrativo;

14. Analisar o Project Charter aprovado pelo

cliente e as regras de negócio, a fim de

identificar todos os requisitos necessários

para o projeto;

15. Elaborar o Documento de Requisitos;

16. Reunir em documento as solicitações dos

envolvidos no projeto;

17. Verificar inconsistências, re-avaliando todos

os artefatos gerados;

18. Emitir “Solicitação de Mudança”, quando

necessário;

19. Usar os dados fornecidos pela equipe de

analistas seniores, pelo repositório de dados

de projeto e ferramentas de análise

matemática para elaboração do cronograma;

20. Deverá designar o Gerente da equipe de

Gerenciamento de Riscos e acompanhar as

fases de tomada de decisão;

21. Executar o inclusão do Planejamento de

Gerenciamento de Riscos no repositório de

modelos.

Gerente de Recursos

Humanos

1. Deverá prover subsídios para tomada de

decisões por parte do Gerente de Projeto no

que tange ao material humano

228

2. Deverá prover material humano devidamente

treinado e qualificado para adequação ao

projeto e cumprimento do cronograma

Gerente de

Planejamento de

Recursos

1. Deverá realizar reuniões para desenvolver o

gerenciamento de recursos

2. Sua atuação é em conjunto com o Gerente

do Projeto visando adequação ao orçamento

negociado.

3. Definir estimativas de recursos; definir um

baseline para medir e controlar o desempenho;

facilitar a atribuição clara de responsabilidades.

SEPG

1. Participar ativamente das reuniões ou

workshop’s realizados pelo Gerente do Projeto, a

fim de identificar todos os requisitos não funcionais

e não técnicos do projeto.

Analistas Seniores 1. Fornecer know-how para estimativa da

duração das atividades.

Gerente de

Planejamento de

Riscos

1. Deverá realizar reuniões para desenvolver o

plano de gerenciamento de riscos.

2. Deverá desenvolver os elementos de custo de

riscos e as atividades dos cronogramas de riscos

3. Deverá desenvolver os elementos de custo de

riscos e as atividades dos cronogramas de riscos

4. Melhorar a precisão das estimativas de custo,

tempo e recursos; definir um baseline para medir e

controlar o desempenho; facilitar a atribuição clara

de responsabilidades

Figura 4.36 – Quadro de papéis do subprocesso P3.SP2

229

4.5.3.3.2.3. Detalhamento do sub-processo

As duas atividades do subprocesso P3.SP2 são: Planejar e Gerenciar o

projeto (P3.SP2.#1) e Elaborar a Estrutura Analítica do Projeto (P3.SP2.#2).

Figura 4.37 – Quadro de detalhamento do subprocesso P3.SP2

230

Subprocesso P3.SP2.#1: Planejar e Gerenciar o projeto

Atividade: Elaborar Planejamento de Escopo Propósito: Desenvolver uma declaração de escopo que será utilizada como base para futuras decisões do projeto, incluindo, em particular, os critérios que avaliarão se o projeto, ou fase dele, foi implementado com sucesso. Determinando os limites do trabalho no projeto. Passos: - Analisar os artefatos de entrada - Identificar e Descrever: - titulo do pojeto - nome do gerente de projetos e suas responsabilidades e autoridades - nome da pessoa responsável pela elaboração do documento - nome do patrocinador - nome dos integrantes da equipe do projeto - descrição do projeto - objetivo do projeto - justificativa do projeto - produto do projeto - expectativa do cliente/patrocinador - fatores de sucesso do projeto - restrições, premissas - exclusões específicas (aquilo que não será abordado pelo projeto) - Definir principais atividades e estratégias do projeto

231

- Definir principais entregas do projeto - Elaborar orçamento básico do projeto - Elaborar plano de entregas e marcos do projeto - Criar registro de alterações no documento - Obter aprovação de todos os envolvidos Artefatos de Entrada: - Project Charter - Descrição do produto - Restrições - Premissas

Artefatos de Saída: - Declaração do escopo - Plano de Gerenciamento de escopo

Freqüência: a cada início de projeto Ator: Gerente de Projetos

Atividade: Definir Escopo Propósito: Desenvolver uma declaração de escopo que será utilizada como base para futuras decisões do projeto, incluindo, em particular, os critérios que avaliarão se o projeto, ou fase dele, foi implementado com sucesso. Determinando os limites do trabalho no projeto. Passos: - Identificar os principais subprodutos do projeto, - Decidir se as estimativas de custo e duração podem ser adequadamente estabelecidas para cada subproduto. - Identificar elementos tangíveis e verificáveis para os subprodutos Artefatos de Entrada: - Declaração de Escopo - Restrições - Premissas - Informações históricas

Artefatos de Saída: - Alterações na Declaração do escopo - Estrutura Analítica do Projeto (EAP ou WBS)

Freqüência: a cada início de projeto Ator: Gerente de Projetos

Atividade: Verificar Escopo Propósito: Processo formal de aprovação do escopo pelos envolvidos. Requer uma revisão dos produtos do trabalho e dos resultados de modo a garantir que tudo foi completado satisfatoriamente. Esse processo ocorre durante o controle do projeto. Passos: - Revisar produtos e resultados do trabalho - Formalizar aceite do escopo pelas partes envolvidas Artefatos de Entrada: - Resultado do trabalho - Documentação do produto - WBS - Declaração do escopo - Plano do projeto

Artefatos de Saída: - Aceite formal

Freqüência: ao termino do projeto Ator: Gerente de Projetos

Atividade: Controlar Mudanças de Escopo Propósito: Avaliar fatores que criam mudanças de escopo, de modo a garantir que essas mudanças não sejam prejudiciais. Passos:

232

- Analisar Requisição de mudança - Analisar WBS - Analisar impactos - Avaliar mudança Artefatos de Entrada: - WBS - Requisições de mudanças - Plano de gerenciamento de escopo

Artefatos de Saída: - Mudanças do escopo - Ações corretivas - Baseline ajustado

Freqüência: a cada início de projeto Ator: Gerente de Projetos

Atividade: Analisar o projeto Propósito: Analisar o projeto formalizado identificando os requisitos Passos: - Identificar os principais requisitos não funcionais e não técnicos do projeto Artefatos de Entrada: - Regras de negócios; - Project Charter; - Solicitações dos envolvidos.

Artefatos de Saída: - Documento de Requisitos; - Solicitações dos Envolvidos.

Freqüência: a cada início de projeto Ator: Gerente de Projeto e SEPG

Atividade: Identificar Necessidades dos Envolvidos

233

Propósito: Analisar as informações dos envolvidos no projeto a fim de compreender quais são suas reais necessidades. Passos: - identificar os envolvidos no projeto; - avaliar as necessidades. Artefatos de Entrada: - Solicitações dos Envolvidos; - Documento de Requisitos.

Artefatos de Saída: - Glossário; - Solicitações dos envolvidos (revisada); - Especificações Suplementares; - Documento de Requisitos.

Freqüência: a cada início de projeto Ator: Gerente de Projeto e SEPG

Atividade: Identificar inconsistências Propósito: Garantir que todos os requisitos necessários para o início do projeto foram encontrados, ou alterá-los se necessário. Passos: - Revisar todos os artefatos gerados nas atividades “analisar o projeto” e “identificar necessidades dos envolvidos”. - Emitir “solicitação de mudança” caso haja novos requisitos. Artefatos de Entrada: - Glossário; - Solicitações dos envolvidos (revisada); - Especificações Suplementares; - Documento de Requisitos.

Artefatos de Saída: - Documento de Revisão; - Solicitação de Mudança; - Documento de Requisitos (revisado).

Freqüência: a cada início de projeto Ator: Gerente de Projeto

Atividade: Gerenciar Mudanças nos Requisitos Propósito: Avaliar as solicitações de mudança nos requisitos pré-definidos no processo. Passos: - avaliar o impacto de mudanças de escopo no prazo, custo e na qualidade do projeto; - acompanhar a implantação das mudanças nos documentos que definem os requisitos a serem cumpridos; - emitir solicitações de ações corretivas caso haja requisitos faltantes, sobrando ou errados. Artefatos de Entrada: - Documento de Revisão; - Solicitação de Mudança.

Artefatos de Saída: - Solicitação de Mudança (revisada).

Freqüência: durante todo o projeto Ator: Gerente de Projeto

234

Atividade: Elaborar Plano de Gerenciamento de Riscos

Propósito: Identificar, analisar e planejar riscos. Passos: - Identificar Riscos - Quantificar Riscos - Qualificar Riscos - Analisar impacto - Elaborar Plano de Respostas a Riscos - Elaborar Plano de Gerenciamento de Riscos - Elaborar Plano de Mudança de Gerenciamento de Riscos Artefatos de Entrada: - Relatórios de desempenho - Proposta - Project Charter - Informações Históricas

Artefatos de Saída: - Registro de Riscos - Plano de gerenciamento de risco - Ações corretivas recomendadas - Ações preventivas recomendadas - Plano de Respostas a Riscos

Freqüência: durante o projeto Ator: Gerente de planejamento de riscos

235

Atividade: Planejamento das Comunicações Propósito: Determinar a necessidade de informações de cada envolvido no projeto. E determinar também, como ela será encaminhada até o envolvido e qual o nível de detalhe dado a cada informação. Passos: - Definir métodos de comunicação - Identificar tecnologias adequadas - Preparar ambiente técnico e estrutura de armazenamento e distribuição da informação - Elaborar modelos de: atas de reunião e relatórios técnicos - Elaborar cronograma dos eventos de comunicação.

Artefatos de Entrada: - Requisitos de Comunicações - Restrições - Premissas

Artefatos de Saída: - Plano de Gerenciamento das comunicações

Freqüência: No início do projeto e se necessário nos eventos de comunicação. Ator: Gerente de Projetos

Atividade: Distribuição das informações Propósito: Tornar disponível de forma regular, as informações necessárias às partes envolvidas do projeto

236

Passos: - Definir habilidades de comunicação (Escrita e oral, interna e externa, formal e informal) - Descrever como será a sistemática de recuperação de informação - Descrever sistemática de distribuição das informações (reuniões, acesso a bancos de dados, correspondência eletrônica, etc.)

Artefatos de Entrada: - Plano de gerenciamento das comunicações - Plano do projeto

Artefatos de Saída: - Registros do Projeto - Relatórios do Projeto - Apresentações do Projeto

Freqüência: A cada evento de comunicação. Ator: Gerente de Projetos

Atividade: Elaborar Relatórios de Desempenho Propósito: Coletar e disseminar as informações de performance do projeto para que os envolvidos possam avaliar como os recursos estão sendo utilizados para atingir os objetivos do projeto. Passos: - Revisar desempenho - Analisar variações - Analisar tendências - Analisar valor agregado - Distribuir informação Artefatos de Entrada: - Plano de projeto - Resultados do trabalho - Outros registros do projeto

Artefatos de Saída: - Requisições de mudanças - Relatórios de desempenho

Freqüência: quinzenal Ator: Gerente de Projetos

Atividade: Encerramento administrativo Propósito: Verificar e documentar os resultados obtidos em uma determinada fase, ou entrega, visando formalizar o fechamento perante dos envolvidos. Passos: - Analisar resultados obtidos - Analisar sucesso e efetividade do projeto - Arquivar informações do projeto Artefatos de Entrada: - Relatórios de Desempenho - Descrição do produto - Outros registros do projeto

Artefatos de Saída: -Requisições de mudanças - Relatórios de desempenho - Aceitação formal

Freqüência: de acordo com o cronograma do projeto Ator: Gerente de Projetos

237

Atividade: Calcular estimativas de recursos Propósito: Determinar quais os recursos, as quantidades e disponibilidade dos recursos para realização das atividades do projeto. Passos: - Análise, reuniões de departamento e refinamento. Artefatos de Entrada: - Project charter - Proposta

Artefatos de Saída: - EAR (Estrutura Analítica de Recursos) - Alocação de Recursos - Atributos das atividades

Freqüência: Início do projeto e em planos de contingência Ator: Gerente de projetos e gerente de planejamento de recursos

238

Atividade: Avaliar as atividades do projeto. Propósito: Usar o conhecimento da equipe de analistas seniores para estimar a duração de cada atividade. Passos: - Avaliar a lista de atividades; - Comparar com informações históricas; - Estimar a duração de cada atividade. Artefatos de Entrada: - Lista de atividades; - Informações históricas.

Artefatos de Saída: - Estimativa de duração das atividades.

Freqüência: a cada início de projeto Ator: Analistas Seniores

Atividade: Quantificar a demanda de cada atividade Propósito: Definir quantas vezes cada atividade poderá ser executada. Passos: - Verificar nos diagramas a quantidade de vezes que cada atividade é executada. Artefatos de Entrada: - Diagramas de rede do projeto; - Lista de atividades;

Artefatos de Saída: - Estimativa de duração das atividades (rev.)

239

- Estimativa de duração das atividades. Freqüência: a cada início de projeto Ator: Gerente de projetos

Atividade: Definir tempo de reserva Propósito: Acrescentar uma folga aos prazos de cada atividade. Passos: - Definir uma folga no prazo de cada atividade. Artefatos de Entrada: - Estimativa de duração das atividades (rev.).

Artefatos de Saída: - Tempos de reserva; - Estimativa de duração das atividades (rev.).

Freqüência: a cada início de projeto Ator: Gerente de projetos

Atividade: Determinar prazos individuais Propósito: Determinar datas de início e término de cada atividade, sem considerar restrições e premissas. Passos: Usar o método do caminho crítico para definir as datas de início e fim das atividades. Artefatos de Entrada: - Estimativa de duração das atividades (revisado).

Artefatos de Saída: - Análises matemáticas.

Freqüência: a cada início de projeto Ator: Gerente de projetos

Atividade: Analisar as atividades em paralelo Propósito: Verificar quais atividades podem ser feitas em paralelo e quais são críticas.

Passos: Usar o método de caminho rápido para reduzir a duração total do projeto. Artefatos de Entrada: - Estimativa de duração das atividades (rev.); - Análises matemáticas.

Artefatos de Saída: - Cronograma do projeto.

Freqüência: a cada início do projeto Ator: Gerente de projetos

Atividade: Fazer simulações Propósito: Esboçar vários cronogramas com a inclusão de suposições que alterem o prazo das atividades. Passos: - Elaborar várias versões de cronogramas utilizando a técnica de Monte Carlo e variante “E se...” Artefatos de Entrada: - Premissas; - Restrições; - Cronograma do projeto.

Artefatos de Saída: - Plano de gerenciamento do cronograma;

Freqüência: a cada início de projeto Ator: Gerente de projeto

240

Atividade: Nivelar recursos Propósito: Fazer o melhor aproveitamento dos recursos. Passos: - Gerenciar recursos de forma que os recursos escassos sejam disponibilizados primeiro para as atividades do caminho crítico. Artefatos de Entrada: - Cronograma do projeto; - Necessidade de recursos.

Artefatos de Saída: - Atualização da necessidade de recursos.

Freqüência: a cada início de projeto Ator: Gerente de projetos

Figura 4.38 - Conjunto de Atividades do subprocesso P3.SP2.#1

Subprocesso P3.SP2.#2: Elaborar EAP

Atividade: Identificar os principais subprodutos Propósito: :Identificar os principais subprodutos do projeto, incluindo o próprio gerenciamento. Passos: - Definir os principais componentes de cada fase do projeto; - Avaliar e decidir o princípio de organização dentro de cada ramo da EAP Artefatos de Entrada: - Premissas; - Declaração do Escopo; - Restrições.

Artefatos de Saída: - Declaração do Escopo (revisada)

Freqüência: a cada início de projeto Ator: Gerente de projetos

Atividade: Decidir estimativas Propósito: Realizar o processo de tomada de decisão nas estimativas propostas Passos: - estruturar a declaração de escopo para os subprodutos identificados; - avaliar a possibilidade de inferência no nível de detalhe Artefatos de Entrada: - Modelo de EAP (repositório);

Artefatos de Saída: - Declaração de escopo (detalhada)

241

Freqüência: a cada início de projeto Ator: Gerente de projetos

Atividade: Identificar os elementos Propósito: Escrever os elementos constituintes em termos de resultados tangíveis e verificáveis para facilitar a medida do desempenho; Passos: - verificar os elementos constituintes dos subprodutos; - descrevê-los em resultados tangíveis e verificáveis (serviços e produtos – relatório da situação do início ao fim) para facilitar a medida; - definir como o trabalho do projeto deverá ser organizado e realizado; Artefatos de Entrada: - Declaração de Escopo (detalhada);

Artefatos de Saída: - Revisão;

Freqüência: a cada início de projeto Ator: Gerente de Projetos

Atividade: Verificar decomposição Propósito: Avaliar se os itens de níveis mais baixos são necessários e suficientes para a conclusão do item decomposto; Passos: - inferir na massa de dados para saber se os itens de níveis mais baixos são suficiente para a execução do item decomposto, se não, modificá-los; - verificar se todos os itens estão claros e bem definidos; - verificar se cada item pode ser adequadamente cronogramado, orçado, designado para a execução de um papel satisfatoriamente; - realizar a EAP. Artefatos de Entrada: - Revisão

Artefatos de Saída: - Repositório de EAP; - EAP.

Freqüência: a cada início de projeto Ator: Gerente de projetos

Figura 4.39 - Conjunto de Atividades do subprocesso P3.SP2.#2

4.5.3.3.3. Subprocesso 3 (SP3): finalizar a demanda (P3.SP3)

4.5.3.3.3.1. Descrição e objetivos

O processo de Finalização de Demanda tem como finalidade, distribuir

informações que formalizam a conclusão do projeto, tais como aceite do projeto e

encerramentos de contratos.

242

4.5.3.3.3.2. Papéis envolvidos

Papéis Responsabilidades

Gerente de Projetos

1. Revisar contrato

2. Preparar documentação para reunião de Aceitação do

Projeto

3. Conduzir reunião de aceitação

4. Efetuar encerramento da demanda/projeto

Figura 4.40 – Quadro de papéis do subprocesso P3.SP3

4.5.3.3.3.3. Detalhamento do sub-processo

O processo de Finalização de Demanda tem como finalidade distribuir

informações que formalizem a conclusão do projeto, tais como aceite do projeto e

encerramentos de contratos.

243

Figura 4.41 – Quadro de detalhamento do subprocesso P3.SP3

Subprocesso P3.SP3.#1: Encerrar o projeto formalmente

Atividade: Finalizar Demanda

Propósito: Obter o aceite formal da entrega do projeto junto ao cliente e encerrar contrato. Passos: - Analisar contrato - Certificar a entrega do todos os produtos/subprodutos contratados - Programar Reunião de Aceitação de Projeto - Realizar Reunião de Aceitação de Projeto - Obter aceite de finalização do projeto junto ao cliente

244

- Obter aceite de encerramento de contrato junto ao cliente - Realizar reunião de encerramento com os membros da equipe de projetos - Listar lições aprendidas no projeto - Listar pontos fortes e fracos do projeto - Liberar membros da equipe do projeto - Finalizar projeto internamente Artefatos de Entrada: - Contrato

Artefatos de Saída: - Aceitação Formal e fechamento do projeto

Freqüência: uma vez por projeto. Ator: Gerente de Projetos

Figura 4.42 - Conjunto de Atividades do subprocesso P3.SP3.#1

4.5.4. Processo de entendimento e aceite (P4)

Esse processo ocorre no momento de concepção de um projeto. Quando o

cliente entra em contato com a área de negócios demonstrando interesse em

realizar um projeto. A partir deste momento, um analista de negócios é designado

para avaliar a necessidade do cliente e uma interface com a Fábrica de Software

iniciada com o objetivo de verificar a viabilidade do projeto, para então ser

elaborada uma proposta.

Para a realização desse processo, as seguintes subdivisões deverão ser

executadas:

P4.SP1 – Avaliar Necessidade do Cliente

P4.SP2 – Verificar Viabilidade (tecnológica)

P4.SP3 – Elaborar Proposta Técnica

4.5.4.1. Objetivos

O objetivo deste processo, é entender a necessidade do cliente e verificar a

viabilidade deste projeto ser executado pela Fábrica de Software.

245

4.5.4.2. Políticas

A Gerência de Negócios, abaixo define e faz cumprir, as seguintes

políticas que orientam as atividades relacionadas à execução do processo de

Entendimento e Aceite.

Descrição das Políticas

• Uma proposta técnica somente poderá ser elaborada se a Fábrica de

Software aprovar o pré-escopo, garantindo a viabilidade do projeto;

• O projeto somente terá continuidade se a proposta for aceita e assinada

pelo cliente.

Figura 4.43 – Quadro de políticas do processo de entendimento e aceite

4.5.4.3. Subprocessos do processo (P4)

4.5.4.3.1. Subprocesso 1 (SP1): avaliar a necessidade (P4.SP1)

4.5.4.3.1.1. Descrição e objetivos

O sub-processo P4.SP1, tem como objetivo entender a real necessidade do

cliente obtendo informações de negócios, premissas e requisitos básicos. Com

essas informações, o analista de negócios elabora um pré-escopo e submete-o para

a Fábrica de Software para que esta verifique a viabilidade do projeto.

4.5.4.3.1.2. Papéis envolvidos

Papéis Responsabilidades

Analista de Negócios

1. Levantar necessidades do cliente

2. Elaborar Pré-escopo

3. Revisar Pré-escopo

Figura 4.44 – Quadro de papéis do subprocesso P4.SP1

246

4.5.4.3.1.3. Detalhamento do sub-processo

As duas atividades do subprocesso P4.SP1 são: Avaliar a necessidade do

cliente (P4.SP1.#1) e Elaborar o pré-escopo (P4.SP1.#2).

Figura 4.45 – Quadro de detalhamento do subprocesso P4.SP1

247

Subprocesso P4.SP1.#1: Avaliar necessidades do cliente

Atividade: Avaliar Necessidade do Cliente Propósito: Entender a necessidade do cliente Passos: - Reunir-se com o cliente - Entender o negócio relacionado ao projeto - Fazer o levantamento básico de premissas, restrições e fatores críticos - Preencher um check-list de levantamento Artefatos de Entrada: - Solicitação do cliente

Artefatos de Saída: - Registros sobre regras de negócios e características sobre o projeto a ser desenvolvido; - Check-list de levantamento preenchido

Freqüência: a cada nova solicitação de um cliente Ator: Analista de negócios

Figura 4.46 - Conjunto de Atividades do subprocesso P4.SP1.#1

Subprocesso P4.SP1.#2: Elaborar o pré-escopo

248

Atividade: Elaborar Pré-escopo

Propósito: Documentar as principais características, restrições e premissas da solicitação efetuada pelo cliente e submeter o pré-escopo para a avaliação da Fábrica de Software. Passos: - Listar as características, premissas, restrições e regras de negócio obtidas em reunião com cliente; - Fazer uma estimativa inicial de tempo, recursos e custo; - Elaborar Pré-escopo com as principais características do projeto. - Enviar Pré-escopo para Fábrica de software, para que seja verificado a viabilidade do projeto. Artefatos de Entrada: - Solicitação de mudança de pré-escopo; - Check-list de levantamento preenchido; - Registros inicias de premissas, restrições, regras de negócios e características.

Artefatos de Saída: - Pré-escopo

Freqüência: início do projeto Ator: Analista de negócios

Figura 4.47 - Conjunto de Atividades do subprocesso P4.SP1.#2

4.5.4.3.2. Subprocesso 2 (SP2): verificar a viabilidade tecnológica

(P4.SP2)

4.5.4.3.2.1. Descrição e objetivos

O subprocesso Verificar a Viabilidade Tecnológica tem como objetivo

possibilitar que a Fábrica de Software analise o pré-escopo, checando se o mesmo

possui informações claras, e, com essas informações, fazer um prognóstico para

saber se a Fábrica tem condições de, em processos posteriores, dar prosseguimento

ao projeto sem que tenha eventuais problemas relacionados a recursos, sejam eles

técnicos ou humanos.

249

4.5.4.3.2.2. Papéis envolvidos

Papéis Responsabilidades

Gerente da Fábrica

SW

1. Analisar Pré-escopo;

2. Solicitar alterações no pré-escopo;

3. Solicitar maiores informações sobre o projeto;

4. Revisar estimativas iniciais;

5. Analisar especificações, caso existam;

6. Aprovar/Reprovar pré-escopo.

Figura 4.48 – Quadro de papéis do subprocesso P4.SP2

4.5.4.3.2.3. Detalhamento do sub-processo

A atividade do subprocesso P4.SP2 é: verificar a viabilidade do projeto

(P4.SP2.#1).

250

Figura 4.49 – Quadro de detalhamento do subprocesso P4.SP2

Subprocesso P4.SP2.#1: Verificar viabilidade

Atividade: Verificar Viabilidade do projeto Propósito: Identificar falhas no pré-escopo que possam comprometer o projeto no que diz respeito a recursos tecnológicos, custo e prazo. Passos: - Analisar Pré-escopo; - Analisar Especificação; - Avaliar ferramentas e técnicas selecionadas; - Avaliar estimativas; Artefatos de Entrada: Artefatos de Saída:

251

- Pré-escopo - Especificações

- Pré-escopo Aprovado ou Reprovado

Freqüência: início do projeto Ator: Analista de negócios

Figura 4.50 - Conjunto de Atividades do subprocesso P4.SP2.#1

4.5.4.3.3. Subprocesso 3 (SP3): elaborar a proposta técnica

(P4.SP3)

4.5.4.3.3.1. Descrição e objetivos

O sub-processo “Elaborar Proposta Técnica” tem como objetivo documentar

as características e estimativas do projeto e obter a aprovação formal destas pelo

cliente estabelecendo um contrato comercial para a execução do projeto.

4.5.4.3.3.2. Papéis envolvidos

Papéis Responsabilidades

Analista de Negócios

1. Elaborar Proposta Técnica

2. Obter aprovação do Cliente

3. Encaminhar proposta para o PMO

Figura 4.51 – Quadro de papéis do subprocesso P4.SP3

4.5.4.3.3.3. Detalhamento do sub-processo

A atividade do subprocesso P4.SP3 é: elaborar a proposta técnica

(P4.SP3.#1).

252

Figura 4.52 – Quadro de detalhamento do subprocesso P4.SP3

Subprocesso P4.SP3.#1: Elaborar a proposta

Atividade: Elaborar Proposta técnica Propósito: Transcrever as informações do pré-escopo para a proposta de maneira detalhada, para obter a aprovação formal do cliente e estabelecer um vínculo contratual. Passos: - Alterar propostas rejeitadas - Elaborar proposta - Submeter proposta para aprovação do cliente

253

Artefatos de Entrada: - Pré-escopo aprovado - Especificações

Artefatos de Saída: - Proposta

Freqüência: início do projeto Ator: Analista de negócios

Figura 4.53 - Conjunto de Atividades do subprocesso P4.SP3.#1

4.5.5. Processo de construção do produto (P5)

O processo de Construção do Produto da Fábrica de Software é responsável

pelo desenvolvimento do produto solicitado.

Para o desenvolvimento do produto, alguns subprocessos devem ser

percorridos, sendo eles iterativos, ou seja, até a maturidade do software cada

subprocesso poderá ser executado mais de uma vez.

O processo foi estruturado tomando como base os conceitos de

desenvolvimento do modelo RUP – Rational Unified Process.

O início do processo se dá com a inclusão do projeto em repositório de

informações para acesso de todas as áreas envolvidas no desenvo lvimento, a fim de

prever o cronograma inicial e recursos necessários.

Assim que a Estrutura Analítica do Projeto (EAP) é recebida, inicia-se o

desenvolvimento do Projeto Lógico do Software com agendamento de reuniões e

workshop’s com o cliente, usuários finais do sistema e demais envolvidos no projeto

no intuito de levantamento de requisitos e conhecimento das regras de negócios que

comporão o software.

O Projeto Lógico é um artefato desenvolvido pela área de Desenvolvimento

da Fábrica de Software que detalha através de Modelos de Casos de Uso, todo o

funcionamento do sistema de acordo com o solicitado. Esse artefato não utiliza

254

termos técnicos, ou seja, é de fácil entendimento do cliente, para que o mesmo

possa aprová-lo.

Quando o Projeto Lógico é aprovado pelo cliente, o artefato retorna ao

processo para que o banco de dados e os componentes do sistema sejam

projetados e agregados ao Projeto Lógico que é então encaminhado para a

Execução de Demanda e Execução de Testes.

Em Execução de Demanda, o software começa a receber forma sendo

implementado, ou seja, codificado pelos especialistas da área. O produto vai sendo

composto ao longo do processo por subsistemas que formarão um único sistema.

Todos os build’s (subsistemas e sistemas) que ao longo do projeto vão sendo

liberados pela execução de demanda, são encaminhados ao Processo de Testes de

Software, processo este que, ao recebimento do Projeto Lógico inicia a elaboração

do Plano de Testes, ou seja, quando um build é recebido no processo todo um

planejamento já foi previsto para execução dos testes.

Somente quando forem encontrados ZERO defeitos no sistema testado, de

acordo com o planejamento de qualidade da iteração e do projeto, é que o mesmo é

encaminhado para o processo de implantação em versão BETA.

Em Implantação, todo o planejamento de “como”, “onde”, “quando” implantar

o produto estará elaborado para que o sistema BETA seja implantando, no ambiente

de teste, a fim de obter o aceite do cliente para a implantação definitiva.

Na implantação BETA, ou seja dentro do site da fábrica, o sistema é testado

por um grupo de usuários que são treinados por um especialista da Fábrica. Os

usuários recebem o material de suporte e material de treinamento que os auxiliam

no processo de aprendizagem, utilização, operação e manutenção do produto.

255

Já a implantação definitiva, no ambiente de produção do cliente, somente

será executada quando o sistema BETA for aceito pelo cliente. Esta implantação é

executada em todo ambiente de produção que fará uso do produto. Após a

implantação, o cliente deverá assinar a Carta de Encerramento para que os

processos referentes ao projeto sejam finalizados na Fábrica de Software.

Para melhor compreensão, segue abaixo figura que representa o fluxo do

Processo de Desenvolvimento de Software explicado:

256

Figura 4.54 – Quadro de Detalhamento do Processo de Construção do Produto

4.5.5.1. Objetivos

Este processo tem por objetivo estruturar os procedimentos de

Desenvolvimento de Software, alinhado às políticas definidas pela Gerência de

257

Desenvolvimento da Fábrica de Software de forma a desenvolver softwares com a

máxima qualidade prevista no processo P2 - Gestão de Qualidade.

4.5.5.2. Políticas

A Gerência de Desenvolvimento da Fábrica de Projetos de Software, abaixo

define e faz cumprir, as seguintes políticas que orientam as atividades relacionadas

à execução do Processo de Desenvolvimento de Software.

Descrição das Políticas

• Todas as áreas envolvidas no processo P5 Construção do Produto devem

iniciar os trabalhos a partir da inclusão de um novo projeto no repositório de

Informações sobre Projetos;

• Todos os artefatos gerados pelos subprocessos devem ser revisados para

que não existam inconsistências, informações faltantes ou inexatas, através

da supervisão da SQA;

• Todas as partes envolvidas devem estar de acordo com a definição do

problema que o sistema se propõe a solucionar;

• Para todo projeto deve ser elaborado um Glossário para facilitar a

comunicação entre os envolvidos no projeto;

• Para todo projeto devem ser realizadas reuniões, workshop's, ou outras

formas de encontro com os envolvidos no projeto para levantamento e

entendimento de requisitos e regras de negócios;

• Para todo projeto os artefatos previstos no diagrama P5.SP2.#1 Definir

Requisitos, Sistema e Arquitetura, devem ser elaborados e refinados.

• O projeto lógico poderá ser encaminhado para outras áreas de

desenvolvimento somente quando aprovado pelo cliente e os projetos de

banco de dados e componentes estiverem prontos;

• Deve ser realizada uma prova conceitual para todo projeto que existirem

dúvidas com relação ao funcionamento do sistema de acordo com a

258

solicitação do cliente, definido pelo subprocesso relacionado;

• Para todo projeto, a equipe de design deve projetar estruturas de banco de

dados apropriadas, a fim de armazenar as classes persistentes;

• Para projetar o Banco de Dados devem ser definidos os mecanismos e

estratégias de armazenamento e recuperação de dados persistentes, de

modo a atender aos critérios de desempenho do sistema;

• O componente criado deve ser compatível com as diretrizes de

programação e com o previsto no levantamento de requisitos.

• Os objetos de design devem ser implementados conforme a orientação do

guia de design.

• Metas e objetivos, itens-alvo, abordagem adotada, recursos necessários e

produtos que serão liberados devem estar descriminados no Plano de

Teste;

• O Plano de Testes deve ser gerenciado e atualizado pelo Gerente de

Testes;

• Devem ser analisados e identificados todos os itens a serem testados

durante o processo de teste;

• Para todo o esforço de teste a ser executado, devem ser verificadas as

melhores técnicas para sua abordagem. As técnicas escolhidas devem ser

implementadas para verificar seu real funcionamento e abrangência

(verificação da performance);

• Todas as idéias de teste devem estar listadas, documentadas, bem como,

catalogadas no Guia de Teste.

• Todo o build recebido deve ser avaliado e testado para verificar sua

estabilidade, só podendo ser liberado quando avaliado e validado como

estável pelo Analista de Testes;

• Todo o teste executado deve ser relatado no Log de Teste;

• As solicitações de mudança devem ser emitidas somente após análise

detalhada do Log de Teste;

• O build pode ser liberado para o processo de implantação somente quando

o mesmo tiver sido completamente testado, não apresentar defeitos e

estiver validado como estável pelo Analista de Testes.

• Ao final de cada iteração do subprocesso de execução dos testes, devem

259

ser analisadas as formas de melhorias e vantagens para o processo;

• As melhorias identificadas devem ser implantadas nas iterações seguintes

do subprocesso de execução de testes;

• Todas as lições aprendidas durante o subprocesso de execução dos testes

devem ser documentadas, dentro do contexto da fase de transição (registro

de lições);

• As oportunidades para reutilização e melhorias na produtividade devem ser

exploradas, porém com supervisão da SEPG;

• O planejamento de implantação deve ser iniciado a partir da Inclusão do

Projeto em repositório de informações de projetos do subprocesso P5.SP1,

evoluindo no decorrer do tempo;

• A equipe designada para a implantação deve suprir este processo com a

declaração do escopo (justificativa, produto e sub-produto do projeto),

restrições (definidas pelas cláusulas contratuais das SLA´s), premissas e

informações históricas;

• Deverá existir um repositório com todo histórico do planejamento de

implantação para avaliação, correção e melhoria dos processos desta e de

outras áreas de conhecimento.

• O processo P5.SP4: Executar os testes poderá ser finalizado somente

quando o Sistema final estiver testado e completamente sem defeitos.

• O produto BETA gerado deve ser gerenciado e avaliado pelo Gerente de

Implantação;

• O produto deve ser utilizado por um grupo de usuário durante um período

pré-estabelecido no ambiente do cliente;

• O Gerente de Implantação deve acompanhar todo o processo em que o

produto BETA estiver em funcionamento para verificação de mudanças

necessárias e/ou defeitos existentes.

• Devem participar da execução do subprocesso P5.SP5 Implantação BETA,

um Testador para implementar um conjunto de testes, o Cliente para

acompanhar a simulação do sistema em funcionamento e um Gerente de

Implantação, para avaliar os resultados dos testes executados no ambiente

de desenvolvimento;

• Deverá existir um repositório com todo histórico de implantação que, para

260

todo projeto, seja alimentado com informações como práticas,

peculiaridades encontradas, avaliação, correção e melhoria, bem como,

outros dados;

• O desenvolvimento de material de suporte deve ser iniciado a partir do build

versão beta ou equivalente e terá como referência o Manual de Guia de

Estilo.

• Todo o produto gerado pela Fábrica de Software deve possuir Material de

Treinamento e Material de Suporte ao Usuário que devem ser elaborados

no processo P5.SP5: Realizar implantação BETA;

• Um conjunto de testes baseado em um subconjunto selecionado dos testes

já existentes deve ser executado para garantir o funcionamento e

estabilidade do produto implantado;

• Todo o subprocesso P5.SP5 deve ser acompanhado pelo Gerente de

Implantação, o qual avalia a aceitação do produto ou as anormalidades,

elaborando assim uma solicitação de mudança.

• O subprocesso P5.SP5 somente poderá ser finalizado com o aceite do

cliente com relação ao produto BETA implantado.

Figura 4.55 – Quadro de políticas do processo de Construção do Produto

4.5.5.3. Subprocessos do processo (P5)

4.5.5.3.1. Subprocesso 1 (SP1): incluir projeto na linha de

produção (P5.SP1)

4.5.5.3.1.1. Descrição e objetivos

O processo de Inclusão do Projeto tem como principal objetivo incluir as

especificações do novo projeto em repositório de informações para iniciação dos

trabalhos de construção do sistema solicitado pelo cliente. Além disso, ele é

responsável por colocar a OS no plano de produção (encaminhamento) e verificar a

situação da demanda dentro do processo de execução da fábrica de software.

261

Após a real formalização do projeto (executada pela área de PMO da Fábrica)

e o recebimento de informações do tipo: cronograma inicial e check-list do trabalho a

ser executado, é possível iniciar os trabalhos na área de Construção do Produto da

Fábrica de Software, através de uma pré-alocação de recursos.

Com a inclusão do novo projeto, todas as áreas que compõem o ambiente de

Construção da Fábrica poderão executar todos os ajustes que serão necessários,

bem como, prever necessidades antes de o projeto entrar em real execução no

ambiente de desenvolvimento.

Para melhor execução deste trabalho de inclusão do projeto, o processo está

subdividido em:

P5.SP1.#1 – Avaliar o Projeto

P5.SP1.#2 – Incluir Especificações do Projeto

4.5.5.3.1.2. Papéis envolvidos

Papéis Responsabilidades

Gerente de Projeto

1. Avaliar cronograma inicial e check-list do projeto

recebido pela área de PMO.

2. Identificar todas as especificações convenientes

para a área de Construção da Fábrica.

3. Elaborar documento contendo as Especificações

do Projeto.

4. Refinar o Documento de Especificações do

Projeto a fim de certificar-se que todas as

informações necessárias foram identificadas.

262

5. Incluir as Especificações em Repositório de

Informações de Projetos.

Figura 4.56 – Quadro de papéis do subprocesso P5.SP1

4.5.5.3.1.3. Detalhamento do subprocesso

Figura 4.57 – Quadro de detalhamento do subprocesso P5.SP1

Subprocesso P5.SP1.#1: Avaliar Projeto

Atividade: Avaliar Projeto Propósito: avaliar cronograma inicial e check-list recebido da área de PMO, avaliando viabilidade de inclusão em repositório de dados. Passos:

- Analisar Cronograma inicial;

263

- Analisar Check-list; - Elaborar Documento contendo as Especificações encontradas para

execução do projeto. Artefatos de Entrada:

- Check-list - Cronograma inicial

Artefatos de Saída: - Documento de Especificações do Projeto.

Freqüência: a cada novo projeto iniciado na Fábrica Ator: Gerente de Projeto

Figura 4.58 - Conjunto de Atividades do subprocesso P5.SP1.#1

Subprocesso P5.SP1.#2: Incluir Especificações do Projeto

Atividade: Refinar Especificações Propósito: revisar o cronograma inicial e check-list recebidos da área de PMO, bem como, o documento de especificações do projeto a fim de certificar-se que todas as informações necessárias para o início do projeto na área de desenvolvimento foram identificadas. Passos:

- Revisar Cronograma inicial; - Revisar Check-list; - Atualizar o Documento de Especificações do Projeto.

Artefatos de Entrada: - Check-list - Cronograma inicial - Documento de Especificações

do Projeto.

Artefatos de Saída: - Documento de Especificações do Projeto.

Freqüência: a cada novo projeto iniciado na Fábrica Ator: Gerente de Projeto

Atividade: Incluir Projeto Propósito: executar a inclusão das especificações do projeto em um repositório para que as demais áreas que compõem a fase de desenvolvimento de software possam consultar a fim de identificarem todos os ajustes e recursos que serão necessários para o início do projeto. Passos:

- Incluir Especificações do Projeto em repositório de informações. - Executar pré-alocação de recursos de acordo com o grau de

complexidade da demanda. Artefatos de Entrada: Artefatos de Saída:

264

- Documento de Especificações do Projeto (atualizado).

- Repositório de Informações de Projetos.

Freqüência: a cada novo projeto iniciado na Fábrica Ator: Gerente de Projeto

Figura 4.59 - Conjunto de Atividades do subprocesso P5.SP1.#2

4.5.5.3.2. Subprocesso 2 (SP2): elaborar o projeto lógico (P5.SP2)

4.5.5.3.2.1. Descrição e objetivos

O processo tem como objetivo a elaboração do Projeto Lógico do sistema a

ser desenvolvido na Fábrica de Software.

O processo é iniciado com o recebimento da Estrutura Analítica do Projeto

(EAP), e, a partir desse momento, a equipe de análise de sistemas se reúne com o

cliente e os envolvidos no projeto para o levantamento e refinamento de requisitos

funcionais e regras de negócios para a elaboração de artefatos como: Modelo de

Casos de Uso, Modelo de Casos de Negócios, Modelo de Objetos de Negócios,

Atributos de Requisitos, entre outros, que são necessários para a elaboração do

projeto lógico.

Para facilitar a comunicação entre os profissionais da FSW e os envolvidos no

projeto, é elaborado ao longo das reuniões um Glossário contendo um breve

explicativo dos termos utilizados.

Caso os analistas encontrem algum ponto divergente nas solicitações do

cliente e precisem tirar a prova de que a solicitação é factível, faz-se uma avaliação

do ponto em questão através de uma simulação do cenário (prova conceitual)

verificando-se assim a viabilidade da solicitação.

265

Após o refinamento dos requisitos e o modelo de casos de uso elaborado, a

equipe de análise de sistemas, juntamente com o arquiteto de software, definem o

sistema e a arquitetura do software, formando assim o projeto lógico do sistema, de

forma que seja fácil o entendimento do cliente.

O artefato finalizado é encaminhado para o cliente a fim de obter aprovação.

Caso o Projeto Lógico não seja aprovado, a equipe de análise verifica onde constam

divergências e realiza as alterações necessárias no Projeto Lógico.

Após a aprovação do cliente, será agregado ao Projeto Lógico do Sistema o

projeto do Banco de Dados e dos Componentes. A partir desse momento, o artefato

é encaminhado para os subprocessos P5.SP3 – Execução da Demanda e P5.SP4 –

Execução de Testes, esse último dá início à elaboração do Plano de Testes.

O subprocesso é executado de acordo com as seguintes subdivisões:

P5.SP2.#1: Definir Requisitos, Sistema e Arquitetura

P5.SP2.#2: Elaborar / Alterar Projeto Lógico

P5.SP2.#3: Projetar Banco de Dados e Componentes

P5.SP2.#4: Encaminhar Projeto Lógico

4.5.5.3.2.2. Papéis envolvidos

Papéis Responsabilidades

Analista de Sistemas

1. Liderar e coordenar a identificação

de requisitos, regras de negócios e

modelagem de casos de uso.

266

2. Elaborar e atualizar o Plano de

Gerenciamento de Requisitos, Guia de

Modelagem de Casos de Uso,

Glossário, Solicitações dos Envolvidos,

Documento de Visão e Especificações

Suplementares.

3. Gerenciar as mudanças nos

requisitos.

4. Coordenar todas as atividades do

processo e iterações.

Arquiteto de Software

1. Construir Prova de Conceito

Arquitetural (quando necessário)

2. Elaborar/Atualizar Documento de

Arquitetura de Software

3. Avaliar a viabilidade da prova

conceitual (quando necessário a

realização da prova conceitual)

4. Determinar Critérios de Avaliação

Designer de Banco de Dados

1 – Definir tabelas, índices, visões,

restrições, triggers, procedimentos

armazenados, parâmetros de

armazenamento e outras construções

específicas de um banco de dados

necessárias para armazenar, recuperar

e excluir objetos persistentes.

2 - Realizar Análise do Caso de Uso

Designer

1 - Realizar Design de Caso de Uso,

Design da Classe, Design do

Subsistema e projetar classes e

pacotes de teste.

267

3 - Definir as responsabilidades, as

operações, os atributos e os

relacionamentos de uma ou de várias

classes;

4 – Planejar e conduzir as revisões

formais de designer juntamente com a

área de qualidade.

5 – Garantir que a classe informe o

comportamento necessário às

realizações dos casos de uso;

Cliente 1. Analisar e aprovar o Projeto Lógico

do Sistema.

Usuário Final

1. Participar de reuniões, workshop’s,

ou outras formas de encontros

realizados para identificação de

requisitos.

2. Fornecer informações sobre a rotina

de trabalho executada (workflow dos

procedimentos e processos do

negócio), a fim de colaborar com o

levantamento dos requisitos do

sistema.

Figura 4.60 – Quadro de papéis do subprocesso P5.SP2

268

4.5.5.3.2.3. Detalhamento do subprocesso

Figura 4.61 – Quadro de detalhamento do subprocesso P5.SP2

269

Subprocesso P5.SP2.#1: Definir Requisitos, Sistema e Arquitetura.

Atividade: Detalhar o Problema Propósito: Analisar o Problema e Elaborar artefatos gerenciais. Passos: - Analisar o Problema; - Identificar os Envolvidos; - Descrever a documentação de requisitos, tipos de requisitos e seus respectivos atributos; - Elaborar Documento de Visão; - Elaborar Glossário. Artefatos de Entrada: Artefatos de Saída:

270

- Regras de Negócio; - Solicitações dos Envolvidos; - Modelo de Caso de Uso.

- Glossário; - Documento de Visão; - Plano de Gerenciamento de Requisitos; - Atributos de Requisitos.

Freqüência: ao longo do projeto, exceto na fase de implantação. Ator: Analista de Sistemas, Cliente, Usuário Final, Envolvidos.

Atividade: Identificar atores e Casos de Uso Propósito: Identificar as funções pretendidas do sistema e seu ambiente. Passos: - Analisar Modelo de Caso de Uso de Negócios; - Analisar Modelo de Objetos de Negócios; - Identificar os atores e casos de uso; - Criar diagramas do modelo de casos de uso; - Desenvolver um relatório sintético do modelo de casos de uso; - Estruturar o Modelo de Caso de Uso. Artefatos de Entrada: - Modelo de Caso de Uso de Negócios; - Modelo de Objetos de Negócios.

Artefatos de Saída: - Modelo de Casos de Uso.

Freqüência: ao longo do projeto, exceto na fase de implantação. Ator: Analista de Sistemas, Cliente, Usuário Final, Envolvidos.

Atividade: Identificar Solicitações dos Principais Envolvidos. Propósito: Coletar solicitações com as necessidades que o sistema deverá atender. Passos: - Entrevistar envolvidos; - Coletar e documentar informações. Artefatos de Entrada: - Documento de Visão; - Solicitação de Mudança.

Artefatos de Saída: - Solicitações dos Principais Envolvidos - Especificações Suplementares.

Freqüência: ao longo do projeto, exceto na fase de implantação. Ator: Analista de Sistemas, Cliente, Usuário Final, Envolvidos.

Atividade: Gerenciar Dependências Propósito: Utilizar os atributos e os requisitos do projeto para auxiliar no gerenciamento do escopo do projeto e gerenciar requisitos variáveis. Passos: - Definir os atributos a serem rastreados para cada tipo de requisito; - Estabelecer e verificar rastreabilidade; - Gerenciar as mudanças nos requisitos. Artefatos de Entrada: - Guia de Modelagem de Casos de Uso; - Atributos de Requisitos; - Solicitação de Mudança; - Especificações Suplementares.

Artefatos de Saída: - Atributos de Requisitos (refinados); - Documento de Visão (refinado); - Modelo de Caso de Uso.

271

Freqüência: ao longo do projeto, exceto na fase de implantação. Ator: Analista de Sistemas, Cliente, Usuário Final, Envolvidos.

Atividade: Revisar / Estruturar Requisitos de Modelo de Casos de Uso Propósito: Reavaliar os principais artefatos gerados durante o processo. Passos: - Rever o Modelo de Caso de Uso já definido; - Verificar se não houve erros ou requisitos faltantes na localização de atores, casos de uso e nos atendimentos das solicitações dos envolvidos; - Estruturar o Modelo de Casos de Uso. Artefatos de Entrada: - Atributos de Requisitos; - Plano de Gerenciamento de Requisitos; - Modelo de Caso de Uso; - Plano de Iteração; - Documento de Visão; - Solicitações dos Principais Envolvidos; - Especificações Suplementares.

Artefatos de Saída: - Registro de Revisão; - Modelo de Caso de Uso (reestruturado).

Freqüência: ao longo do projeto, exceto na fase de implantação. Ator: Analista de Sistemas, Cliente, Usuário Final, Envolvidos.

Atividade: Definir Arquitetura Propósito: definir a arquitetura do sistema. Passos: - analisar modelo de casos de uso, modelo de implantação e modelo de design. - elaborar Documento de Arquitetura de Software - refinar Documento de Arquitetura de Software Artefatos de Entrada: - Modelo de Casos de Uso; - Modelo de Implantação; - Modelo de Design; - Solicitação de Mudança; - Documento de Arquitetura de Software.

Artefatos de Saída: - Documento de Arquitetura de Software (atualizado).

Freqüência: após o recebimento da EAP. Ator: Arquiteto de Software.

Figura 4.62 - Conjunto de Atividades do subprocesso P5.SP2.#1

272

Subprocesso P5.SP2.#2: Elaborar / Alterar Projeto Lógico

Atividade: Elaborar Projeto Lógico Propósito: elaborar o projeto lógico a ser enviado para aprovação do cliente, bem como, para outras áreas da FSW. Passos: - analisar modelo de casos de uso, modelo de implantação e modelo de design e Documento de Arquitetura de Software. - Elaborar o Projeto Lógico; - Refinar o Projeto Lógico antes de encaminhá-lo para o cliente Artefatos de Entrada: - Modelo de Casos de Uso; - Modelo de Implantação; - Modelo de Design; - Solicitação de Mudança; - Documento de Arquitetura de Software.

Artefatos de Saída: - Documento de Arquitetura de

Software (atualizado). - Projeto lógico.

Freqüência: após requisitos definidos e a cada alteração no PL solicitada. Ator: Arquiteto de Software / Analista de Sistemas.

Figura 4.63 - Conjunto de Atividades do subprocesso P5.SP2.#2

273

Subprocesso P5.SP2.#3: Projetar Banco de Dados e Componentes

Atividade: Definir Design de Classes Propósito: fazer a análise das classes identificando persistências para projeção do banco de dados. Passos: - receber o projeto lógico com o aceite do cliente; - analisar o projeto lógico, modelo de caso de uso e modelo de design; - identificar classes persistentes; - elaborar classe de design. Artefatos de Entrada: - Modelo de Design - Modelo de Caso de Uso; - Realização dos Casos de Uso; - Projeto Lógico.

Artefatos de Saída: - Classe de Design

Freqüência: a cada iteração Ator: Designer

Atividade: Executar Definição Propósito: realizar a modelagem de dados.

274

Passos: - analisar o modelo de design, modelo de caso de uso, projeto lógico, realização de caso de uso e a classe de design; - elaborar o Modelo de Dados. Artefatos de Entrada: - Modelo de Design - Modelo de Caso de Uso; - Realização dos Casos de Uso; - Projeto Lógico; - Classe de Design.

Artefatos de Saída: - Modelo de Dados

Freqüência: a cada iteração Ator: Designer de Banco de Dados

Atividade: Revisar Design Propósito: revisar o modelo de dados. Passos: - analisar o modelo de dados elaborado, guia de design e especificações suplementares; - verificar se o modelo atende todas as funcionalidades que o sistema deve abranger; - elaborar solicitação de mudança para as divergências encontradas. Artefatos de Entrada: - Modelo de Dados; - Guia de Design; - Especificações Suplementares;

Artefatos de Saída: - Registro de Revisão; - Solicitação de Mudança.

Freqüência: a cada iteração Ator: Revisor de Design

Atividade: Realizar Design de Caso de Uso Propósito: Refinar os requisitos nas operações (classes de design, subsistemas e cápsulas) e as realizações de casos de uso em termos de iterações. Passos: - Descrever Interações Entre Objetos de Design; - Simplificar Diagramas de Seqüência Usando Subsistemas (opcional); - Descrever o Comportamento Relacionado à Persistência; - Refinar a Descrição do Fluxo de Eventos; - Unificar Classes e Subsistemas; - Avaliar os Resultados. Artefatos de Entrada: - Subsistema de Design - Classe de Design - Caso de Uso - Especificações Suplementares - Cápsula - Interface - Realização de Casos de Uso

Artefatos de Saída: - Realização de Casos de Uso

Freqüência: A cada iteração Ator: Design

Atividade: Realizar Design da Classe Propósito: Garantir que a classe informe o comportamento necessário às realizações dos casos de uso e garantir que sejam fornecidas informações suficientes para implementá-la sem ambigüidades, tratar requisitos não funcionais

275

e incorporar os mecanismos usados pela classe. Passos: - Criar Classes de Design Inicial; - Identificar Classes Persistentes; - Definir Visibilidade da Classe; - Definir Operações; - Definir Métodos; - Definir Estados; - Definir Atributos; - Definir Dependências; - Definir Associações; - Definir Generalizações; - Resolver Conflitos entre Casos de Uso; - Tratar Requisitos Não-funcionais em Geral; - Avaliar os Resultados. Artefatos de Entrada: - Guia de Design - Especificações Suplementares - Modelo de Design - Realização de Casos de Uso - Evento - Sinal

Artefatos de Saída: - Classe de Design

Freqüência: A cada iteração Ator: Design

Atividade: Realizar Design do Subsistema Propósito: Definir o comportamento especificado nas interfaces do subsistema e as classes armazenadas. Documentar a estrutura interna do subsistema e determinar as dependências de outros subsistemas. Passos: - Distribuir o comportamento do Subsistema para Elementos do Subsistema; - Documentar elementos do Subsistema; - Descrever Dependências do Subsistema. Artefatos de Entrada: - Guia de Design - Subsistema de Design - Realização de Casos de Uso - Interface

Artefatos de Saída: - Cápsula - Classe de Design - Subsistema de Design - Realização de Casos de Uso

- Interface Freqüência: A cada iteração Ator: Design

Atividade: Projetar Classes e Pacotes de Teste Propósito: Projetar funcionalidade especifica de teste Passos: - Identificar Classes e Pacotes específicos de Teste; - Projetar Interface para a ferramenta de Automatização de Testes; - Projetar o Comportamento dos procedimentos de Teste. Artefatos de Entrada: - Caso de Teste - Classe de Design - Especificação da Interface de Teste

Artefatos de Saída: - Classe de Teste - Pacote de Design

276

- Classe de Teste - Pacote de Design Freqüência: A cada iteração Ator: Design

Atividade: Revisar Design Propósito: Verificar se o modelo de design obedece aos requisitos do sistema e serve como base para sua implementação. Assegurar que o modelo é consistente no que diz respeito às diretrizes gerais de design e que estas atingirão seus objetivos. Passos: - Revisar o Modelo de Design como um todo; - Revisar cada realização de casos de uso; - Revisar cada Subsistema ou Classe; - Revisar Guia de Design; - Preparar Registro de Revisão e Documentar Defeitos. Artefatos de Entrada: - Modelo de Design - Guia de Design - Especificações Suplementares

Artefatos de Saída: - Registro de Revisão - Solicitação de Mudança

Freqüência: A cada iteração Ator: Revisor de Design

Figura 4.64 - Conjunto de Atividades do subprocesso P5.SP2.#3 Subprocesso P5.SP2.#4: Encaminhar Projeto Lógico

Atividade: Encaminhar Projeto Lógico Propósito: Finalizar os trabalhos de desenvolvimento do projeto lógico e encaminhá-lo para os processos de Execução da Demanda (implementação do software) e Execução Testes (elaboração do Plano de Testes). Passos: - agregar ao projeto lógico aprovado pelo cliente, o modelo de dados e o

277

projeto dos componentes do sistema; - finalizar os trabalhos armazenando em repositório de informações os dados relevantes sobre o projeto lógico desenvolvido; - encaminhar o projeto lógico para os processos de Execução da Demanda e Execução de Testes. Artefatos de Entrada: - Projeto Lógico (aprovado)

Artefatos de Saída: - Projeto Lógico (aprovado) - Repositório de informações.

Freqüência: após aprovação do Projeto Lógico. Ator: Analista de Sistemas.

Figura 4.65 - Conjunto de Atividades do subprocesso P5.SP2.#4

4.5.5.3.3. Subprocesso 3 (SP3): Executar a Demanda (P5.SP3)

4.5.5.3.3.1. Descrição e objetivos

O processo Execução da Demanda tem como principal objetivo construir o

sistema, tomando como base o modelo de design elaborado pelo subprocesso

P5.SP2 – Elaborar Projeto Lógico, a fim de atender todos os requisitos do cliente.

A princípio, o processo tem como atribuição organizar o Modelo de

Implementação de acordo com o Modelo de Design que foi elaborado no

subprocesso P5.SP2 – Elaborar Projeto Lógico, identificando os subsistemas que

são compostos por um ou mais componentes a serem construídos e arquivos

relacionados para a formação de um subsistema. Com o modelo de implementação

definido e refinado, é possível iniciar a construção dos componentes, para que após

a construção cada componente faça parte da formação do subsistema conforme o

previsto no modelo de implementação. Em seguida, é realizada a integração dos

componentes para a formação dos subsistemas, e, ao final, com todos os

subsistemas construídos, o integrador realiza a junção desses subsistemas

resultando no sistema final.

278

Para a realização deste subprocesso, serão percorridas algumas subdivisões

a fim de que o esforço das equipes seja focado, resultando assim, em um sistema

bem elaborado. São elas:

P5.SP3.#1 - Planejar o modelo de implementação

P5.SP3.#2 - Construir Componentes

P5.SP3.#3 - Integrar cada Subsistema

P5.SP3.#4 - Integrar o sistema

4.5.5.3.3.2. Papéis envolvidos

Papéis Responsabilidades

Arquiteto de

Software

1. Estabelecer uma estrutura para integração.

2. Estruturar o Modelo de Implementação.

Implementador

1. Escrever o código fonte de acordo com as diretrizes de

qualidade.

2. Realizar testes unitários no código.

3. Corrigir defeitos.

Integrador

1. Planejar a integração dos componentes e subsistemas

para a formação do sistema final.

2. Combinar os componentes implementados para criar

um build.

3. Encaminhar Builds para Testes.

4. Realizar a integração dos componentes de acordo com

o modelo de implementação, formando assim

subsistemas.

5. Realizar a integração dos subsistemas para a

279

formação do sistema final.

Revisor de

Código

1. Comparar o código fonte com as diretrizes de

qualidade.

Figura 4.66 – Quadro de papéis do subprocesso P5.SP3

280

4.5.5.3.3.3. Detalhamento do subprocesso

Figura 4.67 – Quadro de detalhamento do subprocesso P5.SP3

281

Subprocesso P5.SP3.#1: Planejar o Modelo de Implementação

Atividade: Estruturar o modelo de implementação Propósito: Estabelecer a estrutura em que a implementação residirá. Atribuir responsabilidades para subsistemas de implementação e seu conteúdo. Passos: - Criar a estrutura inicial do modelo de implementação; - Ajustar subsistemas de implementação; - Definir importações para cada sistema; - Decidir como tratar os executáveis; - Decidir como tratar os ativos de teste; - Atualizar a visão de implementação; - Avaliar o modelo de implementação. Artefatos de Entrada: - Modelo de design

Artefatos de Saída: - Documento de arquitetura de software - Modelo de implementação

Freqüência: a cada novo componente Ator: Arquiteto de software

Atividade: Planejar integração Propósito: Planejar os subsistemas que devem ser implementados e a ordem em que devem ser integrados Passos: - Identificar subsistemas; - Definir “Conjuntos de Builds”; - Definir uma série de Builds; - Avaliar o Plano de Integração do Build.

282

Artefatos de Entrada: - Modelo de implementação - Plano de iteração - Realização de casos de uso - Integração do build

Artefatos de Saída: - Integração do build

Freqüência: a cada novo componente Ator: Implementador

Figura 4.68 - Conjunto de Atividades do subprocesso P5.SP3.#1

Subprocesso P5.SP3.#2: Construir componentes

Atividade: Implementar componente

Propósito: Produzir código fonte de acordo com o modelo de design Passos: - Implementar o modelo de design; - Usar reutilização (se possível); - Enviar feedback para o design; - Avaliar o código. Artefatos de Entrada: - Classe de design

Artefatos de Saída: - Componente

Freqüência: a cada novo componente Ator: Implementador

Atividade: Corrigir um defeito Propósito: Corrigir defeitos do código

283

Passos: - Isolar o defeito; - Localizar a falha; - Corrigir a falha. Artefatos de Entrada: - Solicitação de Mudança

Artefatos de Saída: - Componente

Freqüência: a cada evento Ator: Implementador

Atividade: Implementar componentes de teste e subsistemas Propósito: Implementar os componentes que irão testar os componentes do sistema final. Passos: - Implemente o modelo de teste; - Realizar teste; - Enviar feedback para testes; - Analisar os testes; Artefatos de Entrada: - Classe de teste

Artefatos de Saída: - Componente de teste - Subsistema de implementação

Freqüência: a cada novo componente Ator: Implementador

Atividade: Realizar teste unitário Propósito: Testar cada componente separadamente Passos: - Realizar testes; - Avaliar os testes; - Submeter feedback para testes; - Corrigir defeitos encontrados e retomar testes interrompidos. Artefatos de Entrada: - Componente

Artefatos de Saída: - Componente

Freqüência: a cada novo componente Ator: Gerente de Projeto

Atividade: Revisar código Propósito: Comparar o código fonte com as diretrizes definidas pela qualidade para a implementação de componentes. Passos: - Realizar a revisão do código fonte; - Registrar os resultados. Artefatos de Entrada: - Componente

Artefatos de Saída: - Registro de revisão

Freqüência: a cada novo componente Ator: Revisor de código

Atividade: Planejar integração de subsistemas Propósito: Planejar a ordem com que os componentes serão integrados Passos: - Definir os builds; - Identificar as classes; - Atualizar os subsistemas relacionados. Artefatos de Entrada: Artefatos de Saída:

284

- Componente - Realização de casos de uso - Plano de Iteração

- Plano de integração do Build

Freqüência: durante todo o projeto Ator: Integrador

Figura 4.69 - Conjunto de Atividades do subprocesso P5.SP3.#2 Subprocesso P5.SP3.#3: Integrar Subsistema

Atividade: Integrar os Subsistemas

Propósito: Integrar os componentes em um subsistema de implementação e liberar esse subsistema para integração do sistema.

Passos: - Integrar Componentes; - Liberar o Subsistema de Implementação. Artefatos de Entrada: - Componente - Plano de Integração do Build - Subsistema de Implementação.

Artefatos de Saída: - Build - Subsistema de Implementação

Freqüência: a cada iteração Ator: Integrador

Figura 4.70 - Conjunto de Atividades do subprocesso P5.SP3.#3

285

Subprocesso P5.SP3.#4: Integrar Sistema

Atividade: Integrar o Sistema

Propósito: Integrar os subsistemas de implementação por partes em um build formando o sistema. Passos: - Aceitar Subsistemas e produzir Builds Intermediários; - Promover Baselines. Artefatos de Entrada: - Componente - Plano de Integração do Build - Subsistema de Implementação

Artefatos de Saída: - Build

Freqüência: A cada iteração Ator: Integrador

Figura 4.71 - Conjunto de Atividades do subprocesso P5.SP3.#4

4.5.5.3.4. Subprocesso 4 (SP4): executar os testes (P5.SP4)

4.5.5.3.4.1. Descrição e objetivos

O processo de Execução de Testes realiza os testes em cada build, gerado

pelo processo de execução da demanda, tendo como principal finalidade, identificar,

corrigir, armazenar e formalizar os defeitos existentes nos componentes, a fim de

garantir a liberação de software com a ocorrência de ZERO defeitos para o usuário.

286

O processo inicia-se quando o Projeto Lógico é recebido. O Gerente de

Testes avalia o artefato com o intuito de definir as metas, objetivos dos testes no

escopo do projeto, os itens-alvo, a abordagem adotada, os recursos necessários e

os produtos que serão liberados, elaborando assim, o Plano de Testes.

Na seqüência é elaborada uma Abordagem para o Teste onde se demonstra

que as técnicas a serem utilizadas funcionarão e facilitarão os testes exigidos. Após

esse momento, é possível testar todo build recebido da Execução de Demanda

(P5.SP3) – interação entre os subprocessos de execução e teste.

Os testes se iniciam, primeiramente, com um pré-teste contendo pequeno

grau de abrangência a fim de validar o build como sendo passível de testes

profundos. Caso o build não supere essa expectativa, o mesmo é encaminhado

novamente para o processo P5.SP3 – Execução de demanda juntamente com a

Solicitação de Mudança e a Lista de Problemas encontrados para que o build seja

corrigido. Caso contrário, o build passa dessa fase de validação para a real

execução dos testes onde é feia a avaliação do build profundamente com o intuito

de encontrar seus defeitos.

Se forem encontrados defeitos e esses não forem causados por erros de

execução dos testes, esse build é encaminhado para o processo P5.SP3 –

Execução da Demanda com respectiva Lista de Problemas e Solicitação de

Mudança.

Caso o build seja aprovado nos testes, o mesmo é encaminhado para o

processo P5.SP3 – Execução da Demanda para que seja integrado a outros builds

já testados, formando assim um subsistema.

Vale lembrar, que o esforço de teste funciona como um ciclo, ou seja, cada

build é testado. Depois desses builds aprovados nos testes serem integrados pelo

287

processo de execução de demanda a um subsistema, este também é testado. Ao

final, após a integração dos subsistemas formando o sistema principal, este também

é completamente testado.

Somente quando o sistema apresentar Zero defeitos será encaminhado para

o processo P5.SP5 – Implantação BETA.

Todas as vantagens, melhorias, boas práticas encontradas durante os testes

são agregados ao guia de testes para serem executados nas próximas iterações,

bem como, todos os elementos de testabilidade verificados como facilitadores de

testes são agregados ao processo, tanto durante o projeto em execução, como

reaproveitados em outros projetos.

O subprocesso de Execução dos Testes está subdividido de acordo com os

subprocessos abaixo relacionados:

P5.SP4#1 – Definir Foco do Teste

P5.SP4#2 – Verificar Abordagem do Teste

P5.SP4#3 – Validar Build

P5.SP4#4 – Executar Teste

P5.SP4#5 – Manter / Melhorar Vantagens do Teste

4.5.5.3.4.2. Papéis envolvidos

Papéis Responsabilidades

Gerente de Teste

1. Avaliar o Projeto Lógico a fim de definir as metas,

objetivos dos testes no escopo do projeto, os itens-alvo,

a abordagem adotada, os recursos necessários e os

produtos que serão liberados, elaborando assim, o Plano

de Testes.

2. Verificar a forma mais eficaz de utilizar os recursos de

teste.

288

Analista de Teste

1. Identificar idéias de teste a serem executados durante

a iteração;

2. Identificar elementos que deverão ser testados;

3. Atualizar o Plano de Teste com os objetivos e metas

encontrados durante a atividade;

4. Definir a estratégia de avaliação para o esforço de

teste.

5. Definir os testes e dados de teste.

6. Liberar produto para execução de testes abrangentes

quando o build estiver estável e passível de testes.

7. Avaliar o Log de Teste e Solicitações de Mudança

elaboradas durante a execução do teste;

8. Relatar as falhas ocorridas em uma Lista de

Problemas;

9. Elaborar o Sumário de Avaliação de Testes relatando

os resultados dos testes.

10. Elaborar Guia de Teste com as idéias de teste

catalogadas;

Designer de Teste

1. Avaliar Abordagem do Teste

2. Identificar e descrever as técnicas de teste

apropriadas;

3. Definir e manter a Arquitetura de Automatização de

Teste

4. Identificar necessidades do ambiente para execução

dos testes.

5. Avaliar guia de teste existente, fazer adaptações,

elaborar guia de teste.

6. Identificar os elementos físicos necessários para

permitir testes em cada Configuração de Ambiente de

Teste, bem como, definir os requisitos de design de

software que deverão ser atendidos.

Testador 1. Verificar funcionamento do script de teste;

289

2. Executar os testes de acordo com o script de teste;

3. Executar testes para avaliação do build recebido;

4. Manter os Dados de teste utilizado na validação do

build para utilização em testes maiores.

5. Alimentar Log de Teste;

6. Avaliar as falhas ocorridas e corrigi-las caso tenham

sido geradas por erro de aplicação do procedimento de

teste.

7. Listar problemas e idéias de testes

Figura 4.72 – Quadro de papéis do subprocesso P5.SP4

290

4.5.5.3.4.3. Detalhamento do subprocesso

291

Figura 4.73 – Quadro de detalhamento do subprocesso P5.SP4

Subprocesso P5.SP4.#1: Definir Foco do Teste

Atividade: Identificar Motivadores do Teste Propósito: Analisar o Projeto Lógico com o intuito de elaborar o Plano de Testes, identificando itens, incluindo eventos e artefatos, que servirão como base para o teste nesta iteração. Passos: - Obter uma noção inicial dos objetivos específicos; - Relacionar itens motivadores para o teste. Artefatos de Entrada: - Projeto Lógico - Plano de Iteração

Artefatos de Saída: - Plano de Teste

Freqüência: Várias vezes durante cada iteração. Ator: Gerente de Teste

Atividade: Identificar Idéias e Objetivos de Teste Propósito: Identificar idéias para os testes e elementos de sistema (hardware/software) que devem ser explorados nos testes, atualizando o Plano de Teste com essas informações. Passos: - Avaliar o Modelo de Design, Implantação e de Caso de Uso; - Atualizar o Plano de Teste com todos os objetivos e metas identificados nesta atividade; - Relacionar idéias de Teste; - Gerar Guia de Teste contendo o catálogo de Idéias de Teste. Artefatos de Entrada: - Plano de iteração; - Modelo de Caso de Uso;

Artefatos de Saída: - Plano de Teste; - Lista de Idéias;

292

- Modelo de Design; - Modelo de Implantação.

- Guia de Teste.

Freqüência: Várias vezes durante cada iteração. Ator: Analista de Teste

Figura 4.74 - Conjunto de Atividades do subprocesso P5.SP4.#1 Subprocesso P5.SP4.#2: Verificar Abordagem do Teste

Atividade: Identificar Necessidades do Teste Propósito: identificar necessidades de ambiente e de recursos para o esforço do teste. Passos: - Definir requisitos de ambiente e recursos necessários; - Compreender a arquitetura do software e seu relacionamento com os ambientes-alvo de implantação. - Identificar os possíveis mecanismos de teste necessários para a abordagem de teste. - Comunicar as decisões tomadas sobre os mecanismos de teste necessários. Artefatos de Entrada: - Arquitetura para Automatização de Testes

Artefatos de Saída: - Configuração do Ambiente de Teste; - Arquitetura para Automatização de Testes; - Script de Teste.

Freqüência: Várias vezes por cada iteração Ator: Designer de Teste

Atividade: Definir Detalhes do Teste Propósito: Definir condições necessárias para realizar uma idéia de teste, bem como, identificar pontos de observação e previsões de teste, além de

293

registrar Dados de Teste válidos para facilitar os testes. Passos: - Obter uma noção detalhada do Item de Teste-Alvo com base nas possíveis Idéias de Teste; - Projetar o Teste para cada idéia de teste; - Identificar a entrada, a saída e as condições de execução; - Definir fontes de dados, valores e faixas necessárias; - Elaborar o documento de arquitetura para automatização de testes. Artefatos de Entrada: - Plano de Teste; - Lista de Idéias de Teste.

Artefatos de Saída: - Caso de Teste; - Modelo de Análise de Carga de Trabalho; - Documento de Arquitetura para Automatização de Testes.

Freqüência: Várias vezes por cada iteração Ator: Analista de Teste

Atividade: Implementar Teste Propósito: Implementar testes a fim de validar o produto para um teste maior e mais abrangente. Passos: - Determinar a técnica apropriada para a implementação do teste; - Implementar corretamente um Script de Teste; - Verificar se o funcionamento do Script de Teste está correto executando-o; Artefatos de Entrada: - Configuração do Ambiente de Teste; - Arquitetura para Automatização de Testes; - Script de Teste; - Caso de Teste.

Artefatos de Saída: - Conjunto de Teste; - Script de Teste; - Guia de Teste.

Freqüência: Várias vezes por cada iteração Ator: Testador

Figura 4.75 - Conjunto de Atividades do subprocesso P5.SP4.#2

294

Subprocesso P5.SP4.#3: Validar Build

Atividade: Implementar Teste

Propósito: executar pré-teste com o objetivo de validar o build para testes mais específicos na seqüência do fluxo. Passos: - Aplicar teste para validar build; - Gerar solicitação de Mudança se necessário. Artefatos de Entrada: - Build; - Conjunto de Testes; - Caso de Teste; - Lista de Idéias de Teste;

Artefatos de Saída: - Solicitação de Mudança; - Log de Testes.

Freqüência: Várias vezes por iteração Ator: Testador

Atividade: Analisar Falha Propósito: Analisar as falhas geradas durante a implementação do teste. Passos: - Verificar o Log de Testes - Corrigir as falhar geradas devido ao procedimento de teste aplicado; - Relatar descobertas de problemas por meio de solicitações de mudança. Artefatos de Entrada: - Log de Testes.

Artefatos de Saída: - Solicitação de Mudança.

Freqüência: Várias vezes por iteração Ator: Testador

Atividade: Determinar Resultados do Teste

295

Propósito: Relatar os resultados dos testes executados propondo correções. Passos: - Avaliar o Log de Testes; - Avaliar a Solicitação de Mudança; - Relatar no Sumário de Avaliação do Teste os resultados e propor correções se necessário. - Relacionar falhas que não puderam ser resolvidas em uma Lista de problemas. -Encaminhar Build, juntamente com a Lista de Problemas e Solicitação de Mudança para a “Execução da Demanda” corrigir o build reprovado no teste. Artefatos de Entrada: - Log de Testes; - Solicitação de Mudança.

Artefatos de Saída: - Resultados do Teste; - Sumário de Avaliação do Teste; - Lista de Problemas.

Freqüência: Várias vezes por iteração Ator: Analista de Teste

Figura 4.76 - Conjunto de Atividades do subprocesso P5.SP4.#3 Subprocesso P5.SP4.#4: Executar Teste

Atividade: Executar Conjunto de Testes

Propósito: executar os testes no build. Passos: - Executar os testes no build de acordo com técnicas pré-estabelecidas no Plano de Teste;

296

- Listar problemas encontrados durante o teste; - Listar idéias de teste; - Elaborar solicitação de mudança quando necessário. Artefatos de Entrada: - Build; - Script de Teste; - Conjunto de Teste; - Dados de Teste; - Caso de Teste.

Artefatos de Saída: - Lista de Problemas; - Solicitação de Mudança; - Log de Teste; - Lista de Idéias de Teste.

Freqüência: Várias vezes por iteração. Ator: Testador

Atividade: Analisar Falha de Teste Propósito: Analisar as falhas geradas durante a implementação do teste. Passos: - Verificar o Log de Testes - Corrigir as falhar geradas devido ao procedimento de teste aplicado; - Relatar descobertas de problemas por meio de solicitações de mudança. Artefatos de Entrada: - Log de Teste.

Artefatos de Saída: - Solicitação de Mudança.

Freqüência: Várias vezes por iteração. Ator: Testador

Atividade: Verificar Mudanças no Build Propósito: Analisar e testar as mudanças no build Passos: - confirmar a conc lusão de solicitações de mudança executando testes; - relatar resultados dos testes executados no build alterado. Artefatos de Entrada: - Solicitação de Mudança.

Artefatos de Saída: - Resultado do Teste.

Freqüência: Várias vezes por iteração Ator: Analista de Teste

Atividade: Identificar / Executar Idéias do Teste Propósito: identificar e executar as idéias de teste que devem ser exploradas. Passos: - analisar a lista de idéias de teste; - definir detalhes para a execução de idéias de teste. Artefatos de Entrada: - Lista de Idéias de Teste

Artefatos de Saída: - Lista de Idéias de Teste; - Dados de Teste; - Caso de Teste; - Modelo de Análise de Carga de Trabalho.

Freqüência: Várias vezes por iteração Ator: Analista de Teste

Atividade: Determinar Resultados de Teste Propósito: Avaliar a qualidade do produto testado e relatar os resultados dos testes executados propondo correções. Passos: - Examinar o Log de Teste - Avaliar Solicitações de Mudança;

297

- Relatar no Sumário de Avaliação do Teste os resultados e propor correções se necessário. - Relacionar falhas que não puderam ser resolvidas em uma Lista de problemas. Artefatos de Entrada: - Log de Testes; - Solicitação de Mudança.

Artefatos de Saída: - Resultados do Teste; - Sumário de Avaliação do Teste; - Lista de Problemas.

Freqüência: Várias vezes por iteração Ator: Analista de Teste

Figura 4.77 - Conjunto de Atividades do subprocesso P5.SP4.#4 Subprocesso P5.SP4.#5: Manter / Melhorar Vantagens do Teste

Atividade: Desenvolver Guia de Teste

Propósito: elaborar guia contendo práticas, ajustes táticos e conhecimento do processo de teste. Passos: - Identificar guias existentes para reutilização; - Fazer adaptações; Artefatos de Entrada: - Sumário de Avaliação de Testes.

Artefatos de Saída: - Guia de Teste (abordagem do teste)

Freqüência: a cada ajuste necessário Ator: Designer de Teste

Atividade: Definir Elementos de Testabilidade Propósito: Identificar os elementos físicos necessários para permitir testes em cada Configuração de Ambiente de Teste, bem como, definir os requisitos de design de software que deverão ser atendidos. Passos: - Identificar os elementos da infra-estrutura de teste - Identificar as necessidades de design específicas de teste

298

- Especificar os requisitos das funções de software necessárias para suportar a implementação e a execução de testes. Artefatos de Entrada: - Sumário de Avaliação de Testes.

Artefatos de Saída: - Script de Teste.

Freqüência: a cada iteração. Ator: Designer de Teste

Atividade: Definir Necessidades e Idéias Propósito: identificar as necessidades e idéias a serem melhoradas no processo. Passos: - Elaborar Guia de Teste com as idéias de teste catalogadas; - Definir a estratégia de avaliação para o esforço de teste. Artefatos de Entrada: - Sumário de Avaliação de Testes.

Artefatos de Saída: - Guia de Teste (idéias de teste); - Dados de Teste; - Plano de Teste;

Freqüência: a cada iteração. Ator: Analista de Teste

Atividade: Implementar Teste Propósito: implementar testes a fim de validar as melhorias e vantagens do teste. Passos: - Determinar a técnica apropriada para a implementação do teste; - Implementar corretamente um Script de Teste; - Verificar se o funcionamento do Script de Teste está correto executando-o; Artefatos de Entrada: - Sumário de Avaliação de Testes.

Artefatos de Saída: - Guia de Teste (automatização de teste); - Script de Teste; - Plano de Teste.

Freqüência: a cada iteração. Ator: Testador

Figura 4.78 - Conjunto de Atividades do subprocesso P5.SP4.#5

4.5.5.3.5. Subprocesso 5 (SP5): implantação beta (P5.SP5)

4.5.5.3.5.1. Descrição e objetivos

O processo tem como objetivo, a implantação de uma versão não definitiva do

produto a fim de obter o aceite do cliente para a implantação definitiva.

299

O processo de implantação pode ser realizado em um ambiente da Fábrica

configurado exatamente com as mesmas características tecnológicas do ambiente

em que estará em produção ou ser implantado diretamente em um ambiente de

produção na empresa do cliente para testes do usuário final.

Para a implantação do produto BETA, a principio, é necessário realizar o

planejamento de como será feita a implantação verificando quais serão as

necessidades, e, em seguida, a elaboração do material de suporte com o intuito de o

usuário utilizar o sistema corretamente.

Gera-se então, uma unidade de implantação, ou seja, a versão BETA do

sistema, material de suporte, de treinamento e demais artefatos necessários para a

implantação.

Após esse momento, o produto é implantado para testes do usuário final a fim

de que seja verificado o funcionamento. Se forem verificadas necessidades de

alterações ou forem encontrados defeitos no sistema, o produto retorna ao processo

de Execução de Testes (P5.SP4) juntamente com as anotações de

alterações/correções para elaboração da Solicitação de Mudança e Lista de

Problemas Encontrados que serão encaminhados para o pessoal de Execução de

Demanda (P5.SP3) para que as alterações/correções sejam executadas.

Caso o sistema seja aprovado na Implantação BETA, o cliente homologa o

produto para a implantação definitiva em ambiente de produção.

Para a realização desse processo, as seguintes subdivisões deverão ser

executadas:

P5.SP5.#1 - Planejar Implantação BETA

P5.SP5.#2 - Desenvolver Material de Suporte e Treinamento

P5.SP5.#3 - Implantar Produto BETA

300

P5.SP5.#4 - Executar Testes no produto BETA implantado

4.5.5.3.5.2. Papéis envolvidos

Papéis Responsabilidades

Gerente de Projetos

1. Deverá designar o Gerente da equipe de Implantação

e acompanhar as fases de tomada de decisão.

2. Executar a inclusão do Plano de Implantação e Lista

de Materiais no repositório de modelos;

Gerente de

Implantação

1. Deverá assegurar a que a implantação seja feita

dentro do prazo e recursos estabelecidos.

2. Coordenar e designar equipe de implantação.

3. Elaborar o Plano de Implantação, Plano de Aceitação,

Lista de Materiais.

4. Escrever Notas de Release

5. Emitir solicitação de mudança / correções, se

necessário;

6. Gerenciar os testes para aceitação do produto

7. Avaliar os resultados dos testes;

8. Obter o aceite do cliente para a implantação definitiva;

9. Liberar produto para implantação definitiva quando

todos os testes tiverem sido aplicados, as solicitações de

mudanças atendidas e o produto não apresentar

defeitos.

Implementador 1. Desenvolver Artefatos de Instalação do produto

BETA.

Desenvolvedor do

Treinamento

1. Desenvolver material de treinamento para ensinar os

usuários a utilizar o produto.

Redator técnico 1. Elaborar o material de suporte para o usuário final,

como manuais do usuário e textos da ajuda.

Cliente 1. Acompanhar o processo de teste de aceitação do

produto.

301

Usuários

1. Utilizar o programa BETA para fins de testes

comunicando o gerente de implantação caso sejam

encontrados defeitos ou correções a serem feitas.

Figura 4.79 – Quadro de papéis do subprocesso P5.SP5

4.5.5.3.5.3. Detalhamento do subprocesso

Figura 4.80 – Quadro de detalhamento do subprocesso P5.SP5

302

Subprocesso P5.SP5.#1: Planejar Implantação BETA

Atividade: Desenvolver plano de implantação Propósito: Documentar e assegurar que o produto seja disponibilizado nos meios e prazos acordados. Passos: - Planejamento de distribuição, instalação e migração. - Treinamento ao usuário - Suporte ao usuário Artefatos de Entrada: - Project charter - Plano de Iteração

Artefatos de Saída: - Plano de Implantação

Freqüência: assim que o Project charter for concluído. Ator: Gerente de projetos e gerente de implantação

Atividade: Desenvolver lista de materiais Propósito: Criar uma lista de artefatos contendo documentos, itens de configuração de software e scripts de instalação que compõem o produto. Passos: - Controlar itens liberados - Atualização da lista de materiais Artefatos de Entrada: - Project charter - Plano de Iteração

Artefatos de Saída: - Lista de materiais

Freqüência: assim que o Project charter for concluído. Ator: Gerente de projetos e gerente de implantação

Figura 4.81 - Conjunto de Atividades do subprocesso P5.SP5.#1

303

Subprocesso P5.SP5.#2: Desenvolver Material de Suporte e Treinamento

Atividade: Desenvolver material de suporte Propósito: Analisar os artefatos de entrada a fim de elaborar todo o material de suporte ao usuário. Passos: - Analisar telas de interface do usuário - Analisar funcionamento do produto (build). - Elaborar o material de suporte ao usuário - Reproduzir o material de suporte ao usuário Artefatos de Entrada: - Project Charter - Protótipo de Interface do Usuário - Build

Artefatos de Saída: - Material de Suporte

Freqüência: após aprovação do build pelo processo de testes. Ator: Redator Técnico e Desenvolvedor do Treinamento

Atividade: Desenvolver material de treinamento Propósito: Criar uma lista de artefatos contendo documentos, itens de configuração de software e scripts de instalação. Passos: - Controlar itens liberados - Atualização da lista de materiais Artefatos de Entrada: - Project charter - Plano de implantação

Artefatos de Saída: - Lista de materiais

Freqüência: após aprovação do build pelo processo de testes. Ator: Redator Técnico e Desenvolvedor do Treinamento

Figura 4.82 - Conjunto de Ati vidades do subprocesso P5.SP5.#2

304

Subprocesso P5.SP5.#3: Implantar Produto BETA

Atividade: Implantar o Produto Propósito: Instalar uma versão BETA do software desenvolvido para obter o feedback de um conjunto de usuários. Passos: - Instalar a versão BETA do produto de acordo com o plano de Implantação; Artefatos de Entrada: - Unidade de Implantação (em Configuração e Mudança) - Plano de Implantação;

Artefatos de Saída:

Freqüência: ao final da fase de testes. Ator: Gerente de Implantação

Figura 4.83 - Conjunto de Atividades do subprocesso P5.SP5.#3

Subprocesso P5.SP5.#4: Executar Testes no produto BETA implantado

Atividade: Gerenciar Testes de Aceitação Propósito: Avaliar os testes executados pelos usuários finais do produto, a fim de validar a aceitação do produto. Passos: - Configurar o ambiente (hardware / software); - Executar conjunto de testes; - Avaliar os resultados dos testes executados pelos usuários; - Obter Aceite do cliente para a implantação caso os usuários não tenham

305

encontrado problemas; - Emitir solicitações de mudanças / correções, caso tenham sido encontradas anormalidades no produto. Artefatos de Entrada: - Plano de Implantação; - Resultados dos testes (em testes); - Plano de Aceitação do Produto.

Artefatos de Saída: - Solicitações de Mudanças / correções; - Aceite do Cliente;

Freqüência: ao final da fase de testes. Ator: Gerente de Implantação

Figura 4.84 - Conjunto de Atividades do subprocesso P5.SP5.#4

4.5.6. Processo de homologação (P6)

4.5.6.1. Objetivos

O processo de homologação tem por objetivo obter o sign-off de qualquer

artefato gerado pela fábrica e que necessite de aceite, no sentido de liberar o

produto resultante para o cliente. Ele deve estar de posse de todas as evidências de

que os requisitos da OS foram cumpridos de forma que o cliente possa formalizar

seu recebimento e término. Além disso, ele contempla a gestão do interfaceamento

operacional com os clientes e usuários e contemplam:

• Recebimento de documentos e complementos;

• Liberação de OS em termos de atendimento e homologadas;

• Encaminhamento de artefatos para as células da fábrica;

• Realização do processo de comunicação com o cliente (ponto de contato);

• Negociação de prioridades com o cliente.

306

4.5.6.2. Políticas

A Gerência de Homologação da Fábrica de Projetos de Software, abaixo

define e faz cumprir, as seguintes políticas que orientam as atividades relacionadas

à execução do Processo de Homologação.

Descrição das Políticas

• Do lado do cliente, deve haver um responsável por organizar a demanda e

enviá-la para a fábrica, gerenciar os níveis de serviço, as questões

contratuais e demais negociações.

• Do lado da fábrica, existirá um revisor de documentos responsável pelo

recebimento das ordens de serviço e pela expedição do produto para o

cliente;

• O processo de gerenciamento (PMO) deverá indicar um participante para

auxiliar o processo de análise da OS, especificamente um membro da SQA;

• Uma ordem de serviço pode ser recusada se não estiver no padrão

estabelecido;

• O cliente pode enviar complemento a qualquer momento para a fábrica;

• O cliente deve ter acesso a informações sobre o progresso da execução de

sua ordem de serviço;

• O cliente pode substituir, solicitar cancelamento e a suspensão de ordens

de serviço, porém o processo de gerenciamento deverá homologar a

solicitação.

• Uma ordem de serviço pode retornar para a fábrica de Programas para ser

consertada (processo de feedback);

• Todos os documentos que percorrem o fluxo operacional da fábrica de

software deverão seguir o workflow criado, fazendo circular produtos

(solicitações, documentos, códigos, módulos de software) no sistema de

informação gerencial;

• Os documentos a serem enviados deverão sofrer a análise para o

entendimento do encaminhamento, devendo este processo realizar o follow-

up para monitorar a entrega correta;

• Nos momentos em que forem necessárias aprovações do cliente, este

307

processo sinalizará o documento e realizará o acompanhamento dos prazos

de retorno.

• Este processo deve estar de posse das evidências de que os requisitos da

ordem de serviço (ou qualquer outro artefato) foram cumpridos de forma que

o cliente possa formalizar seu recebimento e término

• Todos os documentos a serem ratificados pelo cliente deverão percorrer

este processo;

• Realizar revisões conjuntas com o ponto de contato do cliente através de

reuniões programadas para a avaliação e acompanhamento de

desempenho do projeto;

• Nessas reuniões, serão tomadas decisões conjuntas visando à

implementação de ações corretivas e preventivas no projeto, assim como

direcionamentos;

• A implantação definitiva deve ocorrer somente quando o produto BETA

estiver homologado pelo cliente (subprocesso P5.SP5).

• O produto final deve ser gerenciado e avaliado pelo Gerente de

Implantação;

• O Gerente de Implantação deve acompanhar todo o processo implantação

do produto, bem como, avaliar o funcionamento para verificação de

mudanças necessárias e/ou defeitos existentes.

• Devem participar da execução do subprocesso P6.SP1 – Realizar

Implantação, um Testador para implementar um conjunto de testes, o

Cliente e um Gerente de Implantação, para avaliar o produto em

funcionamento;

• Um repositório de informações deverá ser alimentado com todas as

informações relevantes ao que tange a implantação definitiva do produto,

bem como, informações sobre boas práticas e lições aprendidas;

• Material de Suporte e Material de Treinamento devem ser reproduzidos de

acordo com quantidade prevista no Plano de Implantação.

• Um conjunto de testes baseado em um subconjunto selecionado dos testes

já existentes deve ser executado para garantir o funcionamento e

estabilidade do produto implantado;

• O subprocesso P6.SP1 deve ser finalizado mediante a Carta de

308

Encerramento assinada pelo Cliente.

Figura 4.85 – Quadro de políticas do processo de Homologação

4.5.6.3. Subprocessos do processo (P6)

4.5.6.3.1. Subprocesso 1 (SP1): implantação – ambiente: produção

(P6.SP1)

4.5.6.3.1.1. Descrição e objetivos

O processo tem como objetivo, a implantação definitiva do software no

ambiente de produção, ou seja, na empresa do cliente.

Após o aceite do cliente quanto ao funcionamento do sistema em versão

BETA (P5.SP5), inicia-se a implantação definitiva do sistema.

Partindo do princípio que na conclusão da implantação BETA, ou seja, ao

obter o aceite do cliente naquela fase, todo o material de suporte ao usuário,

treinamento, bem como, o produto em si estão de acordo com o esperado, pois,

mesmo que os usuários por ventura solicitaram alterações no sistema, os artefatos

foram atualizados no decorrer das iterações do processo de implantação BETA

(P5.SP5), resta a este processo executar a implantação definitiva em todo o

ambiente de produção.

Ao final da implantação, o Gerente de Implantação obtém a Carta de

Encerramento junto ao cliente para finalização dos trabalhos. Após isso, o repositório

de informações de implantações é alimentado com todos as informações relevantes

do projeto recém finalizado.

Por fim, a carta de encerramento é encaminhada ao processo P3.SP3 para a

finalização da demanda na Fábrica.

309

Para a realização desse processo, as seguintes subdivisões deverão ser

executadas:

P6.SP1.#1 - Implantar Produto

P6.SP1.#2 - Finalizar trabalhos

4.5.6.3.1.2. Papéis envolvidos

Papéis Responsabilidades

Gerente de Projetos 1. Acompanhar as fases de tomada de decisão durante

a implantação.

Gerente de

Implantação

1. Deverá assegurar a que a implantação seja feita

dentro do prazo e recursos estabelecidos.

2. Coordenar e designar equipe de implantação.

3. Obter a carta de encerramento assinada pelo cliente

4. Alimentar repositório de informações sobre a

implantação executada

5. Encaminhar ao processo de Finalização da Demanda

a carta de encerramento assinada pelo cliente.

Cliente 1. Acompanhar o processo de implantação do produto.

Figura 4.86 – Quadro de papéis do subprocesso P6.SP1

310

4.5.6.3.1.3. Detalhamento do subprocesso

Figura 4.87 – Quadro de detalhamento do subprocesso P6.SP1

Subprocesso P6.SP1.#1: Implantar Produto

Atividade: Implantar o Produto Propósito: Instalar versão definitiva do software desenvolvido no ambiente de produção. Passos: - Instalar a versão BETA do produto de acordo com o plano de Implantação. Artefatos de Entrada: - Unidade de Implantação (em Configuração e Mudança) - Plano de Implantação;

Artefatos de Saída:

Freqüência: após a implantação beta do sistema. Ator: Gerente de Implantação

Figura 4.88 - Conjunto de Atividades do subprocesso P6.SP1.#1

311

Subprocesso P6.SP1.#2: Finalizar trabalhos

Atividade: Finalizar Trabalhos de Implantação Propósito: encerrar as atividades de implantação armazenando em repositório de informações todos os registros importantes do projeto realizado. Passos: - Obter a Carta de Encerramento assinada pelo cliente; - Finalizar os trabalhos de implantação no local de produção; - Registrar em repositório de informações sobre implantações de sistemas todos os registros importantes sobre o projeto finalizado; - Encaminhar a Carta de Encerramento para o P3.SP3 – Finalizar Demanda. Artefatos de Entrada: - Carta de Encerramento (assinada pelo cliente).

Artefatos de Saída: - Carta de Encerramento (assinada pelo cliente). - Repositório de Informações.

Freqüência: após o aceite do cliente quanto ao funcionamento do sistema BETA. Ator: Gerente de Implantação

Figura 4.89 - Conjunto de Atividades do subprocesso P6.SP1.#2

4.5.6.3.2. Subprocesso 2 (SP2): aceite do cliente (P6.SP2)

4.5.6.3.2.1. Descrição e objetivos

Este subprocesso realiza as atividades de análise e envio de artefatos para

sign-off, ou seja, realizar revisão conjunta com o cliente para o processo de

comunicação do projeto. Além disso, deve analisar o material enviado à fábrica, de

312

forma a entender a estrutura do documento e se está dentro dos padrões definidos

pela fábrica.

Objetivo: Realizar o interfaceamento e o gerenciamento dos artefatos que

necessitem de sign-off pelo cliente.

4.5.6.3.2.2. Papéis envolvidos

Papéis Responsabilidades

Revisor

1. Realizar o ponto de contato entre o cliente o fornecedor;

2. Recepcionar a documentação e encaminhá-la para

análise conjunta com a equipe de qualidade;

3. Acompanhar o encaminhamento do material.

SQA (Software

Quality Assurance)

1. Identificar modelos de documentos existentes;

2. Comparar o documento recebido com o conhecimento

armazenado nos processos de registro;

3. Estudar cada documento e realizar a sua correta

distribuição para as células;

4. Acompanhar o recebimento e o aceita dos envolvidos.

5. Realizar o levantamento de todas evidências para a

aprovação do cliente;

6. Manter reuniões conjuntas para avaliação;

7. Criar mecanismos de ações preventivas e corretivas,

quando necessárias (feedback doc cliente nas

revisões);

8. Acompanhar e garantir o retorno do documento.

313

Gerente de Projeto

1. Garantir o cumprimento das atividades de

encaminhamento dos artefatos aos envolvidos;

2. Criar mecanismos de controle para realizar o contato

com outros processos, quando necessário.

3. Deve garantir a posse das evidências pela equipe de

revisão;

4. Monitorar o cumprimento de sign-off do cliente de

documentos que necessitem de tal comportamento.

5. Designar equipe de homologação para determinado

evento.

Figura 4.90 – Quadro de papéis do subprocesso P6.SP2

314

4.5.6.3.2.3. Detalhamento do subprocesso

Os conjuntos de atividades do subprocesso P6.SP2 são: Avaliar o documento

(P6.SP2.#1), encaminhar o documento para o responsável (P6.SP2.#2), sign-off do

cliente (P6.SP2.#3), os quais serão detalhados abaixo.

Figura 4.91 – Quadro de detalhamento do subprocesso P6.SP2

315

Subprocesso P6.SP2.#1: Avaliar o documento

Atividade: Receber Ordem de Serviço

Propósito: Criar um ponto de contato entre o cliente e o fornecedor, no sentido de entender o modelo de documento Passos: - Receber documentação; - Identificar padrão a ser comparado; - Verificar pontos a serem modificados; Artefatos de Entrada: - Ordem de Serviço; - Especificações Suplementares;

Artefatos de Saída: - Ordem de Serviço (padronizada)

Freqüência: a cada evento de avaliação Ator: Revisor e SQA

Atividade: Executar Avaliação Propósito: Criar um procedimento que padronize os documentos a serem encaminhados para as próximas etapas. Passos: - Executar a modificação; - Reescrever o documento (caso necessário); - Manter ordem de serviço padronizada. Artefatos de Entrada: - Ordem de Serviço (padronizada)

Artefatos de Saída: - Ordem de Serviço (revisada)

Freqüência: a cada evento de avaliação Ator: SQA

Figura 4.92 - Conjunto de Atividades do subprocesso P6.SP2.#1

316

Subprocesso P6.SP2.#2: Encaminhar o documento para o responsável

Atividade: Especificar o responsável

Propósito: Entender o tipo de documento existente no fluxo e designar uma entidade responsável para o encaminhamento correto do artefato. Passos: - Avaliar tipo de documento; - Comparar com modelos existentes; - Identificar possíveis responsáveis; - Mitigar dúvidas existentes com recursos; Artefatos de Entrada: - Ordem de Serviço (revisada) - Especificações Suplementares

Artefatos de Saída: - Guia de procedimento - Registro de Revisão

Freqüência: a cada evento de homologação Ator: Gerente de Projetos

Atividade: Acompanhar o procedimento Propósito: Executar o acompanhamento Passos: - Comunicar célula envolvida; - Realizar o encaminhamento do material; - Manter o mecanismo de protocolos para garantir o recebimento; Artefatos de Entrada: - Guia de procedimento - Registro de Revisão

Artefatos de Saída: - Ordem de Serviço (revisada)

Freqüência: a cada evento de homologação Ator: SQA

Figura 4.93 - Conjunto de Atividades do subprocesso P6.SP2.#2

317

Subprocesso P6.SP2.#3: Sign-off do cliente

Atividade: Identificar documento

Propósito:Entender o modelo de documento a ser aprovado pelo cliente Passos: - Receber os documentos da atividade de avaliação; - Analisar e comparar com modelos existentes; - Levantar todas as evidências para a aprovação do documento - Criar um relatório que demonstre claramente os objetivos da reunião Artefatos de Entrada: - Ordem de Serviço; - Registro de Revisão.

Artefatos de Saída: - Relatório de Revisão

Freqüência: a cada evento de homologação Ator: SQA

Atividade: Realizar acompanhamento Propósito: Executar as revisões com o cliente e acompanhar o procedimento de retorno do relatório Passos: - Estudar o relatório criado; - Montar uma estratégia para a produção da reunião; - Realizar a revisão conjunta; - Criar um mecanismo de retorno à fábrica de ações preventivas e corretivas; - Solicitar a aprovação do cliente - Registrar lições aprendidas. Artefatos de Entrada: - Relatório de Revisão

Artefatos de Saída: - Relatório de Revisão (ratificado)

Freqüência: a cada evento de homologação Ator: Gerente de projetos e SQA

Figura 4.94 - Conjunto de Atividades do subprocesso P6.SP2.#3

318

4.6. Guia de implantação dos processos mapeados

Com a explicitação dos processos gerenciais e operacionais da fábrica e os

seus respectivos detalhamentos nos subprocessos envolvidos, deve-se demonstrar

a estruturação da sistemática de atividades que convergirão na implantação

adequada do workflow operacional. Este guia identifica quatro fases principais e,

dentro de cada uma, alguns passos, ou dicas, de como proceder à implantação do

modelo.

Deve-se destacar que a implantação de uma nova forma de trabalho não é

uma tarefa simples, mas que envolve mudanças significativas na cultura da

empresa, assim como definições e redefinições políticas (KRUCHTEN, 2000).

A implantação deve estar fortemente apoiada e entendida pela equipe

envolvida, pois afetará diretamente os profissionais, no que se refere às tarefas

diárias e à motivação para executá -las.

As fases da implantação destes modelos de construção de software sugeridas

neste estudo são: concepção, planejamento, implantação e avaliação. Cada uma

dessas fases será descrita a seguir:

4.6.1. Concepção

Antes de se conceber o projeto de implantação da Fábrica, deve-se realizar

um diagnóstico da organização, através de entrevistas, observação e coleta de

resultados de projetos já realizados. Como resultado deste diagnóstico, devem-se

identificar os pontos fortes e fracos da atual situação, a fim de facilitar a implantação

e determinar a quais aspectos deve ser dada maior atenção.

319

Feito o diagnóstico, na concepção da implantação devem ser estudados: o

modelo de processo de desenvolvimento, o método de gerenciamento de projetos

(alguns modelos processos de desenvolvimento já possuem fluxos específicos de

gerenciamento), e a certificação da qualidade de software buscada pela

implantação, no caso o CMMi. Nesta fase deve-se ouvir a opinião de toda a equipe e

buscar apoio da gerência, mostrando através de um pré-projeto quais os benefícios

de se usar o modelo de fábrica de projetos e os parâmetros escolhidos como

referências (processo, projeto, qualidade).

Os passos para esta fase são:

• Estudar a proposta do modelo de fábrica de projetos de software;

• Realizar diagnóstico da organização, identificando pontos fracos e fortes da

forma de trabalho atual;

• Demonstrar o processo de desenvolvimento a ser adotado pela equipe;

• Disseminar o método de gerenciamento de projetos que será utilizado;

• Colocar os objetivos de qualidade a serem atingidos;

• Definir um pré-projeto para a Implantação, contendo pontos como: objetivos a

serem alcançados; justificativas para os parâmetros de processo, gerência e

qualidade escolhidos; estimativa de custos; e benefícios da implantação;

• Obter aprovação gerencial.

• Publicar pré-projeto aprovado para a equipe.

4.6.2. Planejamento

A fase de planejamento é iniciada após aprovação do pré-projeto definido na

fase de concepção e consiste basicamente em gerar um projeto que descreva passo

320

a passo “o que” tem que ser realizado, “quando”, por “quem” e “quanto” irá custa r, a

fim de alcançar os objetivos definidos dentro do framework explicitado nas seções

anteriores deste trabalho.

Todos os membros da equipe deverão poder participar de alguma forma do

processo de elaboração, objetivando fazê-los parte do processo, minimizando assim

rejeições e nivelando as informações.

As prioridades do projeto devem ser decididas de acordo com os riscos

identificados para cada tarefa, ou ainda pela análise do diagnóstico realizado na fase

de concepção, guiando a implantação a iniciar pelos pontos mais críticos no modelo

de trabalho utilizado.

É importante ressaltar que algumas tarefas do projeto podem ser desmembradas

em sub-projetos, uma vez que atividades como “implantar processo de

desenvolvimento” requerem um esforço considerável da equipe envolvida. Os

passos desta fase são:

• Elaborar um projeto de implantação – vide processo de implantação de produto

no ambiente de produção.

• Obter aprovação gerencial;

• Publicar projeto aprovado para a equipe.

4.6.3. Implantação

A fase de implantação consiste na execução e validação das tarefas do projeto

criado na fase de Planejamento.

321

Quando a tarefa exigir que se utilize um projeto-piloto, o projeto-piloto deve ser o

mesmo para todas as tarefas do projeto de implantação. Os passos da implantação

são:

• Executar tarefas do projeto de implantação;

• Validar conclusão das tarefas;

• Publicar resultado de cada tarefa a nível gerencial;

• Publicar resultados para a equipe.

4.6.4. Avaliação

Ao final da execução do projeto os resultados devem ser avaliados para

identificar se os objetivos propostos foram alcançados, dentro do contexto dos

subprocessos de lições aprendidas do framework proposto. Caso tenha ocorrido

algum desvio não identificado nas validações individuais de cada tarefa, a equipe

deve redefinir um projeto complementar para corrigir o desvio e concluir com

sucesso a implantação do modelo de fábrica apresentado.

Os passos para a avaliação final são:

• Em reunião com os responsáveis por cada tarefa realizar análise dos resultados

de cada individuais e avaliar se os objetivos do projeto como um todo foram

atendidos;

• Caso necessário corrigir desvios;

• Apresentar resultado final a nível gerencial;

• Apresentar resultado final para a equipe.

322

Neste sentido, foi proposto um roteiro (modelo) de implementação da

operação estruturada nas seções anteriores deste capítulo. Desta forma, pode-se

utilizar as melhores práticas de gerência de projetos do PMBOK para realizar um

esboço de mapeamento e projeto de cada área no contexto de processos e áreas de

conhecimento do modelo. Além disso, torna-se possível aplicar as áreas de

processos do CMMI para a obtenção e melhoria da qualidade no projeto de

implementação e automatização dos processos, ou seja, na necessidade de se

instanciar os processos de construção de softwares da fábrica em um projeto de

automatização da operação.

4.7. Mapeamento dos processos da fábrica de software dentro do contexto

dos modelos estudados: RUP, PMBOK e CMMI

Como mencionado anteriormente, a Fábrica de Projetos de Software que este

trabalho objetivamente se propôs a modelar foi elaborada tomando como base

metodologias de construção de software, gerenciamento de projetos, garantia de

qualidade, dos quais se podem citar respectivamente RUP, PMBOK e CMMI.

4.7.1. Processos de engenharia de software na estrutura do processo

unificado Rational (RUP)

Para a construção do produto, ou seja, o software solicitado pelo cliente, foi

utilizado a metodologia Rational Unified Process (RUP) por ser um método

largamente utilizado e extremamente qualificado pelo mercado, sendo adaptável às

mais diversas formas de desenvolvimento de software.

323

Para o melhor entendimento de como o RUP foi adequado à Fábrica de

Software modelada, a figura 4.95 apresenta um comparativo de como as Disciplinas

e Atividades do RUP estão mescladas aos Processos e Subprocessos da Fábrica.

324

Figura 4.95 - Mapeamento dos processos da Fábrica de Projetos de Software no

contexto do processo unificado

325

Como podemos analisar na figura 4.95, o processo P5.SP2 foi elaborado de

acordo com as Disciplinas Modelagem de Negócios, Requisitos e Análise e Design

do RUP, ou seja, é durante a execução desse processo em que as regras de

negócios são identificadas, bem como é entendido o funcionamento da organização

em que o sistema deverá ser implantado. Além do que, é nesse momento em que

são identificados os requisitos funcionais do sistema, e, os casos de uso, modelo de

classes, diagramas de seqüência entre outros artefatos que são gerados para que o

processo de Execução da Demanda (P5.SP3) possa ser iniciado.

O Processo P5.SP3, abrange a Disciplina de implementação do RUP. É nesta

fase que o produto tem efetivamente seu código construído pelos programadores.

O sistema é desenvolvido em partes, ou seja, os componentes são

produzidos e testados para a seguir serem integrados ao subsistema.

Após a liberação dos componentes pelo processo de Execução da Demanda

(P3.SP3), inicia-se o processo P5.SP4, o qual foi modelado com os princípios da

Disciplina de Testes do RUP.

Os componentes recebidos são testados de acordo com o Plano de Testes

elaborado durante a fase de iniciação. Somente quando o componente não

apresentar defeitos ele é liberado para ser integrado ao subsistema ou ao sistema

final.

Os processos P5.SP4 e P6.SP1 equivalem ao processo de Implantação do

RUP e envolvem todo o planejamento de implantação, elaboração de materiais de

suporte ao usuário final, materiais de treinamento e, é nesse momento do processo

em que é executada a implantação BETA do sistema para uso de alguns usuários a

fim verificar se todas as solicitações foram atendidas, ou seja, se o sistema está

funcionando da maneira em que foi solicitado à Fábrica. Sendo o sistema aprovado

326

pelos usuários e pelo cliente, obtém-se o aceite para a implantação definitiva do

sistema (suprido pelo processo P6.SP1 – Realizar Implantação em Ambiente de

Produção).

4.7.2. Processos de gestão de projetos na estrutura do PMBOK

Como mencionado anteriormente, a Fábrica de Projetos de Software a ser

modelada no próximo capítulo, foi elaborada tomando como base metodologias de

construção de software, gerenciamento de projetos, garantia de qualidade, dos quais

se pode citar respectivamente RUP, PMBOK e CMMI.

Para a gerência de projetos foi utilizado o modelo PMBOK no sentido de

retirar as melhores práticas na gestão de execução das múltiplas demandas da

fábrica.

Para o melhor entendimento de ele foi adequado à Fábrica de Software

modelada, o quadros 4.2, 4.3 e 4.4 apresentam um comparativo de como as áreas

de conhecimento e processos estão mapeados nos Processos e Subprocessos da

Fábrica. A coluna conjunto de atividades demonstra os subprocessos alocados nos

processos de gestão da fábrica: estratégica, de qualidade e de projetos. Já a relação

das áreas de conhecimentos com os subprocessos ilustram os procedimentos dentro

do contexto da gerência de projetos preconizado pelo modelo PMBOK.

327

Quadro 4.2 – Mapeamento dos processos para integração, escopo e tempo

328

Quadro 4.3 – Mapeamento dos processos para custo, qualidade e RH

329

Quadro 4.4 – Mapeamento dos processos para comunicações, riscos e aquisições

4.7.3. Processos de gestão da qualidade na estrutura do CMMI

Conforme a descrição dos processos de qualidade (P2) da Fábrica de

Software modelada, a garantia da qualidade do processo de software visa prover

evidências sobre a capacidade do processo em produzir determinado produto,

330

identificando falhas nesse processo e buscando resolvê-las antes que impactem no

produto. A garantia da qualidade do produto de software, por sua vez, visa garantir

que o software produzido esteja em conformidade com requisitos funcionais e de

desempenho especificados; atenda aos padrões de desenvolvimento

documentados; seja o mais isento possível de erros; e atenda às características

implícitas esperadas pelo usuário.

Desta forma, após a demonstração dos processos e subprocessos de

qualidade da fábrica de projetos de software nas seções anteriores, será executado

um mapeamento das principais PA´s da estrutura estagiada, no sentido de se

identificar aquelas que estão implícitas no processo da qualidade, além da interação

entre eles. Assim, poder-se-á ter uma visão global dos componentes do modelo

presentes na operação e na sua gestão privilegiando as melhores práticas

existentes em cada área do processo. As principais áreas de processos são:

§ Medição e Análise (PA 2.5);

§ Garantia de qualidade do produto e do processo (PA 2.6);

§ Verificação (PA 3.4);

§ Validação (PA 3.5);

• Foco no processo organizacional (PA 3.6);

§ Gerenciamento de riscos (PA 3.10);

§ Análise e resolução de decisão (PA 3.12);

§ Performance do processo organizacional (PA 4.1);

§ Gerenciamento quantitativo do projeto (PA 4.2);

§ Análise de Causas e resolução (PA 5.2);

331

5. CONCLUSÃO

Este trabalho procurou estudar a modelagem dos processos gerenciais e

operacionais de uma fábrica de projetos de software.

O conceito de Fábrica de Software está baseado na idéia de prover uma linha

de produção de soluções que atendam às necessidades específicas de cada cliente.

Isto se dá através da formalização de todas as atividades e seus produtos,

trabalhando em forma de linha de produção, com etapas e tarefas bem definidas

para cada tipo de profissional, indo das tarefas básicas da linha de produção até

rotinas de controle de qualidade (CESAR, 2005).

Assim, com a alta especialização dos profissionais, cada um garante a

produtividade da etapa de produção em que está engajado e a qualidade do artefato

produzido para a etapa seguinte.

A definição de um processo para guiar o desenvolvimento é fundamental para

se conseguir qualidade e produtividade. Neste trabalho, apresenta-se um processo

padrão para o desenvolvimento de software orientado a objetos e definido que tem

por base o Processo Unificado. A escolha do RUP como ponto de partida deveu-se

ao fato do mesmo ser direcionado à tecnologia de objetos, já estar sendo utilizado

na prática e ter sido derivado a partir da experimentação. Contudo, julga-se ser

necessário adaptá-lo por duas razões principais: (i) considerar as características da

organização, procurando adaptar o jargão e utilizar práticas já consagradas na

mesma e (ii) considerar normas de qualidade e gerenciamento de projetos,

sobretudo os modelos CMMI e PMBOK, respectivamente, uma vez que a qualidade

de processo não é o foco direto do RUP.

332

Para o perfeito funcionamento das atividades de uma Fábrica de Software é

fundamental a adoção de um processo de desenvolvimento que defina as tarefas,

produtos e responsáveis pelas etapas do ciclo de vida do software.

Assim, este trabalho apresentou uma sugestão de um possível mapeamento

dos processos operacionais e gerenciais de uma estrutura para o desenvolvimento

de software, quanto à sua execução, de acordo com o modelo de Fábrica de

Projetos de Software, classificadas por (FERNANDES, 2004).

Para a implantação de uma fábrica de projetos de software, três tópicos foram

abordados neste trabalho: o processo de desenvolvimento, a gerência de projetos e

a qualidade de software.

Os processos foram definidos como atividades ordenadas que caracterizam o

ciclo de vida de um produto de software; a gerência de projetos como parte

fundamental dos processos, estabelecendo padrões para gerenciamento de diversas

atividades no decorrer do desenvolvimento dos projetos; e a qualidade como fator

fundamental para que o processo de software atinja os objetivos definidos no início

de um projeto.

Dentro deste contexto, foi proposto um modelo de fábrica de software no qual

são destacadas quatro fases principais: iniciação, elaboração, construção e

transição; nas quais são utilizados padrões para definição de atividades de cada

fase.

A curto e médio prazo, com a utilização do processo de desenvolvimento

padrão, espera-se que as estimativas tornem-se mais precisas, que os produtos

gerados apresentem maior qualidade, e conseqüentemente menos tempo seja gasto

com manutenção, e, finalmente, que a produtividade aumente em decorrência da

introdução de uma abordagem sistemática de produção de software.

333

Para a implantação de uma fábrica de software, são seguidas algumas

normatizações, principalmente ao que se refere aos processos. A implantação não é

uma atividade simples de ser executada; requerendo sempre novos modelos,

procedimentos, atitudes de gerentes e equipe, e com isso provocando grande

mudança estrutural na empresa.

Procurou-se de forma simplificada, demonstrar um guia de implantação do

modelo de fábrica de software no qual os processos são caracterizados em três

pontos principais, todos envolvendo a qualidade do produto: processo de

desenvolvimento; gerência de projetos e qualidade da operação de construção de

software. Além disso, evidenciou-se a essencialidade da interação do cliente com

todos os processos.

O objetivo principal da implantação é a qualidade do produto gerado; sendo

os resultados avaliados a partir da verificação dos requisitos atendidos.

Dentro deste contexto, é proposto um modelo de fábrica de software que

privilegia a normatização, a execução faseada das tarefas e a garantia da aderência

aos requisitos. Procurou-se de forma simplificada, demonstrar os processos

relevantes para implantação da estrutura estudada.

Assim, entende-se que os processos citados criarão a base de sustentação

para a implantação da fábrica de software e darão suporte para que a operação

funcione de acordo com o projetado.

Como possibilidades futuras de trabalhos pretende-se executar a modelagem

e automatização dos processos com a utilização da linguagem UML 2.0 e dos

processos modelados neste trabalho, ou seja, criar um sistema computacional que

automatize as atividades utilizando a proposta apresentada neste trabalho como

processo de criação de software, no sentido de garantir que o framework

334

apresentado pode realizar todas as tarefas para as quais foi projetado, ou seja,

provar através das práticas do mercado que a solução proposta é factível. Além

disso, será proposto um processo de gerenciamento de configuração de software

que proverá recursos para identificação, controle de evolução e auditagem dos

artefatos de software criados durante o desenvolvimento do projeto de software, ou

seja, uma processo de gerenciamento de configuração institucionalizado dentro da

organização; pois, atualmente, o processo não está institucionalizado conforme

preconizado pela área de processo: gerenciamento de configuração do modelo

CMMI.

Este trabalho acadêmico servirá como base para uma dissertação de

Mestrado, que tem como objetivo propor um modelo de fábrica de software que seja

escalável, de acordo com a classificação da fábrica que o estará instanciando, e que

garanta, em termos de organograma e atividades básicas, a execução de todas as

exigências mínimas para adequação ao modelo de qualidade escolhido, orientando

também na definição do tipo de processo de desenvolvimento a ser adotado.

Assim, este trabalho realizou a construção de um modelo (framework) de

desenvolvimento de software, aderente aos três principais modelos do mercado (em

cada área específica que sustenta a operação – gerência de projetos, qualidade e

processo de desenvolvimento), no sentido de propor mudanças que valorizassem

processos e métodos robustos, melhoria contínua da operação e resultados em

termos de qualidade e produtividade explícitos no framework.

335

REFERÊNCIAS BIBLIOGRÁFICAS (AMARU, 2003) AMARU, A.Cesar. Administração de Projetos : Como Transformar idéias em resultados. Ed. Atlas. São Paulo: 2003. (ASSANO, 2002) ASSANO, M. (2002). Gerenciando Fábricas de Software Terceirizadas suportadas por Modelagem de Negócios. Rational Software White Paper, 2002. (BACH, 1995) BACH, J. (1995). SCRUM Software Development Process - Building The Best Possible Software. ADVANCED DEVELOPMENT METHODS, 1995. (BASILI, 1994) BASILI, V.R., (1994). Facts and Myths affecting Software Reuse. IEEE, Maryland, 1994. (BECK, 2000) BECK, Kent. Extreme Programming Explained: Embrace change. Reading, Massachusetts: Ed. Addison-Wesley, 2000. (BRUCE; LANGDON, 2003) BRUCE, Andy; LANGDON, Ken. Como Gerenciar Projetos. Publifolha. São Paulo: 2003. (CASTELLS, 2000) CASTELLS, M., (2000). A Sociedade em Rede. 3 ed. São Paulo: Paz e Terra, 2000. (CESAR, 2005) CESAR, R. (2005). Fábrica de Software: Uma vocação nacional?. Disponível em: <http://www.siscorp.com.br/imprensa/computerworld02.htm?documento=24655&Area=51>. Acesso em: 25 agosto 2005. (COCKBURN, 2002) COCKBURN, A. (2002). Crystal Clear – A human-powered methodology for small teams including the seven properties of effective software projects. Humans and Technology. (CONRADI, 1994) CONRADI, R. et. Al (1994). EPOS: Object-Oriented Cooperative Process Modelling, In: FINKELSTEIN, Software Process Modelling and Technology, Kauton Research Studies Press. (CUSUMANO, 1989) CUSUMANO, M. A. (1989). The software factory: a historical interpretation. IEEE Software, 6(2), p.23-30. (Cap. 14) (CUSUMANO, 1991) CUSUMANO, M (1991). A. Factory Concepts and Practices in Software Development. Annals of the History of Computing. Cambridge. V.13, n.1. 1991 (D´SOUZA, 1999) D´SOUZA, D., Wills, A. (1999). Objects, Components and Frameworks with UML – The Catalysis Approach. Addison-Wesley Publishing Company.

336

(FERNANDES, 2004) FERNANDES, A.A., TEIXEIRA, D. S. (2004). Fábrica de Software: Implantação e gestão de Operações. São Paulo: Atlas. (GREENFIELD, 2003) GREENFIELD J., SHORT K. (2003). Software Factories – Assembling Applications with Patterns, Models, Framworks and Tools. OOPSLA’03, ACM, California. (GUEZI, 1991) GUEZZI, C.; JAZAYERI, M. Fundamentals of software Engineering. Prentice Hall, 1991. (HUMPHREY, 1989) HUMPHREY, W. S. (1989). Managing the Software Process. New York: Addison-Wesley. (JEFRRIES, 2001) JEFRRIES, R. (2001) What is Extreme Programming?. Disponível em: <http://www.xprogramming.com/xpmag/whatis.htm>. Acesso em: 10 junho 2005. (KERZNER, 2002) KERZNER, Harold. Gestão de projetos : as melhores práticas. Ed. Bookman. São Paulo: 2002. (KRIPALINI, 2003) KRIPALINI, M., ENGARDIO P., HAMM, S. (2003). The Rise of India. Disponível em:<http://www. businessweek.com/magazine/content/03_49/b3861001_mz001.htm>, BusinessWeek Online, Dezembro. Acesso em: 10 abr 2005. (KROLL, 2003) KROLL, Per; KRUCHTEN, Philippe (2003). Guia prático do RUP. Pearson Education, 2003. (KRUCHTEN, 2003) KRUCHTEN, P. (2003). Introdução ao RUP – Rational Unified Process. Rio de Janeiro: Editora Ciência Moderna Ltda.. (LAROUSSE, 1999) LAROUSSE. Grande Enciclopédia. Nova Cultural, v. 10 e 23, 1999. (LONCHAMP, 1993) LONCHAMP, J. (1993). A Structured Conceptual and Terminological Framework for the Software Process Engineering, In: INTERNATIONAL CONFERENCE ON THE SOFTWARE PROCESS, Berlin, Proceedings. (MARTINS, 2002) MARTINS, J.C.C. Gestão de Projetos de Desenvolvimento de Software – PMI. Editora Brasport. Rio de Janeiro: 2002. (MARTINS, 2003) MARTINS, J.C.C. Gerência de Projetos em Segurança da Informação. Editora Brasport. São Paulo: 2003.

(NAUR & RANDELL, 1968) NAUR, Peter; RANDELL, Brian. Software Engineering. NATO SCIENCE COMMITTEE. Germany,1968 (OLIVEIRA, 2001) OLIVEIRA, Sandro Ronaldo Bezerra. ToolManager: Um Gerenciador de Ferramentas CASE. 2001. 231f. Dissertação (Mestrado em

337

Ciência da Computação) – Centro de Informática, Universidade Federal de Pernambuco, Recife, 2001. (PADUA, 2003) PÁDUA FILHO, Wilson de P. Engenharia de Software: fundamentos, métodos e padrões. 2. ed. Rio de Janeiro: LTC, 2003. (PAULLK, 1993) PAULLK, M. C. et al (1993). Capability Maturity Model for Software. Version 1.1, Technical Report CMU/SEI-93-TR-024. Software Engineering Institute - Carnegie Mellon University. (PMBOK, 2000) A Guide to the Project Management Body of Knowledge - Project Management Institute, 2000 Edition. (PMI, 2004) Project Management Institute. Disponível em: <http://www.pmi.org>. Acesso: 20 out 2004.

(PRESSMAN, 2000) PRESSMAN, R. S. (2000). Software Engineering: A Practioner’s Approach, 5th edition. MacGraw-Hill International Edition. (RUP, 2003) Rational Software Corporation, Rational Unified Process, Version 2003.06.00.65, CD-ROM, Rational Software, Cupertino, California, 2003. (ROCHA, 2005) ROCHA, Tayssa. OLIVEIRA, Sandro. VASCONCELOS, Alexandre. (2005) Adequação de processos para fábrica de software. Disponível em: <http://www.cin.ufpe.br/~tar/trabalhos.htm>. Acesso em: 16 maio 2005. (SEI, 2005) SEI. CMMi Models. Software Engineering Institute, Carnegie Mellon University, April 2005. Disponível em: <http://www.sei.cmu.edu/cmmi/models>. Acesso em: 10 junho 2005. (SELLERS, 1997) SELLERS, B. H. et. Al (1997) The OPEN Process (Tasks, Techniques and Management), Chapter of Handbook of Object Technology, Centre for Object Technology Applications and Research – School of Information Technology – Swinburne University of Technology, CRC Press. (SILVA, 1998) SILVA, A. M.P. A. da; ROCHA, T.A. Modelagem de uma ferramenta case orientada a objetos. Trabalho de Conclusão de Curso de Tecnologia em Processamento de Dados. Área de Ciências Exatas e Informática do Centro Universitário do Pará, Belém, 1998 (SOMMERVILLE, 2003) SOMMERVILLE, I. Engenharia de Software. 6 ed. Ver. Tec.Kechi Hirama. São Paulo: Addison Wesley, 2003. (TARTARELLI, 2004) TARTARELLI, R.V., WINCKLER, W. S. (2004) Aprendizagem organizacional em fábricas de software. Disponível em: <http://www.pmirs.org/Estudos/Rubens.pdf>. Acesso em: 10 abr 2005. (UPF, 2005) UNIVERSIDADE DE PASSO FUNDO (UPF). Instituto de Ciências Exatas e Geociência. Qualidade de Software. Disponível em :

338

<http://www.psphome.hpg.ig.com.br/downloads/apostila_QS.doc>. Acesso em: 10 agosto 2005. (YOURDON, 1997) YOURDON, E., (1997). Death March: Managing “Mission Impossible” Projects. Upper Saddle River, NJ, Prentice-Hall. (VOLPE, 2005) VOLPE, Renato Luiz Della; JOMORI, Sergio Massao; ZABEU, Ana Cecília Peixoto. As diferenças entre CMM e CMMI. Disponível em: <http://www.cin.ufpe.br/~tg/2004-2/rcm2.pdf>. Acesso em: 7 abr 2005.