Planejamento do processo_de_software_halan

MBA-ENGSOFT Qualidade de Software 1 © 2005 Halan Ridolphi

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


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_Software

Ativ idadeRecurso Procedimento

Artefato

0..*Compõe

1..*

Requer

** Util iza 0..*

0..*

Consome

* 1..*

Produz

1..*

1..*

Possui

1

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 • Definição de ferramentas CASE

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 • Inspeção de código • Inspeção de projeto • 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 • Correção de defeitos

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

Ger

ente

de

Pro j

eto

Ana

lista

Che

fe

Ana

lista

Proj

etis

ta

Prog

ram

ador

Clie

nte

Test

ador


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 testes • Execução de planos de testes • 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)

• Inspeção de projeto • Inspeção de código • 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 • Inspeção de código • Correção de defeitos • Apoio ao planejamento de implantação • Definição de ferramentas CASE • 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 • Correção de defeitos • Reportar progresso das atividades aos Programadores Seniores

Testadores

• Elaboração de planos de testes • Execução de planos de testes • 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 Precedência da Comunicação Interna

Reuniões do Projeto

Periodicidade Participantes Objetivos

4 Reunião da Gerência de Projeto

Quinzenal Gerente de Projeto Analista Chefe Analistas Projetistas

Gerenciar o progresso do projeto como um todo e resolver questões escaladas nas reuniões das equipes de Projeto Técnico e Desenvolvimento, além de determinar as diretrizes gerais do 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 equipe de Projeto Técnico

Semanal Analista Chefe Analistas Projetistas

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 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 equipe de Desenvolvimento

Semanal Projetistas Programadores

Discutir abordagens de desenvolvimento; Analisar status de progresso das atividades; 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

equipe de Garantia de Qualidade

Semanal Analista Chefe Analistas Testadores

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; 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 de Projeto X X X X

Reunião de equipe de Projeto Técnico X X X

Reunião de equipe de Desenvolvimento X X

Reunião de equipe de Garantia de Qualidade X X X

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 /Prioridade

Efeito Impacto do Risco

Mitigação do Risco Contingência ao Risco

Má compreensão dos requisitos

Moderada/Alta Catastrófico Construção do software errado; Degradação do orçamento e cronograma.

Construção de protótipos; Revisão de casos de uso com cliente; Inspeções de requisitos.

Realização de um contrato de seguro, a fim de cobrir qualquer perda financeira.

Perda de pessoal fundamental

Moderada/Alta Sério Atraso na entrega do produto; Elevação de custos por conta de treinamento e ambientação de pessoal.

Treinamento cruzado; Pessoal principal previamente agendado (comprometimento); Cuidado com aspectos morais da equipe (confiança, etc.).

Remanejamento de atividades ao pessoal de maior talento e experiência; Negociação de novos prazos finais de entrega do produto; Contratação de pessoal externo ao projeto em caráter temporário.

Tempo insuficiente para realização de testes

Moderada/Alta Sério Entrega do produto com defeitos críticos; Desempenho não aceitável.

Aceleração do desenvolvimento por reutilização de software; Desenvolvimento incremental com liberação de releases intermediárias do produto, certificando grupos de funcionalidades independentes.

Não realização de testes de regressão; Certificação das funcionalidades mais relevantes do release a ser liberado; Negociação de novos prazos de entrega.

Cronogramas e orçamentos não realistas

Moderada/Alta Catastrófico Atraso na entrega do produto; Insuficiência de verba para conclusão do projeto;

Estimativa detalhada de custo e cronograma, a partir de várias fontes de informação;

Realização de contrato de seguro; Renegociação de prazos e


Sem compensação financeira para equipe do projeto.

Projeto de acordo com o custo; Simplificação dos requisitos; Reutilização de software.

orçamento com cliente.

Desenvolvimento de interface do usuário inadequada

Moderada/Alta Catastrófico Não aceitação pelo usuário final; Aumento dos custos do projeto por retrabalho; Ampliação do prazo final.

Construção de protótipos; Revisão de requisitos de usabilidade com área usuária.

Realização de contrato de seguro; Renegociação de prazos e orçamento com cliente.

Fluxo contínuo de modificações nos requisitos

Moderada/Alta Sério Atraso na entrega do produto; Aumento dos custos do projeto; Retrabalho; Diminuição da produtividade e moral da força de trabalho.

Criação de projeto técnico flexível; Desenvolvimento incremental, protelando mudanças para fases posteriores.

Orçamento por homem-hora e não por projeto fechado; Renegociação de prazos e orçamento com cliente.

Insuficiência no desempenho em tempo real

Moderada/Alta Sério Não aceitação pelo usuário final; Inviabiliza realização das funções de negócio.

Simulação; Instrumentação; Otimização de código; Testes de stress.

Programar algoritmos paralelos na solução; Revisão técnica; Simplificação de requisitos de desempenho; Análise de custo-benefício; Expansão do tempo e esforço dos testes.

Insuficiência nos componentes fornecidos externamente

Baixa/Alta Sério Atraso na entrega do produto; Aumento dos custos do projeto; Desempenho não aceitável.

Análise de compatibilidade; Iniciar cedo o entendimento e certificação de componentes desenvolvidos por terceiros; Inspeções de conteúdo e funcionalidades; Benchmarking.

Realização de contrato de seguro; Escolhe de novo fornecedor externo; Renegociação de prazos e orçamento com cliente; 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 necessárias sobre o sistema foram omitidas do artefato de software.

1. Algum requisito importante relacionado a funcionalidade, ao desempenho, as restrições de projeto, ao atributo ou a 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).

A representação de um conceito dos requisitos gerais do domínio ou do documento de requisitos não está presente em nenhum diagrama de projeto.

Fato incorreto Algumas informações no artefato de

Um requisito descreve um fato que

Um diagrama de projeto contém uma


software contradizem as informações presentes na especificação de requisitos ou o conhecimento geral do domínio.

não é verdadeiro, considerando as condições solicitadas para o sistema de software.

representação errada de um conceito descrito nos requisitos gerais do domínio ou no documento de requisitos.

Inconsistência As informações em uma parte do artefato de software estão inconsistentes com outras no artefato de software.

Dois ou mais requisitos são conflitantes.

Uma representação de um conceito em um diagrama de projeto está em desacordo com a representação do mesmo conceito no mesmo ou em outro diagrama de projeto.

Ambigüidade As informações no artefato de software são ambíguas, isto é, é possível ao desenvolvedor interpretar as informações de diferentes maneiras, podendo não levar a uma implementação correta.

Um requisito tem várias interpretações devido a diferentes termos utilizados para uma mesma característica ou vários significados de um termo para um contexto particular.

Uma representação de um conceito no projeto não está clara e poderia causar má interpretação ou entendimento errado do seu significado por parte do usuário do documento.

Informação estranha As informações são fornecidas, mas não são necessárias ou mesmo usadas.

As informações no requisito são fornecidas, mas não são necessárias ou mesmo usadas.

O projeto inclui informações que embora talvez verdadeiras, não se 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 SharePoint (repositório de documentação); 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 SharePoint (repositório de documentação); Microsoft Office (especificação); 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 SharePoint (repositório de documentação); Microsoft Office (especificação); 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 SharePoint (repositório de documentação); Microsoft Office (especificação); 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: Microsoft SharePoint (repositório de documentação); Microsoft Office (especificação); 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

Subsistemas Classe 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.

Planejamento do processo_de_software_halan

Technology

Transcript of Planejamento do processo_de_software_halan