Gestão de Projectos de Software · Web view“Usabilidade” – um conjunto de ... Todos os...

Gestão de Projectos de SoftwareLicenciatura em Engenharia Informática e Computação

Faculdade de Engenharia da Universidade do Porto

Projecto SAPIENSProjecto SAPIENSSistema de Avaliação Assistida por ComputadorSistema de Avaliação Assistida por Computador

MMANUALANUAL DEDE Q QUALIDADEUALIDADE 2000/10/232000/10/23

Projecto SAPIENS Manual de Qualidade

GGRUPORUPO DEDE P PROJECTOROJECTO

Chefe (Gestor de Projecto)

Rui Pereira

Secretária

Sandra Oliveira

Controlo da Qualidade/Auditor

Miguel Teixeira

Analistas/Arquitectos

Artur Matos

Nuno Costa

Programadores

João Pires

Luís Almeida

GPS 2000/2001 2


ÍÍNDICENDICE

1. INTRODUÇÃO 6

2. AS NORMAS ISO 9000 7

2.1. ISO 9001 7

2.2. ISO 9000-3 8

2.3. ISO 9004-2 9

2.4. Aplicação as normas 10

3. GESTÃO DO PROJECTO 11

3.1. Modelo do Processo de Software 11

3.2. Organização do Grupo de Projecto 113.2.1. Descrição das funções 113.2.2. Definição de funções 12

4. DOCUMENTAÇÃO 13

4.1. Documentos a produzir 134.1.1. Actas de Reunião 134.1.2. Relatório de Progresso 134.1.3. Relatório de Avaliação do Produto Recebido 134.1.4. Relatório de Planeamento do Projecto 134.1.5. Manual da qualidade 144.1.6. Relatório de Especificação de Requisitos 144.1.7. Relatório de Projecto 144.1.8. Relatório de Especificação do Trabalho para Fora 144.1.9. Relatório Intermédio de Gestão do Projecto 144.1.10. 1º Relatório de Auditoria 144.1.11. Relatório de Desenvolvimento do Trabalho Encomendado 154.1.12. Relatório de Avaliação do Trabalho para Fora 154.1.13. Relatório Final de Gestão do Projecto 154.1.14. Manual do utilizador 154.1.15. Manual de Instalação 154.1.16. Relatório de Desenvolvimento 154.1.17. 2º Relatório de Auditoria 15

4.2. Escrita de documentos 16

4.3. Revisão de documentos 16

4.4. Versões de Documentos 16

4.5. Armazenamento de Documentos 16

5. ESPECIFICAÇÃO DE REQUISITOS E DESIGN 18

6. CODIFICAÇÃO/IMPLEMENTAÇÃO 19

GPS 2000/2001 3


7. TESTES E CONTROLO DE QUALIDADE 20

8. AUDITORIAS 21

8.1. Auditoria Interna 21

8.2. Auditoria Externa 21

9. Bibliografia 22

GPS 2000/2001 4


Resumo

Este manual apresenta as linhas que regem a garantia de qualidade oferecida pela equipa do

projecto SAPIENS para com o cliente e os seus utilizadores em geral. Pretende-se detalhar a

organização interna da equipa do projecto, os métodos de trabalho seguidos pelos seus membros, a

documentação produzida e as regras para a sua elaboração.

Para uma descrição do objectivo do projecto, aconselha-se a consulta do Relatório de Especificação

de Requisitos.

GPS 2000/2001 5


1.1. IntroduçãoIntrodução

A importância de um Manual de Qualidade verifica-se não só quando o produto é apresentado ao

cliente, mas também durante todo o seu ciclo de vida. É um suporte de informação de grande utilidade

para as mais variadas entidades - novos funcionários, clientes, auditores de instituições de certificação

independentes e os próprios membros da equipa de projecto - e que apresenta essencialmente um

objectivo base – diz-nos extensivamente o quê, quando, por quem e como foi produzido. É revisto e

reavaliado frequentemente. Como tal, poderão eventualmente existir várias versões.

A definição da ISO para qualidade é “a totalidade das funcionalidades e características de um

produto ou serviço que assentam na sua habilidade de cumprir necessidades explícitas ou implícitas”. Nos

dias de hoje, em termos informáticos e da industria em geral, a palavra “Qualidade” está directamente

ligada a “Certificação”. Uma ferramenta ou aplicação para ser creditada no mercado terá que cumprir

certas normas, nomeadamente as ISO 9000. O programa de qualidade de um projecto é vital para a sua

certificação e toda a imagem deste programa é reflectida no Manual de Qualidade.

Neste caso concreto, visto ser um projecto de desenvolvimento de um produto de software, as

seguintes normas serão levadas em consideração:

ISO 9001 – o standard internacional para sistemas de qualidade que contenham componentes de

design e desenvolvimento

ISO 9000-3 – fornece as linhas mestre para a aplicação da norma ISO 9001 para o

desenvolvimento, fornecimento e manutenção de produtos de software

ISO 9004-2 – oferece guias para serviços em geral, sendo facilmente aplicáveis a serviços de

apoio e manutenção do software

Existem vários standards, que de uma forma ou outra seriam aplicáveis a um projecto desta natureza,

mas a opção de escolha por estes aqui apresentados justifica-se plenamente por serem os mais usados e

largamente aceites a nível mundial. A escrita em si deste manual tem a orientação da ISO 10013.

O programa de qualidade de um projecto de software é essencial para o sucesso e sobrevivência do

produto e a prova disso é o destaque que cada vez mais as grandes casas de software demonstram não só

internamente, mas principalmente no marketing do produto. Um produto sem qualidade é um produto

sem futuro.

GPS 2000/2001 6


2.2. As Normas ISO 9000As Normas ISO 9000

Como já foi referido, para a elaboração de um plano de qualidade para este projecto, serão seguidas

um conjunto de normas que estão incluídas nas ISO 9000. Antes de detalhar as normas a usar, faz-se

apenas uma breve referência à Definição das Características de Qualidade, presentes na norma ISO 9126:

Funcionalidade – um conjunto de atributos que assentam na existência de um conjunto de

funções a das suas propriedades especificadas. As funções são aquelas que satisfazem as

necessidades explícitas ou implícitas.

Robustez – um conjunto de atributos que assentam na capacidade do software de manter o seu

nível de performance debaixo de condições especificadas e durante um determinado período de

tempo.

“Usabilidade” – um conjunto de atributos que assentam no esforço necessário para o uso e no

reconhecimento individual desse uso por um conjunto especificado ou implícito de utilizadores.

Eficiência – um conjunto de atributos que assentam na relação entre o nível de performance do

software e a quantidade de recursos usados dentro de condições determinadas.

Manutenção – um conjunto de atributos que assentam no esforço necessário para fazer alterações

especificadas.

Portabilidade – um conjunto de atributos que assentam na habilidade do software de ser

transferido de um ambiente para outro.

A definição e compreensão destas características é absolutamente essencial, pois ao apresentarem

uma meta clara de como o produto deve ser, permitem fazer uma avaliação objectiva do seu sucesso. Para

atingir estes objectivos, seguem-se então as linhas de orientação especificadas nas normas ISO 9000.

2.1.2.1. ISO 9001ISO 9001

Como já foi referido, a norma ISO 9001 apresenta uma lista de requisitos a serem cumpridos por um

sistema de qualidade quando é necessário assegurar a conformidade com um padrão durante várias etapas,

que podem incluir o design, desenvolvimento, produção, instalação e manutenção. O documento está

bastante orientado para indústrias de manufactura, mas é possível interpretar os requisitos presentes de

forma a que se tornem adequados para o desenvolvimento de software – isto é precisamente o que faz a

norma ISO 9000-3. Estes requisitos estão agrupados em vinte conjuntos:

- responsabilidade de gestão

- sistema de qualidade

- revisão de contracto

- controlo de design

- controlo de documentação

- compras

- produto fornecido pelo comprador

- identificação e rastreio do produto

- controlo do processo

- inspecção e teste

GPS 2000/2001 7


- medições de teste e equipamento de

teste

- situação corrente de inspecção e teste

- controlo de produto não em

conformidade

- acção correctiva

- manuseamento, armazenamento,

embalagem e entrega

- registos da qualidade

- auditorias internas

- treino

- serviço pós-venda

- técnicas estatísticas

Como é óbvio, algumas destas características não são muito apropriadas para a produção de software.

Por essa razão houve a necessidade de apresentar uma norma mais apropriadas para este tipo específico

de projectos.

2.2.2.2. ISO 9000-3ISO 9000-3

A norma 9000-3 apresenta um conjunto de linhas orientadoras que facilitam a aplicação da ISO 9001

por parte de organizações que desenvolvem, fornecem e mantêm software. Ela separa a matéria em

questão em três grandes áreas genéricas que requerem atenção ao estabelecer um sistema de qualidade:

1) Janela de Trabalho

2) Actividades do Ciclo de Vida

3) Actividades de Suporte

A Janela de Trabalho lida com questões de responsabilidade da gestão, o sistema de qualidade, as

auditorias internas de qualidade e as acções correctivas. Estas questões definem-se da seguinte forma:

Responsabilidade da gestão – cobre a responsabilidade, por parte de quem desenvolve o

produto, pela política de qualidade, estabelecendo responsabilidades, autoridades e linhas de

comunicação muito claras, fornecendo recursos e pessoal adequados para as actividades de

verificação. Engloba a revisão periódica da aplicabilidade do sistema de qualidade. Inclui

também a responsabilidade do cliente em cooperar com o fornecedor e fazer parte de revisões

conjuntas.

Sistema de qualidade – engloba o estabelecimento e manutenção de um sistema que está

integrado em todos os aspectos do negócio, e zela pela sua qualidade.

Auditorias internas de qualidade – servem essencialmente de garantia de que o sistema

de qualidade é eficaz.

GPS 2000/2001 8


Acções correctivas – definição de medidas concretas para lidar com defeitos e erros do

produto ou do processo.

A secção referente a “Actividades de Ciclo de Vida” refere que todos as fases deste ciclo devem ser

atendidas cuidadosamente. Especial ênfase é dado para as seguintes fases:

- revisão de contractos

- especificação de requisitos

- planeamento do desenvolvimento

- planeamento da qualidade

- design e implementação

- testes e validação

- procedimentos de aceitação

- procedimentos de manutenção

A secção de “Actividades de Suporte” faz referência para uma série de outras actividades

complementares que devem ser levadas em conta como essenciais. São referidas explicitamente:

- gestão de configurações ou versões

- controlo de documentação

- registos de qualidade

- medições

- regras, práticas e convenções

- ferramentas e técnicas

- compras

- inclusão de produtos externos de software

- treino

2.3.2.3. ISO 9004-2ISO 9004-2

Esta norma é um guia para estabelecer e implementar um sistema de qualidade numa organização

que forneça serviços a clientes, quer exista ou não um produto próprio. Logo, é aplicável a empresas que

oferecem o serviço de manutenção dos produtos que elas mesmas produzem. Ela identifica um conjunto

de princípios que devem estar incluídos no sistema de qualidade de forma a tornar isto possível:

a gestão é responsável pela política e objectivos de qualidade, por definir responsabilidades,

autoridades e linhas de comunicação, e pela revisão do próprio planeamento

a gestão deve planear o fornecimento de recursos suficientes para implementar o sistema de

qualidade e atingir os seus objectivos, incluindo para isso, pessoal treinado e recursos materiais

GPS 2000/2001 9


o sistema de qualidade deve ser montado de forma a permitir controlo adequado sobre todas os

processos operacionais que afectam a qualidade, e devem enfatizar as acções preventivas sem

sacrificar a habilidade de responder e corrigir falhas à medida que elas aparecem

passos devem ser tomados para estabelecer uma interacção efectiva entre os clientes e o pessoal

da organização, o que é essencial para uma boa percepção por parte do cliente da qualidade do

serviço

Esta norma chama ainda a atenção para a qualidade do serviço que passa essencialmente pelos

seguintes tópicos:

- Processo de Marketing

- Processo de Design

- Processo de Oferta de Serviço

- Análise e melhoria da performance do Serviço

2.4.2.4. AAPLICAÇÃOPLICAÇÃO ASAS NORMASNORMAS

Este manual de qualidade procurará aplicar este conjunto de normas definidos nos três pontos

anteriores ao projecto SAPIENS, tendo sempre em conta a aplicabilidade de cada um dos tópicos ao caso

concreto, e suprimindo-os sempre que sejam considerados irrelevantes. É preferível descartar assuntos

que não se relacionam de forma alguma com a realidade em questão do que tentar artificialmente aplicá-

los.

GPS 2000/2001 10


3.3. Gestão do ProjectoGestão do Projecto

Nesta secção especificam-se todos os aspectos referentes à gestão global do projecto.

3.1.3.1. MMODELOODELO DODO P PROCESSOROCESSO DEDE S SOFTWAREOFTWARE

Tendo em conta as características do projecto SAPIENS, o modelo do processo de software a utilizar

será o modelo em cascata ou incremental (waterfall model). Este mostra-se o mais adequado como guia

de orientação pois ajusta-se melhor ao escalonamento das várias fases do projecto previstas.

3.2.3.2. OORGANIZAÇÃORGANIZAÇÃO DODO G GRUPORUPO DEDE P PROJECTOROJECTO

Um aspecto essencial num bom sistema de qualidade é definir exactamente quais são os papéis

necessários para a execução do projecto, e atribuir responsabilidades concretas a pessoas por esses papéis.

3.2.1.3.2.1. DDESCRIÇÃOESCRIÇÃO DASDAS FUNÇÕESFUNÇÕES

Neste quadro estão definidas as várias funções necessárias para a execução do projecto.

Função Descrição

Chefe (Gestor de Projecto) Responsável por toda a planificação e coordenação do projecto. Este papel é desempenhado

por uma pessoa a tempo inteiro.

Secretário Responsável pela manutenção do sítio do projecto onde se armazena toda a documentação e

outros artefactos relativos ao projecto, pela elaboração de agendas e actas das reuniões

efectuadas pelos elementos do grupo, pela elaboração do folheto publicitário do produto

desenvolvido e pelo controlo de versões dos artefactos produzidos.

Analista Responsável pela elaboração do Relatório de Especificação de Requisitos.

Arquitecto Responsável pela elaboração do Relatório de Projecto.

Programador Responsável pela codificação/implementação, execução do trabalho para fora, elaboração do

Relatório de Desenvolvimento e realização de testes parcelares. Colabora na elaboração do

Manual do Utilizador.

Controlo de qualidade Responsável pela elaboração do manual de qualidade, que define as normas de qualidade, e

pela imposição dessas normas. Colabora com os analistas e arquitectos no planeamento dos

testes, e acompanha os programadores na execução dos testes finais.

Colabora com os programadores na elaboração do Manual do Utilizador.

Auditor Responsável por auditar o funcionamento doutros grupos.

Tabela 1 - Papéis do projecto

GPS 2000/2001 11


3.2.2.3.2.2. DDEFINIÇÃOEFINIÇÃO DEDE FUNÇÕESFUNÇÕES

As funções foram atribuídas aos vários elementos do grupo de projecto da seguinte maneira:

Nome Funções

Rui Pereira Chefe

Sandra Oliveira Secretária

Miguel Teixeira Controlo da Qualidade/Auditor

Artur Matos Arquitecto/Analista

Nuno Costa Arquitecto/Analista

João Pires Programador

Luís Almeida Programador

Tabela 2 - Funções de cada elemento do grupo de Projecto

Salienta-se no entanto que, tendo em conta as circunstâncias específicas deste projecto, enquadrado

numa óptica académica, não se espera que a separação de funções seja estanque, e que haja cooperação de

vários elementos na realização de algumas tarefas. Algumas destas situações estão previstas no

planeamento inicial, e outras que ocasionalmente aconteçam serão também lá reflectidas.

GPS 2000/2001 12


4.4. DocumentaçãoDocumentação

A documentação assume uma importância absolutamente crucial no processo de qualidade do

projecto. Nas secções seguintes descrevem-se os vários tipos de documentos a produzir e os responsáveis

pela sua elaboração. Descrevem-se igualmente algumas normas referentes à sua escrita, revisão e

armazenamento.

4.1.4.1. DDOCUMENTOSOCUMENTOS AA PRODUZIRPRODUZIR

4.1.1.4.1.1. AACTASCTAS DEDE R REUNIÃOEUNIÃO

Descrevem os actos ocorridos durante uma reunião de grupo. É da responsabilidade do secretário e é

feito sempre que se realiza uma reunião. Deverá vir indicada a data da realização da reunião e deverá

estar assinado por todos os seus intervenientes.

4.1.2.4.1.2. RRELATÓRIOELATÓRIO DEDE P PROGRESSOROGRESSO

Descreve o progresso semanal do grupo de projecto. É da responsabilidade do chefe e é feito

semanalmente. Deve referir sucintamente as tarefas realizadas, o estado das que se estão a realizar, os

replaneamentos efectuados e os documentos produzidos. Deverá conter um diagrama de Gantt actualizado

com um horizonte temporal que abranja a semana em questão.

4.1.3.4.1.3. RRELATÓRIOELATÓRIO DEDE A AVALIAÇÃOVALIAÇÃO DODO P PRODUTORODUTO R RECEBIDOECEBIDO

Este relatório faz a avaliação do produto legado. É executado pelos analistas no fim da análise do

produto recebido.

Deve cobrir os seguintes pontos de avaliação: qualidade dos requisitos, qualidade do projecto/design,

estado e qualidade da implementação, manuais e estruturação do código.

4.1.4.4.1.4. RRELATÓRIOELATÓRIO DEDE P PLANEAMENTOLANEAMENTO DODO P PROJECTOROJECTO

Escrito pelo gestor do projecto (chefe). Deve conter uma definição inicial das tarefas que irão ser

executadas, as suas datas de início e fim e a sua duração prevista. Deve também conter uma atribuição das

pessoas às tarefas e uma estimativa inicial de custos.

GPS 2000/2001 13


4.1.5.4.1.5. MMANUALANUAL DADA QUALIDADEQUALIDADE

Define o trabalho a realizar para garantir a qualidade. É executado pelo controlador de qualidade do

processo e a segundo as suas normas que todo o processo deve ser desenvolvido.

4.1.6.4.1.6. RRELATÓRIOELATÓRIO DEDE E ESPECIFICAÇÃOSPECIFICAÇÃO DEDE R REQUISITOSEQUISITOS

Os requisitos do sistema a desenvolver tem que ser especificados por parte do cliente. Tem então o

analista a responsabilidade de os estudar e registar neste relatório. Este documento deverá cobrir todos os

aspectos a desenvolver no trabalho. Ou seja funcionalidades, restrições, ambiente onde irá ser

implementado e outros serviços associados ao projecto.

Devem-se descrever as funções a implementar em termos das necessidades a colmatar, sem

especificar directamente como o fazer.

4.1.7.4.1.7. RRELATÓRIOELATÓRIO DEDE P PROJECTOROJECTO

Construir o modelo lógico do produto final é uma obrigação do arquitecto. A sua visualização é feita

neste relatório, definindo componentes do sistema e as respectivas interfaces entre eles. Em suma, deve

conter todos os aspectos que caracterizam uma análise de alto nível.

4.1.8.4.1.8. RRELATÓRIOELATÓRIO DEDE E ESPECIFICAÇÃOSPECIFICAÇÃO DODO T TRABALHORABALHO PARAPARA F FORAORA

Especificação dos Requisitos de uma componente do projecto que será executada recorrendo a

Outsourcing. Deverá ser escrita pelos analistas/arquitectos, com a colaboração dos programadores e do

chefe.

4.1.9.4.1.9. RRELATÓRIOELATÓRIO I INTERMÉDIONTERMÉDIO DEDE G GESTÃOESTÃO DODO P PROJECTOROJECTO

Escrito pelo gestor do projecto (chefe). Deve consistir de uma revisão intermédia do planeamento

executado pelo Relatório de Projecto, reportando o estado actual da execução das tarefas, e ajustar o resto

do planeamento para adequar à realidade da altura.

4.1.10.4.1.10. 1º R1º RELATÓRIOELATÓRIO DEDE A AUDITORIAUDITORIA

Escrito pelo Auditor. Deve conter a sua avaliação dos métodos de trabalho e das decisões tomadas

por outro grupo de projecto

GPS 2000/2001 14


4.1.11.4.1.11. RRELATÓRIOELATÓRIO DEDE D DESENVOLVIMENTOESENVOLVIMENTO DODO T TRABALHORABALHO E ENCOMENDADONCOMENDADO

Este relatório documenta o trabalho desenvolvido pelo grupo para fora, de forma a fornecer aos

clientes as informações que eles requerem para utilizá-lo com sucesso. Será da responsabilidade dos

programadores.

4.1.12.4.1.12. RRELATÓRIOELATÓRIO DEDE A AVALIAÇÃOVALIAÇÃO DODO T TRABALHORABALHO PARAPARA F FORAORA

Avalia o grau de conformidade do produto recebido em relação àquilo que foi especificado. É escrito

pelo controlador de qualidade em conjunto com os programadores.

4.1.13.4.1.13. RRELATÓRIOELATÓRIO F FINALINAL DEDE G GESTÃOESTÃO DODO P PROJECTOROJECTO

Descrição final e revista do planeamento feito e da sua conformidade com realidade. Deve fornecer

os indicadores do projecto: horas despendidas, custos, etc. É escrito pelo chefe.

4.1.14.4.1.14. MMANUALANUAL DODO UTILIZADORUTILIZADOR

Explica como usar todas as funcionalidades do sistema. Está sob a tutela do programador e do

responsável da qualidade e é feito no fim da construção do sistema. É essencialmente para o cliente,

portanto deve conter uma linguagem corrente e não muito técnica.

4.1.15.4.1.15. MMANUALANUAL DEDE I INSTALAÇÃONSTALAÇÃO

Deve ser uma descrição bastante simples mas completa dos procedimentos a tomar para instalar o

produto.

4.1.16.4.1.16. RRELATÓRIOELATÓRIO DEDE D DESENVOLVIMENTOESENVOLVIMENTO

O relatório final referente ao projecto. Deve ser escrito em colaboração com todos os intervenientes.

Aborda a totalidade dos tópicos de uma forma conclusiva, desde a revisão final de arquitectura, até aos

teste de qualidade executados, passando pelas questões de implementação.

4.1.17.4.1.17. 2º R2º RELATÓRIOELATÓRIO DEDE A AUDITORIAUDITORIA

GPS 2000/2001 15


Deve ser essencialmente uma repetição do 1º Relatório de Auditoria, mas num tempo posterior, de

forma a que se possam proceder a algumas comparações.

4.2.4.2. EESCRITASCRITA DEDE DOCUMENTOSDOCUMENTOS

Todos os documentos serão escritos em português. O nível de linguagem terá em conta a audiência

esperada, sendo natural esperar que, por exemplo, relatórios de programação contenham linguagem mais

técnica que outros documentos.

Para criar um aspecto mais uniforme da documentação, serão usados determinados templates, criados

propositadamente para este projecto, e que têm como principal preocupação a organização da informação

e uma apresentação clara e de fácil compreensão das ideias.

Todos os documentos deverão ser escritos em Microsoft Word, e serão sempre disponibilizados no

formato original em Postscript. Eventualmente poderão ser usados formatos complementares, se tal for

visto como útil.

4.3.4.3. RREVISÃOEVISÃO DEDE DOCUMENTOSDOCUMENTOS

Todos os documentos são revistos pelo chefe e secretária antes da sua apresentação final. Eventuais

erros detectados serão corrigidos pelos próprios em casos simples, ou em casos que o justifiquem, será

notificado o autor para que proceda à reparação.

4.4.4.4. VVERSÕESERSÕES DEDE D DOCUMENTOSOCUMENTOS

Qualquer documento pode ser revisto e actualizado em qualquer altura, gerando assim uma nova

versão. Estas novas versões serão submetidas à mesma revisão e processo de armazenagem que as

originais. A secretária será responsável pela gestão das novas versões.

4.5.4.5. AARMAZENAMENTORMAZENAMENTO DEDE D DOCUMENTOSOCUMENTOS

O armazenamento é da responsabilidade da secretária do projecto. Estes documentos serão colocados

num repositório central, o que os tornará automaticamente acessíveis pela Internet. Cabe a este elemento

certificar-se da acessibilidade a estes documentos, organizando-os de forma a tornar o mais fácil o

possível o processo de consulta de documentação. A documentação deverá estar organizada de acordo

com a natureza dos documentos. Será suficiente a existência de versões electrónicas da documentação,

dispensando-se as versões em papel, tendo em conta dois aspectos:

GPS 2000/2001 16


- uma genuína preocupação ecológica

- as revisões constantes dos documentos tornarem obsoletas as versões impressas

Esta forma de repositório central fornece uma excelente linha de comunicação entre os elementos do

grupo do projecto e os clientes, sendo complementada pelo uso de e-mail. O local física para a

armazenagem será o dos servidores do CICA, através de uma conta criada para esse efeito.

GPS 2000/2001 17


5.5. Especificação de Requisitos e DesignEspecificação de Requisitos e Design

O trabalho de especificação de requisitos design cabe essencialmente aos arquitectos. A apresentação

dos seus relatórios deve seguir as linhas gerais apresentadas para a documentação. Nesta caso específico,

também é necessário definir uma linguagem para a modelização do sistema. Pela sua aceitação e

familiaridade será usado o UML (Unified Modelling Language) para esta tarefa.

GPS 2000/2001 18


6.6. Codificação/ImplementaçãoCodificação/Implementação

As normas a usar na criação do código fonte é ainda uma questão em aberto. De momento é possível

definir que todo os ficheiros de código fonte devem conter um cabeçalho indicando o(s) autor(es), a data

de início da codificação, a versão actual e um registo sumário das alterações em cada uma das versões

anteriores. Além disso, todo o código deve ser muito bem comentado.

GPS 2000/2001 19


7.7. Testes e Controlo de QualidadeTestes e Controlo de Qualidade

Testes serão efectuados em cada módulo de software para ser dado como concluído. A definição

concreta de quais os testes a efectuar deverá ser estabelecida pelo programador e pelo controlador de

qualidade do software. Os testes procurarão comprovar a satisfação dos requisitos preestabelecidos,

segundo o que está estritamente estipulado no Relatório de Especificação de Requisitos. Sempre que

possível, ou seja, sempre que existir um protótipo funcional, procurar-se-á fazer a validação junto do

cliente.

Figura 1 - Ciclo de teste do código

Como se pode observar, existem duas situações distintas, que correspondem a uma avaliação interna

e outra externa. Existe ainda a hipótese de extrema de, devido a circunstâncias completamente

imprevistas, ter de haver uma alteração a um módulo já considerado concluído. O grau de complexidade e

esforço exigido por cada uma destas três situações é progressivamente maior, portanto deve ser evitado a

todo o custo que se cheguem a esses extremos.

GPS 2000/2001 20

Sim

Não

Sim

Sim

Sim

Não

Escrita de Código

Testes(Especificação)

Não

Escrita de Código


Não

Escrita de Código


Criação de um

protótipo

Testes(Especificaç

ãoe

Cliente)

Finalizações


8.8. AuditoriasAuditorias

Existem dois tipos de auditorias neste projecto: as internas e as externas. A sua execução responsável

é essencial como medida de controlo do sistema de qualidade que se pretende implementar.

8.1.8.1. AAUDITORIAUDITORIA I INTERNANTERNA

A auditoria interna é na realidade mais um processo de monitorização contínuo e constante. Este

processo de monitorização é feito a dois níveis distintos:

- a revisão de todos os documentos apresentados e os testes de qualidade do produto, em suma,

avaliação de todos os artefactos que vão sendo produzidos, tendo em conta as normas de

qualidade

- utilização das reuniões semanais do grupo de projecto para a verificação do ponto de situação de

cada elemento relativamente às tarefas que lhe tinham sido atribuídas

A auditoria interna é um instrumento de controlo interno e é responsabilidade do controlador de

qualidade, com a assistência do chefe.

8.2.8.2. AAUDITORIAUDITORIA E EXTERNAXTERNA

Ao contrário do ponto anterior, as auditorias externas são situações relativamente pontuais no tempo,

onde outro grupo de projecto é avaliado segundo um conjunto determinado de critérios:

- modelo de desenvolvimento adoptado

- métodos de trabalho

- normas utilizadas

- comunicação interna

- grau de cumprimento de metas

- documentação produzida

Esta tarefa é da exclusiva responsabilidade do auditor do grupo, e espera-se a total cooperação por

parte da empresa auditada.

GPS 2000/2001 21


9.9. BibliografiaBibliografia

fotocópias da disciplina de Engenharia de Software do 4º ano da Licenciatura em Engenharia Informática e Computação

"Software Quality – A Framework for Success in Software Development and Support", Joc Sanders, Eugene Curran, Addison-Wesley, 1994

“The Quality Manual”, Terence J. Hall, John Willey & Sons, 1992

“Software Engineering”, Ian Sommerville, 1995

GPS 2000/2001 22

Gestão de Projectos de Software · Web view“Usabilidade” – um conjunto de ... Todos os...

Documents

Transcript of Gestão de Projectos de Software · Web view“Usabilidade” – um conjunto de ... Todos os...