Embed Size (px)
Citation preview
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
FACULDADE INTEGRADA AVM
Gerenciamento de Projetos em Fábrica de Softwares
Por: Rodrigo Leal Gonçalves
Orientador
Prof. Nélson Magalhães
Rio de Janeiro
2010
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
FACULDADE INTEGRADA AVM
Gerenciamento de Projetos em Fábrica de Softwares
Apresentação de monografia à Universidade
Candido Mendes como requisito parcial para
obtenção do grau de especialista em Gestão de
Projetos.
Por: Rodrigo Leal Gonçalves.
3
AGRADECIMENTOS
Agradeço à ajuda e colaboração de
meu mestre orientador, Nelson
Magalhães, a amizade de meus
colegas de classe que me
proporcionaram momentos de alegria e
compartilhamento de experiências e a
todos os meus familiares.
4
DEDICATÓRIA
Dedico este trabalho aos meus pais,
Diumar Ibá Gonçalves e Arlete Leal
Gonçalves, as minhas irmãs Aline Leal
Gonçalves e Carmem Lúcia da Conceição
(in memorian) e a minha amada esposa
Fernanda Mara dos Santos Machado.
5
RESUMO
As pesquisas realizadas para este trabalho apontam um problema
comum na área de Tecnologia da Informação, que é a utilização e definição de
uma fábrica de softwares. O gerenciamento de projetos em fábricas de
softwares depende primordialmente de sua concepção e aplicação correta.
Uma vez definida a concepção, que difere dos modelos de contratação
comumente realizados, como “BodyShop” (Alocação de mão-de-obra
terceirizada), onde a gestão, alocação e controle das atividades são de
responsabilidade do cliente, a fábrica de softwares equivale-se a uma caixa
preta, onde requisitos definidos e padronizados entram por uma porta e
softwares ou componentes saem por outra porta, de forma totalmente
transparente para quem contrata.
Essa concepção será abordada com clareza e definiremos as fronteiras,
processos envolvidos e extremamente relevantes para a orquestração das
atividades que envolvem a construção de softwares ou componentes de
softwares em um modelo de fábrica de mercado.
6
METODOLOGIA
Este trabalho foi desenvolvido com base em pesquisas bibliográficas em
livros técnicos, revistas especializadas, manuais de produtos que suportam
processos de fabricação de softwares e em minha própria experiência em
implantação de fábrica de softwares em grandes e pequenas organizações de
desenvolvimento de software.
Aborda de forma eficaz uma metodologia, processos e um modelo de
uso capaz de orientar outros profissionais da área de TI que queiram implantar
uma fábrica de softwares em suas organizações.
7
SUMÁRIO
CAPÍTULO I ..................................................................................................... 11
GERENCIAMENTO DE PROJETOS .............................................................. 11
CAPÍTULO II .................................................................................................... 14
FABRICAÇÃO DE SOFTWARES ................................................................... 14
CAPÍTULO III ................................................................................................... 15
GERENCIAMENTO DE REQUISITOS ........................................................... 15
CAPÍTULO IV .................................................................................................. 17
GERENCIAMENTO DE CONFIGURAÇÃO E MUDANÇAS ........................... 17
CAPÍTULO V ................................................................................................... 22
GERENCIAMENTO DE RISCOS .................................................................... 22
CAPÍTULO VI .................................................................................................. 26
GERENCIAMENTO FINANCEIRO ................................................................. 26
CAPÍTULO VII ................................................................................................. 29
GERENCIAMENTO DE ATIVIDADES ............................................................ 29
CAPÍTULO VIII ................................................................................................ 31
GERENCIAMENTO DA QUALIDADE ............................................................. 31
CAPÍTULO IX .................................................................................................. 35
FINALIZAÇÃO DO PROJETO ........................................................................ 35
8
INTRODUÇÃO
Este trabalho tem como objetivo ser um guia de boas práticas para o
gerenciamento de projetos em fábrica de softwares, trazendo a tona
características que definem claramente o seu papel frente às demais formas de
contratação de projetos de softwares no mercado brasileiro.
Uma fábrica de softwares é caracterizada por uma unidade de
construção de códigos de computadores em pequena ou larga escala e que
pode ou não gerar um produto de software de valor significante para a
contratante. Ao ser contratada, esta receberá insumos (chamados requisitos,
normas e critérios de aceitação) e construirá rigorosamente o software, ou
componente de software conforme as especificações existentes.
Os recursos utilizados por uma fábrica de software são dinâmicos e
podem a todo o momento estarem trabalhando (construindo códigos) para uma
contratante diferente, desde que, é claro, seja respeitado a capacidade técnica
de cada um deles.
Diferentemente de uma contratação do tipo “body shop”, onde cada
contratante sabe exatamente quem está contratando e possui gerência sobre
esses recursos, em uma fábrica isso não ocorre, sendo completamente
transparente a quantidade e os indivíduos que nela trabalham.
Figura 1 - Modelo
Para seguirmos com o est
tenhamos alguns conceito
Vamos identificar as fronte
fábrica de softwares neste
odelo Conceitual de uma Fábrica de Software
o estudo apresentado neste trabalho é necessár
nceitos bem definidos e claros.
fronteiras existentes no projeto de software e o p
neste contexto.
9
ftwares
essário que
e o papel da
Figura 2
A figura acima mostra cl
projeto de softwares e
organização ou contratada
Equipe de Proje
Fábrica de Softwares
- Fronteiras da Fábrica de Softwares
tra claramente as responsabilidades de uma
s e de uma fábrica de softwares que pod
ratada no mercado.
•Business Modeling•Levantamento de Requisitos•Analise & Design•Testes Integrados•Implantação•Garantia do Projeto•Acompanhamento Assistido
rojeto
•Construção de software ou componente software (Código Fonte).
de res
10
uma equipe de
e pode ser da
nte de
11
CAPÍTULO I
GERENCIAMENTO DE PROJETOS
1. A entrada do projeto na fábrica de softwares
O gerenciamento de um projeto quando entra em uma fábrica de
softwares deve seguir determinadas práticas, objetivando o controle total sobre
os artefatos construídos, a qualidade dos mesmos, os custos e prazos
contratados e a melhor alocação dos recursos disponíveis na fábrica.
Um projeto ao entrar em uma fábrica de softwares deverá ser acompanhado
pelo artefato “IP”, que significa Informação do Projeto.
Esse artefato possui informações como nome do projeto, tamanho em pontos
de função, ou outra técnica que permita estabelecer o tamanho do produto a
ser construído, o cliente, o órgão ou área do cliente que receberá o produto, o
nome do responsável por este projeto junto ao cliente, as tecnologias que
serão utilizadas, o percentual aproximado de cada tecnologia dentro da
construção, data de entrega final, taxa de produtividade adotada por ponto de
função em cada tecnologia ou outra métrica utilizada, nome do gerente do
projeto dentro da fábrica de softwares, o valor monetário do projeto, definição
dos meios de comunicação e termos para liberação dos produtos construídos.
Após a chegada do IP, o gerente de projeto designado pela fábrica de
softwares irá analisar se a mesma possui condições de atender a demanda.
Caso não seja possível, este será recusada e deverá ser revista pela
contratante ou até mesmo descartada de imediato.
2. Reuniões de Acom
O projeto deverá se
softwares com reuniões d
tratado o andamento do
versus realizado, anális
conformidades, entregas e
3. Reuniões de Equip
O gerente do projeto n
de desenvolvimento ao m
realizada por projetos, ou
O objetivo de realiza
entender as dificuldades
entregues, alinhar expecta
os processos de construçã
Figura 3 - Avaliação do IP
Acompanhamento
rá ser acompanhado pelos envolvidos na f
ões de acompanhamento semanais. Nestas reu
to do projeto, a relação entre o cronograma
análise dos riscos, desempenho dos recu
gas e pendências.
Equipe
jeto na fábrica deverá realizar uma reunião com
o menos uma vez a cada 15 dias. Esta p
s, ou tecnologias ou clientes por exemplo.
ealizar reuniões com a equipe de desenvol
ades que a equipe está encontrando com os
xpectativas da organização, prover treinamentos
strução empregados.
12
na fábrica de
s reuniões será
rama planejado
recursos, não
o com a equipe
sta poderá ser
envolvimento é
m os requisitos
entos e avaliar
13
4. Papéis e Responsabilidades
Papel
Responsabilidade
Gerente de Projeto
Garantir a entrega do produto dentro do prazo, custo e qualidade contratada.
Programador
Construir o produto com base na tecnologia e requisitos contratados.
Analista de Qualidade
Testar os produtos construídos de acordo com os critérios de aceitação estabelecidos pelo contratante.
Garantia da Qualidade
Garantir que o processo está sendo cumprido em sua totalidade e realizar testes baseados em amostras para dos produtos construídos.
Engenharia de Software Estabelecer os processos destinados a construção de softwares, metodologias, boas práticas e tecnologias voltadas para melhorar a produtividade da equipe.
Board
Controlar os itens de configuração, disponibilizar produtos nas baselines e manter a rastreabilidade dos produtos construídos com os requisitos.
Gerente da Fábrica de Softwares Controlar e garantir a entrega de todos os projetos existentes dentro da fábrica de softwares.
Os papéis acima citados são considerados mínimos por esse estudo e
demais papéis poderão ser criados de acordo com o tamanho e complexidade
da fábrica implantada.
FABRIC
1. A ordem de produç
Todo software ou c
através de uma “OP” (Or
construção que informa c
oficial do produto, o taman
o prazo de construção, os
itens de configuração (Ver
Um projeto ao entrar na
para construção. Essa té
simultaneamente, garantin
construções muito longas
requisitos e ou especific
abaixo.
Figura 4 - Artefato
Especificaç
CAPÍTULO II
ABRICAÇÃO DE SOFTWARES
rodução
ou componente de software construído em um
” (Ordem de Produção). Uma OP é uma desig
rma claramente o que será construído, a nom
tamanho da construção em pontos de função, a t
ão, os critérios de aceita da contratante, a locali
o (Veremos mais a frente) na baseline.
r na fábrica de softwares é quebrado em vários p
sa técnica permite que sejam utilizados vários
arantindo entregas contínuas e minimizando o
ongas ou grandes. Uma OP deve ser acompan
ecificações pertinentes a mesma como ilustra
rtefatos que Compõem uma Ordem de Produç
Ordem de
Produção
Capa
Critérios de Aceite do Produto
Diagramas e Protótipos
icações
14
m uma fábrica é
designação de
a nomenclatura
ão, a tecnologia,
localização dos
ários pacotinhos
vários recursos
ndo o risco de
mpanhada dos
ilustra a figura
rodução
15
CAPÍTULO III
GERENCIAMENTO DE REQUISITOS
1. Tipos de requisitos
Para que um software ou componente seja construído, é necessário que
sejam enviados documentos de especificações sobre o mesmo. Estes
documentos irão descrever o software com relação aos aspectos funcionais e
não funcionais.
Requisitos funcionais: São os requisitos que o sistema deverá executar
não levando em consideração aspectos físicos para o mesmo. Definem
claramente as entradas e saídas do software.
Requisitos não funcionais: São aqueles que representam atributos,
aspectos e características e ambiente em que o software deverá ser
executado.
Outros documentos também deverão estar presentes nos requisitos,
como modelos de dados, diagramas de atividades, classes, sequência, caso de
uso (Caso ocorra um desenvolvimento orientado a objetos), DFD, modelos de
dados, estrutura de dados, dicionário de dados, protótipos, especificações
funcionais e técnicas. Outros artefatos podem ser enviados de acordo com a
tecnologia empregada ou metodologia utilizada. As mais comuns são análise
essencial, estruturada, Orientação a Objetos e SOA.
Notem que ao entrar na fábrica o software depois de fracionado em
ordens de produção (OP’s) para construção, medição e controle envolve um
conjunto de artefatos que evidenciam ou modelam o que será construído. Uma
espécie de forma de bolo onde tudo já foi planejado, pensado e definido. Não
restam alternativas para a construção do mesmo. O protótipo é uma casca
onde o programador colo
recebidas.
Não é de responsa
além daquilo que está ex
ser levantadas durante a
projeto da fábrica de s
esclarecer, medir e avalia
original. Caso isso ocorra v
Toda a comunicação exist
deverá ser documentada,
construídas.
Entre os requisitos,
de testes. Esses artefatos
as informações que valida
que o software poderá ou
Vejamos no exemplo abaix
Caso de Teste 001 - Sis
O sistema "Calculadora" deverá receber como
entrada de dados apenasnúmeros inteiros entre
zero e dez.
r colocará os códigos de acordo com as espe
ponsabilidade da fábrica alterar, propor ou cons
tá explícito, documentado e contratado. Dúvida
nte a construção e estas serão repassadas ao g
de softwares para que o mesmo possa do
avaliar se a mesma se tornará uma alteração d
corra veremos com mais detalhes no Capítulo IV.
existente entre o gerente do projeto e os prog
tada, mantendo a rastreabilidade da mesma co
isitos, deverá existir as especificações de testes
efatos são muito importantes, pois são eles que
validam a construção e também fornecem dado
rá ou não fazer.
abaixo como isso funcionaria:
Figura 5 - Caso de Teste
Sistema Calculadora
ra"
nas tre
O sistema "Calculadora" não poderá permitir a entrada de letras ou
caracteres especiais como A, B, #, *, &, @ etc..
Resultados es
2 + 2 =
2 x 2 =
2 / 2 =
2 - 2 =
16
especificações
u construir nada
úvidas poderão
s ao gerente do
documentar,
ção do requisito
IV.
programadores
a com as OP’s
testes, ou casos
s que possuem
dados sobre o
s esperados:
2 = 4
x 2 = 4
/ 2 = 1
2 = 0
17
CAPÍTULO IV
GERENCIAMENTO DE CONFIGURAÇÃO E MUDANÇAS
1. Gerenciamento de Configuração
O gerenciamento de configuração em uma fábrica de softwares deverá
abordar o controle dos itens de configuração (Requisitos, casos de testes,
modelos, programas e componentes) de forma a garantir a rastreabilidade dos
mesmos. Todos os itens devem ser versionados e a sua manipulação
controlada pelo Board, que é o guardião dos artefatos.
O Board é o responsável por disponibilizar os componentes e ou programas
no ambiente de desenvolvimento e depois controlar a sua passagem para
ambiente de homologação. Toda esta movimentação é controlada por meio de
documentos de movimentação que garantirá a integridade do produto final a
ser implantado no cliente.
Nenhuma nova construção é iniciada na fábrica de softwares sem o “de
acordo” do Board e nada é liberado para o cliente antes que o mesmo faça a
checagem junto à área de homologação. Após estas conferências é o mesmo
que determina a versão do produto e o “Label” que será gerado.
Caso ocorra algum incidente (“Bug de software”) o Board possuirá a versão
anterior guardada com integridade e poderá, caso solicitado restabelecer as
versões anteriores dos produtos liberados.
A figura abaixo demonstra
baseline ou repositório de
Gera ou
Disponibiliza para Cliente
onstra o ciclo de vida de um item de configuraçã
rio de ativos.
Figura 6 - Tarefas do Board
Inclui um item de configuração
DisponibDesenvol
Movimenta para Homologação
era um “Label” ou pacote fechado
ara
18
uração em uma
onibiliza em nvolvimento
A estrutura de de
oferecer uma área segura
armazenamento dos pro
membros da equipe e
concluídos e disponibilizad
A figura abaixo mostra com
Figura
de desenvolvimento disponibilizada pelo Boa
egura para o desenvolvedor, uma área de STR
s programas concluídos e em utilização po
e e uma área para armazenamento dos
bilizados para testes.
ra como essa estrutura poderá ser disponibilizad
gura 7 - Estrutura de Desenvolvimento
19
oard deverá
STREAM para
ão por demais
dos programas
ilizada.
20
2. Gerenciamento de Mudanças Uma mudança depois de aprovada pela área de gerenciamento de
projetos, tendo seus impactos analisados assim como prazo e custo da
mesma, será encaminha para que o Board da fábrica possa liberar em
ambiente de desenvolvimento apenas os itens de configuração que serão
modificados pela demanda.
Isso significa que a equipe de desenvolvimento embora tenha todo o produto
em seu ambiente e mesmo que realize centenas de melhorias a revelia,
apenas o que foi disponibilizado pelo Board fará parte do pacote que será
liberado para o cliente.
Vamos utilizar a figura abaixo para entender melhor o processo de mudança
quando este ocorre.
Figura 8 - Solicitação de Mudança
Fábrica recebe pedido de mudança
Analisa o impacto técnico e financeiro
Cliente aprova a mudança
Board libera os itens em
Desenvolvimento
Fábrica constrói, testa , libera e
fatura a mudança
21
Uma mudança quando mal analisada ou dimensionada poderá causar o
fracasso de um projeto, portanto, devem ser analisadas com cautela, com
utilização de métricas e técnicas apropriadas para completo entendimento.
GEREN
1. Definição de riscos
Riscos são um conj
influenciar diretamente no
O risco em um projeto de
relacionadas à ocorrência
seu processo ou o seu pro
acontecer e ameaçar o
Developers' Magazine –
Figu
•Rede elétrica inadequade.
•Contingência de dados ineficaz.
•Informações confidenciais.
•Fraudes•Vírus, Spywares.
CAPÍTULO V
ERENCIAMENTO DE RISCOS
riscos
conjunto de ameaças ou oportunidades qu
te no sucesso ou fracasso de um projeto.
to de software é uma medida da probabilidade e
rência de um evento negativo que afete o própr
eu produto. Em outras palavras, qualquer coisa
ar o bom andamento do projeto é um risco.
Maurício Aguiar – Diretor da TI Métricas”).
Figura 9 - Classificação de Riscos
•Atendimento as noISO 9000 ou SarbaOxley.
•Controle da qualid
•Lentidão de rede ddados.
•Produtividade da equipe de program
Segurança Produtividade e Desempenho
ConformidadeDisponibilidade
22
es que podem
dade e da perda
próprio projeto,
coisa que possa
risco. (“Paper -
s normas rbanes
alidade.
de de
da gramação.
23
2. Classificação de alguns riscos na fábrica de softwares
Segurança: São os riscos relativos às ameaças internas ou externas que
podem resultar em acessos não autorizados a alguma informação. Podemos
citar aqui os riscos relativos ao vazamento de dados confidenciais de clientes,
privacidade de dados e fraudes. Encontra-se ainda nesta categoria os riscos
causados por vírus, malwares e spywares que podem acabar com um projeto
caso a infra-estrutura da fábrica de softwares não esteja preparada para conter
essas ameaças.
Disponibilidade: Trata-se do risco de uma informação apresentar-se
inacessível devido a interrupções não planejadas em sistemas. As
organizações têm a responsabilidade de manter seus sistemas de negócio
operacionais. Como resultado, elas precisam reduzir os riscos de perda ou
corrupção de dados e de indisponibilidade de aplicações. E, no caso de uma
falha, os negócios devem ser recuperados em um prazo adequado. O uso de
redes privativas de dados sem contingência, rede elétrica desprotegida de
estabilização e geradores para serem usados em caso de falta de energia das
concessionárias.
Desempenho: É o risco de uma informação apresentar-se inacessível devido a
limitações de escalabilidade ou gargalos relativos à comunicação de dados. Os
negócios precisam garantir os requerimentos de volume e performance
mesmo durante momentos de pico. Aspectos relativos à performance devem
ser identificados proativamente, antes que os usuários finais ou aplicações
sejam impactados.
Produtividade: É o risco ocasionado pelo baixo desempenho das equipes de
desenvolvimento de projetos da fábrica de softwares. As organizações buscam
diminuir este risco mesclando equipes com profissionais juniores, plenos e
seniores, buscando uma fórmula para equilibrar os custos de mão-de-obra sem
baixar a qualidade e sem diminuir a produtividade, o que causa atraso nas
24
entregas e desvios no gerenciamento do projeto. Vale ressaltar que quando um
desvio ocorre e o mesmo não é imediatamente tratado, a solução tardia pode
comprometer todo o projeto pois a adição de novos membros na equipe pode
não surtir efeito no tempo esperado.
Conformidade: É o risco de violação de exigências regulatórias ou de falha no
alcance de requerimentos de políticas internas. As empresas precisam
apresentar conformidade a regulações dos mais diversos níveis (federais,
estaduais) como SOX (Lei Sarbanes Oxley) e ISO 9000. As organizações
precisam preservar informações e prover um eficiente sistema de busca e
recuperação de conteúdo quando requerido (principalmente em e-mails). Em
adição, os empregados devem ser responsáveis pela observação das melhores
práticas e políticas internas para garantir mais eficiência à operação dos
negócios.
3. Relação riscos x capital investido Todo risco identificado deve ser classificado quanto ao seu tipo, criticidade,
probabilidade de ocorrer e o custo que causará, caso seja realizado.
A relação entre os riscos identificados para o projeto e o valor monetário
investido no projeto devem ser monitorados a todo momento pois poderá
indicar os rumos que deverão ser seguidos, seja sua continuidade, paralisação
ou até mesmo cancelamento.
Um projeto onde a soma dos riscos em valor monetário é igual ou superior ao
valor total investido no projeto indica de imediato que se trata de um projeto
delicado e a sua realização deverá ser muito bem avaliada, optando-se até
mesmo por não fazê-lo.
25
A tabela abaixo exemplifica a categorização dos riscos conforme supracitado.
Descrição do Risco Criticidade Probabilidade de
Ocorrer
Valoração do
risco (R$)
Queda de Produtividade da
equipe de programação Alta Pequena R$350,00/hora
Atraso na entrega dos servidores
de desenvolvimento Média Pequena R$1.200,00/dia
Atraso na contratação de equipe
especializada em software livre Alta Média R$500,00/dia
Atraso no treinamento da equipe
em Banco de Dados Firebird Alta Pequena R$500,00/dia
Com a tabela acima podemos rapidamente identificar que se o risco “Atraso na
entrega dos servidores de desenvolvimento” ocorrer durante 3 dias por
exemplo; isso significará um custo de R$ 3.600,00.
Esses valores foram calculados tomando-se como base as medidas de
contorno que serão adotadas. Neste caso, o aluguel de servidores ao custo de
R$ 1.200,00 por dia.
26
CAPÍTULO VI
GERENCIAMENTO FINANCEIRO
1. O custo do projeto
Um projeto ao entrar na fábrica de softwares, com seu documento de IP
(Informações de projeto) devidamente preenchido e aprovado, conterá
informações de total de pontos de função do projeto, taxa em horas por ponto
de função nas referidas tecnologias e valor cobrado por hora.
O projeto será particionado em ordens de produção e o total destas será o
equivalente ao total do projeto (Descartadas as alterações).
A soma de todas as ordens de produção deverá representar o custo total do
projeto (Custo Inicial), ou seja, um projeto que inicialmente foi projetado para
custar R$ 230.000,00 deverá ter esse valor rateado entre as ordens de
produção encaminhadas a fábrica de softwares.
Não importará a quantidade de ordens de produção enviadas, podendo ser
10 ordens de R$ 23.000,00 ou 100 ordens de R$ 2.300,00. O importante é que
a ordem de produção descreva com clareza o produto que será construído e o
seu tamanho bem definido, para que todo o trabalho possa ser rateado entre
diversos programadores.
2. O custo da ordem de produção
Como visto anteriormente, uma ordem de produção é uma instrução de
construção dentro da fábrica de softwares e além de determinar “o que será
feito”, indica também quem é o responsável pela mesma, assim como data de
início e prazo.
27
Toda ordem de produção possui um “preço”, que representa o valor
monetário que “aquilo” que está sendo construído representa financeiramente
para o projeto.
Tomemos como exemplo a ordem de produção 2011/0010.
Esta, indica um produto que será construído em tecnologia Java / MySQL,
será iniciada em 10/01/2011 e tem o tamanho de 5 pontos de função (Unidade
de medida utilizada pela fábrica de softwares).
No documento de informações do projeto vimos que durante o acordo
realizado para a entrada do projeto na fábrica, foi determinado uma quantidade
de horas para desenvolvimento de ponto de função na tecnologia contratada.
Utilizaremos o valor de 9 horas por ponto de função (9h/PF).
Realizando uma conta simples, multiplicando-se o tamanho da ordem de
produção pela taxa em horas contratada para ponto de função, identificamos
que a referida OP, terá uma duração de 45 horas, ou 5,6 dias para
representação em cronograma; obtendo assim a data de término da OP, dia
17/01/2011.
Essa mesma conta poderá ser feita para identificar o custo monetário da
ordem de produção, multiplicando-se a quantidade de horas que serão
consumidas pelo valor em moeda contratado para cada ponto de função,
conforme acordado no artefato de informações de projeto.
Em nosso exemplo, 45 horas multiplicadas pelo valor de R$ 95,00, obteremos
o valor da OP em reais, que totalizará R$ 4.275,00.
28
3. O custo da mudança
Como abordado, toda construção é referenciada a uma ordem de produção
e uma alteração em qualquer componente ou parte do software construído,
implicará em um custo extra que deverá ser pago pelo cliente à fábrica de
softwares.
O cliente deverá enviar a ordem de produção que contém a parte do
software construído que deseja realizar a mudança com um orçamento de
pontos de função para executar a mesma. A fábrica irá receber, fazer sua
medição e comparar com o orçamento enviado pelo cliente e estando de
acordo, realizará a implementação solicitada.
Com isso a OP será composta de seu orçamento inicial mais o valor
referente à mudança solicitada.
Veja a tabela abaixo com um exemplo:
Ordem de produção com orçamento original
Número da Ordem
de Produção
Quantidade de
Pontos de Função
Valor total de horas
utilizadas
Preço da Ordem de
Produção
2011/010
5 45 R$ 4.275,00
Ordem de produção com pedido de alteração
Número da Ordem
de Produção
Quantidade de
Pontos de Função
Valor total de horas
utilizadas
Preço da Ordem de
Produção
2011/010
5
2 Mudança
45
16
R$ 4.275,00
R$ 1.520,00
29
CAPÍTULO VII
GERENCIAMENTO DE ATIVIDADES
1. Atividades obrigatórias para o gerenciamento de projetos
em uma fábrica de softwares
A correta condução de um projeto na fábrica de softwares não depende
exclusivamente da correta aplicação da tecnologia contratada ou da
capacidade da equipe contratada. É necessário que algumas tarefas sejam
executadas para controle e garantia de sucesso do projeto, como citadas
abaixo.
Planejamento da reunião de abertura do projeto realizada entre a equipe de
desenvolvimento, o gerente do projeto, o gerente da fábrica de softwares, a
equipe de CQS (Controle da qualidade de software) e a equipe de SQA
(Garantia da qualidade de software).
Planejamento das reuniões de acompanhamento, revisão e controle do projeto
entre a equipe de desenvolvimento e o gerente do projeto na fábrica de
softwares.
Planejamento das reuniões de acompanhamento, revisão e controle entre os
gerentes de projetos da fábrica de softwares e o gerente da fábrica de
softwares.
Planejamento das reuniões de revisão de processos entre o gerente de projeto
e a equipe de SQA (Garantia da qualidade de software).
Planejamento das reuniões de revisão de processos entre a equipe de
desenvolvimento e a equipe de SQA (Garantia da qualidade de software).
30
2. Atividades de replanejamento de projeto
Toda vez em que um projeto sofre uma alteração motivada ou não por uma
solicitação do cliente, uma atividade de replanejamento deverá ser
imediatamente executada.
Esta tarefa consiste em documentar as alterações de cronograma ocorridas em
função de solicitações de mudança, concretização de riscos ou fatores
externos.
Além de realizar estas alterações em cronograma, o documento de
informações de projeto deverá ser alterado caso exista reflexo financeiro ou
nos marcos descrito pelo mesmo e deverá ser dada ciência a todos os
envolvidos no projeto.
31
CAPÍTULO VIII
GERENCIAMENTO DA QUALIDADE
1. Características da qualidade de software
Qualidade é um termo muito subjetivo e que está ligado diretamente as
percepções de cada indivíduo, suas referências, expectativas e aculturamento.
A qualidade de software basicamente consiste em um sistema atender as
necessidades e expectativas de seus usuários, oferecendo informações e
resultados corretos, tempo de resposta adequado, ter uma tela de uso fácil e
agradável e estar disponível sempre que solicitado.
As revisões de softwares são ferramentas poderosas que ajudam a equipe de
CQS na tarefa de inspecionar e avaliar os softwares desenvolvidos. Estas
podem ocorrer das seguintes formas:
Revisões gerenciais: Tem o objetivo de garantir o progresso do
desenvolvimento do software, recomendar ações corretivas e garantir a correta
alocação dos recursos disponíveis.
Revisões técnicas: Tem o objetivo de avaliar que o software atenda aos
requisitos especificados e garantir a integridade das mudanças ocorridas.
Inspeções: Tem o objetivo de encontrar anomalias no software, identificar
medidas equivocadas e verificar a qualidade final do sistema.
Auditorias: É uma avaliação independente, ocorre e identifica problemas por
amostragens e visa cumprir padrões e regulamentações vigentes.
32
2. FURPS
FURPS é um acrônimo que significa Funcionalidade, Usabilidade,
Confiabilidade, Desempenho e Suportabilidade. Qualidades que devem fazer
parte do software e por isso, avaliadas antes de chegarem ao usuário final.
Nada é pior que o usuário ao receber um novo software diga frases do tipo:
“Uso complicado”, ou “Lento esse sistema”, ou “Esse sistema trava a todo o
momento e não confio nele”.
Para evitar esse transtorno é que as equipes de controle de qualidade de
software devem estar atentas a essas características.
Figura 10 - FURPS
Funcionalidade: Avalia todo o aspecto funcional do sistema e o cumprimento
dos requisitos contratados.
Funcionalidade
Usabilidade
ConfiabilidadeDesempenho
Compatibilidade
33
Usabilidade: É a característica que avalia a interface com o usuário. É
avaliado por prevenção de erros, acesso fácil as funcionalidades, botão de
ajuda, estética e design do sistema.
Confiabilidade: Avalia a integridade do software, tolerância a erros, precisão
de cálculos, exatidão nas informações e tempo de resposta as falhas.
Desempenho: Avalia os recursos de desempenho do sistema, como tempo de
resposta as consultas realizadas, tempo de gravação e recuperação de dados,
capacidade de carga de dados, utilização de CPU e disponibilidade do sistema.
Suportabilidade: Avalia a capacidade de instalação, configuração,
manutenção, estabilidade e escalabilidade do sistema.
3. O papel do CQS (Controle de qualidade de software)
A equipe do controle de qualidade de software é composta em sua maioria
por analistas de sistemas seniores e com grande experiência em
desenvolvimento de sistemas. Estes são responsáveis por realizar os testes
nas aplicações desenvolvidas, verificando e garantindo a aderência as
especificações e requisitos contratados pelos clientes além das qualidades
obrigatórias de softwares de qualidade, com FURPS, como visto acima.
As ocorrências identificadas pela equipe de CQS são registradas e
classificadas como RNC (Registro de não conformidade) e retornam para a
linha de produção para correção imediata. Toda RNC possui prioridade de
construção sobre qualquer atividade de construção em andamento, como as
OP (Ordens de Produção). Após serem corrigidas, as não conformidades
retornam para a área de CQS para serem novamente testadas.
A área de CQS apresenta ao final de cada projeto um painel estatístico
mostrando a quantidade de não conformidades identificadas no projeto, às
34
reincidências, a classificação dos tipos de erros, o tempo médio de correção
pela equipe de construção e indicadores de desempenho da própria área.
4. O papel do SQA (Garantia da qualidade de software)
A área de garantia da qualidade de software atua junto ao processo definido
e aplicado na fábrica de softwares. Sua responsabilidade é acompanhar, medir
o desempenho e propor melhorias no mesmo.
Atua também auditando as equipes de desenvolvimento, gerentes de projetos e
o gerente da fábrica de softwares, buscando irregularidades no cumprimento
fiel dos processos estabelecidos.
Ao identificar uma irregularidade, deverá gerar um RNCP (Registro de não
conformidade no processo), indicar onde ocorreu a falha e comunicar o prazo
para solução do problema. O infrator terá de cumprir a determinação do SQA,
documentar no RNCP a solução adotada e o motivo da falha cometida no
processo.
Qualquer tipo de flexibilização no processo só poderá ocorrer com anuência da
área de SQA e do gerente da fábrica de softwares.
35
CAPÍTULO IX
FINALIZAÇÃO DO PROJETO
1. Como encerrar um projeto
O encerramento de um projeto em uma fábrica de software deve ocorrer
com o TEP (Termo de Encerramento de Projeto) assinado pelo cliente e pelo
gerente da fábrica de softwares.
Este termo indica que todas as ordens de produção contratadas foram
entregues e aceitas pelo cliente, que os valores adicionais de contrato oriundos
de mudanças estão aceitos, incluindo valores monetários e pontos de função,
que o projeto foi entregue dentro do prazo contratado ou acordado e que a
fábrica poderá alocar os recursos em outros projetos, caso necessário.
Toda a documentação disponibilizada pelo cliente é devolvida, os fontes
entregues em mídia (CD, DVD ou Flash Memory), as baselines de gerência de
configuração apagadas e toda informação sigilosa destruída ou devolvida
imediatamente, tendo de ser assistida pelo cliente ou representante do mesmo.
2. Como desalocar a equipe do projeto
O projeto ao encaminhar-se para o fim terá sua equipe desalocada aos
poucos, de forma a garantir o término das atividades com sucesso e também
manter os programadores em uso, pois se ficarem parados, irão gerar um custo
elevado para a fábrica de softwares.
No entanto este fato deve ser planejado com antecedência para que a equipe
não se sinta pressionada ou temerosa com relação ao futuro. O plano deverá
mostrar perspectivas para a equipe como novos projetos ou atividades. Em
36
caso contrário, perderão a motivação e buscarão inclusive outros empregos,
deixando a equipe enfraquecida em um momento crítico do projeto.
3. Documentar as lições aprendidas
Após o encerramento do projeto as “lições” aprendidas deverão ser
documentadas e analisadas pelo gerente de projeto e pelo gerente da fábrica
de softwares. Indicadores de produtividade deverão ser atualizados, riscos
encontrados catalogados assim como as soluções empregadas. Estes registros
servirão de base para novos projetos e para melhorias do processo de
desenvolvimento de software definido e empregado.
37
ÍNDICE DE FIGURAS
Figura 1 - Modelo Conceitual de uma Fábrica de Softwares .............................. 9
Figura 2 - Fronteiras da Fábrica de Softwares ................................................. 10
Figura 3 - Avaliação do IP ................................................................................ 12
Figura 4 - Artefatos que Compõem uma Ordem de Produção ......................... 14
Figura 5 - Caso de Teste .................................................................................. 16
Figura 6 - Tarefas do Board ............................................................................. 18
Figura 7 - Estrutura de Desenvolvimento ......................................................... 19
Figura 8 - Solicitação de Mudança ................................................................... 20
Figura 9 - Classificação de Riscos ................................................................... 22
Figura 10 - FURPS ........................................................................................... 32
38
BIBLIOGRAFIA CONSULTADA
AGUIAR, Maurício. http://www.bfpug.com.br/islig-rio/Downloads/
Gerencia_de_Riscos.pdf.
http://www.virtue.com.br/blog/?p=26
http://pt.wikipedia.org/wiki/Gerenciamento_de_riscos_do_projeto
http://qualidadebr.wordpress.com/2008/07/10/furps/
MONTEIRO, Armando Certificação PMP : Cobertura Completa do PMBOK 3°
Edição / Armando Monteiro. – Rio de Janeiro: Brasport, 2006.
VARGAS, Ricardo Viana. Manual Prático do Plano de Projeto / Ricardo Viana
Vargas, Rio de Janeiro: Brasport, 2003.
BRUZZI, Demerval Guilarducci. Gerência de Projetos: Uma Visão Prática /
Demerval Guilarducci Bruzzi. São Paulo: Érica, 2002.
Fiorini, Soeli T. Engenharia de Software com CMM / Soeli T. Fiorini, Arndt Von
Staa, Renan M. Baptista. Rio de Janeiro: Brasport, 1998.
39
ÍNDICE
AGRADECIMENTOS ........................................................................................ 3
DEDICATÓRIA .................................................................................................. 4
RESUMO ........................................................................................................... 5
METODOLOGIA ................................................................................................ 6
SUMÁRIO .......................................................................................................... 7
INTRODUÇÃO................................................................................................... 8
CAPÍTULO I ..................................................................................................... 11
GERENCIAMENTO DE PROJETOS .............................................................. 11
1. A entrada do projeto na fábrica de softwares ......................................... 11
2. Reuniões de Acompanhamento ............................................................. 12
3. Reuniões de Equipe ............................................................................... 12
4. Papéis e Responsabilidades .................................................................. 13
CAPÍTULO II .................................................................................................... 14
FABRICAÇÃO DE SOFTWARES ................................................................... 14
1. A ordem de produção ............................................................................. 14
CAPÍTULO III ................................................................................................... 15
GERENCIAMENTO DE REQUISITOS ........................................................... 15
1. Tipos de requisitos ................................................................................. 15
CAPÍTULO IV .................................................................................................. 17
GERENCIAMENTO DE CONFIGURAÇÃO E MUDANÇAS ........................... 17
1. Gerenciamento de Configuração ............................................................ 17
2. Gerenciamento de Mudanças ................................................................. 20
CAPÍTULO V ................................................................................................... 22
GERENCIAMENTO DE RISCOS .................................................................... 22
1. Definição de riscos ................................................................................. 22
2. Classificação de alguns riscos na fábrica de softwares .......................... 23
3. Relação riscos x capital investido ........................................................... 24
CAPÍTULO VI .................................................................................................. 26
40
GERENCIAMENTO FINANCEIRO ................................................................. 26
1. O custo do projeto .................................................................................. 26
2. O custo da ordem de produção .............................................................. 26
3. O custo da mudança .............................................................................. 28
CAPÍTULO VII ................................................................................................. 29
GERENCIAMENTO DE ATIVIDADES ............................................................ 29
1. Atividades obrigatórias para o gerenciamento de projetos em uma fábrica
de softwares ................................................................................................. 29
2. Atividades de replanejamento de projeto................................................ 30
CAPÍTULO VIII ................................................................................................ 31
GERENCIAMENTO DA QUALIDADE ............................................................. 31
1. Características da qualidade de software ............................................... 31
2. FURPS ................................................................................................... 32
3. O papel do CQS (Controle de qualidade de software) ........................... 33
4. O papel do SQA (Garantia da qualidade de software) ........................... 34
CAPÍTULO IX .................................................................................................. 35
FINALIZAÇÃO DO PROJETO ........................................................................ 35
1. Como encerrar um projeto ...................................................................... 35
2. Como desalocar a equipe do projeto ...................................................... 35
3. Documentar as lições aprendidas .......................................................... 36
ÍNDICE DE FIGURAS ..................................................................................... 37
BIBLIOGRAFIA CONSULTADA ...................................................................... 38
ÍNDICE ............................................................................................................. 39
