Artigo halan t14_seminário28042007

PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ
SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA

Uma Abordagem Visando Planejamento de Processo Produtivo
em Projetos de Desenvolvimento de Software

Halan Ridolphi (Algoritma Software) halan@ufrj.br
Engenheiro de Software, Pós-Graduação em Gerenciamento de Projetos (SEGRAC/POLI/UFRJ)

Orientador Lysio Séllos (SEGRAC/POLI/UFRJ) lysio@poli.ufrj.br
Engenheiro Civil, D.Sc.

Resumo
Este artigo tem como propósito discorrer sobre relatos de experiência e compilação
de boas práticas vivenciadas pelo autor objetivando planejar o processo produtivo em um
cenário de trabalho focado em projeto de desenvolvimento de software. Frequentemente,
projetos de software envolvem o esforço de equipes de trabalho geograficamente distribuídas
em distintas instalações (fábricas, laboratórios, escritórios), elicitando e especificando
requisitos e regras de negócio complexas, cooperando no detalhamento do projeto técnico,
criando distintos modelos de software em paralelo e com dependências entre si,
compartilhando baselines comuns de código fonte e especificação. Além disso, em frentes de
trabalho de projetos de software encontramos pessoas programando centenas de módulos de
programa interdependentes, executando providências para garantia de qualidade do produto
final e treinando usuários finais. Portanto, configurando um contexto de projeto suscetível à
geração de conflitos, surgimento de problemas, ocorrência de riscos potenciais, perda de
foco e objetivos, queda de produtividade entre pessoas das equipes envolvidas por conta da
compreensão insuficiente acerca do processo de trabalho a ser realizado visando o
atingimento de metas e propósitos do projeto. O artigo expressa o raciocínio geral do autor,
propondo a utilização de mecanismos, tecnologias e conceitos para efetivamente abordar a
organização do processo produtivo de projeto de software. Assim sendo, contemplando o
planejamento de atividades técnicas, sociais e gerenciais, a definição de responsabilidades,
habilidades e perfis nas equipes de trabalho, a utilização de ferramental para elaboração de
artefatos do projeto, a realização de reuniões do projeto e dentre outros aspectos. Em
resumo, objetivando contribuir para o bom gerenciamento das frentes de trabalho em um
projeto de construção de sistema de software, de modo a assegurar melhor confiabilidade e
qualidade do produto final construído neste cenário de projeto.

Palavras chave: Processo, Projeto, Qualidade, Planejamento, Software, Equipe.

1. Introdução
Este documento tem por objetivo detalhar uma abordagem para padronização de processo
produtivo de projeto de software em uma empresa desenvolvedora de software. A Figura 1
demonstra sucintamente o cenário de projeto mencionado.

SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 1
Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJ
http://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br


O propósito a ser alcançado com a definição de um processo produtivo padrão é a adoção de
abordagem sistemática, repetível e organizada visando construção de sistemas de software de
qualidade desejada e cuja operação seja confiável, com menor custo possível e dentro dos
prazos acordados.

Figura 1 – Cenário de desenvolvimento de software
Fonte: do autor
Na experiência do autor, entre os grandes desafios deste contexto de projeto está a
necessidade de prover uma forma de trabalho metódica e não burocrática, de fácil
entendimento e operacionalização, capaz de tornar a capacidade de produção das pessoas mais
eficaz e efetiva. A disseminação do uso da tecnologia da informação tem tornado a sociedade
cada vez mais ávida e dependente de sistemas de software confiáveis, os quais, comumente,
alcançam grandes dimensões no decorrer de sua construção, bem como, envolvem a
automação de regras de negócio complexas. Para viabilizar tais sistemas de software, quase
sempre, várias pessoas estão cooperando em distintas frentes de trabalho (construção, garantia
de qualidade, homologação, implantação, suporte, gerenciamento) e compartilhando artefatos
do projeto (especificação, código fonte, planos, relatórios, cronogramas). Em nosso
entendimento, a falta de abordagem sistemática de trabalho neste cenário de projeto, pode



culminar na atuação das pessoas na forma de “apagar incêndio” quase que na maioria do
tempo. Ou seja, um ambiente de trabalho que será uma visão do "inferno", onde quase não se
“respira” ou se discute soluções, havendo boa carga de trabalho sendo realizado na forma de
improvisação e, com criatividade, inovação e produtividade fortemente minadas pelos
incidentes e suas recorrências.
O desafio do autor neste contexto de projeto tem sido organizar, coordenar e servir equipes de
engenharia de software, mantendo visão sistêmica dos objetivos e metas, facilitando com que
providências necessárias aconteçam e, como também, antecipação de problemas. Além disso,
viabilizar e formalizar melhor organização do ambiente de trabalho, visando minimizar a
improvisação da equipe, promovendo a adoção de padrões, para que se possam alcançar
resultados efetivos e eficazes na conclusão do projeto. Neste sentido, algumas idéias para
contribuir com o bom gerenciamento de projetos de software foram especificadas visando
aperfeiçoar a atuação das pessoas neste cenário de trabalho e, portanto, será objeto de
apresentação neste estudo.
2. Conceituando Processo de Software
A preocupação com o estabelecimento de um processo de software padrão está relacionada à
necessidade de entender, avaliar, controlar, aprender, comunicar, melhorar, predizer e
certificar o trabalho realizado pelas pessoas de uma organização desenvolvedora de software.

cd Processo SW

Processo_de_Softw are

1

Possui

1..*
0..*
Recurso Ativ idade Compõe Procedimento
Requer
1..* *
* Utiliza 0..*

* 1..*

Consome Produz

0..* 1..*

Artefato

Figura 2 – Conceitos de processo de software
Fonte: do autor



A Figura 2 apresenta as entidades principais constituintes de um processo de software:
a. Processo de Software
Organização de um conjunto de atividades com objetivo de desenvolver artefatos de um
produto de software específico.
b. Atividade
Uma ação de transformação que produz artefatos. Para ser executada uma atividade necessita
de recursos e consome artefatos. Podem ser classificadas em atividades de construção,
garantia de qualidade e gerenciamento. Podem ser organizadas em atividades menores ou
tarefas visando orientar o desenvolvimento de artefatos de software.
Exemplos: Planejamento de Projeto, Análise de Requisitos, Projeto do Sistema, Codificação,
Teste do Sistema, Homologação, Implantação.
c. Recurso
Tudo que é requisitado por uma atividade, mas que não pode ser considerado uma entrada
para ela, no sentido que não é incorporado ao artefato produzido. Pode ser software,
hardware, pessoas, documentos ou banco de dados.
d. Procedimento
Ações bem definidas para executar uma atividade. Basicamente, compõe a base técnica para
construção de artefato de software e é classificado em métodos, técnicas e scripts.
Exemplos: Projeto Orientado a Objetos, Modelagem de Casos de Uso, Prototipação, UML,
Análise de Pontos de Função, Padrões de Projeto, Projeto Estruturado, Linguagens de
Programação (Object Pascal, ADA, Java, C++, Cobol, Modula 2).
e. Artefato
A entrada ou saída de uma atividade.
Exemplos:
Categoria do Artefato Artefato
Plano de Projeto
Cronograma de Projeto
Diagrama de Marcos do Projeto
Plano de Release
Plano de Comunicação
Gerencial Plano de Riscos
Estimativas de Pontos por Função
Estimativas de Pontos por Casos de Uso
Plano de Garantia de Qualidade
Ata de Reunião
Relatório de Progresso

Técnico Modelo de Requisitos
Diagramas de Projeto Técnico
Arquitetura de Software
Modelo de Dados



Código Fonte
Código Binário
Mapa de Navegação
Modelo de Casos de Uso
Modelo de Interface do Usuário (Protótipos de Telas/Relatórios)
Plano de Teste
Plano de Treinamento
Plano de Implantação
Manual do Usuário
Tabela 1 – Exemplos de artefatos gerados em projetos de software
Fonte: do autor
3. Padronizando o Processo Produtivo de Projeto de Software
A abordagem de padronização para processo de software contempla a especificação da
estrutura de trabalho genérica adotada durante a realização de projeto de desenvolvimento de
um produto de software. Inclui a definição e sequenciamento de atividades de gerenciamento,
construção e garantia de qualidade, com aplicação de métodos, técnicas e ferramentas da
engenharia de software visando à consolidação de processo de desenvolvimento de software
eficaz e efetivo na construção de produto de qualidade elevada, e que supere as expectativas
dos modelos de negócios. Os seguintes tópicos são abordados:
− Escopo de atividades fundamentais do processo produtivo do projeto de software;
− Organização da equipe de projeto de software e definição dos perfis profissionais;
− Alocação dos recursos humanos nas atividades e respectivas competências;
− Modelos de ciclo de vida a ser adotado;
− Atividades a serem realizadas e ordem de execução das mesmas durante o
desenvolvimento de um produto de software;
− O conjunto mínimo de artefatos de software que devem ser construídos em cada atividade
do processo de software;
− A menção as técnicas, métodos, ferramentas e procedimentos a serem observados pela
equipe de projeto durante as atividades realizadas ao longo do processo de
desenvolvimento de software.



4. Definindo o Escopo do Processo Produtivo de Projeto de Software

Figura 3 – WBS do processo produtivo de projeto de software detalhando fases e atividades
Fonte: do autor

Fases Atividades/Tarefas Associadas
Planejamento
Estimativas de tamanho (APF), custo e orçamentação
Elaboração de proposta de fornecimento de software
Desenvolvimento, controle e monitoração de cronograma
Promoção da integração entre equipes do projeto
Coordenação de levantamento de necessidades
Gerência de Projeto
Gerenciamento de custos e recursos
Gerenciamento de objetivos
Gerenciamento de riscos
Gerenciamento de problemas
Metodologias e ferramentas de controle gerencial
Elaboração e avaliação de relatórios de progresso

Análise de Requisitos Levantamento de necessidades junto ao cliente
Estimativas de tamanho (APF)
Especificação de requisitos



Revisão de requisitos

Definição de solução técnica
Definição da arquitetura de software
Definição padrões de desenvolvimento (frameworks, design patterns)
Definição de ferramentas CASE
Controlar e monitorar cronograma de entregas de releases
Projeto Técnico & Codificação
Construção Teste unitário
Correção de defeitos
Inspeção de código
Inspeção de projeto técnico
Apoio ao planejamento de implantação
Definição de ferramentas IDE

Identificação itens de configuração
Definição de ferramentas de controle da configuração de software
Controle de mudanças
Gerência de Configuração
Controle de versões
Relatório de alterações e respectivos impactos
Armazenamento, manipulação e distribuição dos itens de configuração

Planejamento de teste integrado
Elaboração de planos de testes
Execução de planos de testes
Garantia de Qualidade Inspeção de projeto técnico
Relatórios de não conformidades
Compilação dos resultados de testes
Teste de regressão

Teste de aceitação
Planejamento de instalação
Homologação
Relatórios de não conformidades

Controle da documentação
Plano de treinamento
Empacotamento do produto
Planejamento de produção
Customização e suporte técnico
Criação de bancos de dados
Entrega e Produção
Otimização de query e stored procedures
Planejamento de capacidade de bases de dados
Planejamento de capacidade de servidores de arquivos
Definições de segurança da rede de computadores
Definições de links de comunicação de dados
Criação de contas, grupos e domínios de usuários
Tabela 2 – Detalhamento de fases, atividades e tarefas associadas em projetos de software



Fonte: do autor
5. Organizando a Equipe do Projeto de Software
Neste tópico comentamos sobre os grupos de trabalho envolvidos, responsabilidades e
respectivas habilidades requeridas no escopo do processo produtivo de um projeto de
desenvolvimento de software. Neste sentido, descrevemos a estrutura organizacional e rede de
relacionamentos de reporte entre os membros da equipe de projeto participantes do processo
de desenvolvimento de sistema de software.
5.1. Organograma da Equipe

Figura 4 – OBS do projeto de software detalhando a rede formal de relacionamentos de reporte
Fonte: do autor
5.2. Definição de Responsabilidades

Matriz de Responsabilidades

Recursos



Comitê de Direcionamento
Gerente de Projeto

Líder de Equipe

Programador
Projetista

Testador
Analista

Cliente
Produto, Evento ou Atividade

Plano de Projeto & Cronograma X R R RA

Orçamento X R RA

Levantamento de Requisitos R C C R

Especificação de Requisitos R R R A A

Projeto Técnico & Arquitetura R C R A I

Modelagem de Dados R C R R A I

Documentação do Produto R CX I R I R

Programação de Subsistemas R C

Plano de Testes R R C S S I X

Teste de Software R E EX EX S AI X

Revisões de Artefatos de Software R E EX EX S I X

Gerência de Configuração R R E E X AI

Plano de Implantação R C R S I

Homologação R S S S X

Empacotamento do Produto R R S CX

Treinamento R C A

Instalação A C S R

Tabela 3 – Detalhamento de matriz de responsabilidades para projeto de software
Fonte: do autor
Legenda: A Aprovação I Informação
E Especificação R Revisão



C Construção S Suporte
X Execução
5.3. Definição de Habilidades
Recursos Humanos Habilidades
Validar se soluções estão alinhadas às estratégias de negócio.
Direcionamento estratégico do projeto.
Garantir a o comprometimento das áreas envolvidas.
Solucionar pendências, minimizando impactos no projeto.
Comitê de Direcionamento
Avaliar os benefícios estratégicos / financeiros das solicitações de mudança
durante a execução do projeto.
Autoriza ou rejeita mudanças propostas que possam gerar impacto no
escopo, prazo ou orçamento do projeto.
Aprovação do escopo, prioridades e orçamento.

Planejamento, controle, acompanhamento e liderança do projeto
Definição de processo produtivo de realização do projeto
Manutenção de foco e prioridades
Supervisão de progresso do projeto
Monitoração e acionamento de medidas de mitigação de riscos do projeto
Inspeção, revisão e refinamento da solução técnica empregada no projeto
Definição de prioridades de desenvolvimento no projeto
Auxílio na estratégia e revisão da solução técnica
Planejamento, melhoria e mediação da comunicação entre membros da
equipe do projeto
Resolução de conflitos
Estimativas de tamanho (APF), custos e orçamentação
Gerente de Projeto Organização de equipe do projeto
Desenvolvimento e acompanhamento de cronogramas do projeto
Avaliação do cumprimento de compromissos e requisitos do projeto
Verificação se procedimentos internos formais estão sendo seguidos e, não
elevando custos internos (treinamento, retrabalho, atrasos)
Gerenciamento de recursos financeiros, técnicos e humanos do projeto
Gerenciamento de objetivos
Alcançar os objetivos do projeto, no prazo acordado, com o custo orçado e
contribuindo para a competitividade do negócio do cliente
Gerenciamento de problemas
Planejamento de treinamento, instalação do produto de software no ambiente
alvo do cliente
Controle de mudanças de escopo do projeto

Líder de Equipe de Projeto Entendimento e levantamento de necessidades junto ao cliente
Definição processo produtivo de realização do projeto
Resolução de conflitos
Manutenção de foco e prioridades
Organização de equipe do projeto
Estimativas de tamanho do produto (APF)
Especificação e revisão da solução técnica



Definição das prioridades de desenvolvimento no projeto
Auxílio na definição de arquitetura e componentes da solução técnica
Modelagem de dados
Inspeção de requisitos
Padronizar a construção dos subprodutos (entregáveis) previstos pelo plano
do projeto
Planejamento da certificação interna do produto do projeto
Planejamento da entrega do produto do projeto
Acompanhamento da operação inicial do produto no ambiente alvo do
cliente
Apoio na revisão de planos de testes
Apoio na execução de planos de testes
Elaboração de relatórios de progresso
Reportar o andamento das atividades ao gerente de projeto
Controlar e monitorar cronograma de entregas de release
Orientar a equipe na realização de atividades do processo produtivo do
projeto
Orientar a equipe na construção dos subprodutos (entregáveis) previstos pelo
plano do projeto
Reportar progresso das atividades ao cliente
Argumentar para equipe do projeto que o trabalho de desenvolvimento de
software é totalmente independente do ego:
• O êxito ou fracasso é resultado da equipe e, nunca de membros
individuais;
• Pessoas são a chave do sucesso;
• Poucas pessoas boas é melhor que muitas pessoas ruins;
• Fazer correto antes de fazer rápido.

Auxiliar o cliente na definição de necessidades
Entendimento e levantamento de requisitos e regras de negócio junto ao
cliente
Especificação de requisitos
Modelagem de dados
Inspeção de requisitos
Planejamento de teste integrado
Elaboração de planos de teste
Execução de planos de teste
Elaboração de planos de implantação
Analistas
Relatórios de não conformidade
Compilação das evidências de teste
Elaborar planejamento de instalação de artefatos do produto de software em
ambiente alvo de produção
Elaborar planejamento de certificação de artefatos do produto de software
Auxiliar na definição e especificação de arquitetura e componentes da
solução técnica
Auxiliar na gerência de configuração do produto de software
Auxiliar nas estimativas de tamanho do produto (APF)
Auxiliar o cliente na homologação da solução técnica
Reportar progresso das atividades ao líder de equipe



Definição padrões de arquitetura de software (Orientada a Serviços,
Pipelines, Orientada a Eventos, Cliente-Servidor, Repositório, MVC, MDA,
CORBA, ORB, J2EE, Estruturada {Sistemas, Módulos, Sub-rotinas}, .NET)
Definição padrões de desenvolvimento (frameworks, design patterns,
orientação a componentes, bibliotecas de códigos reusáveis, APIs)
Planejamento de desenvolvimento centrado na arquitetura de software:
• Particionamento funcional do domínio de aplicação;
• Definição da estrutura de software (componentes e suas conexões
{comunicação e controle});
Projetistas • Alocação de funcionalidade do domínio na estrutura de software.
Definição de ferramentas CASE (Ant, JUnit, Microsoft Web Stress Tools,
Borland StarTeam)
Definição de ferramentas RAD (wizards, NetBeans, Borland Entreprise
Studio, Microsoft Visual Studio)
Inspeção de projeto
Definição de arquitetura e componentes da solução técnica
Viabilizar gerência de configuração do produto de software
Reportar progresso das atividades ao líder de equipe

Codificação
Teste unitário
Apoio ao planejamento de implantação
Definição de ferramentas CASE
Programadores Seniores
Definição de ferramentas RAD (wizards)
Definição padrões de programação (refactoring, frameworks, programação
orientada a objetos, programação estruturada)
Auxiliar na definição de arquitetura e componentes da solução
Auxiliar na gerência de configuração do produto de software
Reportar progresso das atividades aos projetistas

Codificação
Teste unitário
Programadores Juniores
Reportar progresso das atividades aos programadores seniores

Elaboração de planos de testes
Execução de planos de testes
Testadores Relatórios de não conformidades
Coleta de evidências de testes
Reportar progresso das atividades aos analistas

Digitação de manuais de usuário
Digitação de manuais técnicos
Documentadores
Digitação de planos de implantação
Digitação de especificações gerais

Administradores de Banco Criação de bancos de dados
de Dados Otimização de query e stored procedures



Elaboração de planos de execução
Planejamento de capacidade de armazenamento de dados
Planejamento de execução periódica de rotinas de backup de dados
Customização e otimização de servidores de bancos de dados

Definições de segurança da rede de computares
Definições de links de comunicação de dados
Criação de contas, grupos e domínios de usuários
Administradores de Redes Planejamento de execução periódica de rotinas de backup de dados
de Computadores Planejamento de capacidade de tráfego de dados
Customização e otimização de servidores de arquivos
Customização e otimização de servidores de conteúdo para Internet
Customização e otimização de servidores de aplicação

Tabela 4 – Detalhamento de matriz de habilidades para equipe do projeto
Fonte: do autor
6. Planejando o Processo Produtivo do Projeto de Software
6.1. Processo de Gerência de Projeto
Define as atividades essenciais a serem praticadas na coordenação do desenvolvimento de um
produto de software.
Neste processo o gerente de projeto executa as seguintes atividades:
− Planejamento: decidir ‘o que fazer’, ‘como fazer’, ‘quando fazer’ e ‘quem deve fazer’;
− Organização: definir estrutura organizacional, eficiente e eficaz, que facilite a execução
das atividades do projeto, que estabeleça autoridades e defina responsabilidades para
execução dessas atividades;
− Seleção de Pessoal: selecionar, treinar e desenvolver pessoas para ocupar os cargos
definidos na estrutura organizacional;
− Liderança: executar tarefas que motivem as pessoas a executar as tarefas definidas;
− Controle: garantir que a execução do projeto ocorra conforme o planejado. Medir
desempenho e resultados, identificar desvios e definir ações corretivas;
− Estimação: elaborar estimativas de custo, tamanho, cronograma e esforço para viabilizar a
execução do projeto de software.
Os procedimentos técnicos envolvidos na realização deste processo incluem:
− Estimativas de tamanho por Análise de Pontos Por Função ou COCOMO II;
− Práticas PMI (PMBOK).
Dentre as ferramentas a serem utilizadas como repositório dos itens de configuração:
− Microsoft SharePoint (repositório de documentação);
− Microsoft Office (plano de projeto);



− Microsoft Report Server (relatórios gerenciais);
− Microsoft Project (cronograma);
− Microsoft Visio (timeline).
Dentre os artefatos resultantes da execução deste processo incluem:
− Estimativas de Pontos por Função
− Proposta de Fornecimento de Serviço de Software
− Cronograma de Projeto
− Plano de Projeto
• Plano de Riscos
• Plano de Comunicação
• Plano de Garantia de Qualidade
• Plano de Recursos Humanos
• Plano de Gerência de Configuração
− Diagrama de Marcos do Projeto
− Relatório de Progresso
A seguir, citamos alguns exemplos de artefatos gerenciais como modelos a serem observados.
a. Exemplo de Cronograma
Exemplo de cronograma para detalhamento de prazos das atividades que compõem cada fase
do processo de desenvolvimento de software e a rede de precedências.



Figura 5 – Exemplo de cronograma de projeto de software detalhando fases, atividades e tarefas associadas
Fonte: do autor



b. Exemplo de Plano de Comunicação
O exemplo de plano de comunicação para garantir que as questões sejam conhecidas com a antecedência necessária de forma a minimizar os
impactos sobre o projeto.
Escala de Reuniões do Projeto
Ordem de
Precedência da
Reuniões do Projeto Periodicidade Participantes Objetivos
Comunicação
Interna
Gerenciar o progresso do projeto como um todo e resolver questões escaladas nas
reuniões das equipes de requisitos, projeto técnico e construção, além de
Gerente de Projeto determinar as diretrizes gerais do projeto;
Reunião da gerência Líder de Equipe Apresentar riscos, problemas e discutir alternativas de solução para avanço do
4 Quinzenal
do projeto Analistas projeto;
Projetistas
Discutir de relatório de progresso do projeto;
Discutir feedback obtido junto ao cliente.
Definir e priorizar alternativas de solução técnica;
Analisar status de progresso das atividades;
Revisar status do projeto, milestones e produtos, issues, dependências e riscos e
Reunião de equipe de Líder de Equipe identificar issues de infra-estrutura e avaliar questões que devem ser
3 requisitos e projeto Semanal Analistas encaminhadas para reunião com Gerente de Projeto;
técnico Projetistas
Discutir técnicas de inspeção e revisão (projeto técnico);
Melhorar padrões de especificação técnica;
Discutir planejamento de homologação e entrada do produto em produção;



Melhorar comunicação interna com equipe de construção.
Discutir abordagens de desenvolvimento;
Analisar status de progresso das atividades;
Discutir problemas e alternativas de solução;
Reunião de equipe de Projetistas
2 Semanal Discutir técnicas de inspeção e revisão (código);
construção Programadores
Discutir entendimento das especificações técnicas.
Melhorar comunicação interna com equipes de requisitos, projeto técnico e
garantia de qualidade.
Discutir e planejar o esforço de teste a ser executado;
Discutir técnicas de inspeção e revisão (requisitos);
Apresentar problemas quando da realização das últimas tarefas de testes;
Líder de Equipe Discutir formas de melhorar comunicação com equipe de construção;
Reunião de equipe de
1 Semanal Analistas
garantia de qualidade Priorizar issues apresentados pelo cliente;
Testadores
Revisar defeitos nas especificações de requisitos;
Discutir novas abordagens de teste e automação do processo de teste;
Compilação das evidências de teste;

Quadro 1 – Exemplo de matriz de reuniões da equipe do projeto
Fonte: do autor



Matriz de Participação em Reuniões do Projeto
Reuniões do Projeto Gerente do Projeto Líder de Equipe Analistas Projetistas Programadores Testadores
Reunião da gerência do
X X X X
projeto
X X X
requisitos e projeto técnico
X X
construção
X X X
garantia de qualidade
Tabela 5 – Exemplo de matriz de participação nas reuniões do projeto
Fonte: do autor



c. Exemplo de Plano de Risco
O exemplo de matriz de risco para detalhamento de medidas de contingência e mitigação de riscos do projeto.
Probabilidade
Risco Efeito Impacto do Risco Mitigação do Risco Contingência ao Risco
/Prioridade
Construção do software errado; Construção de protótipos; Realização de um contrato de
Má compreensão dos
Moderada/Alta Catastrófico Degradação do orçamento e Revisão de casos de uso com cliente; seguro, a fim de cobrir qualquer
requisitos
cronograma. Inspeções de requisitos. perda financeira.
Remanejamento de atividades ao
Treinamento cruzado; pessoal de maior talento e
Atraso na entrega do produto; Pessoal principal previamente experiência;
Perda de pessoal
Moderada/Alta Sério Elevação de custos por conta de agendado (comprometimento); Negociação de novos prazos finais
fundamental
treinamento e ambientação de pessoal. Cuidado com aspectos morais da de entrega do produto;
equipe (confiança, etc.). Contratação de pessoal externo ao
projeto em caráter temporário.
Não realização de testes de
Aceleração do desenvolvimento por
regressão;
Entrega do produto com defeitos reutilização de software;
Certificação das funcionalidades
Tempo insuficiente para críticos; Desenvolvimento incremental com
Moderada/Alta Sério mais relevantes do release a ser
realização de testes Desempenho não aceitável. liberação de releases intermediárias do
liberado;
produto, certificando grupos de
Negociação de novos prazos de
funcionalidades independentes.
entrega.
Estimativa detalhada de custo e Realização de contrato de seguro;
Atraso na entrega do produto;
cronograma, a partir de várias fontes de Renegociação de prazos e
Insuficiência de verba para conclusão do
Cronogramas e informação; orçamento com cliente.
Moderada/Alta Catastrófico projeto;
orçamentos não realistas Projeto de acordo com o custo;
Sem compensação financeira para
Simplificação dos requisitos;
equipe do projeto.
Reutilização de software.



Não aceitação pelo usuário final; Realização de contrato de seguro;
Desenvolvimento de Construção de protótipos;
Aumento dos custos do projeto por Renegociação de prazos e
interface do usuário Moderada/Alta Catastrófico Revisão de requisitos de usabilidade
retrabalho; orçamento com cliente.
inadequada com área usuária.
Ampliação do prazo final.
Atraso na entrega do produto; Orçamento por homem-hora e não
Criação de projeto técnico flexível;
Fluxo contínuo de Aumento dos custos do projeto; por projeto fechado;
Desenvolvimento incremental,
modificações nos Moderada/Alta Sério Retrabalho; Renegociação de prazos e
protelando mudanças para fases
requisitos Diminuição da produtividade e moral da orçamento com cliente.
posteriores.
força de trabalho.
Programar algoritmos paralelos na
solução;
Simulação; Revisão técnica;
Insuficiência no Não aceitação pelo usuário final;
Instrumentação; Simplificação de requisitos de
desempenho em tempo Moderada/Alta Sério Inviabiliza realização das funções de
Otimização de código; desempenho;
real negócio.
Testes de stress. Análise de custo-benefício;
Expansão do tempo e esforço dos
testes.
Análise de compatibilidade; Realização de contrato de seguro;
Iniciar cedo o entendimento e Escolhe de novo fornecedor
Insuficiência nos Atraso na entrega do produto; certificação de componentes externo;
componentes fornecidos Baixa/Alta Sério Aumento dos custos do projeto; desenvolvidos por terceiros; Renegociação de prazos e
externamente Desempenho não aceitável. Inspeções de conteúdo e orçamento com cliente;
funcionalidades; Revisão da solução de integração
Benchmarking. no projeto.
Quadro 2 – Exemplo de matriz de contingência e mitigação de riscos do projeto
Fonte: Adaptado de Rocha, 2001



6.2. Processo de Garantia da Qualidade
Define as atividades para garantir a conformidade dos processos e produtos de software, no
ciclo de vida do projeto, com seus requisitos especificados e sua aderência aos planos
estabelecidos. Esse processo evidencia a relação entre a qualidade do produto e a qualidade do
processo de software utilizado em sua construção. O processo de garantia da qualidade deve
estar coordenado com tarefas de verificação, validação, revisão e resolução de problemas.
Na realização deste processo estão envolvidos gerente, analistas, projetistas, testadores e
programadores os quais devem observar as atividades descritas adiante.
a. Garantia do Produto
A atividade de garantia do produto implica nas seguintes tarefas técnico-administrativas:
− Garantir que todos os planos exigidos pelo contrato de fornecimento estejam de acordo
com o mesmo, sejam documentados, estejam mutuamente consistentes e sejam executados
quando exigidos;
− Garantir que os produtos de software e sua documentação estejam de acordo com o
contrato e os planos;
− Garantir que os produtos de software satisfaçam totalmente os requisitos contratuais e
sejam aceitáveis pelo cliente.
b. Garantia do Processo
A atividade de garantia do processo implica nas seguintes tarefas técnico-administrativas:
− Garantir que os processos do ciclo de vida do software utilizados no projeto estejam de
acordo com o contrato e os planos;
− Garantir que as práticas de engenharia de software, o ambiente de desenvolvimento, o
ambiente de teste e as bibliotecas estejam de acordo com o contrato, com as negociações e
com os planos;
− Garantir, no caso de subcontratação, que os requisitos aplicáveis sejam passados ao
subcontrato e que seus produtos de software satisfaçam os requisitos do contrato original;
− Garantir que o cliente e outras partes envolvidas o apoio e a cooperação necessários;
− Garantir que as medições do produto e do processo de software estejam de acordo com os
padrões e procedimentos estabelecidos;
− Garantir que a equipe tenha a qualificação e o conhecimento necessários para o projeto e
receba todo o treinamento necessário.
c. Sistema de Garantia da Qualidade
Resumidamente, o sistema de garantia da qualidade deve observar as seguintes tarefas
técnicas:
− Investigar métodos e procedimentos de prevenção de defeitos;
− Medir o desempenho dos processos de software descritos nesta norma;
− Aprender a identificar as causas dos problemas ou defeitos;
− Saber agir corretiva e preventivamente para eliminar esses problemas ou defeitos e,
principalmente, as suas causas.



d. Verificação e Validação do Software
As atividades de verificação e validação objetivam minimizar a ocorrência de erros e falhas
associadas no produto de software. O objetivo da verificação é assegurar que o software, ou
uma determinada função do mesmo, esteja sendo implementada corretamente. O objetivo da
validação é assegurar que o software que está sendo desenvolvido é o software correto de
acordo com os requisitos do cliente.
A condução efetiva das atividades de verificação e validação requer a elaboração de um
modelo de erros que capte os erros típicos, os riscos associados, a freqüência de ocorrência e
demais aspectos relevantes, de maneira que a experiência e o conhecimento de
desenvolvimento de software da equipe de projeto sejam utilizados em planejamentos futuros
para novos projetos. O número de locais no produto que podem conter erros é praticamente
infinito para fins práticos e, portanto, a adoção de estratégia baseada em um modelo de erros
tende a conduzir as atividades de V&V com maior eficiência e produtividade. O papel do
modelo de erros é orientar a procura por erros nos locais que apresentam, segundo
informações estatísticas, maiores probabilidades de apresentarem defeitos. Um ‘bom’ modelo
de erros é capaz de retratar os defeitos e seus atributos contidos em sistemas reais. O modelo
de erros deve ser mantido em base histórica de incidentes em repositório de documentação.
Neste caso específico, a ferramenta Microsoft SharePoint pode ser utilizada para armazenar
esse conhecimento na forma de lista de histórico dos incidentes do projeto.
Ressaltamos também que, um Modelo de Casos de Uso estabelece uma base de concordância
entre o cliente e desenvolvedores sobre o que o sistema de software deve fazer e, neste
sentido, este artefato possibilita a validação se o sistema de software está sendo modelado em
conformidade com regras de funcionamento esperadas pelo cliente, constituindo em
ferramenta de apoio à garantia de qualidade:
− Inspeção de requisitos (identificar defeitos na definição):
• Estão corretos, consistentes, sem ambigüidades, completos;
− Validação de requisitos (conceber o software correto):
• Estão refletindo a realidade, sem omissão, sem informação estranha;
As atividades de verificação e validação compreendem tarefas técnicas descritas nas próximas
seções.
Análise Estática
A análise estática não envolve a execução propriamente dita do produto de software e visa
determinar propriedades do produto válidas para qualquer execução do produto final. A
análise estática pode e deve ser aplicada em qualquer artefato de software gerado no
transcorrer do processo de desenvolvimento. Os métodos empregados na realização de análise
estática incluem as revisões de requisitos (PBR – Perspective-Based Reading), revisões de
projeto (OORT – Object-Oriented Readind Techniques), revisões de código (Refactoring),
análise da árvore de falhas, compilação e otimização de código.
Análise Dinâmica
A análise dinâmica tem por objetivo detectar defeitos ou erros no software e envolve a
execução do produto. As tarefas de simulação e teste constituem uma análise dinâmica do
produto. O teste de software é uma tarefa usada para fornecer evidências da confiabilidade do



software em complemento às revisões de software. As informações obtidas durante as
revisões são extremamente úteis para o teste por permitirem a identificação dos módulos
críticos e propensos a erros.
A liberação de novo release do produto não é permitida sem antes haver uma condução
sistemática de análise dinâmica e avaliação dos resultados alcançados.
Os métodos empregados na realização de análise dinâmica incluem a adoção de técnicas de
teste (funcional, estrutural, baseada em erros, baseada em máquinas de estado finito) a serem
utilizadas para estabelecer planos de testes, casos de teste, critérios de teste e a própria
realização dos procedimentos de teste, de modo a verificar se os requisitos especificados para
o software foram corretamente implementados.
Verificação Propriamente Dita
Outras tarefas de escopo da verificação de acordo com a norma ISO/IEC 12207 incluem:
− Verificação do contrato;
− Verificação do processo;
− Verificação de requisitos;
− Verificação do projeto;
− Verificação do código;
− Verificação da integração;
− Verificação da documentação.
Validação Propriamente Dita
Outras tarefas de escopo da validação de acordo com a norma ISO/IEC 12207 incluem:
− Preparar os requisitos de teste, casos de teste, planos de teste para analisar os resultados;
− Assegurar-se de que esses artefatos de teste reflitam os requisitos particulares para um uso
específico do software;
− Conduzir testes considerando teste de estresse, de carga e de entradas específicas,
avaliando a habilidade do produto de software para isolar e minimizar os efeitos de erros;
− Conduzir testes com usuários representativos para avaliar se eles conseguem realizar suas
tarefas usando o produto de software;
− Validar se o produto de software satisfaz seu uso específico e testar o produto de software
propriamente no seu ambiente-alvo.
e. Teste de Software
O teste de software é uma atividade crítica de garantia de qualidade que consiste na análise
dinâmica do produto, ou seja, na execução do produto de software com o objetivo de verificar
a presença de defeitos e aumentar a confiança na correção do software. A atividade de teste
envolve a execução das etapas de planejamento, projeto de casos de teste, execução e
avaliação de resultados. No planejamento da atividade de teste são estimados recursos e são
definidos estratégias, métodos e técnicas de teste, caracterizando-se um critério de aceitação
do software em desenvolvimento. Em geral, atividade de teste não pode mostrar a correção de
um software, pois o conjunto dos dados de entrada normalmente é infinito ou muito extenso, a



ponto de ser inviável testar todas as possibilidades, o que corresponderia ao teste exaustivo,
pelo qual a correção poderia ser comprovada. A atividade de teste é dividida em fases visando
minimizar a complexidade, tanto na abordagem desenvolvimento procedimental quanto na
orientada a objetos. Basicamente, há três fases de teste: de unidade, de integração e de
sistema.
Técnicas de Teste
As técnicas de teste são classificadas de acordo com a origem das informações utilizadas para
estabelecer os requisitos de teste, a saber:
− Técnica Funcional ou Caixa Preta;
− Técnica Estrutural ou Caixa Branca;
− Técnica Baseada em Erros;
− Técnica Baseada em Máquinas de Estado Finito.
Critérios de Teste
Um critério de teste serve para selecionar e avaliar casos de teste de forma a aumentar as
possibilidades de revelar a presença de defeitos ou, quando isso não ocorre, estabelecer um
nível elevado de confiança na correção do produto. Um caso de teste é um par ordenado
composto por um dado de entrada, isto é, um elemento do domínio de entrada, e pela saída
esperada.
Os critérios de teste podem ser utilizados como:
− Critério de adequação de casos de teste;
− Critério de geração de casos de teste.
As propriedades mínimas desejáveis em um critério de teste são:
− Garantir, do ponto de vista do fluxo de controle, a execução de todas as transferências de
fluxo de controle;
− Exigir, do ponto de vista do fluxo de dados, ao menos um uso de todo resultado
computacional;
− Exigir um conjunto de casos de teste finito.
f. Revisões de Software
As revisões (inspeções) no produto de software compreendem o ideal de assegurar que o
artefato produzido, seja ele um documento, especificação de requisitos, projeto técnico ou
outro resultado a ser fornecido, possui qualidade suficiente para ser utilizado por seu usuário.
Os artefatos são revisados ao longo do processo de desenvolvimento de software, para
garantir que a equipe de projeto esteja utilizando documentos pelo menos com a qualidade
mínima especificada. As revisões de software são aplicadas a código-fonte, projeto técnico,
requisitos durante o processo de desenvolvimento, de maneira a encontrar defeitos. Os
defeitos encontrados pelas revisões de software referem-se à faltas. Uma falta em algum
artefato estático – pro exemplo, diagrama de projeto – é importante por levar a
implementações nas quais as falhas ocorrem. Defeitos encontrados por teste representam
sempre falhas do software e podem ser rastreadas por meio de depuração.


Artigo halan t14_seminário28042007

Artigo halan t14_seminário28042007

Recomendados

Recomendados

Más contenido relacionado

Similar a Artigo halan t14_seminário28042007

Similar a Artigo halan t14_seminário28042007 (20)

Más de Halan Ridolphi

Más de Halan Ridolphi (10)

Artigo halan t14_seminário28042007