Processo de Software para Desenvolvimento de Qualidade

POLI / UFRJ
MBA Engenharia de Software – Turma 2004
Disciplina: Qualidade de Software
Professora: Claudia Cappelli
Aluno: Halan Ridolphi Alves

MBA-ENGSOFT Qualidade de Software 1
© 2005 Halan Ridolphi

Sumário
1 Introdução ............................................................................................................. 3
1.1 Definição de Processo de Software ..................................................................... 3
1.2 Norma de Processo de Software ........................................................................ 4
1.3 Escopo do Processo de Software ........................................................................ 5
1.3.1 Atividades e Tarefas Associadas ..................................................................... 5
2 Organização da Equipe............................................................................................. 7
2.1 Estrutura Organizacional .................................................................................. 7
2.1.1 Organograma da Equipe ................................................................................ 7
2.1.2 Matriz de Responsabilidades .......................................................................... 7
2.1.3 Recursos Humanos X Responsabilidades .......................................................... 8
3 Processo de Software............................................................................................. 12
3.1 Processo de Gerência de Projeto ...................................................................... 12
3.1.1 Exemplo de Cronograma ............................................................................. 13
3.1.2 Exemplo de Plano de Comunicação ............................................................... 14
3.1.3 Exemplo de Plano de Risco .......................................................................... 16
3.2 Processo de Garantia da Qualidade .................................................................. 18
3.2.1 Garantia do Produto ................................................................................... 18
3.2.2 Garantia do Processo .................................................................................. 18
3.2.3 Sistema de Garantia da Qualidade ................................................................ 18
3.2.4 Verificação e Validação do Software .............................................................. 18
3.2.5 Teste de Software ...................................................................................... 20
3.2.6 Revisões de Software.................................................................................. 21
3.3 Processo de Gerência de Configuração .............................................................. 23
3.3.1 Identificação da Configuração ...................................................................... 24
3.3.2 Controle de Configuração ............................................................................ 24
3.4 Processo de Desenvolvimento ......................................................................... 25
3.4.1 Modelo de Ciclo de Vida .............................................................................. 25
3.4.2 Desenvolvimento por Fases ......................................................................... 25
3.4.3 Engenharia do Produto de Software .............................................................. 26
3.4.4 Análise de Requisitos .................................................................................. 27
3.4.5 Prototipação .............................................................................................. 29
3.4.6 Projeto do Sistema ..................................................................................... 30
3.4.7 Projeto de Subsistemas ............................................................................... 31
3.4.8 Codificação................................................................................................ 32
3.4.9 Teste de Unidade, Integração e Sistema ........................................................ 33
3.4.10 Homologação ......................................................................................... 34
3.4.11 Entrega e Manutenção ............................................................................. 34
4 Bibliografia Consultada .......................................................................................... 36


1 Introdução
Este documento tem por objetivo detalhar norma de padronização para processo de
software genérico de uma empresa desenvolvedora de software.
A meta a ser alcançada com o estabelecimento de um processo de software padrão é a
adoção de abordagem sistemática, repetível e organizada visando construção de sistemas de
software de qualidade desejada, com menor custo possível e dentro dos prazos acordados.

1.1 Definição de 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.
O diagrama a seguir esclarece as entidades principais constituintes de um processo 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

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, Casos de Uso, Análise de Pontos Por
Função, Prototipação, Padrões de Projeto, Projeto Estruturado, UML, Linguagens de
Programação (Object Pascal, ADA, Java, C++, Cobol).
e. Artefato
A entrada ou saída de uma atividade.
Exemplos:
Artefatos Gerenciais
• Plano de Projeto
• Cronograma de Projeto
• Timeline de Milestones
• Plano de Release
• Plano de Comunicação
• Plano de Riscos
• Estimativas de Pontos por Função
• Plano de Garantia de Qualidade
Artefatos Técnicos
• Especificação de Requisitos
• Diagramas de Projeto Técnico
• Arquitetura de Software
• Modelo de Dados
• Código Fonte
• Código Binário
• Arquivos de Configuração
• Casos de Uso
• Protótipos GUI
• Plano de Testes
• Relatórios de Evidências de Testes
• Plano de Implantação
• Manual do Usuário

1.2 Norma de Processo de Software
A norma de padronização para processo de software contempla a especificação da
estrutura de trabalho genérica adotada durante o desenvolvimento de um produto de software.
Os seguintes tópicos são abordados:
Escopo de atividades fundamentais do processo de software;
Organização da equipe 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.


1.3 Escopo do Processo de Software

1.3.1 Atividades e Tarefas Associadas
Gerência de Projeto
• Planejamento
• Estimativas de tamanho (APF)
• Elaboração de proposta de fornecimento de software
• Controle e monitoração de cronograma
• Buscar integração entre equipes do projeto
• Coordenar levantamento de necessidades
• 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
Desenvolvimento
• 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 release
• Codificação
• Teste unitário
• Correção de defeitos
• Inspeção de código
• Inspeção de projeto
• Apoio ao planejamento de implantação
Gerência de Configuração
• Identificação itens de configuração
• Definição de ferramentas de controle da configuração de software
• Controle de mudanças
• Controle de versões
• Relatório de alterações e respectivos impactos
• Armazenamento, manipulação e distribuição dos itens de configuração.
Garantia da Qualidade
• Planejamento de teste integrado
• Elaboração de planos de testes
• Execução de planos de testes
• Revisão de requisitos
• Relatórios de não conformidades
• Compilação dos resultados de testes
Homologação
• Testes de aceitação
• Planejamento de instalação
• Relatórios de não conformidades
Entrega e Produção
• Controle da documentação e plano de treinamento
• Empacotamento do produto
• Planejamento de produção
• Customização e suporte técnico
• Criação de bancos de dados
• 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
• Definições de links de comunicação
• Criação de contas e domínios


2 Organização da Equipe
Este seção descreve as partes envolvidas e respectivas competências no escopo do
processo de desenvolvimento de software.

2.1 Estrutura Organizacional
Este seção descreve a estrutura organizacional e rede de relacionamentos de reporte
entre os membros da equipe de software participantes do processo de desenvolvimento de
sistema de software.

2.1.1 Organograma da Equipe

2.1.2 Matriz de Responsabilidades

Matriz de Responsabilidades

Recursos
Analista Chefe

Programador
Gerente de

Projetista

Testador
Analista
Projeto

Cliente


Produto, Evento ou Atividade

Plano de Projeto & Cronograma X R R

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

Legenda: A Aprovação I Informação
E Especificação R Revisão
C Construção S Suporte
X Execução

2.1.3 Recursos Humanos X Responsabilidades
Gerente de Projeto
• Planejamento do projeto
• Definição de processo de software
• Definição de metodologia de desenvolvimento de software
• Controle e monitoração de cronograma do projeto
• Buscar integração entre equipes do projeto
• Gerenciamento de custos e recursos
• Gerenciamento de objetivos
• Gerenciamento de riscos
• Gerenciamento de problemas
• Metodologias e ferramentas de controle gerencial
• Auxílio na especificação e revisão da solução técnica
• Definição das prioridades de desenvolvimento no projeto
• Auxílio na verificação e validação da solução em desenvolvimento
• Melhoria e mediação na comunicação entre membros da equipe do projeto


• Monitoração do cumprimento dos compromissos e requisitos do projeto
• Verificação se procedimentos internos formais estão sendo seguidos e, não
elevando custos internos (treinamento, retrabalho, atrasos).
• Alcançar os objetivos do projeto, no prazo acordado, com o custo orçado e
contribuindo para a competitividade do negócio do 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.
Analista Chefe
• Entendimento e levantamento de necessidades junto ao Cliente
• Estimativas de tamanho do projeto (APF)
• Especificação e revisão da solução técnica
• Definição das prioridades de desenvolvimento no projeto
• Definição de arquitetura e componentes da solução
• Modelagem de dados
• Inspeção de requisitos
• Planejamento da certificação interna do produto
• Planejamento da entrega do produto final
• 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
• Reportar progresso das atividades ao Cliente
Cliente
• Definição das necessidades
• Homologação da solução
• Aporte financeiro ao projeto
Analistas
• Especificação de requisitos
• Modelagem de dados
• Inspeção de requisitos
• Planejamento de teste integrado
• Elaboração de planos de implantação
• Relatórios de não conformidade
• Compilação das evidências de testes
• 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
• Auxiliar na gerência de configuração do produto de software
• Auxiliar nas estimativas de tamanho do projeto (APF)
• Reportar progresso das atividades ao Analista Chefe
Projetistas


• Definição padrões de arquitetura (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});
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)
• Viabilizar definição de arquitetura e componentes da solução
• Viabilizar gerência de configuração do produto de software
• Reportar progresso das atividades ao Analista Chefe
Programadores Seniores
• Codificação
• Teste unitário
• Apoio ao planejamento de implantação
• 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
Programadores Juniores
• Codificação
• Teste unitário
• Reportar progresso das atividades aos Programadores Seniores
Testadores
• Relatórios de não conformidade
• Coleta de evidências de testes
• Reportar progresso das atividades aos Analistas
Documentadores
• Digitação de manuais de usuário
• Digitação de manuais técnicos
• Digitação de planos de implantação
• Digitação de especificações gerais
Administradores de Banco de Dados (DBAs)
• Elaboração de planos de execução
• Criação de bancos de dados
• Otimização de query e stored procedures


• Planejamento de capacidade
Administradores de Redes
• Definições de segurança da rede
• Definições de links de comunicação
• Criação de contas e domínios
• Planejamento de capacidade


3 Processo de Software
3.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 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 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
Timeline de Marcos do Projeto
Plano de Release
A seguir, citamos alguns exemplos desses artefatos gerencias como modelos a serem
observados.


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


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

3.1.2.1 Escala de Reuniões de Projeto

Ordem de Reuniões do Periodicidade Participantes Objetivos
Precedência da Projeto
Comunicação
Interna
4 Reunião da Quinzenal Gerente de Projeto Gerenciar o progresso do projeto como um todo e resolver
Gerência de Analista Chefe questões escaladas nas reuniões das equipes de Projeto Técnico
Projeto Analistas e Desenvolvimento, além de determinar as diretrizes gerais do
Projetistas projeto;
Apresentar riscos, problemas e discutir alternativas de solução
para avanço do projeto;
Discutir de relatório de progresso do projeto;
Discutir feedback obtido junto ao cliente.
3 Reunião de Semanal Analista Chefe Definir e priorizar alternativas de solução técnica;
equipe de Projeto Analistas Analisar status de progresso das atividades;
Técnico Projetistas Revisar status do projeto, milestones e produtos, issues,
dependências e riscos e identificar issues de infra-estrutura e
avaliar questões que devem ser encaminhadas para Reunião
com Gerente de Projeto;
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 Desenvolvimento.
2 Reunião de Semanal Projetistas Discutir abordagens de desenvolvimento;
equipe de Programadores Analisar status de progresso das atividades;
Desenvolvimento Discutir problemas e alternativas de solução;
Discutir técnicas de inspeção e revisão (código);
Discutir entendimento das especificações técnicas.
Melhorar comunicação interna com equipes de Projeto Técnico e


Garantia de Qualidade.
1 Reunião de Semanal Analista Chefe Discutir e planejar o esforço de teste a ser executado;
equipe de Analistas Discutir técnicas de inspeção e revisão (requisitos);
Garantia de Testadores Apresentar problemas quando da realização das últimas tarefas
Qualidade de testes;
Discutir formas de melhorar comunicação com equipe de
Desenvolvimento;
Priorizar issues apresentados pelo cliente;
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;

3.1.2.2 Matriz de Participação nas Reuniões do Projeto
Matriz de Participação em Reuniões
Reuniões do Projeto Gerente do Projeto Analista Chefe Analistas Projetistas Programadores Testadores
Reunião da Gerência
X X X X
de Projeto
Reunião de equipe de
X X X
Projeto Técnico
X X
Desenvolvimento
X X X
Garantia de Qualidade

3.1.2.3 Mecanismos de Acompanhamento de Projeto
• Relatório de Progresso Semanal
• Ferramenta de Gestão e Acompanhamento
• Controle de Horas Trabalhadas (Timesheet)
• Controle do Cronograma do Projeto

3.1.2.4 Mecanismo de Controle de Pendências e Entregas
• Lista de Questões no Web Site do Projeto
Rápido atendimento a alterações de especificação e pequenas solicitações de mudanças
Divulgação de incidentes de homologação e produção
Acompanhamento da correção de defeitos.

3.1.2.5 Benefícios dos Mecanismos de Controle e Acompanhamento
• Controle de progresso e de orçamento do projeto
• Rápido atendimento a alterações de especificação
• Transparência para o cliente

3.1.3 Exemplo de Plano de Risco
O exemplo de plano de risco para contingência e mitigação de riscos de projeto.

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

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


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

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

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

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

3.2.4 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 estruturado na forma de lista de histórico dos incidentes do projeto.
As atividades de verificação e validação compreendem tarefas técnicas descritas nas
próximas seções.

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

3.2.4.2 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.
Não será permitida a liberação de novo release do produto 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.

3.2.4.3 Verificação Propriamente Dita
Outras tarefas de escopo da verificação de acordo com a norma ISSO/IEC 12207 (ISO,
1995a) 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.


3.2.4.4 Validação Propriamente Dita
Outras tarefas de escopo da validação de acordo com a norma ISSO/IEC 12207 (ISO,
1995a) 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.

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

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

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


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

3.2.6.1 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.
Tipos de defeitos de software
Defeito Descrição geral Aplicado ao requisito Aplicado ao projeto
Omissão As informações 1. Algum requisito A representação de
necessárias sobre o importante um conceito dos
sistema foram relacionado a requisitos gerais do
omitidas do artefato funcionalidade, ao domínio ou do
de software. desempenho, as documento de
restrições de requisitos não está
projeto, ao presente em nenhum
atributo ou a diagrama de projeto.
interface externa
não foi incluído;
2. Não está definida
a resposta do
software para
todas as possíveis
situações de
entrada de
dados;
3. Faltam seções na
especificação de
requisitos;
4. Faltam
referências de
figuras, tabelas e
diagramas;
5. Falta definição de
termos e
unidades de
medidas (ANSI,
1984).

Fato incorreto Algumas informações Um requisito Um diagrama de
no artefato de descreve um fato que projeto contém uma


software contradizem não é verdadeiro, representação errada
as informações considerando as de um conceito
presentes na condições solicitadas descrito nos
especificação de para o sistema de requisitos gerais do
requisitos ou o software. domínio ou no
conhecimento geral documento de
do domínio. requisitos.
Inconsistência As informações em Dois ou mais Uma representação
uma parte do artefato requisitos são de um conceito em
de software estão conflitantes. um diagrama de
inconsistentes com projeto está em
outras no artefato de desacordo com a
software. representação do
mesmo conceito no
mesmo ou em outro
diagrama de projeto.
Ambigüidade As informações no Um requisito tem Uma representação
artefato de software várias interpretações de um conceito no
são ambíguas, isto é, devido a diferentes projeto não está clara
é possível ao termos utilizados e poderia causar má
desenvolvedor para uma mesma interpretação ou
interpretar as característica ou entendimento errado
informações de vários significados de do seu significado por
diferentes maneiras, um termo para um parte do usuário do
podendo não levar a contexto particular. documento.
uma implementação
correta.
Informação estranha As informações são As informações no O projeto inclui
fornecidas, mas não requisito são informações que
são necessárias ou fornecidas, mas não embora talvez
mesmo usadas. são necessárias ou verdadeiras, não se
mesmo usadas. aplicam a esse
domínio e não
deveriam ser
incluídas ao projeto.

3.2.6.2 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. O diagrama a seguir descreve o
encadeamento de atividades do processo de revisão de software:


3.2.6.3 Detecção de Defeitos
Uma abordagem para identificar defeitos em artefatos é fornecida pelas técnicas para
leitura de software. Uma técnica para leitura é uma série de etapas (heurísticas) preparada
para a análise individual de um artefato que permite alcançar a compreensão necessária para
uma determinada tarefa (Basili, 1996). Técnicas para leitura aumentam a eficiência dos
revisores individuais por fornecerem diretrizes utilizadas durante a fase de detecção de 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 a serem observadas na detecção de defeitos
mencionamos:
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).

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

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

3.3.2 Controle de Configuração

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

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

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

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

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

3.4.2 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.
O diagrama a seguir esclarece a abordagem baseada no desenvolvimento incremental e
iterativo de versões do produto de software:


3.4.3 Engenharia do Produto de Software
O encadeamento de atividades praticadas na engenharia do produto para cada release
intermediário em construção é detalhado no diagrama a seguir:


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.

3.4.4 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, brainstorn;
Sessões JAD, observação, documentação, reutilização.
A figura a seguir demonstra algumas fontes possíveis de requisitos [Pfleeger, 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;
Casos de Uso;
Protótipos GUI;
Diagramas de Fluxo de Dados;
Diagramas de Classes de Domínio;
Diagramas Hierárquicos Funcionais.
Dentre as ferramentas a serem utilizadas na elaboração de uma especificação de
requisitos:
Microsoft Office (especificação);
Microsoft Visio (protótipos GUI, fluxo de dados, DHF);
Enterprise Architect (casos de uso, classes de objetos do domínio).
O diagrama a seguir esclarece o encadeamento de tarefas na construção de uma
especificação de requisitos [Pfleeger, 2000]:


3.4.5 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 a seguir exemplifica na construção de um protótipo de interface do usuário
elaborado com Microsoft Visio:


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

3.4.7 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;

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

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


A tabela abaixo 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

3.4.10 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 registrados 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.

3.4.11 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;
Requisitos e Casos de Uso;
Modelo de Dados;
Diagramas de Projeto:
• Arquitetura;
• Classes e Objetos;
• Fluxo de Dados;
• Transição de Estados;
• Colaboração e Seqüência;
• Distribuição de Componentes;
Mapa de Navegação;
Planos 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.


4 Bibliografia Consultada
Fontes de artigos e livros consultados sobre padronização de Processo de Software e
assuntos correlatos:
• Norma NBR ISSO/IEC 12207 (Tecnologia da Informação – Processos de ciclo de vida de
software).
• Engenharia de Software: Teoria e Prática – Shari Lawrence Pfleeger, editora Prentice
Hall 2003.


Processo de Software para Desenvolvimento de Qualidade

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Processo de Software para Desenvolvimento de Qualidade

Semelhante a Processo de Software para Desenvolvimento de Qualidade (20)

Mais de Halan Ridolphi

Mais de Halan Ridolphi (12)

Processo de Software para Desenvolvimento de Qualidade