Planejamento do processo_de_software_halan
Upcoming SlideShare
Loading in...5
×
 

Planejamento do processo_de_software_halan

on

  • 2,778 views

Software Engineering

Software Engineering

Statistics

Views

Total Views
2,778
Views on SlideShare
2,726
Embed Views
52

Actions

Likes
0
Downloads
121
Comments
0

3 Embeds 52

http://tecnologia-de-valor.blogspot.com 33
http://tecnologia-de-valor.blogspot.com.br 18
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Planejamento do processo_de_software_halan Planejamento do processo_de_software_halan Document Transcript

  • POLI / UFRJ MBA Engenharia de Software – Turma 2004 Disciplina: Qualidade de Software Professora: Claudia Cappelli Aluno: Halan Ridolphi AlvesMBA-ENGSOFT Qualidade de Software 1© 2005 Halan Ridolphi
  • Sumário1 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 ..................................................................... 52 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 .......................................................... 83 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 ............................................................................. 344 Bibliografia Consultada .......................................................................................... 36MBA-ENGSOFT Qualidade de Software 2© 2005 Halan Ridolphi
  • 1 Introdução Este documento tem por objetivo detalhar norma de padronização para processo desoftware genérico de uma empresa desenvolvedora de software. A meta a ser alcançada com o estabelecimento de um processo de software padrão é aadoção de abordagem sistemática, repetível e organizada visando construção de sistemas desoftware 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 desoftware. O diagrama a seguir esclarece as entidades principais constituintes de um processo desoftware: cd Processo SW Processo_de_Softw are 1 Possui 1..* 0..* Recurso Ativ idade Compõe Procedimento Requer 1..* * * Utiliza 0..* * 1..* Consome Produz 0..* 1..* Artefato a. Processo de Software Organização de um conjunto de atividades com objetivo de desenvolver artefatos de um produto de software específico. b. Atividade Uma ação de transformação que produz artefatos. Para ser executada uma atividade necessita de recursos e consome artefatos. Podem ser classificadas em atividades de construção, garantia de qualidade e gerenciamento. Podem ser organizadas em atividades menores ou tarefas visando orientar o desenvolvimento de artefatos de software. Exemplos: Planejamento de Projeto, Análise de Requisitos, Projeto do Sistema, Codificação, Teste do Sistema, Homologação, Implantação. c. RecursoMBA-ENGSOFT Qualidade de Software 3© 2005 Halan Ridolphi
  • 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ário1.2 Norma de Processo de Software A norma de padronização para processo de software contempla a especificação daestrutura 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.MBA-ENGSOFT Qualidade de Software 4© 2005 Halan Ridolphi
  • 1.3 Escopo do Processo de Software1.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 CASEMBA-ENGSOFT Qualidade de Software 5© 2005 Halan Ridolphi
  • • 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íniosMBA-ENGSOFT Qualidade de Software 6© 2005 Halan Ridolphi
  • 2 Organização da Equipe Este seção descreve as partes envolvidas e respectivas competências no escopo doprocesso de desenvolvimento de software.2.1 Estrutura Organizacional Este seção descreve a estrutura organizacional e rede de relacionamentos de reporteentre os membros da equipe de software participantes do processo de desenvolvimento desistema de software.2.1.1 Organograma da Equipe2.1.2 Matriz de ResponsabilidadesMatriz de Responsabilidades Recursos Analista Chefe Programador Gerente de Projetista Testador Analista Projeto ClienteMBA-ENGSOFT Qualidade de Software 7© 2005 Halan Ridolphi
  • Produto, Evento ou AtividadePlano de Projeto & Cronograma X R RLevantamento de Requisitos R C C REspecificação de Requisitos R R R A AProjeto Técnico & Arquitetura R C R A IModelagem de Dados R C R R A IDocumentação do Produto R CX I R I RProgramação de Subsistemas R CPlano de Testes R R C S S I XTeste de Software R E EX EX S AI XRevisões de Artefatos de Software R E EX EX S I XGerência de Configuração R R E E X AIPlano de Implantação R C R S IHomologação R S S S XEmpacotamento do Produto R R S CXTreinamento R C AInstalação A C S RLegenda: A Aprovação I Informação E Especificação R Revisão C Construção S Suporte X Execução2.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 projetoMBA-ENGSOFT Qualidade de Software 8© 2005 Halan Ridolphi
  • • 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 ProjetistasMBA-ENGSOFT Qualidade de Software 9© 2005 Halan Ridolphi
  • • 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 proceduresMBA-ENGSOFT Qualidade de Software 10© 2005 Halan Ridolphi
  • • 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 capacidadeMBA-ENGSOFT Qualidade de Software 11© 2005 Halan Ridolphi
  • 3 Processo de Software3.1 Processo de Gerência de Projeto Define as atividades essenciais a serem praticadas na coordenação do desenvolvimentode 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 seremobservados.MBA-ENGSOFT Qualidade de Software 12© 2005 Halan Ridolphi
  • 3.1.1 Exemplo de Cronograma Exemplo de cronograma para detalhamento de prazos das atividades que compõemcada fase do processo de desenvolvimento de software e a rede de precedências.MBA-ENGSOFT Qualidade de Software 13© 2005 Halan Ridolphi
  • 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 formaa minimizar os impactos sobre o projeto.3.1.2.1 Escala de Reuniões de ProjetoOrdem de Reuniões do Periodicidade Participantes ObjetivosPrecedência da ProjetoComunicaçãoInterna4 Reunião da Quinzenal Gerente de Projeto Gerenciar o progresso do projeto como um todo e resolver Gerência de Analista Chefe questões escaladas nas reuniões das equipes de Projeto Técnico Projeto Analistas e Desenvolvimento, além de determinar as diretrizes gerais do Projetistas projeto; Apresentar riscos, problemas e discutir alternativas de solução para avanço do projeto; Discutir de relatório de progresso do projeto; Discutir feedback obtido junto ao cliente.3 Reunião de Semanal Analista Chefe Definir e priorizar alternativas de solução técnica; equipe de Projeto Analistas Analisar status de progresso das atividades; Técnico Projetistas Revisar status do projeto, milestones e produtos, issues, dependências e riscos e identificar issues de infra-estrutura e avaliar questões que devem ser encaminhadas para Reunião com Gerente de Projeto; Discutir técnicas de inspeção e revisão (projeto técnico); Melhorar padrões de especificação técnica; Discutir planejamento de homologação e entrada do produto em produção; Melhorar comunicação interna com equipe de Desenvolvimento.2 Reunião de Semanal Projetistas Discutir abordagens de desenvolvimento; equipe de Programadores Analisar status de progresso das atividades; Desenvolvimento Discutir problemas e alternativas de solução; Discutir técnicas de inspeção e revisão (código); Discutir entendimento das especificações técnicas. Melhorar comunicação interna com equipes de Projeto Técnico eMBA-ENGSOFT Qualidade de Software 14© 2005 Halan Ridolphi
  • Garantia de Qualidade.1 Reunião de Semanal Analista Chefe Discutir e planejar o esforço de teste a ser executado; equipe de Analistas Discutir técnicas de inspeção e revisão (requisitos); Garantia de Testadores Apresentar problemas quando da realização das últimas tarefas Qualidade de testes; Discutir formas de melhorar comunicação com equipe de Desenvolvimento; Priorizar issues apresentados pelo cliente; Revisar defeitos nas especificações de requisitos; Discutir novas abordagens de teste e automação do processo de teste; Compilação das evidências de teste;3.1.2.2 Matriz de Participação nas Reuniões do ProjetoMatriz de Participação em Reuniões Reuniões do Projeto Gerente do Projeto Analista Chefe Analistas Projetistas Programadores TestadoresReunião da Gerência X X X Xde ProjetoReunião de equipe de X X XProjeto TécnicoReunião de equipe de X XDesenvolvimentoReunião de equipe de X X XGarantia de Qualidade3.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 Projeto3.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.MBA-ENGSOFT Qualidade de Software 15© 2005 Halan Ridolphi
  • 3.1.2.5 Benefícios dos Mecanismos de Controle e Acompanhamento • Controle de progresso e de orçamento do projeto • Rápido atendimento a alterações de especificação • Transparência para o cliente 3.1.3 Exemplo de Plano de Risco O exemplo de plano de risco para contingência e mitigação de riscos de projeto.Risco Probabilidade Efeito Impacto do Mitigação do Risco Contingência ao Risco /Prioridade RiscoMá compreensão Moderada/Alta Catastrófico Construção do software errado; Construção de protótipos; Realização de um contratodos requisitos Degradação do orçamento e Revisão de casos de uso com de seguro, a fim de cobrir cronograma. cliente; qualquer perda financeira. Inspeções de requisitos.Perda de pessoal Moderada/Alta Sério Atraso na entrega do produto; Treinamento cruzado; Remanejamento defundamental Elevação de custos por conta de Pessoal principal previamente atividades ao pessoal de treinamento e ambientação de agendado (comprometimento); maior talento e pessoal. Cuidado com aspectos morais experiência; da equipe (confiança, etc.). Negociação de novos prazos finais de entrega do produto; Contratação de pessoal externo ao projeto em caráter temporário.Tempo insuficiente Moderada/Alta Sério Entrega do produto com Aceleração do desenvolvimento Não realização de testes depara realização de defeitos críticos; por reutilização de software; regressão;testes Desempenho não aceitável. Desenvolvimento incremental Certificação das com liberação de releases funcionalidades mais intermediárias do produto, relevantes do release a ser certificando grupos de liberado; funcionalidades independentes. Negociação de novos prazos de entrega.Cronogramas e Moderada/Alta Catastrófico Atraso na entrega do produto; Estimativa detalhada de custo Realização de contrato deorçamentos não Insuficiência de verba para e cronograma, a partir de seguro;realistas conclusão do projeto; várias fontes de informação; Renegociação de prazos e MBA-ENGSOFT Qualidade de Software 16 © 2005 Halan Ridolphi
  • Sem compensação financeira Projeto de acordo com o custo; orçamento com cliente. para equipe do projeto. Simplificação dos requisitos; Reutilização de software.Desenvolvimento Moderada/Alta Catastrófico Não aceitação pelo usuário Construção de protótipos; Realização de contrato dede interface do final; Revisão de requisitos de seguro;usuário inadequada Aumento dos custos do projeto usabilidade com área usuária. Renegociação de prazos e por retrabalho; orçamento com cliente. Ampliação do prazo final.Fluxo contínuo de Moderada/Alta Sério Atraso na entrega do produto; Criação de projeto técnico Orçamento por homem-modificações nos Aumento dos custos do projeto; flexível; hora e não por projetorequisitos Retrabalho; Desenvolvimento incremental, fechado; Diminuição da produtividade e protelando mudanças para Renegociação de prazos e moral da força de trabalho. fases posteriores. orçamento com cliente.Insuficiência no Moderada/Alta Sério Não aceitação pelo usuário Simulação; Programar algoritmosdesempenho em final; Instrumentação; paralelos na solução;tempo real Inviabiliza realização das Otimização de código; Revisão técnica; funções de negócio. Testes de stress. Simplificação de requisitos de desempenho; Análise de custo-benefício; Expansão do tempo e esforço dos testes.Insuficiência nos Baixa/Alta Sério Atraso na entrega do produto; Análise de compatibilidade; Realização de contrato decomponentes Aumento dos custos do projeto; Iniciar cedo o entendimento e seguro;fornecidos Desempenho não aceitável. certificação de componentes Escolhe de novo fornecedorexternamente desenvolvidos por terceiros; externo; Inspeções de conteúdo e Renegociação de prazos e funcionalidades; orçamento com cliente; Benchmarking. Revisão da solução de integração no projeto. MBA-ENGSOFT Qualidade de Software 17 © 2005 Halan Ridolphi
  • 3.2 Processo de Garantia da Qualidade Define as atividades para garantir a conformidade dos processos e produtos desoftware, no ciclo de vida do projeto, com seus requisitos especificados e sua aderência aosplanos estabelecidos. Esse processo evidencia a relação entre a qualidade do produto e aqualidade do processo de software utilizado em sua construção. O processo de garantia daqualidade deve estar coordenado com tarefas de verificação, validação, revisão e resolução deproblemas. Na realização deste processo estão envolvidos gerente, analistas, projetistas, testadorese 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 tarefasté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 efalhas associadas no produto de software. O objetivo da verificação é assegurar que oMBA-ENGSOFT Qualidade de Software 18© 2005 Halan Ridolphi
  • software, ou uma determinada função do mesmo, esteja sendo implementada corretamente. Oobjetivo da validação é assegurar que o software que está sendo desenvolvido é o softwarecorreto de acordo com os requisitos do cliente. A condução efetiva das atividades de verificação e validação requer a elaboração de ummodelo de erros que capte os erros típicos, os riscos associados, a freqüência de ocorrência edemais aspectos relevantes, de maneira que a experiência e o conhecimento dedesenvolvimento de software da equipe de projeto sejam utilizados em planejamentos futurospara novos projetos. O número de locais no produto que podem conter erros é praticamenteinfinito 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 domodelo de erros é orientar a procura por erros nos locais que apresentam, segundoinformações estatísticas, maiores probabilidades de apresentarem defeitos. Um ‘bom’ modelode erros é capaz de retratar os defeitos e seus atributos contidos em sistemas reais. O modelode 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 armazenaresse 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 naspró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 evisa determinar propriedades do produto válidas para qualquer execução do produto final. Aanálise estática pode e deve ser aplicada em qualquer artefato de software gerado notranscorrer do processo de desenvolvimento. Os métodos empregados na realização de análiseestática incluem as revisões de requisitos (PBR – Perspective-Based Reading), revisões deprojeto (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 aexecução do produto. As tarefas de simulação e teste constituem uma análise dinâmica doproduto. O teste de software é uma tarefa usada para fornecer evidências da confiabilidade dosoftware em complemento às revisões de software. As informações obtidas durante as revisõessão extremamente úteis para o teste por permitirem a identificação dos módulos críticos epropensos a erros. Não será permitida a liberação de novo release do produto sem antes haver umaconduçã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 detécnicas de teste (funcional, estrutural, baseada em erros, baseada em máquinas de estadofinito) a serem utilizadas para estabelecer planos de testes, casos de teste, critérios de teste ea própria realização dos procedimentos de teste, de modo a verificar se os requisitosespecificados 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.MBA-ENGSOFT Qualidade de Software 19© 2005 Halan Ridolphi
  • 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 naanálise dinâmica do produto, ou seja, na execução do produto de software com o objetivo deverificar a presença de defeitos e aumentar a confiança na correção do software. A atividadede teste envolve a execução das etapas de planejamento, projeto de casos de teste, execuçãoe avaliação de resultados. No planejamento da atividade de teste são estimados recursos e sãodefinidos estratégias, métodos e técnicas de teste, caracterizando-se um critério de aceitaçãodo software em desenvolvimento. Em geral, atividade de teste não pode mostrar a correção deum software, pois o conjunto dos dados de entrada normalmente é infinito ou muito extenso, aponto 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 visandominimizar a complexidade, tanto na abordagem desenvolvimento procedimental quanto naorientada a objetos. Basicamente, há três fases de teste: de unidade, de integração e desistema.3.2.5.1 Técnicas de Teste As técnicas de teste são classificadas de acordo com a origem das informaçõesutilizadas 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 aumentaras possibilidades de revelar a presença de defeitos ou, quando isso não ocorre, estabelecer umnível elevado de confiança na correção do produto. Um caso de teste é um par ordenadocomposto por um dado de entrada, isto é, um elemento do domínio de entrada, e pela saídaesperada. 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.MBA-ENGSOFT Qualidade de Software 20© 2005 Halan Ridolphi
  • 3.2.6 Revisões de Software As revisões (inspeções) no produto de software compreendem o ideal de assegurar queo artefato produzido, seja ele um documento, especificação de requisitos, projeto técnico ououtro 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 garantirque a equipe de projeto esteja utilizando documentos pelo menos com a qualidade mínimaespecificada. As revisões de software são aplicadas a código-fonte, projeto técnico, requisitosdurante o processo de desenvolvimento, de maneira a encontrar defeitos. Os defeitosencontrados pelas revisões de software referem-se à faltas. Uma falta em algum artefatoestático – pro exemplo, diagrama de projeto – é importante por levar a implementações nasquais as falhas ocorrem. Defeitos encontrados por teste representam sempre falhas dosoftware 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 classesmais abrangentes de defeitos para situações específicas. A tabela abaixo apresenta a descriçãodesse 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 classesde 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 projetoOmissão As informações 1. Algum requisito A representação de necessárias sobre o importante um conceito dos sistema foram relacionado a requisitos gerais do omitidas do artefato funcionalidade, ao domínio ou do de software. desempenho, as documento de restrições de requisitos não está projeto, ao presente em nenhum atributo ou a diagrama de projeto. interface externa não foi incluído; 2. Não está definida a resposta do software para todas as possíveis situações de entrada de dados; 3. Faltam seções na especificação de requisitos; 4. Faltam referências de figuras, tabelas e diagramas; 5. Falta definição de termos e unidades de medidas (ANSI, 1984).Fato incorreto Algumas informações Um requisito Um diagrama de no artefato de descreve um fato que projeto contém umaMBA-ENGSOFT Qualidade de Software 21© 2005 Halan Ridolphi
  • software contradizem não é verdadeiro, representação errada as informações considerando as de um conceito presentes na condições solicitadas descrito nos especificação de para o sistema de requisitos gerais do requisitos ou o software. domínio ou no conhecimento geral documento de do domínio. requisitos.Inconsistência As informações em Dois ou mais Uma representação uma parte do artefato requisitos são de um conceito em de software estão conflitantes. um diagrama de inconsistentes com projeto está em outras no artefato de desacordo com a software. representação do mesmo conceito no mesmo ou em outro diagrama de projeto.Ambigüidade As informações no Um requisito tem Uma representação artefato de software várias interpretações de um conceito no são ambíguas, isto é, devido a diferentes projeto não está clara é possível ao termos utilizados e poderia causar má desenvolvedor para uma mesma interpretação ou interpretar as característica ou entendimento errado informações de vários significados de do seu significado por diferentes maneiras, um termo para um parte do usuário do podendo não levar a contexto particular. documento. uma implementação correta.Informação estranha As informações são As informações no O projeto inclui fornecidas, mas não requisito são informações que são necessárias ou fornecidas, mas não embora talvez mesmo usadas. são necessárias ou verdadeiras, não se mesmo usadas. aplicam a esse domínio e não deveriam ser incluídas ao projeto.3.2.6.2 Processo de Revisão A atividade de revisão de software compreende a execução das etapas deplanejamento, detecção, coleção e correção dos defeitos. O diagrama a seguir descreve oencadeamento de atividades do processo de revisão de software:MBA-ENGSOFT Qualidade de Software 22© 2005 Halan Ridolphi
  • 3.2.6.3 Detecção de Defeitos Uma abordagem para identificar defeitos em artefatos é fornecida pelas técnicas paraleitura de software. Uma técnica para leitura é uma série de etapas (heurísticas) preparadapara a análise individual de um artefato que permite alcançar a compreensão necessária parauma determinada tarefa (Basili, 1996). Técnicas para leitura aumentam a eficiência dosrevisores individuais por fornecerem diretrizes utilizadas durante a fase de detecção de umprocesso de revisão para examinar (ou ler) um dado artefato e identificar defeitos. Em vez deos revisores aplicarem apenas seus próprios conhecimentos e técnicas, as técnicas para leiturade software agregam o conhecimento das melhores práticas para detecção de defeitos em umprocedimento que pode ser seguido e repetido. Dentre as técnicas de leitura de software a serem observadas na detecção de defeitosmencionamos: 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 portodo o ciclo de vida do software, destinadas a identificar e definir os itens de software em umsistema e estabelecer suas linhas básicas (baseline); controlar as modificações e liberações dositens; registrar e apresentar a situação dos itens e dos pedidos de modificação; garantir aMBA-ENGSOFT Qualidade de Software 23© 2005 Halan Ridolphi
  • conclusão, a consistência e a correção dos itens; controlar o armazenamento, a manipulação ea distribuição dos itens de software. Item de configuração de software é o nome dado ao item de informação produzidodurante o processo de desenvolvimento de software para o qual é importante que sejarealizado o controle das alterações. Um conjunto de itens de configuração compõe umaconfiguraçã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 eprogramadores 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. É quesejam selecionados itens relevantes, porque uma superdocumentação onera muito a gerênciade configuração. Os itens mais usados pela equipe, os mais genéricos, os mais importantespara segurança, os projetados para reutilização e os que podem ser modificados por váriosdesenvolvedores 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ção3.3.2.1 Controle de Mudanças As alterações em artefatos de software (código e documentação) devem ser registradasem documento de Controle de Mudanças, o qual deve contemplar descrições detalhadas dasmudanças incluídas em novas revisões desses artefatos. As mudanças devem comentar anecessidade, a solução, a questão ou incidente associado, a data de liberação da nova revisãodo artefato. Também deve ser utilizado a ferramenta Microsoft SharePoint para registro dequestõ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 mantidaspelas ferramentas Microsoft SourceSafe e Microsoft SharePoint. A liberação de nova versão demódulos de programa deve ser registra em rótulos na base de código fonte do MicrosoftSourceSafe. O procedimento de geração de build oficial deve ser seguido e ao final de suaexecução deve ser publicado na lista de build mantidas Microsoft SharePoint. As novas versõesde documentação serão mantidas pelo histórico de versões do Microsoft SharePoint. Asalterações em documentos devem ser seguidas pela atualização da seção de histórico derevisões constantes nos próprios documentos, cujo objetivo é manter registros das mudançasassociadas à nova revisão da documentação. A organização do código fonte na base do Microsoft SourceSafe deve observar oprocedimento 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 normapadrão de organização do site de projeto, incluindo as bibliotecas de acesso a documentaçãoMBA-ENGSOFT Qualidade de Software 24© 2005 Halan Ridolphi
  • (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 oprocedimento oficial de geração de nova compilação e ao final de sua execução deve serpublicado na lista de build mantidas Microsoft SharePoint. A área de deploy localizado emservidor de desenvolvimento deve ser organizada para facilitar a transferência dos módulos deprograma para ambiente de produção. Notadamente, a área de deploy deve ser organizadaconsiderando 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 serdisponibilizado na área de deploy.3.4 Processo de Desenvolvimento Define as atividades essenciais para engenharia do produto de software. Inclui aexecuçã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 dasatividades do processo de software desde identificação da necessidade passando por definiçãoda solução, certificação, instalação, treinamento, uso e manutenção do produto de softwareconstruído. O ciclo de vida do software será composto por abordagem de desenvolvimento por fasese 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 entreguesem releases intermediárias do sistema de software final. O objetivo é liberar o mais cedopossível versões operacionais do produto capazes de agregar valor ao negócio e ajustar asnecessidades dos clientes por rapidez nas soluções diante de mudanças ambientais e requisitosde negócio. O diagrama a seguir esclarece a abordagem baseada no desenvolvimento incremental eiterativo de versões do produto de software:MBA-ENGSOFT Qualidade de Software 25© 2005 Halan Ridolphi
  • 3.4.3 Engenharia do Produto de Software O encadeamento de atividades praticadas na engenharia do produto para cada releaseintermediário em construção é detalhado no diagrama a seguir:MBA-ENGSOFT Qualidade de Software 26© 2005 Halan Ridolphi
  • 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çãode requisitos, documentação de requisitos (funcionais e não-funcionais) e especificação derequisitos. 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 deRequisitos apoiar as estimativas de tamanho de projeto por meio do auxilio a Gerência doProjeto em análises de pontos por função aplicadas ao levantamento de necessidades que foidetalhado 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]:MBA-ENGSOFT Qualidade de Software 27© 2005 Halan Ridolphi
  • 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 derequisitos: 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 umaespecificação de requisitos [Pfleeger, 2000]:MBA-ENGSOFT Qualidade de Software 28© 2005 Halan Ridolphi
  • 3.4.5 Prototipação A atividade de prototipação visa apoiar as atividades de especificação de requisitos eprojeto do sistema. O objetivo é compreender as necessidades através de modelos deinteratividade com o produto de software proposto. Também é objetivo demonstramosaparê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 doproduto 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árioelaborado com Microsoft Visio:MBA-ENGSOFT Qualidade de Software 29© 2005 Halan Ridolphi
  • 3.4.6 Projeto do Sistema A atividade de projeto do sistema visa desenvolver uma solução técnica paradesenvolvimento do produto de software centrada na definição da Arquitetura de Software(topologia, inter-relacionamentos, subsistemas, hierarquia, protocolos). O projeto do sistemadetalha 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 osseguintes aspectos técnicos:MBA-ENGSOFT Qualidade de Software 30© 2005 Halan Ridolphi
  • 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 dehardware, das necessidades de software, das interfaces de comunicação, da entrada e saída deinformação do sistema, da arquitetura de rede, e de tudo o que traduz os requisitos em umasolução para o problema do cliente. Neste sentido, o projeto técnico deve contemplar osseguintes 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écnicapara componentes individuais do sistema em construção. Neste sentido, as interfaces, classese componentes são detalhados em baixo nível e requisitos não-funcionais (segurança edesempenho) são considerados. Estruturas de dados e algoritmos são especificados para cadacomponente da solução. Demais decisões de projeto como definição de bases de dados, daslinguagens de programação, dos padrões de projeto, dos padrões de integração entrecomponentes 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).MBA-ENGSOFT Qualidade de Software 31© 2005 Halan Ridolphi
  • 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 edefinir a base de dados usando técnicas de implementação que produzam um código eficiente elivre de erros. Como resultado de uma implementação bem-sucedida, as unidades de softwaredevem 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 esubsistemas 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;MBA-ENGSOFT Qualidade de Software 32© 2005 Halan Ridolphi
  • 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, procurandoidentificar 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ódulosquando esses são integrados para construir a estrutura do software que foi estabelecida nafase de projeto. O teste de sistema objetiva identificar erros de funções e características de desempenhoque não estejam de acordo com a especificação. Ressalta-se que as atividades de teste envolvem as etapas de planejamento, projeto decasos 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 deteste 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 serconsiderados: 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.MBA-ENGSOFT Qualidade de Software 33© 2005 Halan Ridolphi
  • A tabela abaixo descreve a relação entre as fases de teste e os paradigmas dedesenvolvimento de software procedimental e orientado a objetos: Paradigma de desenvolvimentoFases de teste Procedural Orientado a ObjetosUnidade Sub-rotina ou função ClasseIntegração Módulos Classe Subsistemas Subclasse Pacote de classes ComponentesSistema Toda a aplicação Toda a aplicação3.4.10 Homologação A homologação envolve a certificação do produto de software no ambiente-alvo docliente. Esta atividade compreende as tarefas de planejamento de instalação, customização edisponibilização de ferramentas automatizadas de apoio à certificação. Os defeitos detectadosdurante a homologação devem ser registrados em uma lista de questões do projeto,automatizada pela ferramenta Microsoft SharePoint, juntamente com as evidências doincidente, para que possam ser examinadas e trabalhadas pela equipe de desenvolvimento etenham acompanhamento da evolução do progresso da correção por parte do cliente. Um novorelease do produto gerado em resposta a correção dos defeitos seguirão os procedimentospadrões de geração de release e disponibilização para implantação em ambiente dehomologação do cliente. Todas as alterações funcionais no produto em decorrência daimplementação da correção de defeitos devem ser registrados em documento de Controle deMudanças e, a documentação associada ao produto deve ser adequadamente revisada pararefletir fielmente as características nativas do produto. Toda documentação técnica, planos deteste, planos de implantação e manuais de usuário deve estar disponível a consulta prévia pelocliente.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 mantidasMicrosoft SharePoint. A área de deploy localizado em servidor de desenvolvimento deve serorganizada 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 deimplementaçã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 deimplantação em produção deve ser elaborado com objetivo de especificar os detalhesespecíficos (precedência, periodicidade, expurgo, customização) dos módulos do sistema desoftware sendo instalado em ambiente de produção previsto em contrato. Toda documentaçãotécnica, manuais de treinamento e manuais de usuário devem ser empacotados edisponibilizados ao cliente. Acompanhamento pós-implantação deve ser oferecido ao clientedurante 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;MBA-ENGSOFT Qualidade de Software 34© 2005 Halan Ridolphi
  • • 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çãocontinue sendo útil e atendendo as necessidades do usuário. A manutenção pode ser solicitadapor 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écnicoe codificação visto que, a implementação da modificação requer a reaplicação das atividades deengenharia de software para o desenvolvimento do produto. Seguindo esta mesma linha deraciocínio, os métodos e as ferramentas envolvidos incluem os mesmos já realizados nasdemais atividades técnicas de construção do produto.MBA-ENGSOFT Qualidade de Software 35© 2005 Halan Ridolphi
  • 4 Bibliografia Consultada Fontes de artigos e livros consultados sobre padronização de Processo de Software eassuntos 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.MBA-ENGSOFT Qualidade de Software 36© 2005 Halan Ridolphi