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.



Tipos de Defeitos
Para facilitar a revisão do software é possível à identificação e instanciação de classes mais
abrangentes de defeitos para situações específicas. A tabela abaixo apresenta a descrição
desse conjunto de defeitos genéricos e suas instanciações para diferentes contextos de revisão,
no caso especificação de requisitos e projeto técnico. É importante observar que essas classes
de defeitos não são ortogonais (um defeito poderia se enquadrar em mais de uma categoria),
mas pretendem apresentar o conjunto de possíveis defeitos que podem ocorrer.
Defeito Descrição geral Aplicado ao requisito Aplicado ao projeto
• Algum requisito importante
relacionado a
funcionalidade, ao
desempenho, as restrições de
projeto, ao atributo ou a
interface externa não foi
incluído; A representação de um
conceito dos requisitos
As informações necessárias • Não está definida a resposta
gerais do domínio ou do
sobre o sistema foram do software para todas as
Omissão documento de requisitos
omitidas do artefato de possíveis situações de
não está presente em
software. entrada de dados;
nenhum diagrama de
• Faltam seções na
projeto.
especificação de requisitos;
• Faltam referências de
figuras, tabelas e diagramas;
• Falta definição de termos e
unidades de medidas (ANSI,
1984).
Um diagrama de projeto
Algumas informações no
Um requisito descreve um fato contém uma
artefato de software
que não é verdadeiro, representação errada de
contradizem as informações
Fato incorreto considerando as condições um conceito descrito nos
presentes na especificação de
solicitadas para o sistema de requisitos gerais do
requisitos ou o conhecimento
software. domínio ou no
geral do domínio.
documento de requisitos.
Uma representação de um
conceito em um diagrama
As informações em uma parte de projeto está em
do artefato de software estão Dois ou mais requisitos são desacordo com a
Inconsistência
inconsistentes com outras no conflitantes. representação do mesmo
artefato de software. conceito no mesmo ou
em outro diagrama de
projeto.
Uma representação de um
As informações no artefato de
Um requisito tem várias conceito no projeto não
software são ambíguas, isto é,
interpretações devido a diferentes está clara e poderia
é possível ao desenvolvedor
termos utilizados para uma causar má interpretação
Ambigüidade interpretar as informações de
mesma característica ou vários ou entendimento errado
diferentes maneiras, podendo
significados de um termo para do seu significado por
não levar a uma
um contexto particular. parte do usuário do
implementação correta.
documento.
As informações são As informações no requisito são O projeto inclui
Informação
fornecidas, mas não são fornecidas, mas não são informações que embora
estranha
necessárias ou mesmo usadas. necessárias ou mesmo usadas. talvez verdadeiras, não se



aplicam a esse domínio e
não deveriam ser
incluídas ao projeto.
Quadro 3 – Matriz de tipos de defeitos de software
Fonte: Adaptado de Rocha, 2001
Processo de Revisão
A atividade de revisão de software compreende a execução das etapas de planejamento,
detecção, coleção e correção dos defeitos. A figura 6 descreve o encadeamento de atividades
do processo de revisão de software:

Figura 6 – Processo de revisão de software detalhando perfis, atividades e artefatos gerados
Fonte: Prof. D.Sc. Guilherme Travassos, COPPE-UFRJ, 2001
Detecção de Defeitos
Uma abordagem para identificar defeitos em artefatos é fornecida pelas técnicas de leitura de
software. Uma técnica de leitura é uma sequência de etapas (heurísticas) preparada para a
análise individual de um artefato visando compreender suas funcionalidades e identificar seus
potenciais defeitos. Técnicas de leitura aumentam a eficiência dos revisores individuais por
fornecerem diretrizes utilizadas durante a fase de detecção de defeitos em um processo de



revisão para examinar (ou ler) um dado artefato e identificar defeitos. Em vez de os revisores
aplicarem apenas seus próprios conhecimentos e técnicas, as técnicas para leitura de software
agregam o conhecimento das melhores práticas para detecção de defeitos em um
procedimento que pode ser seguido e repetido.
Dentre as técnicas de leitura de software disponíveis para detecção de defeitos destacamos:
− Revisão de requisitos: leitura com base em perspectiva (PBR – Perspective-Based
Reading);
− Revisão de projeto: técnicas de leitura de projeto orientado a objetos (OORT – Object-
Oriented Reading Techniques);
− Revisão de código: refatoração (Refactoring).
6.3. Processo de Gerência de Configuração
Define as atividades para a aplicação de procedimentos administrativos e técnicos por todo o
ciclo de vida do software, destinadas a identificar e definir os itens de software em um sistema
e estabelecer suas linhas básicas (baseline); controlar as modificações e liberações dos itens;
registrar e apresentar a situação dos itens e dos pedidos de modificação; garantir a conclusão,
a consistência e a correção dos itens; controlar o armazenamento, a manipulação e a
distribuição dos itens de software.
Item de configuração de software é o nome dado ao item de informação produzido durante o
processo de desenvolvimento de software para o qual é importante que seja realizado o
controle das alterações. Um conjunto de itens de configuração compõe uma configuração de
software.
Dentre as ferramentas a serem utilizadas como repositório dos itens de configuração:
− Microsoft SourceSafe (código fonte);
− Microsoft SharePoint (documentação).
O método utilizado para trabalhar com itens de configuração no domínio do repositório é
chamado de check-in/check-out, ou seja, conferência na entrada e conferência na saída.
Na realização deste processo estão envolvidos gerente, analistas, projetistas e programadores
os quais devem observar as atividades descritas adiante.
a. Identificação da Configuração
Esta atividade consiste na seleção dos itens de informação a serem gerenciados. É que sejam
selecionados itens relevantes, porque uma superdocumentação onera muito a gerência de
configuração. Os itens mais usados pela equipe, os mais genéricos, os mais importantes para
segurança, os projetados para reutilização e os que podem ser modificados por vários
desenvolvedores ao mesmo tempo.
Notadamente, os artefatos a serem os observados pela gerência de configuração são:
− Código de Frameworks;
− Código de Bibliotecas Reusáveis;
− Código de Módulos, Componentes e Subsistemas;
− Documentação Técnica;



− Arquivos de Configuração.
b. Controle de Configuração
Controle de Mudanças
As alterações em artefatos de software (código e documentação) devem ser registradas em
documento de Controle de Mudanças, o qual deve contemplar descrições detalhadas das
mudanças incluídas em novas revisões desses artefatos. As mudanças devem comentar a
necessidade, a solução, a questão ou incidente associado, a data de liberação da nova revisão
do artefato. Também deve ser utilizado a ferramenta Microsoft SharePoint para registro de
questões e incidentes que podem estar originando a solicitação de mudanças nos artefatos.
Controle de Versões
As versões dos artefatos de software (código e documentação) devem ser mantidas pelas
ferramentas Microsoft SourceSafe e Microsoft SharePoint. A liberação de nova versão de
módulos de programa deve ser registra em rótulos na base de código fonte do Microsoft
SourceSafe. O procedimento de geração de build oficial deve ser seguido e ao final de sua
execução deve ser publicado na lista de build mantidas Microsoft SharePoint. As novas
versões de documentação serão mantidas pelo histórico de versões do Microsoft SharePoint.
As alterações em documentos devem ser seguidas pela atualização da seção de histórico de
revisões constantes nos próprios documentos, cujo objetivo é manter registros das mudanças
associadas à nova revisão da documentação.
A organização do código fonte na base do Microsoft SourceSafe deve observar o
procedimento padrão de estruturação do código fonte para determinado produto de software,
considerando as características específicas de implementação de módulos do produto (web,
database, batch, online, unix, windows, com+).
A disposição da documentação na base do Microsoft SharePoint deve observar a norma
padrão de organização do site de projeto, incluindo as bibliotecas de acesso a documentação
(pública, protegida e privada) e os tipos de documentos em si (cronograma, plano de projeto,
especificação funcional, especificação técnica, plano de teste, plano de implantação).
Liberação e Entrega de Release
A liberação e empacotamento de novo release de módulo de programa deve observar o
procedimento oficial de geração de nova compilação e ao final de sua execução deve ser
publicado na lista de build mantidas Microsoft SharePoint. A área de deploy localizado em
servidor de desenvolvimento deve ser organizada para facilitar a transferência dos módulos de
programa para ambiente de produção. Notadamente, a área de deploy deve ser organizada
considerando a tecnologia específica de implementação de módulos do produto (web,
database, batch, online, unix, windows, com+). O código fonte também deve ser
disponibilizado na área de deploy.
6.4. Processo de Desenvolvimento
Define as atividades essenciais para engenharia do produto de software. Inclui a execução de
análise de requisitos, projeto técnico, codificação, testes, homologação, empacotamento,
entrega, instalação em produção e manutenção.
a. Modelo de Ciclo de Vida



O modelo de ciclo de vida descreve a ordem de execução e relacionamentos das atividades do
processo de software desde identificação da necessidade passando por definição da solução,
certificação, instalação, treinamento, uso e manutenção do produto de software construído.
O ciclo de vida do software será composto por abordagem de desenvolvimento por fases e
atividades técnicas de engenharia do produto de software, conforme descrito adiante.
b. Desenvolvimento por Fases
O desenvolvimento do produto será particionado em subsistemas funcionais entregues em
releases intermediárias do sistema de software final. O objetivo é liberar o mais cedo possível
versões operacionais do produto capazes de agregar valor ao negócio e ajustar as necessidades
dos clientes por rapidez nas soluções diante de mudanças ambientais e requisitos de negócio.
Além disso, organizar o desenvolvimento do produto em releases intermediários em
contraposição a um release “big-bang” reduz riscos do projeto, pela obtenção de feedback dos
desenvolvedores de software logo nos releases iniciais do sistema de software em construção.
A figura 7 esclarece a abordagem baseada no desenvolvimento incremental e iterativo de
versões do produto de software:

Figura 7 – Processo desenvolvimento incremental e iterativo de versões do produto de software
Fonte: do autor
c. Engenharia do Produto de Software



O sequenciamento de atividades praticadas na engenharia do produto para cada release
intermediário em construção está representado na figura 8:

Figura 8 – Processo desenvolvimento de cada release intermediário do produto de software
Fonte: do autor
O modelo ciclo de vida acima contempla as seguintes características desejadas:
− Relaciona as atividades de testes com análise e projeto técnico;
− As conexões implicam em retrabalho se inconformidades são detectadas;
− O foco reside na atividade e na correção.
d. Análise de Requisitos
Esta atividade compreende as tarefas de levantamento de necessidades, identificação de
requisitos, documentação de requisitos (funcionais e não-funcionais) e especificação de
requisitos. O artefato a ser alcançado compreende uma especificação de requisitos (funcional)
do produto de software a ser desenvolvido. Também é objetivo da atividade de Análise de
Requisitos apoiar as estimativas de tamanho de projeto por meio do auxilio a Gerência do
Projeto em análises de pontos por função aplicadas ao levantamento de necessidades que foi
detalhado formalmente.
Uma especificação de requisitos objetiva:
− Estabelecer uma base de concordância entre cliente e desenvolvedores sobre o que



software fará;
− Fornecer uma referência para validação do produto final;
− Detalhar o que o software proposto deve fazer sem preocupar em como deve fazer;
− Reduzir custo de desenvolvimento e minimizar retrabalho;
− Definir o “o quê”, ou seja, quais informações serão processadas, quais funções e
desempenho são desejados, quais interfaces devem ser estabelecidas, quais restrições do
projeto e critérios de validações são necessários.
Algumas técnicas para identificação de requisitos:
− Entrevistas, reuniões de grupo, brainstorning;
− Sessões JAD, observação, documentação, reutilização.
A figura 9 demonstra algumas fontes possíveis de requisitos [Pfleeger, 2000]:

Figura 9 – Descrição de fontes possíveis de requisitos do produto de software
Fonte: Pfeeger, 2000
Os métodos envolvidos na elaboração de uma especificação de requisitos incluem:
− Modelagem de Dados ER;
− Análise de Pontos Por Função;
− Modelagem de Casos de Uso;
− Protótipo de Interface do Usuário (Telas/Relatórios);
− Diagrama de Fluxo de Dados;



− Diagrama de Classes de Domínio;
− Diagrama Hierárquico Funcional.
Dentre as ferramentas a serem utilizadas na elaboração de uma especificação de requisitos:
− Microsoft Office (especificação);
− Microsoft Visio (protótipos, fluxo de dados, DHF);
− Enterprise Architect (casos de uso, classes de objetos do domínio).
A figura 10 esclarece o encadeamento de tarefas na construção de uma especificação de
requisitos [Pfleeger, 2000]:

Figura 10 – Atividade de especificação de requisitos do produto de software
Fonte: Pfeeger, 2000
e. Prototipação
A atividade de prototipação visa apoiar as atividades de especificação de requisitos e projeto
do sistema. O objetivo é compreender as necessidades através de modelos de interatividade
com o produto de software proposto. Também é objetivo demonstramos aparência e
funcionalidade para o sistema de software sendo projetado.
Dentre as ferramentas a serem utilizadas na elaboração de um protótipo básico do produto de
software:
− Microsoft Visio (protótipos GUI);



A figura 11 exemplifica um protótipo de interface do usuário elaborado com Microsoft Visio:

Figura 11 – Exemplo de protótipo de interface do usuário
Fonte: do autor
f. Projeto do Sistema
A atividade de projeto do sistema visa desenvolver uma solução técnica para desenvolvimento
do produto de software centrada na definição da Arquitetura de Software (topologia, inter-
relacionamentos, subsistemas, hierarquia, protocolos). O projeto do sistema detalha a
apresentação e funcionalidades do sistema de software proposto.
Os métodos envolvidos na elaboração do projeto do sistema incluem:
− Padrões arquiteturais;
• Pipelines, Camadas Hierárquicas, Orientado a Eventos;
• Orientada a Componentes [CORBA, J2EE, ORB, .NET, COM+, DCOM];
• Orientada a Serviços [Web Services, Grid Services];
• MVC, Cliente-Servidor;
• Invocação implícita;
• Estruturada [Sistemas, Subsistemas, Módulos, Sub-rotinas];
• Domínios Específicos [Aviação, Biomédica, Geográfica].
− Projeto OO, UML;



− Modelagem de Dados Relacional;
− Projeto Estruturado, Fluxo de Dados;
− Projeto Tempo-Real, Máquinas de Estado.
Dentre as ferramentas a serem utilizadas na elaboração do projeto do sistema:
− Microsoft Visio (arquitetura, fluxo de dados);
− Enterprise Architect (arquitetura, modelagem de objetos, modelagem de dados);
− ERWIN (modelagem de dados).
A arquitetura de software orienta a definição de projeto do sistema focalizando os seguintes
aspectos técnicos:
− Organização do sistema de software como composição de componentes;
− As estruturas de controle globais;
− Os protocolos de comunicação;
− A designação da funcionalidade dos componentes;
− A especificação das interfaces de serviços dos componentes.
O projeto do sistema deve focalizar os seguintes aspectos técnicos:
− Desenvolvimento de projeto estrutural:
• Identificação de Objetos do domínio da aplicação;
• Detalhamento de Objetos (estrutura de dados e comportamento);
• Relacionamentos de Classes e Objetos (associação, agregação, composição, herança);
• Diagramas de classes e objetos;
− Desenvolvimento de projeto comportamental:
• Comunicação, controle, temporização e estados;
• Diagramas de atividades, colaboração, seqüência e estados;
• Diagrama de mapa de navegação;
− Restrições:
• Domínios de validade dos atributos;
• Cardinalidade dos relacionamentos;
• Comportamento dinâmico.
− Inspeções e revisões:
• Consistência;
• Rastreabilidade;
− Desenvolvimento de projeto arquitetural:
• Diagramas de pacotes detalhando a organização lógica de classes (e interfaces) e
provisão de serviços pelos subsistemas.



− Refinamento do Projeto de Interface de Usuário:
• Layouts;
• Usabilidade.
Como observação geral, o projeto técnico abrange o detalhamento da configuração de
hardware, das necessidades de software, das interfaces de comunicação, da entrada e saída de
informação do sistema, da arquitetura de rede, e de tudo o que traduz os requisitos em uma
solução para o problema do cliente. Neste sentido, o projeto técnico deve contemplar os
seguintes aspectos:
− Uma descrição dos principais componentes de hardware e de suas funções;
− A hierarquia e função dos componentes de software;
− A estrutura de dados e o fluxo de dados.
g. Projeto de Subsistemas
A atividade de projeto de subsistemas visa desenvolver e refinar a especificação técnica para
componentes individuais do sistema em construção. Neste sentido, as interfaces, classes e
componentes são detalhados em baixo nível e requisitos não-funcionais (segurança e
desempenho) são considerados. Estruturas de dados e algoritmos são especificados para cada
componente da solução. Demais decisões de projeto como definição de bases de dados, das
linguagens de programação, dos padrões de projeto, dos padrões de integração entre
componentes e dos estilos de interface do usuário.
Os métodos envolvidos na elaboração do projeto de subsistemas incluem:
− Padrões de Projeto (brigde, abstract factory, composite, singleton, facade);
− Modelo Físico de Dados;
− Projeto Tempo-Real (Máquinas de Estado);
− Projeto Estruturado (DFD, DTE, DC, Dicionários de Dados, Pseudo-Código)
− Projeto OO - UML (Diagramas de Casos de Uso, Colaboração, Sequência, Classes,
Atividades, Estados, Pacotes, Componentes, Implantação).
Dentre as ferramentas a serem utilizadas na elaboração do projeto do sistema:
− Microsoft Visio (arquitetura, fluxo de dados);
− Enterprise Architect (padrões de projeto, modelagem de objetos);
O projeto de subsistemas deve focalizar os seguintes aspectos técnicos:
− Inserção de características computacionais:
• Interface do Usuário;
• Tratamento de Exceções;
• Gerenciamento de Tarefas;
• Gerenciamento de Dados:
Persistência de Objetos;



Arquivos de Configuração;
Banco de Dados Relacional;
• Objetos Distribuídos:
Protocolos (http, xml);
Comunicação (pipes, rpc, shared memory, message queue);
Sincronização (semáforos, regiões críticas, variáveis mutex) entre Processos;
• Complexidade Estrutural;
• Reutilização de Bibliotecas de Classes e Frameworks:
COM+, Framework Struts, Framework .NET;
− Preparação dos contratos das classes:
• Padrões de Projeto;
• Especificação das Interfaces de Objetos;
• Especificação das Implementações de Objetos;
− Consideração de requisitos não funcionais:
• Segurança;
• Desempenho;
• Entrada e saída;
• Interoperabilidade;
h. Codificação
A atividade de codificação deve codificar e documentar cada módulo de software e definir a
base de dados usando técnicas de implementação que produzam um código eficiente e livre de
erros. Como resultado de uma implementação bem-sucedida, as unidades de software devem
ser obtidas e critérios de verificação (inspeção de código) devem executados.
Dentre as algumas ferramentas a serem utilizadas na codificação dos módulos e subsistemas
do produto de software:
− Microsoft SourceSafe (repositório de código fonte);
− Framework Struts;
− Microsoft Visual C++;
− Borland Delphi;
− Eclipse;
− PLSQL Developer;
− Oracle DBMS;
− WebLogic.
Os métodos envolvidos na codificação dos módulos de software incluem:
− Padrões de Programação (refactoring);
− Frameworks e Design Patterns;
− Reutilização de Bibliotecas de Funções;



− Programação Estruturada;
− Programação Orientada a Objetos;
A codificação deve observar os seguintes aspectos técnicos:
− Diretriz básica: “Programas não devem ser construídos de forma que eles sejam fáceis de
escrever, mas de forma que eles sejam fáceis de ler, compreender e manter”;
− Tradução dos artefatos de projeto OO para linguagem de programação orientada a objetos;
− Refinamento de estruturas hierárquicas;
− Generalizações para uso futuro (componentes);
− Inspeção de código:
• Comentários e endentação;
• Nomeação de variáveis, constantes e declarações;
• Adequação as boas práticas (facilidade de leitura, compreensão e manutenção);
• Verificação de mecanismos de reutilização, composição, encapsulamento,
polimorfismo e recursividade;
• Verificação de assertivas;
• Verificação de estruturas de controle;
• Verificação de estruturas de dados;
• Verificação de algoritmos;
• Verificação de expressões lógicas, relacionais e aritméticas;
− Teste de Unidade:
• Classes, Módulos e Componentes;
• Verificação de Código.
i. Teste de Unidade, Integração e Sistema
O teste de unidade tem por objetivo explorar a menor unidade do projeto, procurando
identificar erros de lógica e de implementação em cada módulo de programa, separadamente.
O teste de integração objetiva descobrir erros associados as interfaces entre os módulos de
software quando esses são integrados para construir a estrutura do software que foi
estabelecida na fase de projeto.
O teste de sistema objetiva identificar erros de funções e características de desempenho que
não estejam de acordo com a especificação.
Ressalta-se que as atividades de teste envolvem as etapas de planejamento, projeto de casos
de teste, critérios de teste, execução e avaliação dos resultados.
Planos formais de teste unitário e integração devem ser elaborados. As evidências de teste
devem ser coletadas e documentadas.
Dentre as ferramentas a serem utilizadas para apoiar a realização de testes incluem-se:



− Enterprise Architect (casos de testes);
− JUnit (teste automatizado);
− Microsoft Web Stress Tools (teste automatizado).
Após a realização de testes do software os seguintes aspectos técnicos devem ser
considerados:
− Rastreabilidade para os requisitos e projeto;
− Consistência externa com os requisitos e com o projeto;
− Consistência interna entre os requisitos do produto;
− Abrangência do teste;
− Adequação dos métodos e padrões de codificação utilizados;
− Viabilidade de integração e teste do produto;
− Viabilidade de operação e manutenção.
O quadro 4 logo a seguir descreve a relação entre as fases de teste e os paradigmas de
desenvolvimento de software procedimental e orientado a objetos:
Paradigma de desenvolvimento
Fases de teste Procedural Orientado a Objetos
Unidade Sub-rotina ou função Classe
Integração Módulos Classe
Subsistemas Subclasse
Pacote de classes
Componentes
Sistema Toda a aplicação Toda a aplicação
Quadro 4 – Fases de teste versus paradigmas de desenvolvimento de software
Fonte: Adaptado de Pfeeger, 2000
j. Homologação
A homologação envolve a certificação do produto de software no ambiente-alvo do cliente.
Esta atividade compreende as tarefas de planejamento de instalação, customização e
disponibilização de ferramentas automatizadas de apoio à certificação. Os defeitos detectados
durante a homologação devem ser registrados em uma lista de questões do projeto,
automatizada pela ferramenta Microsoft SharePoint, juntamente com as evidências do
incidente, para que possam ser examinadas e trabalhadas pela equipe de desenvolvimento e
tenham acompanhamento da evolução do progresso da correção por parte do cliente. Um
novo release do produto gerado em resposta a correção dos defeitos seguirão os
procedimentos padrões de geração de release e disponibilização para implantação em
ambiente de homologação do cliente. Todas as alterações funcionais no produto em
decorrência da implementação da correção de defeitos devem ser registradas em documento
de Controle de Mudanças e, a documentação associada ao produto deve ser adequadamente
revisada para refletir fielmente as características nativas do produto. Toda documentação
técnica, planos de teste, planos de implantação e manuais de usuário deve estar disponível a
consulta prévia pelo cliente.
k. Entrega e Manutenção



A entrega do produto deve seguir procedimento oficial de geração de nova compilação,
empacotamento de módulos do produto e publicação de novo release na lista de build
mantidas Microsoft SharePoint. A área de deploy localizado em servidor de desenvolvimento
deve ser organizada para facilitar a transferência dos módulos de programa para ambiente de
produção. Notadamente, a área de deploy deve ser organizada considerando a tecnologia
específica de implementação de módulos do produto (web, database, batch, online, unix,
windows, com+). O código fonte também deve ser disponibilizado na área de deploy. Um
planejamento de implantação em produção deve ser elaborado com objetivo de especificar os
detalhes específicos (precedência, periodicidade, expurgo, customização) dos módulos do
sistema de software sendo instalado em ambiente de produção previsto em contrato. Toda
documentação técnica, manuais de treinamento e manuais de usuário devem ser empacotados
e disponibilizados ao cliente. Acompanhamento pós-implantação deve ser oferecido ao cliente
durante os estágios iniciais de operação do produto de software.
A entrega do produto de software deve observar os seguintes aspectos técnicos:
− Empacotamento:
• Código Fonte;
• Código Executável;
• Arquivos de Configuração;
− Instalação:
• Scripts de Instalação;
• Plano de Implantação:
− Treinamento:
• Usuário;
− Documentação:
• Manual do Usuário;
• Manuais Técnicos:
Modelo de Requisitos;
Modelo de Casos de Uso;
Modelo de Dados;
Diagramas de Projeto Técnico:
♦ Arquitetura;
♦ Classes e Objetos;
♦ Fluxo de Dados;
♦ Transição de Estados;
♦ Colaboração e Seqüência;
♦ Distribuição de Componentes;
Mapa de Navegação;
Plano de Teste;
A manutenção do produto deve garantir que o sistema de software em produção continue
sendo útil e atendendo as necessidades do usuário. A manutenção pode ser solicitada por



conta da ocorrência dos seguintes eventos:
− Falhas de processamento;
− Falhas de desempenho;
− Falhas de implementação;
− Alteração no ambiente de dados;
− Alteração no ambiente de processamento;
− Inclusão de novas capacidades, modificações em funções existentes ou ampliações gerais;
− Melhoramento na confiabilidade ou na facilidade de futuras manutenções.
Dentre as tarefas previstas de manutenção citamos:
− Análise do problema e da modificação:
• Tipo de manutenção (corretiva, adaptativa, perfectiva ou preventiva);
• Alcance da alteração (tamanho da modificação, custo envolvido e tempo para
modificação);
• Conseqüências da modificação (impacto no desempenho, na proteção ou na segurança,
nos sistemas de externos);
• Documentação (pedido de modificação, relatório de problemas, opções de mudanças).
− Implementação da modificação;
− Revisão e aceitação da manutenção;
− Migração:
• Análise e definição dos requisitos de migração;
• Desenvolvimento de ferramentas de migração;
• Conversão dos dados e produtos de software;
• Execução da migração;
• Verificação da migração;
• Apoio para o ambiente antigo no futuro.
− Descontinuação do software:
• Interrupção total ou parcial do apoio depois de um determinado período de tempo;
• Arquivamento do produto de software e da documentação associada;
• Responsabilidade por quaisquer questões residuais futuras de apoio;
• Transição para o novo produto de software, se aplicável;
• Acessibilidade às cópias de dados arquivadas.
As ferramentas a serem utilizadas na entrega e na manutenção do produto de software,
compreendem as mesmas já citadas para as atividades de análise de requisitos, projeto técnico
e codificação, visto que, a implementação da modificação requer a reaplicação das atividades
de engenharia de software para o desenvolvimento do produto. Seguindo esta mesma linha de
raciocínio, os métodos e as ferramentas envolvidos incluem os mesmos já realizados nas
demais atividades técnicas de construção do produto.



7. Conclusões
O gerenciamento de projetos de software se preocupa em entregar o sistema de software no
prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitações de
orçamento e tempo. A gerência de projetos de software se caracteriza por tratar sobre um
produto intangível, muito flexível e com processo de desenvolvimento com baixa
padronização.
Um processo produtivo bem definido, documentado e padronizado certamente torna-se
mecanismo efetivo de gerenciamento de projetos. A padronização para processo produtivo de
projeto de software viabiliza a capacidade da corporação construtora do produto de software,
de repetir sucessos anteriores pelo acompanhamento sistemático de custos, cronogramas e
funcionalidades. A padronização também possibilita realizar uma gerência quantitativa do
processo e do produto de software, onde a informação quantitativa é utilizada para melhorar
continuamente e gerenciar o processo produtivo do projeto de software. Visando assegurar
bons resultados e êxito nos projetos de software, entendemos que se torna imperativo definir,
planejar, documentar e publicar a estrutura de trabalho genérica adotada durante a realização
de projeto de desenvolvimento de um produto de software. Para abordar o planejamento de
projeto de software recomendamos fortemente contemplar 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. Portanto, visando à consolidação de
processo produtivo de projeto de software eficaz e efetivo na construção de produto de
qualidade elevada e confiável, capaz de superar as necessidades e demandas de modelos de
negócio em constante mutação.
8. Referências
PFLEEGER, Shari Lawrence Engenharia de Software: Teoria e Prática. São Paulo: Prentice Hall, 2003. Cap. 3,
p. 80 – 110.
NBR ISO/IEC 12207:1998 Tecnologia da Informação – Processos de Ciclo de Vida de Software.
ROCHA, Ana Regina Cavalcanti et al. Qualidade de Software: Teoria e Prática. São Paulo: Prentice Hall, 2001.
Cap. 1, p. 1 – 50.


Artigo halan t14_seminário28042007

Mais conteúdo relacionado

Semelhante a Artigo halan t14_seminário28042007

Mais de Halan Ridolphi

Artigo halan t14_seminário28042007