Manual de Qualidade. BPI - Banca e Mundos Virtuais 16/04/2009 AUTORES. Filipe Ferreira. Gustavo Martins. Tiago Cavaleiro. Versão 0.

I

Manual de Qualidade

BPI - Banca e Mundos Virtuais

16/04/2009

AUTORES Filipe Ferreira Gustavo Martins Tiago Cavaleiro Versão 0.6

I

Resumo

O presente documento tem como finalidade definir padrões de qualidade da empresa, apresentando metodologias, normas de documentação, métricas e outras normas com o objectivo de definir esses mesmos padrões.

O principal objectivo da definição de padrões de qualidade é orientar todos os elementos da empresa, envolvidos em projectos, sobre os procedimentos a seguir de forma a que todo trabalho desenvolvido se enquadre na sua política de qualidade e, consequentemente, potencie o sucesso dos projectos da empresa e a satisfação das necessidades dos clientes.

Este manual revela também uma importância crucial na demonstração aos clientes dos padrões de qualidade que pode esperar dos projectos da Geeone.

III

Histórico de Revisão

Nesta secção encontra-se uma tabela com as diferentes versões da construção do documento:

Autor(es) Data Descrição

Versão do Documento Filipe Ferreira, Gustavo Martins e Tiago Cavaleiro 28/03/2009 Inicio do Documento 0.1 01/04/2009 Inserção de contudos 0.2 08/04/2009 Finalização do documento 0.3

14/04/2009 Alterações menores de revisão 0.4

14/04/2009 Alterações de ortografia e sintaxe 0.5

16/04/2009 Alterações finais de revisão para entrega 0.6

V

Conteúdos

1

INTRODUÇÃO ... 11

1.1 POLÍTICA E OBJECTIVOS ... 11 1.2 PARTICIPANTES... 11 1.3 ESTRUTURA ... 12

2

GESTÃO ... 13

2.1 EMPRESA ... 13 2.2 ESTRUTURA ORGANIZACIONAL ... 13

3

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ... 17

3.1 METODOLOGIA ... 17

3.2 TESTES A REALIZAR ... 18

3.3 GESTÃO DE RISCOS ... 19

3.3.1POLÍTICAS DE GESTÃO DE RISCOS ... 19

3.3.2IDENTIFICAÇÃO DOS RISCOS ... 19

3.3.3AVALIAÇÃO DOS RISCOS ... 20

3.3.4RESPONSABILIDADES ... 21

VI

4

DOCUMENTAÇÃO ... 25

4.1 OBJECTIVOS... 25

4.2 DOCUMENTO DA VISÃO E JUSTIFICAÇÃO DE PRODUTO ... 25

4.3 RELATÓRIO DE ESPECIFICAÇÃO DE REQUISITOS ... 26

4.4 RELATÓRIO PRELIMINAR DE DEFINIÇÃO DA ARQUITECTURA ... 26

4.5 MANUAL DE QUALIDADE ... 26

4.6 PLANO DE GESTÃO DE RISCOS ... 27

4.7 MANUAL DE IMAGEM ... 27

4.8 MANUAL DO UTILIZADOR ... 27

4.9 RELATÓRIO DE DESENVOLVIMENTO ... 28

4.10 RELATÓRIO INTERMÉDIO DE GESTÃO DO PROJECTO ... 28

4.11 RELATÓRIO FINAL DE GESTÃO DO PROJECTO... 28

4.12 REVISÃO DE DOCUMENTAÇÃO ... 28

5

NORMAS, MÉTRICA E CONVENÇÕES ... 30

5.1 OBJECTIVOS... 30

5.2 NORMAS DE CLASSIFICAÇÃO DE REQUISITOS DE QUALIDADE ... 30

5.2.1CICLO DE VIDA E QUALIDADE INERENTE ... 30

5.2.2REQUISITOS DE QUALIDADE ... 31

5.2.3ANÁLISE DA QUALIDADE DO PRODUTO ... 32

5.2.3.1 qualidade interna e externa ... 32

5.2.3.2 Qualidade em uso ... 34

5.3 NORMAS DE DOCUMENTAÇÃO ... 35

5.4 NORMAS DE CODIFICAÇÃO ... 35

5.5 MÉTRICAS ... 36

5.6 CHECKLISTS DE REVISÃO DE CÓDIGO ... 38

6

FERRAMENTAS ... 40

6.1 FERRAMENTAS UTILIZADAS ... 40

6.2 LINGUAGENS UTILIZADAS ... 41

VII

7

GLOSSÁRIO ... 43

8

REFERÊNCIAS ... 45

IX

Lista de Figuras

FIGURA 1-DIAGRAMA COM OS PAPÉIS DOS ELEMENTOS DA EMPRESA ... 14

FIGURA 2-ESTÁGIOS DO CICLO DE VIDA DO SOFTWARE ... 31

FIGURA 3-MODELO DE QUALIDADE ... 31

FIGURA 4-MODELO DE QUALIDADE PARA A QUALIDADE INTERNA E EXTERNA ... 33

FIGURA 5-ATRIBUTOS DE QUALIDADE EM USO ... 34

XI

Lista de Tabelas

TABELA 1-HISTÓRICO DE REVISÃO ... I

TABELA 2-PARTICIPANTES ... 12

TABELA 3-PAPÉIS E RESPECTIVAS DESCRIÇÕES ... 15

TABELA 4-TESTES A REALIZAR E RESPECTIVAS DESCRIÇÕES ... 18

TABELA 5-TABELA DE GRAVIDADE DE DEFEITOS ... 38

1

1 INTRODUÇÃO

1.1 POLÍTICA E OBJECTIVOS

O objectivo da Geeone é alcançar um crescimento positivo e lucrativo, promovendo sempre a satisfação das necessidades dos clientes e superação das suas expectativas.

A política de qualidade da Geeone baseia-se nos regulamentos definidos pelas Normas ISO 9126-1:2001 e ISO/IEC 9126-1. Estas serão apresentadas e explicadas a toda a equipa pelos Gestores de Qualidade, responsáveis pela gestão e dinamização do Sistema de Qualidade da empresa e tendo como objectivo fomentar a comunicação interna e externa e a satisfação do cliente.

O conhecimento das normas por parte de toda a equipa implica que todos os elementos sejam individualmente responsabilizados pela qualidade do trabalho desenvolvido, proporcionando, assim, a melhoria do Sistema de Gestão de Qualidade.

A empresa realizará um investimento contínuo no seu Sistema de Gestão de Qualidade visando manter a empresa competitiva e lucrativa.

O presente manual tem como finalidade orientar todos os colaboradores da Geeone na aplicação da Política de Qualidade da empresa em todos os projectos presentes e futuros.

1.2 PARTICIPANTES

2

Tabela 2 - Participantes

1.3 ESTRUTURA

O presente documento encontra-se dividido em diferentes secções. Na primeira secção (Política e Objectivos) é apresentada a Política de Qualidade da Geeone e os seus objectivos, assim como os resultados que a equipa de Gestão de Qualidade pretende alcançar com a aplicação das normas e métricas do Manual de Qualidade. Os elementos da equipa de Gestão e as tarefas desempenhadas pelos mesmos são também referidos.

A segunda secção (Gestão) apresenta a empresa, a estrutura organizacional e as tarefas desempenhadas por cada um dos departamentos.

A terceira secção (Processo de desenvolvimento de Software) expõe a metodologia de desenvolvimento adoptada pela equipa explicando os motivos da sua escolha, os testes de aceitação a realizar, a política de gestão de riscos e as deliverables a entregar.

A quarta secção (Documentação) descreve todos os documentos que a empresa deve elaborar, entre os quais se encontra o presente documento.

A quinta secção (Normas, Métricas e Convenções) apresenta as normas de documentação, de código e de testes assim como as métricas que devem ser utilizadas como referência.

A sexta secção (Ferramentas) refere as ferramentas de desenvolvimento de Software e as linguagens de programação utilizadas pela equipa.

Por último, apresenta-se o Glossário e as Referências deste manual.

Nome Tarefa Desempenhada

Filipe Ferreira Planificação e elaboração do documento

Gustavo Martins Planificação e elaboração do documento

3

2 GESTÃO

2.1 EMPRESA

A empresa Geeone surgiu no dia 4 de Março de 2009 no âmbito da Unidade Curricular de Laboratório de Gestão de Projectos (LGPR) do Curso de Mestrado Integrado em Engenharia Informática e Computação (MIEIC) da Faculdade de Engenharia da Universidade do Porto (FEUP). A Geeone insere-se no ramo da Engenharia de Software produzindo aplicações Web para empresas apostando, incondicionalmente, na inovação, qualidade e satisfação das necessidades e expectativas do cliente.

A Geeone é constituída por colaboradores especializados na área da Engenharia Informática e Computação e dotados de competências nas diferentes áreas funcionais da empresa.

2.2 ESTRUTURA ORGANIZACIONAL

A estrutura organizacional da Geeone tem como principal característica a flexibilidade, tendo como parâmetros a cooperação, colaboração, empenho, comunicação e entendimento.

A empresa pretende que em todos os seus projectos os processos de gestão sejam conduzidos da melhor forma e que a qualidade dos produtos desenvolvidos seja garantida. Assim, a organização interna da empresa segue a metodologia Team Software Process (TSP), visto ser a indicada para projectos de elevado grau de complexidade e que possuam um elevado número de elementos na equipa.

Neste método atribui-se a cada um dos elementos da equipa um cargo relativo a uma área funcional, sendo a distribuição dos 11 elementos da equipa pelas áreas funcionais baseada nos conhecimentos e preferências dos respectivos elementos. Esta forma de atribuição de cargos possibilita uma maior satisfação e empenho no trabalho a desenvolver por cada elemento,

4

revelando-se também importante para a equipa, visto que esta pode obter benefícios através dos conhecimentos específicos de cada elemento nas diferentes áreas funcionais.

A figura seguinte representa os diferentes papéis dos elementos da empresa e os respectivos Directores e Subdirectores. Os Directores são distinguidos através de um "*".

Figura 1 - Diagrama com os papéis dos elementos da empresa

5

Papel Descrição

Costumer Interface Manager

Responsável pelo levantamento, análise e validação dos requisitos do produto.

Design Manager Responsável pelo desenho da arquitectura do produto de

software.

Implementation Manager

Responsável pela estruturação e implementação do software a ser produzido.

Marketing, Comunication and

Image Manager

Responsável pela promoção dos recursos intangíveis da empresa no exterior.

Planning Manager

Responsável pela realização de estimativas das datas previstas de desenvolvimento e finalização de todos os processos durante o ciclo de vida do produto de software.

Process Manager Responsável pela organização e monitorização de todos os

processos de desenvolvimento de software.

Quality Manager Responsável por garantir que os padrões de qualidades

definidos são seguidos durante todos o ciclo de vida do produto.

Suport Manager Responsável por disponibilizar todo o tipo de suporte físico

necessário ao desenvolvimento do produto de software.

Test Manager Responsável pela elaboração dos testes ao software e da

respectiva documentação.

Usability and Interaction Design

Manager

Responsável pela estruturação e desenvolvimento dos desenhos das interfaces do produto de software.

7

3

PROCESSO

DE DESENVOLVIMENTO DE

SOFTWARE

3.1 METODOLOGIA

A Geeone pretende que o produto seja desenvolvido seguindo um rigoroso controlo de qualidade durante todas as fases do projecto, decidindo, assim, adoptar um modelo de desenvolvimento iterativo inicializado pelo levantamento e análise de requisitos bem como pela concepção e desenho da arquitectura do produto. De modo a que todas as alterações realizadas durante a fase de desenvolvimento se enquadrem correctamente nos padrões de qualidade da empresa, o produto é desenvolvido em pequenas iterações até à sua versão final.

A primeira fase do projecto é designada por fase de concepção e tem como principais requisitos a elaboração de um Relatório de Especificação de Requisitos (RER) e um Relatório Preliminar de Definição de Arquitectura, tendo como objectivo estruturar e delinear a fase de implementação do produto.

Na fase de implementação, em cada iteração deve ser feita a definição da(s) funcionalidade(s) a adicionar ao produto e, seguidamente, implementar essa(s) funcionalidade(s), os testes unitários de forma a validar a nova funcionalidade, a integração da funcionalidade no produto e realizar testes de integração e validação do produto.

O uso desta metodologia assegura um elevado controlo sobre as novas funcionalidades do produto e garante o correcto funcionamento das mesmas.

14

3.2 TESTES A REALIZAR

Os testes a efectuar ao produto de software devem ser realizados ao longo de todo o processo de desenvolvimento do produto.

Testes Descrição

Testes de Aceitação

Estes testes simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado pelo Cliente. Conduzido para determinar se um sistema satisfaz ou não aos seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema.

Testes de Componentes

Testes de componentes são idênticos aos testes unitários mas com a particularidade de testarem componentes bastante maiores do sistema.

Testes de Integração

Estes testes têm como objectivo detectar os erros que possam surgir depois da integração de vários módulos e unidades de software. Geralmente os tipos de falhas encontradas são de transmissão de dados. Os módulos em integração já devem ter sido previamente testados.

Testes Unitários

São testes que têm o objectivo de testar partes individuais de hardware ou pequenas unidades de software e conjuntos das mesmas unidades (IEEE 90).

É um processo de desenvolvimento onde os programadores desenvolvem os testes enquanto desenvolvem o software, estes testes são simples e pequenos. Têm a missão de testar pequenas funcionalidades de módulos do código escrito.

Testes de Usabilidade

Estes testes têm como objectivo a identificação de problemas derivados da utilização comum do software em teste. Normalmente detectam problemas de interfaces com o utilizador, erros que podem fazer com que o utilizador não consiga atingir o seu objectivo no programa.

13

3.3 GESTÃO DE RISCOS

A gestão de riscos é uma das componentes essenciais para o bom funcionamento dos projectos da Geeone, encontrando-se presente em todos os processos de gestão da empresa. Este processo é conduzido essencialmente através de uma lista de gestão de riscos presente no Project WorkBook da empresa.

O seu objectivo é a criação de valor, através da gestão e controlo das incertezas e ameaças que podem afectar os resultados esperados pela Geeone e pelos seus clientes, de forma a assegurar a competitividade da empresa e continuidade do negócio.

A gestão de riscos necessita que todos os elementos da equipa e restantes stakeholders do projecto, cliente e supervisor, assumam compromisso e responsabilidade actuando em conjunto nas diferentes áreas funcionais da empresa.

A capacidade de comunicação dos elementos da equipa e stakeholders é a arma mais poderosa para a identificação e resolução de problemas e melhoria das práticas de comunicação.

Os principais meios de comunicação disponíveis para o fluxo de informação são as reuniões semanais, e-mail e o grupo de conversação.

3.3.1 Políticas de Gestão de Riscos

O sucesso da gestão de riscos na Geeone depende dos seguintes procedimentos:

 Reacção imediata: A identificação de um novo risco, a ameaça para o projecto de um risco ou a concretização do mesmo deve ser imediatamente reportado à equipa, devendo ser tomadas medidas para o atenuar.

 Monitorização frequente: Este processo caracteriza-se pela análise dos riscos que surgem em cada iteração do desenvolvimento do produto e dos riscos que possam afectar a próxima iteração.

 Participação conjunta: A gestão de riscos é uma tarefa conjunta da equipa, devendo por este motivo ser uma preocupação de todos os stakeholders do projecto.

3.3.2 Identificação dos riscos

O processo de identificação de riscos deste projecto é realizado recorrendo a diferentes métodos e é inicializado pela elaboração de uma lista de riscos inicial. Esta lista foi construída recorrendo a entrevistas informais com os vários elementos do projecto e ao brainstorming entre os respectivos elementos.

14

Durante todo o ciclo de vida do projecto é necessário proceder à actualização da lista de riscos através da identificação de novos riscos, sendo para isso utilizados os métodos acima referidos bem como os dados que vão acumulando.

A produtividade da identificação de riscos é progressivamente acrescida com o tempo, dado que a quantidade de informação e a experiência dos elementos do projecto é cada vez maior.

A lista de riscos contém os riscos do projecto definidos pelos seguintes parâmetros:

 Tipo: Este parâmetro define se o risco identificado se mantém como uma ameaça ou se este se concretizou e passou a ser um problema para o projecto.

 Data de identificação/criação: Data de identificação do risco.

 Descrição: Descrição do risco e das condições necessárias para o seu acontecimento.  Responsável: Refere-se ao elemento da equipa que é responsável por evitar o

acontecimento do risco ou pela sua mitigação caso este se concretize.

 Estratégia de Mitigação: Descreve as acções necessárias para evitar a concretização do risco.

 Plano de Contingência: Refere-se às acções a realizar quando o risco se concretiza, tendo como objectivo a resolução dos problemas que possam afectar o projecto.  Data de Resolução: Data de resolução do problema.

Os restantes parâmetros presentes na lista de riscos surgem através da avaliação dos riscos, sendo por este motivo apresentados na seguinte secção.

3.3.3 AVALIAÇÃO DOS RISCOS

O processo de avaliação de riscos é caracterizado pela atribuição de prioridade de acção referente a determinado risco e deve ser executado durante todo o ciclo de vida do projecto. Este processo facilita o processo de detecção de riscos, bem como o processo de determinação dos riscos que são de tratamento mais prioritário, de modo a que o desenvolvimento do projecto não seja afectado.

Os parâmetros de referência para avaliação de riscos são a probabilidade de acontecimento do risco e o impacto estimado para o projecto caso este se concretize, possuindo ambos três níveis qualitativos: Alto, Médio e Baixo.

Probabilidade de acontecimento do risco:

 Alta: corresponde aos riscos com uma probabilidade elevada.  Média: corresponde aos riscos com probabilidade mediana.  Baixa: corresponde aos riscos com uma probabilidade diminuta.

13

Impacto do risco:

 Alto: Representa um impacto muito grave para sucesso do projecto, visto que pode significar o incumprimento dos prazos estabelecidos e a entrega de um produto com defeitos, défices de qualidade e que não se encontra em conformidade com o pretendido pelo cliente e com as suas necessidades.

 Médio: Representa um impacto com alguma gravidade para o sucesso do projecto, podendo significar atrasos no cumprimento de milestones estabelecidas, assim como a não concretização de alguns requisitos propostos e o desenvolvimento de uma funcionalidade importante para o cliente sem os padrões de qualidade estabelecidos pela empresa.

 Baixo: Representa um impacto com pouca relevância para o sucesso do projecto, visto que apenas pode denotar uma pequena perda de performance do produto, pequenos atrasos relativamente aos prazos estipulados ou a não concretização de um requisito não crítico para o sistema.

3.3.4 RESPONSABILIDADES

A responsabilidade é incutida, desde o arranque do projecto, em todos os seus stakeholders de modo a que compreendam o seu papel na empresa, nos projectos e respectivas tarefas.

Torna-se vital para o sucesso dos projectos da empresa que todos os colaboradores compreendam claramente o seu papel e responsabilidades.

Gestor do Projecto

O Gestor do Projecto assume um papel importantíssimo em todo o âmbito do projecto assumindo responsabilidade em diversas áreas:

 Planeamento, monitorização e controlo do projecto;

 Realização de um plano de gestão de riscos, sendo este utilizado durante todas as fases de controlo do projecto no que diz respeito à avaliação e resolução de potenciais riscos;

 Gestão de recursos para a implementação do plano de gestão de riscos;  Cumprimento de prazos e orçamentos definidos para o projecto;

 Manutenção de históricos de progresso do projecto e de desempenho individual;  Realização de reuniões semanais com a equipa de forma a avaliar o estado das

tarefas da semana corrente e atribuir tarefas para a semana seguinte;

 Comunicação do estado do projecto e riscos mais relevantes a todos os

14

Face às responsabilidades que o Gestor do Projecto deve assumir, pretende-se que este seja dotado de uma grande capacidade de liderança e tomada de decisões, conhecimento da sua equipa e capacidade para resolver problemas inter-pessoais.

Gestor de Qualidade

O Gestor de Qualidade tem a responsabilidade de garantir a qualidade de todas as componentes produzidas em todas as fases projecto. Assim, este deverá ter um conjunto de preocupações principais:

 Cumprimento de normas e procedimentos internos da empresa;

 Controlo constante de todas as componentes do projecto e do desempenho da equipa de forma a detectar possíveis riscos e adoptar medidas para a sua resolução;  Manutenção de repositório de riscos do projecto;

 Avaliação do processo de gestão de riscos;  Promoção constante da qualidade na empresa;

 Colaboração com o gestor do projecto na elaboração do Manual de Qualidade da empresa com o intuito de adaptar correctamente as directivas do manual às necessidades do projecto;

 Colaboração com os responsáveis pela verificação e validação de requisitos.

As responsabilidades a que o Gestor de Qualidade se encontra sujeito, requerem que este assuma activamente um papel crítico e tenha conhecimento das normas e métricas de qualidade internacional.

Equipa do Projecto

A equipa do projecto deverá ser responsável pelo seguimento da cultura de qualidade incutida pelos Gestores de Qualidade no que diz respeito ao cumprimento dos padrões de qualidade, normas e métricas definidas para o projecto.

O processo de gestão de riscos deverá também ser atentamente conduzido pela equipa do projecto, assumindo as seguintes responsabilidades:

 Prevenção, identificação e resolução de riscos;

 Avaliação contínua de riscos durante todo o ciclo de vida do projecto;  Comunicação do novo risco no seio da equipa após a sua identificação;

 Comunicação dentro da equipa da evolução do estado dos riscos presentes no repositório destinado à gestão de riscos.

13

Cliente

A elaboração de um bom projecto é em grande parte influenciada pelo papel desempenhado pela entidade cliente. A satisfação das suas necessidades e dos requisitos definidos por si depende da iteração entre o cliente e a equipa do projecto. Assim, o cliente deverá ter um papel activo no processo de avaliação e comunicação da qualidade do trabalho desenvolvido à equipa.

Os riscos presentes durante o ciclo de vida do projecto poderão afectar a qualidade do trabalho desenvolvido e a satisfação das necessidades dos clientes. De forma a combater esta possibilidade, o cliente deverá trabalhar conjuntamente com a equipa do projecto no processo de gestão de riscos, assumindo as seguintes responsabilidades:

 Identificação de novos riscos;

 Comunicação constante com a equipa de forma a ter uma noção actualizada do estado do projecto e, assim, conseguir prevenir o aparecimento de novos riscos;  Definir por prioridades os riscos a resolver.

3.4 TAREFAS

O ciclo de vida dos Projectos da Geeone é protagonizado em duas fases, a primeira fase denominada por "Fase de Concepção” e a segunda fase denominada por "Fase de Desenvolvimento”.

Fase de Concepção

A fase de concepção do projecto é caracterizada por diversas etapas e processos, no âmbito da concepção do produto, que a equipa necessita de realizar:

 Reunião de arranque do projecto;

 Planeamentos semanais e reuniões semanais;

 Definição e planeamento de actividades segundo objectivos e estimativas temporais;  Controlo constante das actividades;

 Comunicação do estado do projecto e potenciais riscos a todos os colaboradores do projecto;

 Monitorização do risco;

 Controlar e garantir a qualidade.

Na etapa final desta fase é pretendido que a equipa apresente:  Plano Inicial do Projecto;

14

 Documento da Visão e Justificação do Produto;

 Relatório de Especificação de Requisitos (aprovado pelo cliente);  Plano de Testes de Aceitação (aprovado pelo cliente);

 Protótipo completo a nível da interface com o utilizador;  Relatório Preliminar de Definição da Arquitectura;  Manual de Qualidade do Projecto;

 Relatório Intermédio de Gestão de Projecto;  Plano de Projecto para a 2ª fase;

 Resultados da auto-avaliação intermédia da equipa;  Resultados do teste de sobrevivência do projecto.

Fase de Desenvolvimento

A fase de desenvolvimento do projecto é caracterizada por diversas etapas e processos, no âmbito do desenvolvimento do produto, que a equipa necessita de realizar:

 Planeamentos semanais;

 Definição de actividades e respectivas estimativas;  Monitorização e controlo de progressos e dos custos;  Controlar e garantir a qualidade

 Gestão do risco;

Na etapa final desta fase é pretendido que a equipa apresente:  Pacotes de Instalação e Manutenção do Produto;  Manual do Utilizador;

 Versão Final do Relatório de Especificação de Requisitos;  Versão Final do Relatório de Definição da Arquitectura;  Versão Final do Manual de Qualidade do Projecto;  Relatório de Desenvolvimento;

35

4 DOCUMENTAÇÃO

4.1 OBJECTIVOS

Ao longo do tempo, a documentação tem-se manifestado o calcanhar de Aquiles de muitas organizações no ramo das Tecnologias de Informação, sendo um factor crítico para o sucesso.

A qualidade deste processo tem grande influência na qualidade do produto final, revelando-se muito importante tanto no processo de derevelando-senvolvimento do produto de software como, posteriormente, no processo de manutenção, melhoria e reutilização. A consulta e análise da documentação possibilitam a reutilização de componentes de um produto em outras aplicações sem a necessidade de conhecer pormenores de desenvolvimento.

A documentação deve ser elaborada durante todo o ciclo de vida do produto começando na sua fase de concepção, onde se realiza o levantamento e registo dos requisitos definidos com o cliente, e terminando antes da entrega do produto final ao cliente. A documentação que se entrega ao cliente tem que coincidir com a versão final das funcionalidades que constituem o produto de software.

4.2 DOCUMENTO DA VISÃO E JUSTIFICAÇÃO DE

PRODUTO

Este documento demonstra uma grande relevância durante as primeiras fases do projecto, visto que tem como objectivo captar, compreender e definir as necessidades e funcionalidades do produto de software, proporcionando um conhecimento e uma visão global do projecto a todos os stakeholders.

O documento revela as características dos stakeholders e dos utilizadores finais do projecto, permitindo a captação das necessidades de ambos e, assim, definir correctamente as características essências do produto de forma a atingir as expectativas do cliente.

30

As restrições que o produto de software deve cumprir são também definidas neste documento.

4.3 RELATÓRIO

DE

ESPECIFICAÇÃO

DE

REQUISITOS

O Relatório de Especificação de Requisitos caracteriza os requisitos do sistema e dos seus utilizadores, sendo útil para as diversas entidades envolvidas no âmbito do projecto. No que diz respeito aos elementos da equipa de desenvolvimento do produto, o documento permite que possam compreender o sistema e a interligação dos seus módulos, bem como a necessidade de desenvolver diferentes tipos de testes para a validação do cumprimento de requisitos.

Os requisitos funcionais consistentemente apresentados no documento descrevem as funcionalidades que se pretendem que o sistema disponibilize. Os aspectos não funcionais do sistema são apresentados através de requisitos não funcionais.

O documento é de extrema importância para o cliente no acompanhamento do cumprimento dos requisitos referidos, bem como para sugestão de alterações a realizar.

4.4 RELATÓRIO PRELIMINAR DE DEFINIÇÃO DA

ARQUITECTURA

A arquitectura de um sistema de software descreve a sua estrutura global em termos dos seus componentes, das propriedades externas desses componentes e das suas inter-relações. Para sistemas de média e grande dimensão a escolha correcta da arquitectura revela capital importância no sucesso do seu desenvolvimento.

O relatório Preliminar de Definição da Arquitectura documenta de uma forma simples e concisa a arquitectura dos produtos desenvolvidos pela Geeone para os seus Clientes.

O objectivo do documento é apresentar a arquitectura do produto, os seus objectivos e restrições, as suas vistas, as principais decisões de desenho, a implementação e tecnologias utilizadas no seu desenvolvimento.

Este documento revela uma grande utilidade para todos os colaboradores do projecto na consulta dos detalhes de implementação dos projectos.

4.5 MANUAL DE QUALIDADE

O Manual de Qualidade define os padrões de qualidade desejáveis no âmbito da empresa e a importância e peso dos vários atributos de qualidade (usabilidade e acessibilidade, segurança, disponibilidade e fiabilidade, desempenho, etc.). Todos estes indicadores serão utilizados como

31

modelo de crítica e avaliação das funcionalidades e componentes do projecto no que diz respeito à satisfação das necessidades do produto.

O documento apresenta as normas, métricas, técnicas, procedimentos e ferramentas a utilizar de forma a detectar e prevenir defeitos e atingir a qualidade pretendida.

A política de Gestão de Riscos e os respectivos processos de detecção, prevenção e resolução de riscos são inseridos também neste documento visto terem uma grande influência na qualidade do produto.

Este documento reporta também a preocupação com o cumprimento e validação dos requisitos do produto, definindo assim a política de testes para o produto de software. A política de testes apresenta a estratégia e técnicas a utilizar.

4.6 PLANO DE GESTÃO DE RISCOS

O plano de Gestão de Riscos é uma lista de gestão de riscos presente no Project WorkBook da empresa. Este plano identifica os riscos inerentes ao projecto durante o seu ciclo de vida, analisando a possibilidade destes acontecerem e as suas consequências. O planeamento de medidas para a prevenção, detecção e resolução de riscos é também uma preocupação deste documento, tendo como objectivo minimizar as consequências dos riscos nas diversas vertentes do projecto (prazos, custos, desempenho e alteração de objectivos).

Este documento acompanha o projecto durante todo o seu ciclo de vida, sendo constantemente revisto e actualizado devido à inserção de novos riscos e à exclusão de riscos que já não são passivos de afectar o projecto, no entanto estes continuam presentes na lista de riscos.

4.7 MANUAL DE IMAGEM

O Manual de Imagem engloba todos os aspectos relacionados com a imagem da empresa, tais como os layouts da documentação e o logótipo da empresa e as respectivas versões e aplicações, normas cromáticas e fontes tipográficas.

4.8 MANUAL DO UTILIZADOR

O Manual do Utilizador descreve todas as funcionalidades do programa de forma simples e clara e o modo de proceder para a sua utilização. Certos utilizadores pretendem aprofundar os seus conhecimentos em alguma funcionalidade ou pormenor de implementação, assim este manual deve referir outros documentos que lhe permitam alcançar tal conhecimento.

30

O documento reporta também os possíveis erros e respectivas mensagens de erro que poderão surgir na interacção entre o utilizador e o sistema e os procedimentos a seguir para a resolução de problemas.

4.9 RELATÓRIO DE DESENVOLVIMENTO

O Relatório de Desenvolvimento visa descrever o processo de desenvolvimento do produto e o seu progresso, reportando todas as alterações aos requisitos iniciais e à arquitectura do sistema que se tenham realizado.

O estado actual do sistema é abordado no relatório através da exposição dos módulos do sistema, das suas funcionalidades e respectivos pormenores de aplicação e de resultados e conclusões aos testes realizados.

4.10 RELATÓRIO INTERMÉDIO DE GESTÃO DO

PROJECTO

Os objectivos do Relatório Intermédio de Gestão do Projecto são apresentar os resultados da primeira fase do projecto (Fase de Concepção), planear a segunda fase através de um plano de desenvolvimento que contém os resultados a atingir, apresentar o tipo de metodologias que irão ser utilizadas pela equipa de desenvolvimento, descrever as tarefas e cargos desempenhados por cada elemento da equipa e mecanismos para o respectivo controlo e monitorização.

4.11 RELATÓRIO FINAL DE GESTÃO DO

PROJECTO

O Relatório Final de Gestão do Projecto sintetiza toda a informação referente à Gestão do Projecto, servindo de complemento e actualização de alguns aspectos apresentados no Relatório Intermédio de Gestão do Projecto.

O balanço final do projecto é realizado através de um sumário de todas as decisões de gestão e do grau de satisfação dos requisitos definidos no início do projecto. Este balanço permite à equipa retirar conclusões que poderão ser úteis para projectos futuros.

4.12 REVISÃO DE DOCUMENTAÇÃO

A Revisão da Documentação na Geeone é um processo constituído por diferentes fases. Numa primeira fase o documento é revisto pelo seu autor de forma a realizar um primeiro

31

despiste de erros, sendo posteriormente enviado para os responsáveis pela Gestão de Qualidade.

Numa segunda fase, os Gestores de Qualidade fazem a revisão do documento com a finalidade de atribuir uma avaliação final.

Na presença de erros, os Gestores de Qualidade podem realizar a sua correcção ou enviar novamente o documento ao autor reportando os aspectos a corrigir. Após a nova revisão pelo autor, o documento será enviado novamente para os Gestores. Este ciclo termina quando o documento sujeito a revisão atingir os padrões de qualidade definidos pelo departamento de Gestão de Qualidade.

Por outro lado, caso o documento revisto não contenha erros, os Gestores de Qualidade atribuem imediatamente a sua avaliação.

30

5 NORMAS, MÉTRICA E CONVENÇÕES

5.1 OBJECTIVOS

Este capítulo apresenta a definição das métricas bem como algumas definições importantes que deverão ser utilizadas ao longo do projecto para a qualidade dos processos e produto desenvolvido, assim como o desempenho da equipa de projecto.

5.2 NORMAS

DE

CLASSIFICAÇÃO

DE

REQUISITOS DE QUALIDADE

5.2.1 CICLO DE VIDA E QUALIDADE INERENTE

As visões de qualidade interna, qualidade externa e qualidade de uso mudam durante o ciclo de vida do software. Como exemplo pode-se falar dos requisitos de qualidade no início do ciclo de vida, estes são normalmente vistos do ponto de vista do usuário (externo), e diferem da qualidade do produto intermédio, tal como a qualidade do projecto, que é geralmente vista do ponto de vista do programador (interno).

Qualidade em uso que é a qualidade do software do ponto de vista do utilizador quando usado num ambiente específico e num determinado contexto de utilização, medindo essencialmente até que ponto os utilizadores conseguem atingir os seus objectivos ao invés da medida das propriedades do software.

Idealmente a qualidade interna determina a qualidade externa e a qualidade externa determina a qualidade em uso.

A figura seguinte ilustra diferentes visões de qualidade do produto e métricas associadas em diferentes estágios do ciclo de vida do software.

31

Figura 2 - Estágios do ciclo de vida do software

5.2.2 REQUISITOS DE QUALIDADE

A figura seguinte ilustra o modelo de qualidade.

30

 Requisitos de qualidade externa:

Especificam o nível requisitado de qualidade do ponto de vista externo. Eles incluem requisitos derivados das necessidades de qualidade do usuário, incluindo requisitos de qualidade em uso. Requisitos de qualidade externa são utilizados com o intuito de validação em várias etapas do desenvolvimento.

 Requisitos de qualidade interna:

Especificam o nível requisitado de qualidade do ponto de vista do produto. Requisitos de qualidade interna são usados para especificar propriedades de produtos intermédios. Requisitos de qualidade interna podem ser utilizados com o intuito de validação em várias etapas do desenvolvimento. Estes podem ser usados para definição de estratégias de desenvolvimento e critérios para validação e verificação durante o desenvolvimento.

 Qualidade interna:

É a totalidade de características do produto de software do ponto de vista interno. A qualidade interna é medida e avaliada em termos dos requisitos de qualidade interna.

 Qualidade externa:

É a totalidade de características do produto de software do ponto de vista externo. É a qualidade quando o software é executado, que é tipicamente medida e avaliada durante o teste de um ambiente simulado com dados simulados usando métricas.

 Qualidade em uso:

É a visão do usuário da qualidade do produto de software quando é utilizado em ambiente e contexto de uso estabelecidos. Esta mede o quanto os usuários podem alcançar seus objectivos num ambiente particular, em vez de medir as propriedades do software propriamente dito.

5.2.3 ANÁLISE DA QUALIDADE DO PRODUTO

5.2.3.1 QUALIDADE INTERNA E EXTERNA

Estes são os atributos da qualidade externa e interna de acordo com a norma ISO 9126-1:2001.

31

Figura 4 - Modelo de qualidade para a qualidade interna e externa

 Usabilidade:

Capacidade do software de ser percebido, aprendido, usado e atractivo para o utilizador, quando usado nas condições especificadas. Em aplicações Web a acessibilidade está correlacionada com a usabilidade. Este é um requisito bastante importante para os clientes visto ser uma das principais características com que o cliente lida directamente, esta pode ditar o fracasso ou o sucesso de um produto.

 Eficiência:

Capacidade do produto de software fornecer performance ajustada e relativa à quantidade de recursos utilizados segundo as condições definidas. Esta deve ser ajustada as exigências dos clientes.

 Fiabilidade:

Capacidade do produto de software de manter um nível especificado de performance quando usado em condições especificadas.

 Manutenção:

Capacidade do produto de software ser modificável, sendo que as modificações podem incluir correcções, melhoramentos ou adaptações do software devido a alterações no meio ambiente ou nos requisitos e especificações funcionais.

 Funcionalidade:

Capacidade do produto de software de providenciar as funções definidas e implícitas nos requisitos quando o software é usado nas condições especificadas. Esta nunca deve ser posta de

30

parte visto que o principal objectivo da empresa é entregar o que o cliente pediu especificamente.

 Portabilidade:

Capacidade do produto de software de ser transferível de um ambiente para outro.

A empresa deve investir fortemente nestes 6 pontos, visto que o seu cumprimento potenciará a fidelização de clientes e o crescimento do seu nome no mercado.

5.2.3.2 QUALIDADE EM USO

De acordo com a norma ISO 9126-1:2001 estes são os atributos a ter em atenção no que diz respeito à qualidade em uso.

Figura 5 - Atributos de qualidade em uso

 Eficácia:

Capacidade do produto de software de permitir aos utilizadores atingir por completo objectivos específicos de utilização com precisão.

 Produtividade:

Capacidade do produto de software de permitir aos utilizadores a dispensa de níveis apropriados de recursos em relação à eficácia atingida num determinado contexto de utilização.

31

 Segurança:

Capacidade do produto de software de atingir níveis aceitáveis de risco de perigo a pessoas, negócios, software, propriedades ou ao ambiente num determinado contexto de utilização.

 Satisfação:

Capacidade do produto de software de satisfazer os utilizadores num determinado contexto de utilização.

Estes pontos serão de vital importância para os clientes da empresa, pois são através destes que o cliente avalia o trabalho desenvolvido. Por este motivo estes nunca deverão ser descuidados por parte das equipas de trabalho da empresa.

5.3 NORMAS DE DOCUMENTAÇÃO

A documentação tornada pública deve sempre obedecer à seguinte estrutura:  Capa (titulo do documento, nome do projecto, responsável, data)  Resumo

 Conteúdo (índice, índice de figuras, índice de tabelas)  Corpo do documento

 Glossário  Referencias

A Documentação deve estar em concordância com o que está definido nos layouts da documentação presentes no Manual de Imagem.

5.4 NORMAS DE CODIFICAÇÃO

Neste capítulo são especificadas boas condutas de programação a usar e um pequeno código exemplo. A empresa deve seguir escrupulosamente as regras apresentadas seguidamente.

Boas práticas de Programação:

 Evitar utilizar ficheiros grandes. Se um ficheiro tiver mais de 300-400 linhas de código, deve-se dividir o código por mais que um ficheiro.

 Evitar escrever métodos muito longos. Um método deve ter normalmente 1-25 linhas de código. Se um método passar das 25 linhas de código, deve-se considerar separar o código em mais que um método, com auxílio de métodos auxiliares.

30

 O nome de um método deve indicar a função desse método.

 Um método deve fazer uma só tarefa. Não combinar mais do que uma tarefa num mesmo método, mesmo que a tarefa seja bastante pequena.

 Não abusar de números. Usar constantes sempre que possível.

 Em caso de problemas, imprimir uma mensagem simples e de fácil compreensão para o utilizador, que o ajude a solucionar o problema.

 Se um valor numérico for inicializado com um determinado número, explicar o porquê dessa inicialização.

 Utilizar +i ou i+ em vez de i+=1 ou i = i + 1.

 Utilizar sempre chavetas em instruções condicionais ou de ciclos, mesmo naqueles que possuam uma são expressão.

 Declarar uma variável por linha.

Código exemplo de formatação:

Figura 6 - Código exemplo de formatação

5.5 MÉTRICAS

Métricas de um projecto de software são medidas quantitativas que permitem à empresa ter ideia da produtividade do processo de desenvolvimento de software. Para isso é necessário definir métricas de qualidade na área de qualidade do produto, dos processos e dos testes.

 Métricas para a Qualidade do Produto:

Existem duas formas de medir a qualidade de um produto de software, sendo estas a qualidade interna do produto e a satisfação do cliente pelo produto desenvolvido. A primeira

31

pode quantificar-se pela densidade de defeitos que o produto apresenta. No que diz respeito à satisfação do cliente, esta pode ser mensurada através do contacto directo com o cliente. Relativamente à densidade de defeitos, esta pode ser medida com a seguinte expressão, que relaciona o número de defeitos encontrados com o número de linhas de código:

DD = ND / LOC

DD: Densidade de defeitos, ND: Número de defeitos, LOC: Linhas de código (lines of code) Relativamente à métrica de satisfação do cliente devem ser realizados inquéritos de satisfação ao cliente e aos utilizadores da aplicação.

 Métricas para a Qualidade de Processos:

Nesta área é necessário definir métricas que tenham em consideração os requisitos do produto de software. A métrica mais importante na área de processo de desenvolvimento é o levantamento de Requisitos. Esta métrica consiste em considerar os requisitos inicialmente definidos para a aplicação e os requisitos realmente contemplados na arquitectura da aplicação utilizando a seguinte expressão:

RR = RA/RI * 100

RR: Levantamento de Requisitos, RA: total de requisitos contemplados na arquitectura, RI: total de requisitos considerados inicialmente

É de notar que não obstante do resultado da expressão ser em percentagem, este pode ser superior a 100%. Isto acontece quando o número de requisitos contemplados na arquitectura é superior aos considerados inicialmente.

 Métricas para a Qualidade dos testes:

No que diz respeito aos testes é importante considerar as seguintes métricas: Número de defeitos encontrados:

O objectivo dos testes é encontrar defeitos, daí ser necessário quantificar o número de defeitos encontrados.

Gravidade dos defeitos:

Esta métrica serve para avaliar a gravidade dos defeitos encontrados de acordo com a seguinte tabela:

30

Nível Gravidade Descrição

1 Defeito crítico Impede a utilização correcta da aplicação e Provoca anomalias

graves

2 Defeito grave Não funciona como requerido mas não impede a utilização mas

tem impacto nos processos

3 Defeito leve Não afecta a utilização normal, mas a falha tem de ser resolvida

4 Melhoria Novos pedidos face ao âmbito do projecto e Melhorias

cosméticas, de interface Tabela 5 - Tabela de gravidade de defeitos

Taxa de correcção dos defeitos encontrados:

Após a detecção de defeitos é necessários corrigi-los, daí ser preciso medir a quantidade de defeitos corrigidos. Para isso deve ser utilizada a seguinte métrica:

TCD = (DC / DE) * 100

TCD: Taxa de correcção de defeitos, DCT: Defeitos corrigidos, DE: Defeitos encontrados

5.6 CHECKLISTS DE REVISÃO DE CÓDIGO

Id Checklist

1 Cada funcionalidade é desempenhada por apenas uma classe ou método?

2 O código está de acordo com a arquitectura da aplicação?

3 É verificada a validade dos dados recebidos pelo programa?

4 As variáveis são devidamente inicializadas? São usados tipos adequados ao seu

propósito?

5 Não existem variáveis inúteis?

6 São atribuídos às variáveis valores fora dos seus limites?

7 É possível haver uma divisão por zero?

8 São usados os operadores de comparação correctos para o propósito a que se

destinam?

31

10 Existe algum bloco de código não executado?

11 Existe repetição de código?

12 Existe algum método que altere valores que não deviam ser alterados?

13 Estão a ser bem tratados todos os ficheiros?

14 Estão a ser tratados devidamente os erros de input/output?

15 Estão a ser apresentadas mensagens de erro e de aviso?

16 O código é comentado sempre que necessário? E quando está estes estão adequados?

17 Os nomes dados a variáveis e métodos são esclarecedores?

18 Existem contradições entre a documentação e o código implementado?

19 O código está devidamente formatado?

30

6 FERRAMENTAS

6.1 FERRAMENTAS UTILIZADAS

Redmine:

O Redmine é uma ferramenta de desenvolvimento de documentos através da sua wiki, mas também uma plataforma de gestão de tempos da equipa e de actividades através das tarefas. Esta é a ferramenta que possibilita uma sempre actualização dos tempos e de documentos.

No Redmine é possível encontrar:  Relatórios produzidos pelo grupo  Área de trabalho do grupo  Actas das reuniões

 Informações sobre todas as partes envolvidas com o grupo  Relatórios Semanais

 Tempos e tarefas dos elementos do grupo  Tarefas activas e já terminadas

GoogleGroups:

Esta ferramenta está a ser usada meramente como forma de comunicação entre o grupo, sempre que é necessário enviar um e-mail a todos os elementos esta ferramenta facilita o envio.

msnGroups:

O msnGroups é uma aplicação que trabalha com o MSN Messenger que faz com que todos os elementos do grupo apareçam como um novo contacto, que sempre que contactado a mensagem é difundida para todos os elementos. Esta ferramenta está a ser usada para conversas e discussões entre os elementos do grupo.

balsamiq mockups:

Esta é uma ferramenta de desenho de interfaces de forma fácil e ao mesmo tempo muito expressiva. Esta está a ser usada para desenho de interfaces por parte dos elementos do grupo.

31

Enterprise Architect:

Esta ferramenta já muito conhecida serve para desenho UML, neste projecto foi usada para desenho do modelo de classes e de casos de utilização.

SVN:

Esta é uma ferramenta de controlo de versões, serve para que todos os membros possuam sempre as mais recentes versões do software a ser desenvolvido.

6.2 LINGUAGENS UTILIZADAS

A empresa aposta nas novas tecnologias de desenvolvimento Web, para isso irá apostar na plataforma .NET Framework 3.5 principalmente em ASP.NET MVC para a programação do produto. De salientar que esta ferramenta saiu em 2009.

Para a Base de dados a empresa vai usar T-SQL e ANSI SQL que são bastante próximos com SQL.

6.3 FERRAMENTAS DE DESENVOLVIMENTO DE

CÓDIGO

As ferramentas utilizadas para o desenvolvimento do produto de software serão o Visual Studio 2008 e SQLServer.

35

7 GLOSSÁRIO

FEUP - Faculdade de Engenharia da Universidade do Porto.

IEEE - Institute of Electrical and Electronics Engineers ou IEEE é uma organização profissional sem fins lucrativos, fundada nos Estados Unidos. É a maior (em número de sócios) organização profissional do mundo.

ISO - International Organization for Standardization é uma organização internacional que incorpora os grupos de padronização/normalização de 148 países. A ISO aprova normas internacionais em todos os campos técnicos, excepto na electricidade e electrónica.

LGPR - Laboratório de Gestão de Projectos.

Métrica - Medida de alguma propriedade do software ou da sua especificação, utilizado para calcular orçamentos, desempenho dos programadores e erros.

MIEIC - Mestrado Integrado em Engenharia Informática e Computação.

Norma - Documento onde são definidos procedimentos ou métodos padrão, elaborado por um grupo ou instituto certificado, com a qualidade de criar normas a serem seguidas por outras empresas na geração dos seus documentos e desenvolvimento da sua actividade.

Stakeholders - Designa todas as pessoas, instituições ou empresas que têm interesse ou

intervêm em acções de uma organização, como por exemplo, clientes, colaboradores, investidores, fornecedores, etc.

TSP - Team Software Process. UML - Unified Modeling Language.

Wiki - Designação para sítio Web que permite aos utilizadores adicionar e actualizar conteúdo do sítio, com recurso a uma linguagem de marcação muito simples e usando apenas um navegador Web. Uma das características definitivas da tecnologia wiki é a facilidade com que as páginas são criadas e alteradas: geralmente não existe qualquer revisão antes de as

34

modificações serem aceites e a maioria das wikis são abertas a todo o público ou pelo menos a todas as pessoas que têm acesso ao servidor wiki.

35

8 REFERÊNCIAS

[Métricas de Qualidade] ISO/IEC 9126-4: 2000. Software engineering– Software product quality- Part 4: Quality in use metrics.

[Modelo de Qualidade], ISO/IEC 9126-1: 2000. Software engineering– Software product quality- Part 1: Quality model.