Estes são os princípios e regras encontrado no Método de Medição COSMIC v4.0.2
Agregando resultados de medição
Regras
a) Para qualquer processo funcional, os tamanhos funcionais dos movimentos de dados individuais devem ser agregados num único valor de tamanho funcional em unidades de CFP, somando-os.
Tamanho (processo funcionali) = Σ tamanho (entradas) + Σ tamanho (saídas) +Σ tamanho (lê) + Σ tamanho (gravações)
b) Para qualquer processo funcional, o tamanho funcional das alterações em seus Requisitos Funcionais do Usuário deverá ser agregado dos tamanhos das movimentações de dados que foram adicionados, modificados ou excluídos no processo funcional para fornecer um tamanho da mudança em unidades de CFP , de acordo com a seguinte fórmula.
Tamanho (mudança (processo funcional)) =
Σ tamanho (movimentos de dados adicionados) +
Tamanho Σ (movimentos de dados modificados) +Σ tamanho (movimentos de dados excluídos)
Para obter mais informações sobre agregação de tamanho funcional, consulte a seção 4.3.2. Para medir o tamanho do software alterado, consulte a seção 4.4.2.
c) O tamanho de uma peça de software dentro de um escopo definido deve ser obtido agregando os tamanhos dos processos funcionais da peça, sujeito às regras e) ef) abaixo
d) O tamanho de qualquer alteração em um software dentro de um escopo definido deve ser obtido agregando os tamanhos de todas as alterações em todos os processos funcionais do software, sujeito às regras e) ef) abaixo.
e) Os tamanhos de peças de software ou de alterações em peças de software podem ser somados somente se medidos no mesmo nível de granularidade do processo funcional de seu FUR.
f) Os tamanhos de peças de software e/ou alterações nos tamanhos de peças de software dentro de qualquer camada ou de camadas diferentes devem ser somados somente se fizer sentido fazê-lo, para fins de medição.
g) O tamanho de um software pode ser obtido somando os tamanhos de seus componentes (independentemente de como o pedaço é decomposto) e eliminando as contribuições de tamanho dos movimentos de dados entre componentes.
h) Apenas uma saída deve ser identificada para todas as mensagens de erro/confirmação emitidas por qualquer processo funcional para um usuário funcional humano.
i) Se o método COSMIC for estendido localmente (por exemplo, para medir algum aspecto do tamanho não coberto pelo método padrão), então o tamanho medido através da extensão local deverá ser relatado separadamente conforme descrito na seção 5.1 e NÃO deverá ser adicionado ao tamanho obtido pelo método padrão, medido em CFP (ver mais adiante na secção 4.5).
Comandos de controle em aplicativos com interface humana
Regra
Em uma aplicação com interface humana, os 'comandos de controle' devem ser ignorados, pois não envolvem qualquer movimentação de dados sobre um objeto de interesse.
Relatórios de medição COSMIC
Regra
Além das medições reais, registradas como em 5.1, alguns ou todos os seguintes atributos de cada medição devem ser registrados, dependendo da finalidade da medição e do nível desejado de comparabilidade com outras medições, por exemplo, para fins de benchmarking.
a) Identificação do componente de software medido (nome, ID de versão ou ID de configuração).
b) As fontes de informação utilizadas para identificar o RFU utilizado para a medição
c) O domínio do software
d) Uma descrição da arquitetura das camadas em que a medição é feita, se aplicável.
e) Uma declaração do propósito da medição.
f) Uma descrição do âmbito da medição e a sua relação com o âmbito global de um conjunto relacionado de medições, se existir. (Use as categorias genéricas de escopo na seção 2.2)
g) O padrão de estratégia de medição utilizado (COSMIC ou local), com o modo de processamento (on-line ou batch)
h) Os usuários funcionais do software
i) O nível de granularidade dos artefactos de software disponíveis e o nível de decomposição do software.
j) O ponto do ciclo de vida do projeto em que a medição foi feita (especialmente se a medição é uma estimativa baseada em requisitos incompletos ou foi feita com base na funcionalidade realmente entregue).
k) A meta ou margem de erro estimada da medição.
l) Indicações se foi utilizado o método de medição padrão COSMIC e/ou uma aproximação local ao método padrão e/ou se foram utilizadas extensões locais (ver secção 4.5). Use as convenções de rotulagem das seções 5.1 ou 5.2.
m) Uma indicação se a medição é de funcionalidade desenvolvida ou entregue (a funcionalidade 'desenvolvida' é obtida através da criação de novo software; a funcionalidade 'entregue' inclui a funcionalidade 'desenvolvida' e também inclui a funcionalidade obtida por outros meios que não a criação de novo software, ou seja, incluindo todas as formas de reutilização de software existente, implementação de pacotes de software, utilização de parâmetros existentes para adicionar ou alterar funcionalidades, etc.).
n) Uma indicação se a medição é de funcionalidade recentemente fornecida ou é o resultado de uma atividade de “aprimoramento” (ou seja, a soma é de funcionalidade adicionada, alterada e excluída – ver 4.4).
o) O número de componentes principais, se aplicável, cujos tamanhos foram somados para obter o tamanho total registrado.
p) A percentagem de funcionalidades implementadas por software reutilizado
q) Para cada escopo dentro do escopo geral de medição, uma matriz de medição, conforme especificado no Apêndice A.
r) O nome do Medidor e quaisquer qualificações de certificação COSMIC; a data da medição
Rotulagem de medição COSMIC
Regras
Um resultado de medição COSMIC deve ser anotado como 'x CFP (v)', onde:
- 'x' representa o valor numérico do tamanho funcional,
- 'v' representa a identificação da versão padrão do método COSMIC usado para obter o valor numérico do tamanho funcional 'x'. NOTA: Se um método de aproximação local foi usado para obter a medição, mas caso contrário a medição foi feita usando as convenções de uma versão COSMIC padrão, a convenção de rotulagem acima deve ser usada, mas o uso do método de aproximação deve ser observado em outro lugar - consulte a seção 5.2. Rotulagem de extensões locais COSMIC
Regra
Um resultado de medição COSMIC usando extensões locais deve ser anotado como: 'x CFP (v) + z Local FP', onde:
- 'x' representa o valor numérico obtido pela agregação de todos os resultados de medição individuais de acordo com o método padrão COSMIC, versão v,
- 'v' representa a identificação da versão padrão do método COSMIC utilizado para obter o valor numérico do tamanho funcional 'x'.
- 'z' representa o valor numérico obtido pela agregação de todos os resultados de medição individuais obtidos a partir de extensões locais ao método COSMIC.
Grupo de dados
Princípio
Cada grupo de dados identificado deve ser único e distinguível através da sua coleção única de atributos de dados.
Identificar diferentes grupos de dados (e, portanto, diferentes objetos de interesse) movidos no mesmo processo funcional
Regra
Para todos os atributos de dados que aparecem na entrada de um processo funcional:
- a) conjuntos de atributos de dados que possuem diferentes frequências de ocorrência descrevem diferentes objetos de interesse;
- b) conjuntos de atributos de dados que têm a mesma frequência de ocorrência, mas diferentes atributos-chave de identificação, descrevem diferentes objetos de interesse;
- c) todos os atributos de dados em um conjunto resultante da aplicação das partes a) e b) desta regra pertencem ao mesmo tipo de grupo de dados, a menos que o FUR especifique que pode haver mais de um tipo de grupo de dados descrevendo o mesmo objeto de interesse na entrada do processo funcional (ver Nota 3)
Esta mesma regra se aplica a todos os atributos de dados que aparecem na saída de um processo funcional, ou a todos os que são movidos de um processo funcional para o armazenamento persistente, ou a todos os que são movidos do armazenamento persistente para um processo funcional.
NOTA 1. Pode ser útil ao analisar resultados complexos, por exemplo, relatórios com dados que descrevem vários objetos de interesse, considerar cada grupo de dados candidatos separado como se fosse produzido por um processo funcional separado. Cada um dos tipos de grupos de dados identificados desta forma também deve ser distinguido e contado ao medir o relatório complexo. Para exemplos, consulte a 'Diretriz para dimensionar software de aplicação de negócios' [7], em particular o exemplo na seção 2.6.1 e sua análise em 2.6.2. Ver também a análise dos exemplos 4 e 5 na secção 4.2.4.
NOTA 2. Examinar como os atributos de dados são fisicamente agrupados ou separados na entrada ou na saída pode ajudar a distinguir diferentes tipos de grupos de dados, mas não pode ser confiável para distingui-los. Por exemplo, dois ou mais conjuntos de atributos de dados que ocorrem na mesma entrada ou saída e que estão fisicamente separados por razões estéticas ou para facilidade de compreensão, pertencerão ao mesmo tipo de grupo de dados se satisfizerem a regra acima.
NOTA 3. Ver seção 3.5 do Manual de Medição para definições, princípios e regras para as movimentações de dados que movimentam grupos de dados, e seção 3.5.7 (exemplos 2, 3, 4 e 5) e 3.5.11 para exceções a estas regras para movimentações de dados, conforme regra c acima.
Regras
a) Um processo funcional deve pertencer inteiramente ao escopo de medição de um software em uma e apenas uma camada.
b) Um processo funcional deve compreender um mínimo de dois movimentos de dados, nomeadamente a Entrada desencadeadora mais uma Saída ou uma Escrita, dando um tamanho mínimo de 2 CFP. Não há limite superior para o número de movimentações de dados em um processo funcional e, portanto, não há limite superior para seu tamanho.
c) Um processo funcional em execução será considerado encerrado quando tiver satisfeito seu FUR para todas as respostas possíveis ao seu Entry acionador. Uma pausa durante o processamento por motivos técnicos não será considerada como encerramento do processo funcional.
Granularidade do Processo Funcional
|
Nível de granularidade do processo funcional Regras
|
|
Seg. |
DESCRIÇÃO DOS PRINCÍPIOS E REGRAS |
|
abordagem aproximada. Essas abordagens definem como os requisitos podem ser medidos em níveis mais altos de granularidade. Os fatores de escala são então aplicados às medições nos níveis mais altos de granularidade para produzir um tamanho aproximado no nível de granularidade dos processos funcionais e seus subprocessos de movimentação de dados. Consulte a 'Diretriz para medição aproximada do tamanho funcional COSMIC' [6]. |
|
Veja também processo funcional
Um processo funcional que requer dados de um usuário funcional
Regras
a) Um processo funcional deve obter um grupo de dados por meio de uma movimentação de dados de entrada de um usuário funcional, quando o processo funcional não precisa informar ao usuário funcional quais dados enviar, como em qualquer um dos quatro casos a seguir:
- quando um usuário funcional envia um grupo de dados por meio de uma entrada acionadora que inicia o processo funcional;
- quando um processo funcional, tendo recebido um grupo de dados por meio de uma Entrada acionadora, espera, esperando a chegada de um grupo de dados adicional do usuário funcional por meio de uma Entrada (pode ocorrer quando um usuário funcional humano insere dados no software de aplicação de negócios);
- quando um processo funcional, iniciado, solicita ao usuário funcional, 'envie-me seus dados agora, se tiver algum' e o usuário funcional envia seus dados;
-
quando um processo funcional, iniciado, inspeciona o estado de um usuário funcional e recupera os dados necessários.
Nos dois últimos casos (normalmente ocorrendo em software de 'sondagem' em tempo real), por convenção, nenhuma saída do processo funcional deve ser identificada para obter os dados necessários. O processo funcional precisa apenas enviar uma mensagem de prompt a um usuário funcional e a funcionalidade dessa mensagem de prompt é considerada parte da Entrada. O processo funcional sabe quais dados esperar. Apenas uma Entrada deverá ser identificada para este caso.
b) Quando um processo funcional precisa obter os serviços de um usuário funcional (por exemplo, para obter dados) e o usuário funcional precisa ser informado sobre o que enviar (normalmente quando o usuário funcional é outra peça de software fora do escopo do software sendo medido), uma saída seguida por uma movimentação de dados de entrada deve ser identificada. A Saída envia a solicitação dos dados específicos; a entrada recebe os dados retornados.
Usuários funcionais
Regras
a) Os usuários funcionais de um software a ser medido dependerão do propósito da medição.
b) Quando o propósito de uma medição de um software está relacionado ao esforço para desenvolver ou modificar o software, então os usuários funcionais devem ser todos os diferentes tipos de remetentes e/ou destinatários pretendidos de dados de/para o funcionalidade nova ou modificada, conforme exigido por seu FUR.
NOTA: A FUR pode especificar que um conjunto de usuários funcionais deve ser identificado individualmente. No entanto, serão do mesmo tipo se cada ocorrência estiver sujeita ao mesmo FUR.
O modelo de software genérico
Princípios
a) Um software interage com seus usuários funcionais através de uma fronteira e com armazenamento persistente dentro dessa fronteira.
b) Os requisitos funcionais do usuário de um software a ser medido podem ser mapeados em processos funcionais únicos.
c) Cada processo funcional consiste em subprocessos.
d) Um subprocesso pode ser uma movimentação ou manipulação de dados.
e) Uma movimentação de dados move um único grupo de dados.
f) Existem quatro tipos de movimentação de dados, Entrada, Saída, Gravação e Leitura.
- Uma entrada move um grupo de dados para um processo funcional de um usuário funcional.
- Uma saída move um grupo de dados de um processo funcional para um usuário funcional.
- Uma gravação move um grupo de dados de um processo funcional para um armazenamento persistente.
- Uma leitura move um grupo de dados do armazenamento persistente para um processo funcional.
g) Um grupo de dados consiste em um conjunto único de atributos de dados que descrevem um único objeto de interesse.
h) Cada processo funcional é iniciado pelo seu acionamento da movimentação de dados de entrada. O grupo de dados movido pela entrada acionadora é gerado por um usuário funcional em resposta a um evento acionador.
i) O tamanho de um processo funcional é igual à contagem total de suas movimentações de dados
j) Um processo funcional deve incluir pelo menos o acionamento da movimentação de dados de entrada e uma movimentação de dados de gravação ou de saída, ou seja, deve incluir um mínimo de duas movimentações de dados. Não há limite máximo para o número de movimentações de dados em um processo funcional
k) Como aproximação para fins de medição, os subprocessos de manipulação de dados não são medidos separadamente; a funcionalidade de qualquer manipulação de dados é considerada responsável pela movimentação de dados à qual está associada
NOTA: O Modelo Genérico de Software COSMIC, como o próprio nome sugere, é um 'modelo' lógico que expõe unidades nas quais o software processa dados que são adequados para medição de tamanho funcional. O modelo não pretende descrever a sequência física das etapas pelas quais o software é executado nem qualquer implementação técnica do software.
Camada
Princípios
a) O software em uma camada fornece um conjunto de serviços que é coeso de acordo com algum critério definido, e que o software em outras camadas pode utilizar sem saber como esses serviços são implementados.
b) O relacionamento entre software em quaisquer duas camadas é definido por uma 'regra de correspondência' que pode ser
- 'hierárquico', ou seja, o software da camada A pode usar os serviços fornecidos pelo software da camada B, mas não vice-versa (onde o relacionamento hierárquico pode ser ascendente ou descendente), ou
- 'bidirecional', ou seja, o software da camada A pode usar software da camada B e vice-versa.
c) Software em uma camada troca grupos de dados com software em outra camada por meio de seus respectivos processos funcionais.
d) O software em uma camada não utiliza necessariamente todos os serviços funcionais fornecidos pelo software em outra camada.
e) O software em uma camada de uma arquitetura de software definida pode ser particionado em outras camadas de acordo com uma arquitetura de software definida diferente.
O modelo de contexto de software COSMIC
Princípios
- a) O software é limitado pelo hardware.
- b) O software é normalmente estruturado em camadas.
- c) Uma camada pode conter um ou mais softwares “pares” separados.
- d) Qualquer software a ser medido deverá ser definido pelo seu escopo de medição, que deverá estar totalmente confinado em uma única camada.
- e) O escopo de um software a ser medido dependerá do propósito da medição.
- f) Os usuários funcionais de um software a ser medido devem ser identificados a partir de seus Requisitos Funcionais do Usuário (FUR) como os remetentes e/ou destinatários pretendidos dos dados de/para o software, respectivamente.
- g) Os requisitos funcionais de software podem ser expressos em diferentes níveis de granularidade.
- h) Uma medição precisa do tamanho COSMIC de um software requer que seus RFU sejam conhecidos nos níveis de granularidade nos quais seus processos e subprocessos funcionais podem ser identificados.
- i) Uma medição aproximada do tamanho COSMIC de um software é possível se seus requisitos funcionais forem medidos em um alto nível de granularidade por uma abordagem de aproximação e escalados para os níveis de granularidade dos processos e subprocessos funcionais.
Níveis de granularidade para medir um processo funcional
Regras
- a) Uma medição do tamanho funcional de um software exige que seus RFU sejam conhecidos nos níveis de granularidade nos quais seus processos funcionais e subprocessos de movimentação de dados podem ser identificados.
- b) Se alguns requisitos precisarem ser medidos antes de terem sido definidos com detalhes suficientes para uma medição precisa, os requisitos poderão ser medidos usando uma abordagem aproximada. Essas abordagens definem como os requisitos podem ser medidos em níveis mais altos de granularidade. Os fatores de escala são então aplicados às medições nos níveis mais altos de granularidade para produzir um tamanho aproximado nos níveis de granularidade dos processos funcionais e seus subprocessos de movimentação de dados. Consulte a Diretriz para medição precoce ou rápida do tamanho funcional COSMIC por abordagens de aproximação. [6].
Entrada (E)
Princípios
a) Uma Entrada deverá mover um único grupo de dados que descreve um único objeto de interesse de um usuário funcional através da fronteira e para o processo funcional do qual a Entrada faz parte. Se a entrada para um processo funcional compreender mais de um grupo de dados, cada um descrevendo um objeto de interesse diferente, identifique uma Entrada para cada grupo de dados exclusivo na entrada. (Consulte também a seção 3.5.7 sobre 'Unicidade da movimentação de dados'.)
b) Uma Entrada não deverá transferir dados através da fronteira, nem ler ou gravar dados de/para armazenamento persistente.
Regras
a) O grupo de dados de uma Entrada acionadora pode consistir em apenas um atributo de dados que simplesmente informa ao software que 'ocorreu um evento Y'. Muitas vezes, especialmente em software de aplicação de negócios, o grupo de dados da entrada acionadora possui vários atributos de dados que informam ao software que “ocorreu um evento Y e aqui estão os dados sobre esse evento específico”.
b) Os ticks do relógio que disparam eventos devem ser sempre externos ao software que está sendo medido. Portanto, por exemplo, um evento de clock que ocorre a cada 3 segundos deve ser associado a uma Entrada que move um grupo de dados de um atributo de dados. Observe que não faz diferença se o evento desencadeador é gerado periodicamente pelo hardware ou por outro software fora dos limites do software que está sendo medido.
c) A menos que seja necessário um processo funcional específico, a obtenção da data e/ou hora do relógio do sistema não será considerada como causa de uma Entrada ou qualquer outra movimentação de dados.
d) Se a ocorrência de um evento específico causar a Entrada de um grupo de dados compreendendo até 'n' atributos de dados de um determinado objeto de interesse e o FUR permitir que outras ocorrências do mesmo evento possam causar uma Entrada de um grupo de dados que tenha valores para atributos de apenas um subconjunto dos 'n' atributos do objeto de interesse, então uma Entrada deverá ser identificada, movendo um grupo de dados compreendendo todos os 'n' atributos de dados.
e) Ao identificar entradas em uma tela que permite que usuários funcionais humanos insiram dados em processos funcionais, analise apenas as telas preenchidas com dados. Ignore qualquer tela formatada, mas 'em branco', exceto possíveis valores padrão, e ignore todos os campos e outros títulos que permitem que usuários humanos entendam os dados de entrada necessários.
OBSERVAÇÃO. Pode ser necessário considerar o campo e outros títulos ao medir o FUR para alterações nas Entradas – consulte a seção 4.4.1.
Sair (X)
Princípios
a) Uma Saída deve mover um único grupo de dados que descreve um único objeto de interesse do processo funcional do qual a Saída faz parte através da fronteira para um usuário funcional. Se a saída de um processo funcional compreender mais de um grupo de dados, identifique uma Saída para cada grupo de dados exclusivo na saída. (Consulte também a seção 3.5.7 sobre 'Unicidade da movimentação de dados'.)
b) Uma Saída não deverá inserir dados através da fronteira, nem ler ou gravar dados de/para armazenamento persistente.
Regras
a) Uma consulta que gera texto fixo (onde 'fixo' significa que a mensagem não contém valores de dados variáveis, por exemplo, o resultado de pressionar um botão para 'Termos e Condições' em um site de compras), deve ser modelada como tendo uma Saída para a saída de texto fixa.
NOTA: Para obter o resultado da funcionalidade 'Ajuda', consulte a 'Diretriz para dimensionar software de aplicativos de negócios'. Para a saída de mensagens relacionadas a condições de erro ou confirmação de sucesso, consulte a seção 3.5.11 deste Manual de Medição.
b) Se uma Saída de um processo funcional movimenta um grupo de dados compreendendo até 'n' atributos de dados de um determinado objeto de interesse e o FUR permite que o processo funcional possa ter uma ocorrência de uma Saída que movimenta um grupo de dados que possui valores para atributos de apenas um subconjunto dos 'n' atributos do objeto de interesse, então uma Saída deve ser identificada, movendo um grupo de dados compreendendo todos os 'n' atributos de dados.
c) Ao identificar saídas, ignore todos os campos e outros títulos que permitam aos usuários humanos compreender os dados de saída.
NOTA: Pode ser necessário considerar o campo e outros rumos ao medir o FUR para alterações nas Saídas – consulte a seção 4.4.1
Leia (R)
Princípios
a) Um Read deve mover um único grupo de dados que descreve um único objeto de interesse do armazenamento persistente para um processo funcional do qual o Read faz parte. Se o processo funcional precisar recuperar mais de um grupo de dados do armazenamento persistente, identifique uma Leitura para cada grupo de dados exclusivo recuperado. (Consulte também a seção 3.5.7 sobre 'Unicidade da movimentação de dados'.)
b) Um Read não deve receber ou enviar dados através da fronteira ou gravar dados em armazenamento persistente.
c) Durante um processo funcional, movimento ou manipulação de constantes ou variáveis que sejam internas ao processo funcional e que só possam ser alteradas por um programador, ou cálculo de resultados intermédios num cálculo, ou de dados armazenados por um processo funcional resultando apenas da implementação, e não do FUR, não serão considerados como movimentos de dados de leitura.
d) Uma movimentação de dados de leitura sempre inclui qualquer funcionalidade de 'solicitação de leitura' (portanto, uma movimentação de dados separada nunca será contada para qualquer funcionalidade de 'solicitação de leitura'). Consulte também a seção 3.5.9.
Regras
a) Identifique uma leitura quando, de acordo com o FUR, o software que está sendo medido deve recuperar um grupo de dados do armazenamento persistente.
b) Não identifique uma leitura quando o FUR do software que está sendo medido especifica qualquer usuário funcional de software ou hardware como a fonte de um grupo de dados ou como o meio de recuperar um grupo de dados armazenado persistentemente. (Para este caso consulte os princípios e regras de Entradas e Saídas.)
Escreva (W)
Princípios
a) Uma Write deve mover um único grupo de dados que descreve um único objeto de interesse do processo funcional do qual a Write faz parte para o armazenamento persistente. Se o processo funcional precisar mover mais de um grupo de dados para o armazenamento persistente, identifique uma Gravação para cada grupo de dados exclusivo que for movido para o armazenamento persistente. (Consulte também a seção 3.5.7 sobre 'Unicidade da movimentação de dados'.)
b) Uma gravação não deve receber ou enviar dados através da fronteira, nem ler dados de armazenamento persistente.
c) Um requisito para excluir um grupo de dados do armazenamento persistente deve ser medido como uma única movimentação de dados de gravação.
e)
O seguinte não deve ser considerado como movimentação de dados de gravação:
- A movimentação ou manipulação de quaisquer dados que não existiam no início de um processo funcional e que não se tornaram persistentes quando o processo funcional é concluído;
- Criação ou atualização de variáveis ou resultados intermediários internos ao processo funcional;
- Armazenamento de dados por processo funcional resultante apenas da implementação, e não do RFU. (Um exemplo seria o uso de armazenamento para armazenar dados temporariamente durante um grande processo de classificação em uma tarefa processada em lote.)
Regras
a) Identifique uma escrita quando, de acordo com o FUR, o software que está sendo medido deve mover um grupo de dados para armazenamento persistente.
b) Não identificar uma Gravação quando o FUR do software que está sendo medido especificar qualquer usuário funcional de software ou hardware como destino do grupo de dados, ou como meio de armazenamento do grupo de dados. (Para este caso consulte os princípios e regras de Entradas e Saídas.)
Manipulação de dados associada a movimentações de dados
Princípio
Toda manipulação de dados em um processo funcional deve estar associada aos quatro tipos de movimentação de dados (E, X, R e W). Por convenção, presume-se que as movimentações de dados de um processo funcional também explicam a manipulação de dados do processo funcional.
Regras
a) Uma movimentação de dados de entrada leva em conta toda a manipulação de dados para permitir que um grupo de dados seja inserido por um usuário funcional (por exemplo, manipulações de formatação e apresentação) e seja validado.
b) Uma movimentação de dados de saída leva em conta toda a manipulação de dados para criar os atributos de dados de um grupo de dados a serem gerados e/ou permitir que o grupo de dados seja gerado (por exemplo, manipulações de formatação e apresentação) e seja roteado para o usuário funcional pretendido .
c) Uma movimentação de dados de leitura leva em conta toda a computação e/ou processamento lógico necessário para recuperar um grupo de dados do armazenamento persistente.
d) Uma movimentação de dados de gravação leva em conta toda a computação e/ou processamento lógico para criar ou atualizar um grupo de dados a ser gravado ou para excluir um grupo de dados.
e) A manipulação de dados associada a qualquer uma dessas movimentações de dados não inclui qualquer manipulação de dados necessária após a movimentação de dados ter sido concluída com êxito, nem inclui qualquer manipulação de dados associada a qualquer outra movimentação de dados.
Exclusividade da movimentação de dados e possíveis exceções
Regras
NB: Todas as regras COSMIC dizem respeito a tipos de usuários funcionais, grupos de dados, movimentos de dados, processos funcionais e objetos de interesse. Para facilitar a leitura, normalmente omitimos “tipo” destes termos. Esta convenção é seguida nas regras a), b) e c) abaixo, mas na regra d) incluímos 'tipo' onde é útil distinguir um 'tipo' de uma 'ocorrência'.
a) A menos que os Requisitos Funcionais do Usuário sejam os indicados nas regras b) ou c), todos os dados que descrevem qualquer objeto de interesse que deva ser inserido em um processo funcional deverão ser identificados como um grupo de dados movido por uma Entrada.
NOTA: Um processo funcional pode, é claro, ter múltiplas entradas, cada uma movendo dados descrevendo um objeto de interesse diferente.
A mesma regra equivalente se aplica a qualquer movimentação de dados de leitura, gravação ou saída em qualquer processo funcional.
b) Se os Requisitos Funcionais do Usuário especificarem que diferentes grupos de dados devem ser inseridos em um processo funcional, cada um de um usuário funcional diferente, onde cada grupo de dados descreve o mesmo objeto de interesse, então uma Entrada deverá ser identificada para cada um desses diferentes grupos de dados.
A mesma regra equivalente se aplica a saídas de dados para diferentes usuários funcionais de qualquer processo funcional.
NOTA: Qualquer processo funcional deve ter apenas uma entrada de acionamento.
c) Se os Requisitos Funcionais do Usuário especificarem que diferentes grupos de dados devem ser movidos do armazenamento persistente para um processo funcional, cada um descrevendo o mesmo objeto de interesse, então uma Leitura deverá ser identificada para cada um desses diferentes grupos de dados.
A mesma regra equivalente se aplica a gravações em qualquer processo funcional.
NOTA: Esta regra é análoga à regra b). No caso do FUR ler diferentes grupos de dados que descrevem o mesmo objeto de interesse, eles provavelmente serão originados de diferentes usuários funcionais. No caso do FUR escrever diferentes grupos de dados, eles provavelmente serão disponibilizados para serem lidos por diferentes usuários funcionais.
d) Não serão contabilizadas ocorrências repetidas de qualquer tipo de movimentação de dados quando esta estiver sendo executada.
Isso se aplica mesmo se diversas ocorrências do tipo de movimentação de dados diferirem em sua execução porque diferentes valores dos atributos de dados do grupo de dados movido resultam em diferentes caminhos de processamento seguidos através do tipo de processo funcional.
Mensagens de erro/confirmação e outras indicações de condições de erro
Regras
a) Uma saída deve ser identificada para contabilizar todos os tipos de mensagens de erro/confirmação emitidas por qualquer processo funcional do software sendo medido de todas as causas possíveis de acordo com seu FUR, por exemplo, sucessos ou falhas de: validação de dados inseridos ou para um chamada para recuperar dados ou torná-los persistentes, ou para a resposta de um serviço solicitado de outro software.
NOTA: Caso o RFU do processo funcional não exija a emissão de nenhum tipo de mensagem de erro/confirmação, não identifique nenhuma Saída correspondente.
b) Se uma mensagem para um usuário funcional humano fornecer dados além de confirmar que os dados inseridos foram aceitos ou que os dados inseridos estão errados, então esses dados adicionais deverão ser identificados como um grupo de dados movido por uma Saída da maneira normal , além do erro/confirmação Exit.
c) Todos os outros dados, emitidos ou recebidos pelo software que está sendo medido, de/para seus usuários funcionais de hardware ou software devem ser analisados de acordo com o FUR como Saídas ou Entradas respectivamente, de acordo com as regras normais do COSMIC, independentemente de o valores de dados indicam uma condição de erro.
d) Leituras e gravações são consideradas responsáveis por qualquer relatório associado de condições de erro. Portanto, nenhuma entrada no processo funcional que está sendo medido deverá ser identificada para qualquer indicação de erro recebida como resultado de uma leitura ou gravação de dados persistentes.
e) Nenhuma entrada ou saída será identificada para qualquer mensagem indicando uma condição de erro que possa ser emitida durante o uso do software que está sendo medido, mas que não precise ser processada de forma alguma pelo FUR desse software, por exemplo, uma mensagem de erro emitida por o sistema operacional.
Modificando uma movimentação de dados
Regras
a) Se uma movimentação de dados precisar ser modificada devido a uma alteração na manipulação de dados associada à movimentação de dados e/ou devido a uma alteração no número ou tipo de atributos no grupo de dados movido, um CFP alterado deverá ser medido, independentemente do número real de modificações na movimentação de dados.
b) Se um grupo de dados precisar ser modificado, os movimentos de dados que movem o grupo de dados modificado cuja funcionalidade não seja afetada pela modificação no grupo de dados não serão identificados como movimentos de dados alterados.
NOTA: Uma modificação em qualquer dado que apareça nas telas de entrada ou saída que não esteja relacionado a um objeto de interesse de um usuário funcional não deve ser identificada como um CFP alterado. (Veja a seção 3.3.3 para exemplos de tais dados.)
Tamanho do software funcionalmente alterado
Regra
Depois de alterar funcionalmente um software:
Novo tamanho total (software alterado) = Tamanho total antigo (software)
+ Tamanho Σ (movimentos de dados adicionados) – Tamanho Σ (movimentos de dados excluídos)
Manual de Medição, v4.0.2 Copyright © 2017
O dimensionamento COSMIC está em conformidade com o padrão internacional: ISO 19761:2011
Artigos recentes
Arquivo
- Abril 2024
- Dezembro 2023
- Novembro 2023
- Setembro 2023
- Agosto 2023
- Julho 2023
- Junho 2023
- Abril 2023
- Março 2023
- Janeiro 2023
- Dezembro 2022
- Novembro 2022
- Outubro 2022
- Setembro 2022
- Julho 2022
- Junho 2022
- Maio 2022
- Abril 2022
- Março 2022
- Fevereiro 2022
- Janeiro 2022
- Dezembro 2021
- Outubro 2021
- Junho 2021
- Maio 2021
- Abril 2021
- Março 2021
- Janeiro 2021
- Dezembro 2020
- Outubro 2020
- Setembro 2020
- Julho 2020
- Junho 2020
- Abril 2020
- Fevereiro 2020
- Janeiro 2020
- Dezembro 2019
- Novembro 2019
- Outubro 2019
- Setembro 2019
- Agosto 2019
- Julho 2019
- Junho 2019
- Maio 2019
- Março 2019
- Fevereiro 2019
- Janeiro 2019
- Dezembro 2018
- Novembro 2018
- Setembro 2018
- Agosto 2018
- Julho 2018
- Junho 2018
- Maio 2018
- Abril 2018
- Março 2018
- Janeiro 2018
- Dezembro 2017
- Novembro 2017
Comentários recentes