(1) Documento que regista a política de qualidade, sistemas e práticas de uma organização.
[ED - MQ]
 

(2) Documento que estabelece a política da qualidade e descreve o sistema da qualidade de uma organização.
Nota 1: Um manual da qualidade pode referir-se à totalidade das actividades de uma organização ou somente a uma parte dela. O título e o objecto do manual explicitam o campo de aplicação.
Nota 2: Um manual da qualidade contem normalmente ou faz referência, pelo menos:
a) à política da qualidade
b) às responsabilidades, autoridades e às relações entre as pessoas que dirigem, efectuam, verificam ou revêm o trabalho com incidência sobre a qualidade.
c) aos procedimentos do sistema da qualidade e às instruções.
d) às disposições para rever, actualizar e gerir o manual.
Nota 3: Para se adaptar às necessidades de uma organização, o grau de detalhe e a forma de um manual da qualidade podem variar. O manual pode ser constituído por vários volumes. Dependendo do objectivo do manual, um qualificativo pode ser utilizado, por exemplo "manual de garantia da qualidade", "manual de gestão da qualidade".
[NP EN ISO 8402]

(3) Documento que descreve o sistema de gestão adoptado por cada organismo e fixa objectivos, padrões e procedimentos.

Deve incluir os seguintes temas:

• Definição do ciclo de vida do desenvolvimento e documentos a produzir em cada fase
• Princípios enquadradores para a estrutura organizativa dos projectos, distribuição de tarefas, calendários de execução e gestão dos recursos;
• Gestão das configurações;
• Gestão dos condicionamentos, riscos e planos de contingência;
• Mecanismos de Verificação e Validação.

Exemplo de estrutura dum manual da qualidade para um projecto de software:

1. Introdução

Objectivo
Alcance
Revisão do Plano de qualidade
Documentação aplicável e de referência
Relação com outros planos
Definições
Siglas e abreviaturas

Visão de conjunto do projecto
Condicionantes
Produtos a entregar

Estrutura organizativa do projecto
Distribuição de tarefas
Calendário de execução
Recursos do projecto

Métodos, processos, normas, técnicas e ferramentas
Documentos de desenvolvimento de software
Biblioteca de desenvolvimento de software

Manutabilidade  = Facilidade de manutenção
 
 
 

(1) Processo de modificar um sistema de software ou componente após a entrega para corrigir falhas, melhorar o desempenho ou outros atributos ou adaptá-lo a um ambiente novo.
[IEEE 610.12]
 

(2) Deveres rotineiros requeridos para tornar disponíveis todos os melhoramentos feitos nos pormenores e na gestão diária dos processo de trabalho. Isto é conduzido através duma dedicação disciplinada à acumulação contínua dos melhoramentos do passado e através da normalização (escrita ou compreendida) destes melhoramentos no trabalho diário.
 

(3) As actividades de manutenção (do ponto de vista do fornecedor de sofytware) podem ser classificadas da seguinte forma:

a) Resolução de problemas (manutenção correctiva). Envolve a detecção, análise e correcção de falhas do software que causam problemas operacionais. Na resolução de problemas poderão ser usadas correcções temporárias para minimizar as consequências e as modificações permanentes poderão ser feitas mais tarde.
b) Alterações das Interfaces (manutenção adaptativa). Podem se requeridas pela adição ou mudança no sistema de hardware ou componentes controladas por software.
c) Expansão funcional ou melhoramentos de performance (manutenção perfeccionista). Podem ser requeridas pelo utilizados no estádio de manutenção.
 
 
 
 

Atributo que se refere à frequência com que ocorrem falhas do produto devidas a erros embutidos no software.
 
 
 

Processo pelo qual são atribuídos valores (números ou símbolos), numa dada escala de unidades, a atributos de entidades, de forma a caracterizá-las de acordo com padrões claramente definidos.
 
 
 

Resultado do processo de medição.
 
 
 

Princípio que reza que a melhoria num produto, serviço ou processo é contínua e que deve ser sistematicamente procurada. A melhoria contínua não é somente limitada às mudanças incrementais, mas inclui igualmente alterações radicais e inovadoras.
[ED - MQ]
 
 
 

(1) Descrição dos procedimentos duma técnica; são abordagens rigorosas, sistemáticas e disciplinadas; distingue-se das técnicas pois estas são mais mecânicas e geralmente de aplicabilidade mais restrita.

(2) Norma que descreve ordenadamente as características  dum processo ou procedimento usado na engenharia dum produto ou na prestação de um serviço
[IEEE 612.12]

(3) Conhecimento formalizado que pode ser comunicado duma forma reprodutível e que permite a qualquer pessoa organizar o trabalho para atingir determinados objectivos dentro duma certa classe de situações problemáticas. Um método geralmente contém conceitos, uma ou mais linguagens, assumpções, regras, heurísticas, procedimentos, guias, modelos subsidiários e técnicas. Um método descreve uma maneira de conduzir um processo.
[Euromethod version 1 - Dictionary]

Tipo de métodos:

• Orientados pelos processos (funcionais)
concentram-se na abstracção algorítmica do problema;
a decomposição é descendente e em módulos (top-down);
cada módulo representa uma função (acção do sistema);
não descrevem as relações estruturais entre os dados.
Exemplo:
Análise Estruturada (Gane & Sarson)
Desenho Estruturado (Yourdin & Constantine
• Orientados pelos dados
concentram-se na identificação das estruturas de dados;
a arquitectura do sistema é baseada nas estruturas de dados:
pobres para representar funções complexas de manipulação de dados.
Exemplo:
Jackson Structured Design (M. Jackson)
• Métodos Mistos (utilizam técnicas de suporte às duas visões: funcional e de dados)
DFD (visão funcional);
DEA (visão dos dados).
Exemplo:
Structered Systems Analysis and Design Method (SSADM)
Análise Estruturada Moderna (Yourdon)
• Orientados pelos objectos
concentram-se na identificação de objectos;
os objectos suportam estruturas de dados e as operações (serviços) para manipular esses dados;
a arquitectura do sistema é baseada nos objectos;
cada objecto é um módulo;
técnicas diferentes representam visões complementares do mesmo problema;
decomposição descendente e composição ascendente (mas não obrigatoriamente).
Exemplo:
OMT - Object Modelling Tecnic

(1) Reunião de métodos e técnicas; o propósito de uma metodologia é promover uma determinada abordagem na solução dum problema, pré-seleccionando os métodos e as técnicas a utilizar.
Exemplo: OMT (Object Modelling Tecnice) e  IE (Information Engeneering) empregues no contexto das abordagens OO (Orientado por Objectos)  e da Engenharia da Informação, respectivamente.
No caso do IE o processo de desenvolvimento dos sistemas de informação é percorrido através do emprego das tradicionais técnicas de Análise Estruturada.
 

(2) Processo para a produção organizada de software usando uma colecção de técnicas predefinidas e convenções de notação
 
 
 
 

A metodologia OMT (Object Modelling Tecnic) usa 3 tipos de modelos para descrever um sistema:

• o modelo de objectos que descreve os objectos no sistema e as suas relações;
• o modelo dinâmico que descreve as interacções entre os objectos no sistema;
• o modelo funcional que descreve as transformações dos dados do sistema.

Os 3 modelos são partes ortogonais da descrição dum sistema completo e são cross-linked. O modelo de objectos é o mais importante, pois é necessário descrever o que está a mudar ou transformar antes do quando ou como muda.
 
 
 

(1) Uma medida quantitativa do grau com que um sistema, componente ou processo possui um dado atributo.
[IEEE 610.12]

(2) Quantificação de uma dada característica de uma entidade que se presume poder manifestar-se através de um conjunto de atributos mensuráveis.
 
 
 

(1) Uma medida quantitativa do grau pelo qual um item possui um dado atributo da qualidade.
(2) Uma função cujo input são dados do software e cujo output é um valor numérico singular que pode ser interpretado como o grau pelo qual o software possui um dado atributo da qualidade.
[IEEE 610.12]
 
 
 

Qualquer combinação de medidas de atributos de um produto de software, ou do processo de desenvolvimento, que permita avaliar quantitativamente o produto ou o processo.
 
 
 

Um modelo é uma abstracção de qualquer coisa com o propósito de a conhecer antes de a construir. Porque um modelo omite detalhes não essenciais, é mais fácil de manipular que a entidade original. A abstracção é a capacidade humana que nos permite negociar com a complexidade. Para construir sistemas complexos a pessoa que modeliza deve abstrair vistas diferentes do sistema, construir modelos usando notações precisas, verificar que os modelos satisfazem os requisitos do sistema e gradualmente adicionar detalhe para transformar esses modelos em implementação.

Talvez a principal razão da modelização, que incorpora as razões vistas (testar a entidade física antes de a construir, comunicação com o cliente, visualização) é tratar com os sistemas que são demasiado complexos para se perceberem directamente. Os modelos reduzem a complexidade separando um pequeno número de coisas importantes e tratar cada uma de cada vez.

A abstracção é um exame selectivo de certos aspectos dum problema. O objectivo é isolar aqueles aspectos que são importantes para algum propósito e suprimir os aspectos que não são importantes. A abstracção deve servir sempre algum propósito, porque o propósito determina o que é e o que não é importante. Muitas abstracções diferentes da mesma coisa são possíveis, dependendo do propósito para que são feitas.

Todas as abstracções são incompletas e não rigorosas. O propósito da abstracção é limitar o universo para podermos fazer coisas. Na construção de modelos não se deve procurar a verdade completa mas a adequação a algum propósito.

Um bom modelo captura os aspectos cruciais dum problema. Um modelo que contenha detalhes desnecessários limita a escolha da decisão do desenho e distrai dos objectivos reais.
 
 

Modelização conceptual dos Sistemas de Informação

É a actividade característica das primeiras fases do processo de desenvolvimento do software.

Conceitos básicos:

Estrutura de Conceitos,
Modelo,
Esquema,
Técnica,
Método,
Metodologia.

Nível de abrangência;
Natureza dos modelos: Modelos estruturais  e modelos comportamentais;
Nível de abstracção;
Nível semântico.

Principais paradigmas:

Orientação pelos dados;
Orientação pelos processos;
Orientação pelos objectos;
Abordagens Top-down e Bottom-up.

(1) Resultado da interpretação do real segundo uma determinada estrutura de conceitos

(2) Uma abstracção de qualquer coisa com o propósito de a compreender antes de a construir

(3) Representação de um sistema usando DFDs, DD, DED, etc
 
 
 

Norma com a qual uma organização deve cumprir para ser certificada.
 
 
 

O modelo de objectos descreve a estrutura estática dos objectos num sistema e as suas relações. Contém diagramas de objectos.

Passos para construir o modelo de objectos:

1. identificar os objectos e as classes
2. preparar o dicionário de dados (para cada entidade encontrada, escrever um parágrafo de descrição no dicionário de dados)
3. identificar associações (incluindo agregação) entre classes
4. identificar atributos
5. organizar e simplificar objectos e classes, usando herança
6. verificar caminhos de acesso
7. iterar e refinar
8. agrupar classes em módulos

O modelo dinâmico descreve os aspectos dum sistema que muda ao longo do tempo. É usado para especificar e implementar os aspectos de controlo dum sistema. Contém diagramas de estado.

Os conceitos principais de modelização dinâmica são os eventos e os estados. Realçamos o uso de acontecimentos e estados para especificar controlo mais que construções algébricas, para mostrar que estados e eventos podem ser organizados em generalizações hierárquicas e para partilhar estrutura e comportamento.

Mostra o comportamento do sistema no tempo. Descreve a sequência de operações que ocorrem em resposta a estímulos externos, sem considerar o que é que a operação faz ou como é implementada.

Passos para construir o modelo dinâmico:

1. preparar cenários
2. identificar eventos entre objectos e desenhar um diagrama de eventos para cada cenário
3. desenhar um diagrama de fluxo de eventos para o sistema
4. construir diagramas de estados
5. verificar coerência e completação

A norma ISO/IEC 12207 define modelo do ciclo de vida como um quadro que contem os processos, actividades e tarefas envolvidos no desenvolvimento, operação e manutenção dum produto de software, contemplando a vida do sistema desde a definição dos seus requisitos até ao fim da sua utilização.

Os ciclos de vida do software referem-se à progressão dum sistema de software desde o desenvolvimento até à manutenção e eventualmente à sua substituição.

Os modelos do ciclo de vida são descritivos (para monitorar), mas também prescritivos (para planear).
 
 
 

Também conhecido por abordagem "top-down" foi proposto por Royce em 1970 e popularizado por Boehm. Define as seguintes fases:

1. Estudo de viabilidade
2. Análise de requisitos
3. Especificação de requisitos
4. Desenho global
5. Desenho de pormenor
6. Implementação
7. Validação e verificação
8. Distribuição

Cada fase só começa depois de a anterior acabar.
As alterações a resultados aprovados limita-se à fase precedente.

Méritos do modelo:

• Torna o processo de desenvolvimento estruturado. Tem uma ordem sequencial de fases. Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do início da seguinte;
• A análise, a especificação, o desenho são importantes;
• Deve haver uma verificação e validação explícita, para determinar se o software atinge os seus objectivos;
• Todas as actividades identificadas nas fases do modelo são mesmo necessárias e estão na ordem certa;
• Esta abordagem é actualmente a norma e provavelmente permanecerá como tal nos próximos tempos.

• Não fornece feeback entre as fases e não permite a actualização ou redefinição das fases anteriores;
• Não suporta modificações nos requisitos;
• Não prevê a manutenção;
• Não permite a reutilização;
• É excessivamente sincronizado;
• Se ocorrer um atraso todo o processo é afectado;
• Faz aparecer o software muito tarde.

• O modelo conduz a uma rígida divisão de trabalho (analistas, arquitectos, programadores, controladores de qualidade, programadores de manutenção);
• Só o chefe do projecto tem uma visão global do problema;
• Quando algo corre mal, a culpa é dos outros... Ninguém se sente realmente responsável.

Proposto por Boehm, em que cada círculo da espiral identifica o subproblema com maior risco associado e refina a solução para esse problema.

Quadrantes:
1. Determinar objectivos, alternativas, condicionantes
2. Avaliar alternativas: identificar, assumir os riscos ( análise de riscos, protótipo 1, protótipo 2, protótipo 3)
3. Compromisso, planear as fases seguintes (plano de requisitos, ciclo de vida; plano de desenvolvimento; integração e teste)
4. Desenvolver, verificar (Conceito; Requisitos; Validação Requesitos; desenho; validação e verificação; desenho de pormenor; codificação; teste unitário; integração; implementação)
 
 
 

O modelo Entidade-Associação foi introduzido num artigo publicado em 1976 por Peter Chen, no qual descreve a estrutura de conceitos utilizados: entidades e associações - e os seus atributos. O modelo foi posteriormente estendido para suportar novos conceitos, quer por Chen quer por outros autores. A sua popularidade ficou a dever-se à sua facilidade de utilização, à divulgação de CASES’s que o suportam e à crença que entidades e associações são conceitos apropriados para interpretar o mundo real.

O modelo de dados E-A é uma representação lógica dos dados de uma organização ou de uma área de negócio. É expresso em termos de Entidades, Associações (ou relações) entre essas entidades, e atributos (ou propriedades) quer das Entidades quer das Associações.

Um modelo E-A é normalmente expresso como um diagrama E-A, que é uma representação gráfica do modelo E-A.

Os modelos E-A são geralmente construídos durante a fase de análise do processo de desenvolvimento, embora também possam ser usados para representar o modelo de dados de uma organização. O output da fase de análise é um modelo conceptual de dados expresso na forma de um diagrama detalhado de Entidades e Associações.

 O Modelo E-A é usado para construir o modelo de dados conceptual, que será a representação da estrutura de uma base de dados.  É, no entanto,  independente do  sistema de gestão de bases de dados que será usado para a implementação física.
 
 
 

Descrição dos aspectos dum sistema que transforma valores usando funções, mapeamentos, restrições e dependências funcionais

Mostra a definição das operações no modelo de objectos e as acções no modelo dinâmico e
é suportado por um DFD. Mostra como os valores são calculados sem revelar sequência, decisão ou estrutura do objecto.

Passos:

1. identificar valores de entrada e saída;
2. construir diagramas de fluxos de dados;
3. descrever funções;
4. identificar restrições;
5. especificar critério de optimização.

Modelo de uma parte do sistema; descrição de uma modificação.
 
 
 

(1) O grau pelo qual um sistema ou programa informático é composto por componentes discretas tal que uma alteração num componente tem um impacto mínimo nos outros componentes.
[IEEE 610.12]

(2) A modularidade trata da questão de como a estrutura (de um programa) pode ajudar a atingir certos objectivos. Um desses objectivos é o domínio da complexidade e por isso este princípio defende uma estratégia de dividir para conquistar. Cada unidade de divisão é geralmente denominada módulo.
A modularidade permite que:

• um problema seja atacado em simultâneo por pessoas distintas
• as alterações provocadas num módulo não condicionam obrigatoriamente a recompilação de todo o sistema em construção

(1) O processo de partir um sistema em componentes de forma a facilitar o desenho e o desenvolvimento; um elemento da programação modular.
[IEEE 610.12]

(2) Todos os sistemas grandes são decompostos em módulos (top-down) e compostos de módulos (bottom-up).
Cada módulo deve ser coeso, isto é, os seus elementos internos devem ter muito a ver uns com os outros. Os módulos devem estar desacopulados, isto é, cada módulo deve ter pouco a ver com os outros módulos.

Ver acoplamento e coesão.
 
 
 

(1) Subconjunto coerente dum sistema contendo, com fronteiras definidas, classes e suas relações.

(2) Um programa unitário que é discreto e identificável no que respeita à compilação e à combinação com outros programas unitários.
(3) Uma parte logicamente separável dum programa.
[IEEE 610.12]
 
 
 

Momento em que o fornecedor tem oportunidade de satisfazer (ou exceder) as expectativas dum cliente durante a transacção, quando o cliente utiliza o produto ou serviço.
[Albrecht, 1992]
 
 
 

Nasceu no final dos anos 20 através das experiências do australiano Elton Mayo. O fundador da escola de relações humanas (uma filosofia oposta aos princípios científicos do trabalho de Taylor) pretendia provar que os trabalhadores não eram motivados apenas pela remuneração, mas também por outros factores como as condições de trabalho e o apreço das chefias. Nos anos 50, dois autores deram uma contribuição decisiva para esta corrente: Abraham Maslow (pirâmide das necessidades) e Frederick Herzberg (teoria dos dois factores).
[50 Conceitos de A a Z]
 
 
 
 
 
 
 

Visitas:

Última actualização: 16 de Fevereiro de 2000