Pim 5 unip interativa

...

Todo dado relativo a outro dado é chamado de metadados. No exemplo anterior do ano 2001 o dado “Ano do atendado terrorista às torres gêmeas” é um metadado, pois ele é um dado sobre o dado “2001”. Um outro exemplo mais comum em banco de dados: o campo telefone da tabela cliente tem, entre outros, os seguinte metadados: nome (telefone), tipo (texto), tamanho (30 caracteres), obrigatoriedade (não), etc.

Um banco de dados é formado por dado e metadados. Sem os metadados não seria possível organizar e extrair informações de um banco de dados.

Engenharia de Software

O levantamento de Requisitos de Software

O início para toda a atividade de desenvolvimento de software é o levantamento de requisitos, sendo esta atividade repetida em todas as demais etapas da engenharia de requisitos.

Sommerville (2003) propõe um processo genérico de levantamento e análise que contém as seguintes atividades:

- Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;

- Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;

- Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;

- Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;

- Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;

- Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra, conforme exemplificado pela

Figura 1.

Figura 1. Processo de levantamento e análise de requisitos (SOMMERVILLE, 2003)

Dificuldades encontradas

O problema de não saber especificar corretamente o que o sistema deverá fazer é muito antigo. Pompilho (1995) cita um exemplo do relatório produzido por McKinsey, em 1968, e mencionado por B. Langefords e B. Sundgren onde se afirmava que dois terços das empresas ali estudadas estavam desapontadas com o atendimento recebido em sistemas de informação.

Após mais de 30 anos da elaboração do relatório a situação não é muito diferente. Algumas das razões para o baixo grau de satisfação dos usuários para os sistemas destacam-se:

- Na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema;

- A falha do analista em não descrever os requisitos do sistema de modo claro, sem ambigüidades, conciso e consistente com todos os aspectos significativos do sistema proposto.

Entre as dificuldades encontradas na fase de levantamento de requisitos estão: o usuário principal do sistema não sabe o que quer que o sistema faça ou sabe e não consegue transmitir para o analista; requisitos identificados, mas que não são realistas e não identificam os requisitos similares informados por pessoas diferentes. Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema.

Identifica-se um levantamento de requisitos adequado através da boa definição do projeto, da efetividade do projeto, de informações necessárias a um perfeito diagnóstico e de soluções inteligentes. Quanto ao levantamento de requisitos inadequado, o resultado é um diagnóstico pobre com conclusões comprometidas, não identificação das causas dos problemas, custos elevados, prazos vencidos ou comprometedores, omissão de processos fundamentais e descréditos.

Qualidade do Software

Qualidade hoje em dia, não é apenas um diferencial de mercado para a empresa conseguir vender e lucrar mais, é um pré requisito que a empresa deve conquistar para conseguir colocar o produto no Mercado Global. Na área de software, há uma urgente necessidade de uma maior preocupação sobre o tema, mas afinal, o que é qualidade?Existem diversas definições. Algumas pessoas que tentaram uma definição simples chegaram a frases como:

- Qualidade é estar em conformidade com os requisitos dos clientes

- Qualidade é antecipar e satisfazer os desejos dos clientes

- Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito

Segunda a atual norma brasileira sobre o assunto (NBR ISO 8402), qualidade é:

A totalidade das características de uma entidade

que lhe confere a capacidade de satisfazer

às necessidades explícitas e implícitas

Nota-se que esta definição formal exige alguns complementos, principalmente para definir o que são as entidades, asnecessidades explícitas e as necessidades implícitas.

- A entidade é o produto do qual estamos falando, que pode ser um bem ou um serviço.

- As necessidades explícitas são as próprias condições e objetivos propostos pelo produtor.

- As necessidades implícitas incluem as diferenças entre os usuários, a evolução no tempo, as implicações éticas, as questões de segurança e outras visões subjetivas.

Por exemplo, a qualidade de um prato de comida (a entidade, o produto) está relacionada com a satisfação de necessidades (requisitos) tais como: sabor, aparência, temperatura, rapidez no serviço, preço, higiene, valor nutricional, etc... Para avaliar a qualidade de um produto, deve-se fazer uma lista destas necessidades e analisar cada uma destas necessidades.

Proposições da qualidade de software:

- Qualidade é o