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).
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.
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
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.
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.