Artigo halan t14_seminário28042007

PPÓÓSS--GGRRAADDUUAAÇÇÃÃOO EEMM GGEERREENNCCIIAAMMEENNTTOO DDEE PPRROOJJEETTOOSS -- UUFFRRJJ SSEEGGRRAACC –– NNÚÚCCLLEEOO DDEE PPEESSQQUUIISSAA EEMM CCIIÊÊNNCCIIAASS DDAA EENNGGEENNHHAARRIIAA

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

1

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

Halan Ridolphi (Algoritma Software) [email protected] Engenheiro de Software, Pós-Graduação em Gerenciamento de Projetos (SEGRAC/POLI/UFRJ)

Orientador Lysio Séllos (SEGRAC/POLI/UFRJ) [email protected]

Engenheiro Civil, D.Sc.

Resumo

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

1. Introdução

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



2

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

Figura 1 – Cenário de desenvolvimento de software

Fonte: do autor

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



3

culminar na atuação das pessoas na forma de “apagar incêndio” quase que na maioria do tempo. Ou seja, um ambiente de trabalho que será uma visão do "inferno", onde quase não se “respira” ou se discute soluções, havendo boa carga de trabalho sendo realizado na forma de improvisação e, com criatividade, inovação e produtividade fortemente minadas pelos incidentes e suas recorrências.

O desafio do autor neste contexto de projeto tem sido organizar, coordenar e servir equipes de engenharia de software, mantendo visão sistêmica dos objetivos e metas, facilitando com que providências necessárias aconteçam e, como também, antecipação de problemas. Além disso, viabilizar e formalizar melhor organização do ambiente de trabalho, visando minimizar a improvisação da equipe, promovendo a adoção de padrões, para que se possam alcançar resultados efetivos e eficazes na conclusão do projeto. Neste sentido, algumas idéias para contribuir com o bom gerenciamento de projetos de software foram especificadas visando aperfeiçoar a atuação das pessoas neste cenário de trabalho e, portanto, será objeto de apresentação neste estudo.

2. Conceituando Processo de Software A preocupação com o estabelecimento de um processo de software padrão está relacionada à necessidade de entender, avaliar, controlar, aprender, comunicar, melhorar, predizer e certificar o trabalho realizado pelas pessoas de uma organização desenvolvedora de software.

cd Processo SW

Processo_de_Software

Ativ idadeRecurso Procedimento

Artefato

0..*Compõe

1..*

Requer

** Util iza 0..*

0..*

Consome

* 1..*

Produz

1..*

1..*

Possui

1

Figura 2 – Conceitos de processo de software

Fonte: do autor



4

A Figura 2 apresenta as entidades principais constituintes de um processo de software:

a. Processo de Software Organização de um conjunto de atividades com objetivo de desenvolver artefatos de um produto de software específico.

b. Atividade Uma ação de transformação que produz artefatos. Para ser executada uma atividade necessita de recursos e consome artefatos. Podem ser classificadas em atividades de construção, garantia de qualidade e gerenciamento. Podem ser organizadas em atividades menores ou tarefas visando orientar o desenvolvimento de artefatos de software.

Exemplos: Planejamento de Projeto, Análise de Requisitos, Projeto do Sistema, Codificação, Teste do Sistema, Homologação, Implantação.

c. Recurso Tudo que é requisitado por uma atividade, mas que não pode ser considerado uma entrada para ela, no sentido que não é incorporado ao artefato produzido. Pode ser software, hardware, pessoas, documentos ou banco de dados.

d. Procedimento Ações bem definidas para executar uma atividade. Basicamente, compõe a base técnica para construção de artefato de software e é classificado em métodos, técnicas e scripts.

Exemplos: Projeto Orientado a Objetos, Modelagem de Casos de Uso, Prototipação, UML, Análise de Pontos de Função, Padrões de Projeto, Projeto Estruturado, Linguagens de Programação (Object Pascal, ADA, Java, C++, Cobol, Modula 2).

e. Artefato A entrada ou saída de uma atividade.

Exemplos:

Categoria do Artefato Artefato Plano de Projeto Cronograma de Projeto Diagrama de Marcos do Projeto Plano de Release Plano de Comunicação Plano de Riscos Estimativas de Pontos por Função Estimativas de Pontos por Casos de Uso Plano de Garantia de Qualidade Ata de Reunião

Gerencial

Relatório de Progresso

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

Técnico

Modelo de Dados



5

Código Fonte Código Binário Mapa de Navegação Modelo de Casos de Uso Modelo de Interface do Usuário (Protótipos de Telas/Relatórios) Plano de Teste Plano de Treinamento Plano de Implantação Manual do Usuário

Tabela 1 – Exemplos de artefatos gerados em projetos de software

Fonte: do autor

3. Padronizando o Processo Produtivo de Projeto de Software A abordagem de padronização para processo de software contempla a especificação da estrutura de trabalho genérica adotada durante a realização de projeto de desenvolvimento de um produto de software. Inclui a definição e sequenciamento de atividades de gerenciamento, construção e garantia de qualidade, com aplicação de métodos, técnicas e ferramentas da engenharia de software visando à consolidação de processo de desenvolvimento de software eficaz e efetivo na construção de produto de qualidade elevada, e que supere as expectativas dos modelos de negócios. Os seguintes tópicos são abordados:

− Escopo de atividades fundamentais do processo produtivo do projeto de software; − Organização da equipe de projeto de software e definição dos perfis profissionais; − Alocação dos recursos humanos nas atividades e respectivas competências; − Modelos de ciclo de vida a ser adotado; − Atividades a serem realizadas e ordem de execução das mesmas durante o

desenvolvimento de um produto de software; − O conjunto mínimo de artefatos de software que devem ser construídos em cada atividade

do processo de software; − A menção as técnicas, métodos, ferramentas e procedimentos a serem observados pela

equipe de projeto durante as atividades realizadas ao longo do processo de desenvolvimento de software.



6

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

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

Fonte: do autor

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

Gerência de Projeto

Elaboração e avaliação de relatórios de progresso

Levantamento de necessidades junto ao cliente Estimativas de tamanho (APF)

Análise de Requisitos

Especificação de requisitos



7

Revisão de requisitos

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

Projeto Técnico & Construção

Definição de ferramentas IDE

Identificação itens de configuração Definição de ferramentas de controle da configuração de software Controle de mudanças Controle de versões Relatório de alterações e respectivos impactos

Gerência de Configuração

Armazenamento, manipulação e distribuição dos itens de configuração

Planejamento de teste integrado Elaboração de planos de testes Execução de planos de testes Inspeção de código Inspeção de projeto técnico Revisão de requisitos Relatórios de não conformidades Compilação dos resultados de testes

Garantia de Qualidade

Teste de regressão

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

Correção de defeitos

Controle da documentação Plano de treinamento Empacotamento do produto Planejamento de produção Customização e suporte técnico Criação de bancos de dados Otimização de query e stored procedures Planejamento de capacidade de bases de dados Planejamento de capacidade de servidores de arquivos Definições de segurança da rede de computadores Definições de links de comunicação de dados

Entrega e Produção

Criação de contas, grupos e domínios de usuários

Tabela 2 – Detalhamento de fases, atividades e tarefas associadas em projetos de software



8

Fonte: do autor

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

5.1. Organograma da Equipe

Figura 4 – OBS do projeto de software detalhando a rede formal de relacionamentos de reporte

Fonte: do autor

5.2. Definição de Responsabilidades

Matriz de Responsabilidades

Recursos



9

Produto, Evento ou Atividade Ger

ente

de

Proj

eto

Líde

r de

Equi

pe

Ana

lista

Proj

etis

ta

Prog

ram

ador

Clie

nte

Test

ador

Com

itê d

e D

ireci

onam

ento

Plano de Projeto & Cronograma X R R RA

Orçamento X R RA

Levantamento de Requisitos R C C R

Especificação de Requisitos R R R A A

Projeto Técnico & Arquitetura R C R A I

Modelagem de Dados R C R R A I

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

Programação de Subsistemas R C

Plano de Testes R R C S S I X

Teste de Software R E EX EX S AI X

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

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

Plano de Implantação R C R S I

Homologação R S S S X

Empacotamento do Produto R R S CX

Treinamento R C A

Instalação A C S R

Tabela 3 – Detalhamento de matriz de responsabilidades para projeto de software

Fonte: do autor

Legenda: A Aprovação I Informação

E Especificação R Revisão



10

C Construção S Suporte

X Execução

5.3. Definição de Habilidades

Recursos Humanos Habilidades

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

Comitê de Direcionamento

Aprovação do escopo, prioridades e orçamento.

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

Gerente de Projeto

Controle de mudanças de escopo do projeto

Entendimento e levantamento de necessidades junto ao cliente Definição processo produtivo de realização do projeto Resolução de conflitos Manutenção de foco e prioridades Organização de equipe do projeto Estimativas de tamanho do produto (APF)

Líder de Equipe de Projeto

Especificação e revisão da solução técnica



11

Definição das prioridades de desenvolvimento no projeto Auxílio na definição de arquitetura e componentes da solução técnica Modelagem de dados Inspeção de requisitos Padronizar a construção dos subprodutos (entregáveis) previstos pelo plano do projeto Planejamento da certificação interna do produto do projeto Planejamento da entrega do produto do projeto Acompanhamento da operação inicial do produto no ambiente alvo do cliente Apoio na revisão de planos de testes Apoio na execução de planos de testes Elaboração de relatórios de progresso Reportar o andamento das atividades ao gerente de projeto Controlar e monitorar cronograma de entregas de release Orientar a equipe na realização de atividades do processo produtivo do projeto Orientar a equipe na construção dos subprodutos (entregáveis) previstos pelo plano do projeto Reportar progresso das atividades ao cliente Argumentar para equipe do projeto que o trabalho de desenvolvimento de software é totalmente independente do ego:

• O êxito ou fracasso é resultado da equipe e, nunca de membros individuais;

• Pessoas são a chave do sucesso; • Poucas pessoas boas é melhor que muitas pessoas ruins; • Fazer correto antes de fazer rápido.

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

Analistas

Reportar progresso das atividades ao líder de equipe



12

Definição padrões de arquitetura de software (Orientada a Serviços, Pipelines, Orientada a Eventos, Cliente-Servidor, Repositório, MVC, MDA, CORBA, ORB, J2EE, Estruturada {Sistemas, Módulos, Sub-rotinas}, .NET) Definição padrões de desenvolvimento (frameworks, design patterns, orientação a componentes, bibliotecas de códigos reusáveis, APIs) Planejamento de desenvolvimento centrado na arquitetura de software:

• Particionamento funcional do domínio de aplicação; • Definição da estrutura de software (componentes e suas conexões

{comunicação e controle}); • 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 Definição de arquitetura e componentes da solução técnica Viabilizar gerência de configuração do produto de software

Projetistas

Reportar progresso das atividades ao líder de equipe

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

Programadores Seniores

Reportar progresso das atividades aos projetistas

Codificação Teste unitário Correção de defeitos Programadores Juniores

Reportar progresso das atividades aos programadores seniores

Elaboração de planos de testes Execução de planos de testes Relatórios de não conformidades Coleta de evidências de testes

Testadores

Reportar progresso das atividades aos analistas

Digitação de manuais de usuário Digitação de manuais técnicos Digitação de planos de implantação Documentadores

Digitação de especificações gerais

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



13

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

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

Administradores de Redes de Computadores

Customização e otimização de servidores de aplicação

Tabela 4 – Detalhamento de matriz de habilidades para equipe do projeto

Fonte: do autor

6. Planejando o Processo Produtivo do Projeto de Software

6.1. Processo de Gerência de Projeto Define as atividades essenciais a serem praticadas na coordenação do desenvolvimento de um produto de software.

Neste processo o gerente de projeto executa as seguintes atividades:

− Planejamento: decidir ‘o que fazer’, ‘como fazer’, ‘quando fazer’ e ‘quem deve fazer’; − Organização: definir estrutura organizacional, eficiente e eficaz, que facilite a execução

das atividades do projeto, que estabeleça autoridades e defina responsabilidades para execução dessas atividades;

− Seleção de Pessoal: selecionar, treinar e desenvolver pessoas para ocupar os cargos definidos na estrutura organizacional;

− Liderança: executar tarefas que motivem as pessoas a executar as tarefas definidas; − Controle: garantir que a execução do projeto ocorra conforme o planejado. Medir

desempenho e resultados, identificar desvios e definir ações corretivas; − Estimação: elaborar estimativas de custo, tamanho, cronograma e esforço para viabilizar a

execução do projeto de software.

Os procedimentos técnicos envolvidos na realização deste processo incluem:

− Estimativas de tamanho por Análise de Pontos Por Função ou COCOMO II; − Práticas PMI (PMBOK).

Dentre as ferramentas a serem utilizadas como repositório dos itens de configuração:

− Microsoft SharePoint (repositório de documentação); − Microsoft Office (plano de projeto);



14

− Microsoft Report Server (relatórios gerenciais); − Microsoft Project (cronograma); − Microsoft Visio (timeline).

Dentre os artefatos resultantes da execução deste processo incluem:

− Estimativas de Pontos por Função − Proposta de Fornecimento de Serviço de Software − Cronograma de Projeto − Plano de Projeto

• Plano de Riscos • Plano de Comunicação • Plano de Garantia de Qualidade • Plano de Recursos Humanos • Plano de Gerência de Configuração

− Diagrama de Marcos do Projeto − Relatório de Progresso

A seguir, citamos alguns exemplos de artefatos gerenciais como modelos a serem observados.

a. Exemplo de Cronograma Exemplo de cronograma para detalhamento de prazos das atividades que compõem cada fase do processo de desenvolvimento de software e a rede de precedências.



15

Figura 5 – Exemplo de cronograma de projeto de software detalhando fases, atividades e tarefas associadas

Fonte: do autor



16

b. Exemplo de Plano de Comunicação O exemplo de plano de comunicação para garantir que as questões sejam conhecidas com a antecedência necessária de forma a minimizar os impactos sobre o projeto.

Escala de Reuniões do Projeto

Ordem de Precedência da Comunicação Interna

Reuniões do Projeto Periodicidade Participantes Objetivos

4 Reunião da gerência do projeto Quinzenal

Gerente de Projeto Líder de Equipe Analistas Projetistas

Gerenciar o progresso do projeto como um todo e resolver questões escaladas nas reuniões das equipes de requisitos, projeto técnico e construção, além de 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 requisitos e projeto técnico

Semanal Líder de Equipe 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;



17

Melhorar comunicação interna com equipe de construção.

2 Reunião de equipe de construção 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 requisitos, projeto técnico e garantia de qualidade.

1 Reunião de equipe de garantia de qualidade Semanal

Líder de Equipe 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 construção; 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;

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

Fonte: do autor



18

Matriz de Participação em Reuniões do Projeto

Reuniões do Projeto Gerente do Projeto Líder de Equipe Analistas Projetistas Programadores Testadores Reunião da gerência do projeto X X X X

Reunião de equipe de requisitos e projeto técnico X X X

Reunião de equipe de construção X X

Reunião de equipe de garantia de qualidade X X X

Tabela 5 – Exemplo de matriz de participação nas reuniões do projeto

Fonte: do autor



19

c. Exemplo de Plano de Risco O exemplo de matriz de risco para detalhamento de medidas de contingência e mitigação de riscos do projeto.

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; Sem compensação financeira para equipe do projeto.

Estimativa detalhada de custo e cronograma, a partir de várias fontes de informação; Projeto de acordo com o custo; Simplificação dos requisitos; Reutilização de software.

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



20

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.

Quadro 2 – Exemplo de matriz de contingência e mitigação de riscos do projeto

Fonte: Adaptado de Rocha, 2001



21

6.2. Processo de Garantia da Qualidade Define as atividades para garantir a conformidade dos processos e produtos de software, no ciclo de vida do projeto, com seus requisitos especificados e sua aderência aos planos estabelecidos. Esse processo evidencia a relação entre a qualidade do produto e a qualidade do processo de software utilizado em sua construção. O processo de garantia da qualidade deve estar coordenado com tarefas de verificação, validação, revisão e resolução de problemas.

Na realização deste processo estão envolvidos gerente, analistas, projetistas, testadores e programadores os quais devem observar as atividades descritas adiante.

a. Garantia do Produto A atividade de garantia do produto implica nas seguintes tarefas técnico-administrativas:

− Garantir que todos os planos exigidos pelo contrato de fornecimento estejam de acordo com o mesmo, sejam documentados, estejam mutuamente consistentes e sejam executados quando exigidos;

− Garantir que os produtos de software e sua documentação estejam de acordo com o contrato e os planos;

− Garantir que os produtos de software satisfaçam totalmente os requisitos contratuais e sejam aceitáveis pelo cliente.

b. Garantia do Processo A atividade de garantia do processo implica nas seguintes tarefas técnico-administrativas:

− Garantir que os processos do ciclo de vida do software utilizados no projeto estejam de acordo com o contrato e os planos;

− Garantir que as práticas de engenharia de software, o ambiente de desenvolvimento, o ambiente de teste e as bibliotecas estejam de acordo com o contrato, com as negociações e com os planos;

− Garantir, no caso de subcontratação, que os requisitos aplicáveis sejam passados ao subcontrato e que seus produtos de software satisfaçam os requisitos do contrato original;

− Garantir que o cliente e outras partes envolvidas o apoio e a cooperação necessários; − Garantir que as medições do produto e do processo de software estejam de acordo com os

padrões e procedimentos estabelecidos; − Garantir que a equipe tenha a qualificação e o conhecimento necessários para o projeto e

receba todo o treinamento necessário. c. Sistema de Garantia da Qualidade Resumidamente, o sistema de garantia da qualidade deve observar as seguintes tarefas técnicas:

− Investigar métodos e procedimentos de prevenção de defeitos; − Medir o desempenho dos processos de software descritos nesta norma; − Aprender a identificar as causas dos problemas ou defeitos; − Saber agir corretiva e preventivamente para eliminar esses problemas ou defeitos e,

principalmente, as suas causas.



22

d. Verificação e Validação do Software As atividades de verificação e validação objetivam minimizar a ocorrência de erros e falhas associadas no produto de software. O objetivo da verificação é assegurar que o software, ou uma determinada função do mesmo, esteja sendo implementada corretamente. O objetivo da validação é assegurar que o software que está sendo desenvolvido é o software correto de acordo com os requisitos do cliente.

A condução efetiva das atividades de verificação e validação requer a elaboração de um modelo de erros que capte os erros típicos, os riscos associados, a freqüência de ocorrência e demais aspectos relevantes, de maneira que a experiência e o conhecimento de desenvolvimento de software da equipe de projeto sejam utilizados em planejamentos futuros para novos projetos. O número de locais no produto que podem conter erros é praticamente infinito para fins práticos e, portanto, a adoção de estratégia baseada em um modelo de erros tende a conduzir as atividades de V&V com maior eficiência e produtividade. O papel do modelo de erros é orientar a procura por erros nos locais que apresentam, segundo informações estatísticas, maiores probabilidades de apresentarem defeitos. Um ‘bom’ modelo de erros é capaz de retratar os defeitos e seus atributos contidos em sistemas reais. O modelo de erros deve ser mantido em base histórica de incidentes em repositório de documentação. Neste caso específico, a ferramenta Microsoft SharePoint pode ser utilizada para armazenar esse conhecimento na forma de lista de histórico dos incidentes do projeto.

Ressaltamos também que, um Modelo de Casos de Uso estabelece uma base de concordância entre o cliente e desenvolvedores sobre o que o sistema de software deve fazer e, neste sentido, este artefato possibilita a validação se o sistema de software está sendo modelado em conformidade com regras de funcionamento esperadas pelo cliente, constituindo em ferramenta de apoio à garantia de qualidade:

− Inspeção de requisitos (identificar defeitos na definição): • Estão corretos, consistentes, sem ambigüidades, completos;

− Validação de requisitos (conceber o software correto): • Estão refletindo a realidade, sem omissão, sem informação estranha;

As atividades de verificação e validação compreendem tarefas técnicas descritas nas próximas seções.

Análise Estática A análise estática não envolve a execução propriamente dita do produto de software e visa determinar propriedades do produto válidas para qualquer execução do produto final. A análise estática pode e deve ser aplicada em qualquer artefato de software gerado no transcorrer do processo de desenvolvimento. Os métodos empregados na realização de análise estática incluem as revisões de requisitos (PBR – Perspective-Based Reading), revisões de projeto (OORT – Object-Oriented Readind Techniques), revisões de código (Refactoring), análise da árvore de falhas, compilação e otimização de código.

Análise Dinâmica A análise dinâmica tem por objetivo detectar defeitos ou erros no software e envolve a execução do produto. As tarefas de simulação e teste constituem uma análise dinâmica do produto. O teste de software é uma tarefa usada para fornecer evidências da confiabilidade do



23

software em complemento às revisões de software. As informações obtidas durante as revisões são extremamente úteis para o teste por permitirem a identificação dos módulos críticos e propensos a erros.

A liberação de novo release do produto não é permitida sem antes haver uma condução sistemática de análise dinâmica e avaliação dos resultados alcançados.

Os métodos empregados na realização de análise dinâmica incluem a adoção de técnicas de teste (funcional, estrutural, baseada em erros, baseada em máquinas de estado finito) a serem utilizadas para estabelecer planos de testes, casos de teste, critérios de teste e a própria realização dos procedimentos de teste, de modo a verificar se os requisitos especificados para o software foram corretamente implementados.

Verificação Propriamente Dita Outras tarefas de escopo da verificação de acordo com a norma ISO/IEC 12207 incluem:

− Verificação do contrato; − Verificação do processo; − Verificação de requisitos; − Verificação do projeto; − Verificação do código; − Verificação da integração; − Verificação da documentação.

Validação Propriamente Dita Outras tarefas de escopo da validação de acordo com a norma ISO/IEC 12207 incluem:

− Preparar os requisitos de teste, casos de teste, planos de teste para analisar os resultados; − Assegurar-se de que esses artefatos de teste reflitam os requisitos particulares para um uso

específico do software; − Conduzir testes considerando teste de estresse, de carga e de entradas específicas,

avaliando a habilidade do produto de software para isolar e minimizar os efeitos de erros; − Conduzir testes com usuários representativos para avaliar se eles conseguem realizar suas

tarefas usando o produto de software; − Validar se o produto de software satisfaz seu uso específico e testar o produto de software

propriamente no seu ambiente-alvo.

e. Teste de Software

O teste de software é uma atividade crítica de garantia de qualidade que consiste na análise dinâmica do produto, ou seja, na execução do produto de software com o objetivo de verificar a presença de defeitos e aumentar a confiança na correção do software. A atividade de teste envolve a execução das etapas de planejamento, projeto de casos de teste, execução e avaliação de resultados. No planejamento da atividade de teste são estimados recursos e são definidos estratégias, métodos e técnicas de teste, caracterizando-se um critério de aceitação do software em desenvolvimento. Em geral, atividade de teste não pode mostrar a correção de um software, pois o conjunto dos dados de entrada normalmente é infinito ou muito extenso, a



24

ponto de ser inviável testar todas as possibilidades, o que corresponderia ao teste exaustivo, pelo qual a correção poderia ser comprovada. A atividade de teste é dividida em fases visando minimizar a complexidade, tanto na abordagem desenvolvimento procedimental quanto na orientada a objetos. Basicamente, há três fases de teste: de unidade, de integração e de sistema.

Técnicas de Teste As técnicas de teste são classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste, a saber:

− Técnica Funcional ou Caixa Preta; − Técnica Estrutural ou Caixa Branca; − Técnica Baseada em Erros; − Técnica Baseada em Máquinas de Estado Finito.

Critérios de Teste Um critério de teste serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de revelar a presença de defeitos ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto. Um caso de teste é um par ordenado composto por um dado de entrada, isto é, um elemento do domínio de entrada, e pela saída esperada.

Os critérios de teste podem ser utilizados como:

− Critério de adequação de casos de teste; − Critério de geração de casos de teste.

As propriedades mínimas desejáveis em um critério de teste são:

− Garantir, do ponto de vista do fluxo de controle, a execução de todas as transferências de fluxo de controle;

− Exigir, do ponto de vista do fluxo de dados, ao menos um uso de todo resultado computacional;

− Exigir um conjunto de casos de teste finito.

f. Revisões de Software As revisões (inspeções) no produto de software compreendem o ideal de assegurar que o artefato produzido, seja ele um documento, especificação de requisitos, projeto técnico ou outro resultado a ser fornecido, possui qualidade suficiente para ser utilizado por seu usuário. Os artefatos são revisados ao longo do processo de desenvolvimento de software, para garantir que a equipe de projeto esteja utilizando documentos pelo menos com a qualidade mínima especificada. As revisões de software são aplicadas a código-fonte, projeto técnico, requisitos durante o processo de desenvolvimento, de maneira a encontrar defeitos. Os defeitos encontrados pelas revisões de software referem-se à faltas. Uma falta em algum artefato estático – pro exemplo, diagrama de projeto – é importante por levar a implementações nas quais as falhas ocorrem. Defeitos encontrados por teste representam sempre falhas do software e podem ser rastreadas por meio de depuração.



25

Tipos de Defeitos Para facilitar a revisão do software é possível à identificação e instanciação de classes mais abrangentes de defeitos para situações específicas. A tabela abaixo apresenta a descrição desse conjunto de defeitos genéricos e suas instanciações para diferentes contextos de revisão, no caso especificação de requisitos e projeto técnico. É importante observar que essas classes de defeitos não são ortogonais (um defeito poderia se enquadrar em mais de uma categoria), mas pretendem apresentar o conjunto de possíveis defeitos que podem ocorrer.

Defeito Descrição geral Aplicado ao requisito Aplicado ao projeto

Omissão

As informações necessárias sobre o sistema foram omitidas do artefato de software.

• Algum requisito importante relacionado a funcionalidade, ao desempenho, as restrições de projeto, ao atributo ou a interface externa não foi incluído;

• Não está definida a resposta do software para todas as possíveis situações de entrada de dados;

• Faltam seções na especificação de requisitos;

• Faltam referências de figuras, tabelas e diagramas;

• 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 software contradizem as informações presentes na especificação de requisitos ou o conhecimento geral do domínio.

Um requisito descreve um fato que não é verdadeiro, considerando as condições solicitadas para o sistema de software.

Um diagrama de projeto contém uma 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



26

aplicam a esse domínio e não deveriam ser incluídas ao projeto.

Quadro 3 – Matriz de tipos de defeitos de software

Fonte: Adaptado de Rocha, 2001

Processo de Revisão A atividade de revisão de software compreende a execução das etapas de planejamento, detecção, coleção e correção dos defeitos. A figura 6 descreve o encadeamento de atividades do processo de revisão de software:

Figura 6 – Processo de revisão de software detalhando perfis, atividades e artefatos gerados

Fonte: Prof. D.Sc. Guilherme Travassos, COPPE-UFRJ, 2001

Detecção de Defeitos

Uma abordagem para identificar defeitos em artefatos é fornecida pelas técnicas de leitura de software. Uma técnica de leitura é uma sequência de etapas (heurísticas) preparada para a análise individual de um artefato visando compreender suas funcionalidades e identificar seus potenciais defeitos. Técnicas de leitura aumentam a eficiência dos revisores individuais por fornecerem diretrizes utilizadas durante a fase de detecção de defeitos em um processo de



27

revisão para examinar (ou ler) um dado artefato e identificar defeitos. Em vez de os revisores aplicarem apenas seus próprios conhecimentos e técnicas, as técnicas para leitura de software agregam o conhecimento das melhores práticas para detecção de defeitos em um procedimento que pode ser seguido e repetido.

Dentre as técnicas de leitura de software disponíveis para detecção de defeitos destacamos:

− Revisão de requisitos: leitura com base em perspectiva (PBR – Perspective-Based Reading);

− Revisão de projeto: técnicas de leitura de projeto orientado a objetos (OORT – Object-Oriented Reading Techniques);

− Revisão de código: refatoração (Refactoring).

6.3. Processo de Gerência de Configuração Define as atividades para a aplicação de procedimentos administrativos e técnicos por todo o ciclo de vida do software, destinadas a identificar e definir os itens de software em um sistema e estabelecer suas linhas básicas (baseline); controlar as modificações e liberações dos itens; registrar e apresentar a situação dos itens e dos pedidos de modificação; garantir a conclusão, a consistência e a correção dos itens; controlar o armazenamento, a manipulação e a distribuição dos itens de software.

Item de configuração de software é o nome dado ao item de informação produzido durante o processo de desenvolvimento de software para o qual é importante que seja realizado o controle das alterações. Um conjunto de itens de configuração compõe uma configuração de software.

Dentre as ferramentas a serem utilizadas como repositório dos itens de configuração:

− Microsoft SourceSafe (código fonte); − Microsoft SharePoint (documentação).

O método utilizado para trabalhar com itens de configuração no domínio do repositório é chamado de check-in/check-out, ou seja, conferência na entrada e conferência na saída.

Na realização deste processo estão envolvidos gerente, analistas, projetistas e programadores os quais devem observar as atividades descritas adiante.

a. Identificação da Configuração

Esta atividade consiste na seleção dos itens de informação a serem gerenciados. É que sejam selecionados itens relevantes, porque uma superdocumentação onera muito a gerência de configuração. Os itens mais usados pela equipe, os mais genéricos, os mais importantes para segurança, os projetados para reutilização e os que podem ser modificados por vários desenvolvedores ao mesmo tempo.

Notadamente, os artefatos a serem os observados pela gerência de configuração são:

− Código de Frameworks; − Código de Bibliotecas Reusáveis; − Código de Módulos, Componentes e Subsistemas; − Documentação Técnica;



28

− Arquivos de Configuração.

b. Controle de Configuração

Controle de Mudanças As alterações em artefatos de software (código e documentação) devem ser registradas em documento de Controle de Mudanças, o qual deve contemplar descrições detalhadas das mudanças incluídas em novas revisões desses artefatos. As mudanças devem comentar a necessidade, a solução, a questão ou incidente associado, a data de liberação da nova revisão do artefato. Também deve ser utilizado a ferramenta Microsoft SharePoint para registro de questões e incidentes que podem estar originando a solicitação de mudanças nos artefatos.

Controle de Versões As versões dos artefatos de software (código e documentação) devem ser mantidas pelas ferramentas Microsoft SourceSafe e Microsoft SharePoint. A liberação de nova versão de módulos de programa deve ser registra em rótulos na base de código fonte do Microsoft SourceSafe. O procedimento de geração de build oficial deve ser seguido e ao final de sua execução deve ser publicado na lista de build mantidas Microsoft SharePoint. As novas versões de documentação serão mantidas pelo histórico de versões do Microsoft SharePoint. As alterações em documentos devem ser seguidas pela atualização da seção de histórico de revisões constantes nos próprios documentos, cujo objetivo é manter registros das mudanças associadas à nova revisão da documentação.

A organização do código fonte na base do Microsoft SourceSafe deve observar o procedimento padrão de estruturação do código fonte para determinado produto de software, considerando as características específicas de implementação de módulos do produto (web, database, batch, online, unix, windows, com+).

A disposição da documentação na base do Microsoft SharePoint deve observar a norma padrão de organização do site de projeto, incluindo as bibliotecas de acesso a documentação (pública, protegida e privada) e os tipos de documentos em si (cronograma, plano de projeto, especificação funcional, especificação técnica, plano de teste, plano de implantação).

Liberação e Entrega de Release

A liberação e empacotamento de novo release de módulo de programa deve observar o procedimento oficial de geração de nova compilação e ao final de sua execução deve ser publicado na lista de build mantidas Microsoft SharePoint. A área de deploy localizado em servidor de desenvolvimento deve ser organizada para facilitar a transferência dos módulos de programa para ambiente de produção. Notadamente, a área de deploy deve ser organizada considerando a tecnologia específica de implementação de módulos do produto (web, database, batch, online, unix, windows, com+). O código fonte também deve ser disponibilizado na área de deploy.

6.4. Processo de Desenvolvimento Define as atividades essenciais para engenharia do produto de software. Inclui a execução de análise de requisitos, projeto técnico, codificação, testes, homologação, empacotamento, entrega, instalação em produção e manutenção.

a. Modelo de Ciclo de Vida



29

O modelo de ciclo de vida descreve a ordem de execução e relacionamentos das atividades do processo de software desde identificação da necessidade passando por definição da solução, certificação, instalação, treinamento, uso e manutenção do produto de software construído.

O ciclo de vida do software será composto por abordagem de desenvolvimento por fases e atividades técnicas de engenharia do produto de software, conforme descrito adiante.

b. Desenvolvimento por Fases O desenvolvimento do produto será particionado em subsistemas funcionais entregues em releases intermediárias do sistema de software final. O objetivo é liberar o mais cedo possível versões operacionais do produto capazes de agregar valor ao negócio e ajustar as necessidades dos clientes por rapidez nas soluções diante de mudanças ambientais e requisitos de negócio. Além disso, organizar o desenvolvimento do produto em releases intermediários em contraposição a um release “big-bang” reduz riscos do projeto, pela obtenção de feedback dos desenvolvedores de software logo nos releases iniciais do sistema de software em construção.

A figura 7 esclarece a abordagem baseada no desenvolvimento incremental e iterativo de versões do produto de software:

Figura 7 – Processo desenvolvimento incremental e iterativo de versões do produto de software

Fonte: do autor

c. Engenharia do Produto de Software



30

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

Figura 8 – Processo desenvolvimento de cada release intermediário do produto de software

Fonte: do autor

O modelo ciclo de vida acima contempla as seguintes características desejadas:

− Relaciona as atividades de testes com análise e projeto técnico; − As conexões implicam em retrabalho se inconformidades são detectadas; − O foco reside na atividade e na correção.

d. Análise de Requisitos

Esta atividade compreende as tarefas de levantamento de necessidades, identificação de requisitos, documentação de requisitos (funcionais e não-funcionais) e especificação de requisitos. O artefato a ser alcançado compreende uma especificação de requisitos (funcional) do produto de software a ser desenvolvido. Também é objetivo da atividade de Análise de Requisitos apoiar as estimativas de tamanho de projeto por meio do auxilio a Gerência do Projeto em análises de pontos por função aplicadas ao levantamento de necessidades que foi detalhado formalmente.

Uma especificação de requisitos objetiva:

− Estabelecer uma base de concordância entre cliente e desenvolvedores sobre o que



31

software fará; − Fornecer uma referência para validação do produto final; − Detalhar o que o software proposto deve fazer sem preocupar em como deve fazer; − Reduzir custo de desenvolvimento e minimizar retrabalho; − Definir o “o quê”, ou seja, quais informações serão processadas, quais funções e

desempenho são desejados, quais interfaces devem ser estabelecidas, quais restrições do projeto e critérios de validações são necessários.

Algumas técnicas para identificação de requisitos:

− Entrevistas, reuniões de grupo, brainstorning; − Sessões JAD, observação, documentação, reutilização.

A figura 9 demonstra algumas fontes possíveis de requisitos [Pfleeger, 2000]:

Figura 9 – Descrição de fontes possíveis de requisitos do produto de software

Fonte: Pfeeger, 2000

Os métodos envolvidos na elaboração de uma especificação de requisitos incluem:

− Modelagem de Dados ER; − Análise de Pontos Por Função; − Modelagem de Casos de Uso; − Protótipo de Interface do Usuário (Telas/Relatórios); − Diagrama de Fluxo de Dados;



32

− Diagrama de Classes de Domínio; − Diagrama Hierárquico Funcional.

Dentre as ferramentas a serem utilizadas na elaboração de uma especificação de requisitos:

− Microsoft SharePoint (repositório de documentação); − Microsoft Office (especificação); − Microsoft Visio (protótipos, fluxo de dados, DHF); − Enterprise Architect (casos de uso, classes de objetos do domínio).

A figura 10 esclarece o encadeamento de tarefas na construção de uma especificação de requisitos [Pfleeger, 2000]:

Figura 10 – Atividade de especificação de requisitos do produto de software

Fonte: Pfeeger, 2000

e. Prototipação A atividade de prototipação visa apoiar as atividades de especificação de requisitos e projeto do sistema. O objetivo é compreender as necessidades através de modelos de interatividade com o produto de software proposto. Também é objetivo demonstramos aparência e funcionalidade para o sistema de software sendo projetado.

Dentre as ferramentas a serem utilizadas na elaboração de um protótipo básico do produto de software:

− Microsoft SharePoint (repositório de documentação); − Microsoft Office (especificação); − Microsoft Visio (protótipos GUI);



33

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

Figura 11 – Exemplo de protótipo de interface do usuário

Fonte: do autor

f. Projeto do Sistema

A atividade de projeto do sistema visa desenvolver uma solução técnica para desenvolvimento do produto de software centrada na definição da Arquitetura de Software (topologia, inter-relacionamentos, subsistemas, hierarquia, protocolos). O projeto do sistema detalha a apresentação e funcionalidades do sistema de software proposto.

Os métodos envolvidos na elaboração do projeto do sistema incluem:

− Padrões arquiteturais; • Pipelines, Camadas Hierárquicas, Orientado a Eventos; • Orientada a Componentes [CORBA, J2EE, ORB, .NET, COM+, DCOM]; • Orientada a Serviços [Web Services, Grid Services]; • MVC, Cliente-Servidor; • Invocação implícita; • Estruturada [Sistemas, Subsistemas, Módulos, Sub-rotinas]; • Domínios Específicos [Aviação, Biomédica, Geográfica].

− Projeto OO, UML;



34

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



35

− Refinamento do Projeto de Interface de Usuário: • Layouts; • Usabilidade.

Como observação geral, o projeto técnico abrange o detalhamento da configuração de hardware, das necessidades de software, das interfaces de comunicação, da entrada e saída de informação do sistema, da arquitetura de rede, e de tudo o que traduz os requisitos em uma solução para o problema do cliente. Neste sentido, o projeto técnico deve contemplar os seguintes aspectos:

− Uma descrição dos principais componentes de hardware e de suas funções; − A hierarquia e função dos componentes de software; − A estrutura de dados e o fluxo de dados.

g. Projeto de Subsistemas A atividade de projeto de subsistemas visa desenvolver e refinar a especificação técnica para componentes individuais do sistema em construção. Neste sentido, as interfaces, classes e componentes são detalhados em baixo nível e requisitos não-funcionais (segurança e desempenho) são considerados. Estruturas de dados e algoritmos são especificados para cada componente da solução. Demais decisões de projeto como definição de bases de dados, das linguagens de programação, dos padrões de projeto, dos padrões de integração entre componentes e dos estilos de interface do usuário.

Os métodos envolvidos na elaboração do projeto de subsistemas incluem:

− Padrões de Projeto (brigde, abstract factory, composite, singleton, facade); − Modelo Físico de Dados; − Projeto Tempo-Real (Máquinas de Estado); − Projeto Estruturado (DFD, DTE, DC, Dicionários de Dados, Pseudo-Código) − Projeto OO - UML (Diagramas de Casos de Uso, Colaboração, Sequência, Classes,

Atividades, Estados, Pacotes, Componentes, Implantação).

Dentre as ferramentas a serem utilizadas na elaboração do projeto do sistema:

− Microsoft 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;



36

Arquivos de Configuração; Banco de Dados Relacional;

• Objetos Distribuídos: Protocolos (http, xml); Comunicação (pipes, rpc, shared memory, message queue); Sincronização (semáforos, regiões críticas, variáveis mutex) entre Processos;

• Complexidade Estrutural; • Reutilização de Bibliotecas de Classes e Frameworks:

COM+, Framework Struts, Framework .NET; − Preparação dos contratos das classes:

• Padrões de Projeto; • Especificação das Interfaces de Objetos; • Especificação das Implementações de Objetos;

− Consideração de requisitos não funcionais: • Segurança; • Desempenho; • Entrada e saída; • Interoperabilidade;

h. Codificação A atividade de codificação deve codificar e documentar cada módulo de software e definir a base de dados usando técnicas de implementação que produzam um código eficiente e livre de erros. Como resultado de uma implementação bem-sucedida, as unidades de software devem ser obtidas e critérios de verificação (inspeção de código) devem executados.

Dentre as algumas ferramentas a serem utilizadas na codificação dos módulos e subsistemas do produto de software:

− Microsoft SourceSafe (repositório de código fonte); − Framework Struts; − Microsoft Visual C++; − Borland Delphi; − Eclipse; − PLSQL Developer; − Oracle DBMS; − WebLogic.

Os métodos envolvidos na codificação dos módulos de software incluem:

− Padrões de Programação (refactoring); − Frameworks e Design Patterns; − Reutilização de Bibliotecas de Funções;



37

− Programação Estruturada; − Programação Orientada a Objetos;

A codificação deve observar os seguintes aspectos técnicos:

− Diretriz básica: “Programas não devem ser construídos de forma que eles sejam fáceis de escrever, mas de forma que eles sejam fáceis de ler, compreender e manter”;

− Tradução dos artefatos de projeto OO para linguagem de programação orientada a objetos; − Refinamento de estruturas hierárquicas; − Generalizações para uso futuro (componentes); − Inspeção de código:

• Comentários e endentação; • Nomeação de variáveis, constantes e declarações; • Adequação as boas práticas (facilidade de leitura, compreensão e manutenção); • Verificação de mecanismos de reutilização, composição, encapsulamento,

polimorfismo e recursividade; • Verificação de assertivas; • Verificação de estruturas de controle; • Verificação de estruturas de dados; • Verificação de algoritmos; • Verificação de expressões lógicas, relacionais e aritméticas;

− Teste de Unidade: • Classes, Módulos e Componentes; • Verificação de Código.

i. Teste de Unidade, Integração e Sistema O teste de unidade tem por objetivo explorar a menor unidade do projeto, procurando identificar erros de lógica e de implementação em cada módulo de programa, separadamente.

O teste de integração objetiva descobrir erros associados as interfaces entre os módulos de software quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto.

O teste de sistema objetiva identificar erros de funções e características de desempenho que não estejam de acordo com a especificação.

Ressalta-se que as atividades de teste envolvem as etapas de planejamento, projeto de casos de teste, critérios de teste, execução e avaliação dos resultados.

Planos formais de teste unitário e integração devem ser elaborados. As evidências de teste devem ser coletadas e documentadas.

Dentre as ferramentas a serem utilizadas para apoiar a realização de testes incluem-se:

− Microsoft SharePoint (repositório de documentação); − Microsoft Office (especificação);



38

− Enterprise Architect (casos de testes); − JUnit (teste automatizado); − Microsoft Web Stress Tools (teste automatizado).

Após a realização de testes do software os seguintes aspectos técnicos devem ser considerados:

− Rastreabilidade para os requisitos e projeto; − Consistência externa com os requisitos e com o projeto; − Consistência interna entre os requisitos do produto; − Abrangência do teste; − Adequação dos métodos e padrões de codificação utilizados; − Viabilidade de integração e teste do produto; − Viabilidade de operação e manutenção.

O quadro 4 logo a seguir descreve a relação entre as fases de teste e os paradigmas de desenvolvimento de software procedimental e orientado a objetos:

Paradigma de desenvolvimento

Fases de teste Procedural Orientado a Objetos Unidade Sub-rotina ou função Classe Integração Módulos

Subsistemas Classe Subclasse Pacote de classes Componentes

Sistema Toda a aplicação Toda a aplicação

Quadro 4 – Fases de teste versus paradigmas de desenvolvimento de software

Fonte: Adaptado de Pfeeger, 2000

j. Homologação A homologação envolve a certificação do produto de software no ambiente-alvo do cliente. Esta atividade compreende as tarefas de planejamento de instalação, customização e disponibilização de ferramentas automatizadas de apoio à certificação. Os defeitos detectados durante a homologação devem ser registrados em uma lista de questões do projeto, automatizada pela ferramenta Microsoft SharePoint, juntamente com as evidências do incidente, para que possam ser examinadas e trabalhadas pela equipe de desenvolvimento e tenham acompanhamento da evolução do progresso da correção por parte do cliente. Um novo release do produto gerado em resposta a correção dos defeitos seguirão os procedimentos padrões de geração de release e disponibilização para implantação em ambiente de homologação do cliente. Todas as alterações funcionais no produto em decorrência da implementação da correção de defeitos devem ser registradas em documento de Controle de Mudanças e, a documentação associada ao produto deve ser adequadamente revisada para refletir fielmente as características nativas do produto. Toda documentação técnica, planos de teste, planos de implantação e manuais de usuário deve estar disponível a consulta prévia pelo cliente.

k. Entrega e Manutenção



39

A entrega do produto deve seguir procedimento oficial de geração de nova compilação, empacotamento de módulos do produto e publicação de novo release na lista de build mantidas Microsoft SharePoint. A área de deploy localizado em servidor de desenvolvimento deve ser organizada para facilitar a transferência dos módulos de programa para ambiente de produção. Notadamente, a área de deploy deve ser organizada considerando a tecnologia específica de implementação de módulos do produto (web, database, batch, online, unix, windows, com+). O código fonte também deve ser disponibilizado na área de deploy. Um planejamento de implantação em produção deve ser elaborado com objetivo de especificar os detalhes específicos (precedência, periodicidade, expurgo, customização) dos módulos do sistema de software sendo instalado em ambiente de produção previsto em contrato. Toda documentação técnica, manuais de treinamento e manuais de usuário devem ser empacotados e disponibilizados ao cliente. Acompanhamento pós-implantação deve ser oferecido ao cliente durante os estágios iniciais de operação do produto de software.

A entrega do produto de software deve observar os seguintes aspectos técnicos:

− Empacotamento: • Código Fonte; • Código Executável; • Arquivos de Configuração;

− Instalação: • Scripts de Instalação; • Plano de Implantação:

− Treinamento: • Usuário;

− Documentação: • Manual do Usuário; • Manuais Técnicos:

Modelo de Requisitos; Modelo de Casos de Uso; Modelo de Dados; Diagramas de Projeto Técnico: ♦ Arquitetura; ♦ Classes e Objetos; ♦ Fluxo de Dados; ♦ Transição de Estados; ♦ Colaboração e Seqüência; ♦ Distribuição de Componentes;

Mapa de Navegação; Plano de Teste;

A manutenção do produto deve garantir que o sistema de software em produção continue sendo útil e atendendo as necessidades do usuário. A manutenção pode ser solicitada por



40

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.



41

7. Conclusões O gerenciamento de projetos de software se preocupa em entregar o sistema de software no prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitações de orçamento e tempo. A gerência de projetos de software se caracteriza por tratar sobre um produto intangível, muito flexível e com processo de desenvolvimento com baixa padronização.

Um processo produtivo bem definido, documentado e padronizado certamente torna-se mecanismo efetivo de gerenciamento de projetos. A padronização para processo produtivo de projeto de software viabiliza a capacidade da corporação construtora do produto de software, de repetir sucessos anteriores pelo acompanhamento sistemático de custos, cronogramas e funcionalidades. A padronização também possibilita realizar uma gerência quantitativa do processo e do produto de software, onde a informação quantitativa é utilizada para melhorar continuamente e gerenciar o processo produtivo do projeto de software. Visando assegurar bons resultados e êxito nos projetos de software, entendemos que se torna imperativo definir, planejar, documentar e publicar a estrutura de trabalho genérica adotada durante a realização de projeto de desenvolvimento de um produto de software. Para abordar o planejamento de projeto de software recomendamos fortemente contemplar a definição e sequenciamento de atividades de gerenciamento, construção e garantia de qualidade, com aplicação de métodos, técnicas e ferramentas da engenharia de software. Portanto, visando à consolidação de processo produtivo de projeto de software eficaz e efetivo na construção de produto de qualidade elevada e confiável, capaz de superar as necessidades e demandas de modelos de negócio em constante mutação.

8. Referências PFLEEGER, Shari Lawrence Engenharia de Software: Teoria e Prática. São Paulo: Prentice Hall, 2003. Cap. 3, p. 80 – 110.

NBR ISO/IEC 12207:1998 Tecnologia da Informação – Processos de Ciclo de Vida de Software.

ROCHA, Ana Regina Cavalcanti et al. Qualidade de Software: Teoria e Prática. São Paulo: Prentice Hall, 2001. Cap. 1, p. 1 – 50.

Artigo halan t14_seminário28042007

Documents

Transcript of Artigo halan t14_seminário28042007