Aptidão para determinar a história, a utilização ou a localização de uma entidade por meio de identificações registadas.
Nota 1: O termo rastreabilidade pode ser utilizado nas três acepções principais:
a) quando se tratar de um produto pode referir-se à:
-origem dos materiais e das peças;
-história do processamento do produto;
-distribuição e à localização do produto depois da entrega;
b) quando se tratar de calibração, relaciona o equipamento de medição com padrões nacionais ou internacionais, com padrões primários, com constantes e propriedades físicas básicas ou com materiais de referência;
c) quando se tratar de colheita de dados, liga cálculos e dados gerados ao longo do ciclo da qualidade e por vezes, até aos requisitos da qualidade de uma entidade.
Nota 2: Todos os aspectos referentes a eventuais requisitos de rastreabilidade devem ser claramente especificados, por exemplo em termos de períodos de tempo, ponto de origem ou identificação.
[NP EN ISO 8402]

O grau pelo qual cada elemento do desenvolvimento dum produto de software estabelece a sua razão de existir, por exemplo, o grau de correspondência entre o requisito e o desenho dum componente de softtware.
[IEEE-610.12]

Rastreabilidade sincrónica:
Possibilidade de identificar e verificar em cada momento a correspondência entre as representações do mesmo requisito ou entidade do universo de discurso a vários níveis de abstracção

Rastreabilidade diacrónica:
Possibilidade de verificar que evolução temporal teve uma dada representação ao mesmo nível de abstracção, isto é, quais as mutações operadas ao longo do tempo.
 
 
 

Mudança ou melhoria que envolve um repensar radical da forma como a organização gere o seu negócio, incluindo a pertinência ou não de algumas das suas actividades. A gestão da qualidade diz respeito tanto a mudanças radicais (reengenharia) como a pequenas alterações incrementais.
[ED - MQ]

Michael Hammer, ex-professor do MIT, é considerado o pai desta teoria inovadora e radical. Referiu-se pela primeira vez ao tema no artigo publicado em 1990 pela Harvard Business Review. Mas a consagração só chegaria três anos depois com o livro Reengineering the Corporation, escrito em parceria com James Champy. Para os autores, a reengenharia significa um redesenho radical dos processos de negócio com o objectivo de obter melhorias drásticas em três áreas: nos custos; nos serviços; e no tempo.
[50 Conceitos de A a Z]
 
 
 
 

(1) Uma condição ou aptidão necessária a um utilizador para resolver um problema ou atingir um objectivo.
(2) Uma condição ou aptidão que deve ser satisfeita ou que um sistema ou componente deve possuir para satisfazer um contrato, norma, especificação ou outro documento formalmente imposto.
(3) Uma representação documentada de uma condição ou aptidão.
[IEEE 610.12]

(4) Declaração formal duma necessidade particular e a forma esperada pela qual ela será satisfeita.

(5) Condição essencial que um sistema tem de satisfazer.
[ISO/IEC 2382-20]
 
 
 

Um conjunto de critérios ou condições que tem de ser obedecidos de forma a poder-se qualificar um produto de software como conforme com as suas especificações e estar pronto a ser usado no seu ambiente alvo.
[ISO/IEC 12207]
 
 
 

(1) O grau pelo qual um módulo de software ou outro produto do trabalho pode ser usado em mais que um programa ou sistema informático.
[IEEE 610.12]
 

(2) Capacidade de construir um sistema a partir de peças pré-existentes, e de fazer com que os componentes do novo software possam ser usados de novo futuramente.
Se escrevermos os nossos programas com a preocupação de tornar a sua reutilização menos difícil, então eles ficarão mais modificáveis e mais compreensíveis.
Se usarmos nos novos programas componentes reutilizáveis de programas anteriores, teremos agora programas mais fiáveis.
Programar pensando na reutilização implica um acréscimo de trabalho. Para não atrasar o projecto, deve haver uma fase de “generalização”, depois da implementação e teste.
Se os programas forem mais reutilizáveis pode conseguir-se evitar ter que escrever variantes de programas anteriores, nossos ou de outros.
 

Princípio da reutilização

Este princípio advoga que um produto de software deve incorporar componentes pré-fabricados e/ou que partes deste devam ser construídas com o intuito da incorporação em outros produtos de software.
A possibilidade de reutilização é uma razão forte no sentido de favorecer a estruturação do código em componentes independentes. Durante o desenvolvimento de um programa é essencial identificar os componentes reutilizáveis, que sendo agrupados em bibliotecas, poderão ser usados posteriormente.
A reutilização só é possível se num programa for claramente separado o código que é específico do programa daquele que é de utilização genérica, e que pode ser importado de bibliotecas ou escrito para ser posteriormente reutilizado.
 
 
 
 

(1) Grau pelo qual um sistema ou componente pode funcionar correctamente na presença de inputs inválidos ou condiçoes ambientais de stress.

(2) Propriedade do software tal que não falha catastroficamente quando alguns dos pressupostos (assunções) do desenho é violado.
 
 
 
 
 
 
 
 

Visitas:

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