{dvkozak, fborto, henri, marcoa}@{rla01.pucpr.br}

Departamento de Informática

LAMI, Laboratório de Mídias Interativas

PUC PR, Pontifícia Universidade Católica do Paraná

Rua Imaculada Conceição, 1155 – 80215-901 – Curitiba – PR

Este artigo traz uma proposta de metodologia para desenvolvimento de aplicativos multimídia para treinamento baseado em computador focada nos conceitos de qualidade para desenvolvimento de software. Dentro desse contexto foi identificado um ciclo de vida para este tipo de aplicativo, e a partir deste foi detalhada uma seqüência de atividades a serem seguidas durante o processo de desenvolvimento, contemplando produtos intermediários do processo e a documentação pertinente. Também foram feitas considerações sobre as particularidades do desenvolvimento envolvendo recursos multimídia.

This article presents a proposal of a methodology for the development of multimedia applications for computer based training based on quality concepts for software development. A life cycle was identified for this kind of application, from which was derived a schedule of activities to be followed during the development process, taking into account intermediate products and related documentation. Comments concerning specific points on development using multimedia resources were also made.

1. Introdução

O sucesso de um aplicativo computacional é reflexo imediato da qualidade do seu processo de desenvolvimento, que pode ser uma tarefa construtiva e organizada, bem como pode ser um caos de papéis e pessoas, culminando com inúmeros problemas no produto final. O desenvolvimento de sistemas multimídia conta ainda com atributos de subjetividade, inerentes às tarefas de design dos recursos de mídia utilizados, que adiciona a este quadro algumas variáveis particulares.

Neste sentido, as algumas perguntas são pertinentes (cf. Pressman, 1992) e freqüentemente repetidas:

• Por que os programas levam tanto tempo para serem concluídos?
• Por que os custos são tão elevados?
• Por que não se consegue encontrar todos os erros antes de entregar o aplicativo para o usuário?
• Por que se tem dificuldade em se medir o progresso enquanto o aplicativo é desenvolvido?

As respostas a estas questões podem ser várias, e certamente algumas não são óbvias, porém certamente parte significativa delas passa pela identificação da necessidade de se adotar práticas formais de trabalho, como a utilização de uma metodologia de desenvolvimento, associada a uma metodologia de gerenciamento de projeto e um programa de qualidade/métricas.

Tendo isso em vista, nesse artigo é apresentada uma metodologia de desenvolvimento para aplicativos CBT (Computer Based Training - aplicativos para treinamento baseado em computador), ou simplesmente CBT. Esta metodologia tem sido aplicada a projetos desenvolvidos no LAMI, apresentando os efeitos desejados e esperados: melhor planejamento, menor desvio de cronograma / prazos / custos e melhor qualidade do produto final.

1. O Aspecto da Qualidade

A preocupação com a qualidade, tanto do produto quanto do processo que o produz, deve ter como meta a criação de mecanismos que possibilitem que este aspecto se realize a contento. O estabelecimento de um processo de desenvolvimento com atividades e etapas bem definidas, cada uma com suas entradas e produtos especificados e responsabilidades atribuídas, juntamente com marcos para controle do projeto e manutenção da documentação associada, constitui uma metodologia de desenvolvimento. A aplicação desta metodologia é um dos principais mecanismos para se realizar o conceito da qualidade.

Figura 1: Sistema de desenvolvimento de aplicativos multimídia focando a garantia da qualidade (cf. Weinberg, 1994).

Por se tratar de desenvolvimento de software, as normas de qualidade pertinentes, como a ISO-9000/3 (NBR ISO 9000-3, 1993) e a ISO-9126 (NBR ISO/IEC 9126, 1994), devem nortear a construção de tal metodologia de desenvolvimento.

Deve ser lembrado que o desenvolvimento de CBTs possui certas características distintas do processo tradicional de desenvolvimento de software, associadas justamente à produção das diversas mídias (som, imagens, vídeos) que são incorporadas ao produto. Para que a garantia de qualidade pretendida seja alcançada, medições relativas ao processo de desenvolvimento, aos produtos e ao planejamento e condução do projeto necessitam ser realizadas (Figura 1). Isto envolve não só aspectos de engenharia de software, como também os aspectos associados ao processo de criação das diversas mídias, onde arte e inspiração são relevantes, porém bastante subjetivos e de mensuração complexa e difícil, estabelecendo um outro grande desafio: que métricas utilizar para a produção de mídias ?

2. Ciclo de Vida

Para especificar uma metodologia de desenvolvimento de CBTs tendo em vista o processo da qualidade, é necessário que se considere a seqüência básica de atividades envolvidas em seu desenvolvimento. Partindo deste princípio, identificou-se um ciclo de vida  para CBTs, conforme mostrado na Figura 2, cujas etapas estão descritas abaixo:

• Especificação de requisitos: identificação e documentação das necessidades do usuário do CBT.
• Planejamento do Desenvolvimento: definição de um plano de desenvolvimento conforme a metodologia de desenvolvimento adotada.
• Projeto: levantamento e especificação detalhada do aplicativo.
• Implementação: programação e geração dos recursos multimídia conforme especificação detalhada.
• Validação: revisões dos programas e testes do aplicativo pelo usuário.
• Entrega e Aceitação: entrega, instalação e aceitação do aplicativo pelo usuário.
• Manutenção/Descarte: melhoria e adaptação do aplicativo a novas necessidades, e descarte ("morte") do produto.

É preciso observar que o ciclo de vida apresentado deve ser constantemente confrontado com a evolução real do processo de desenvolvimento para confirmar a consecução, na prática, da seqüência identificada. Adaptações devem ser consideradas se o contexto assim exigir.

Além disso, não se deve confundir a técnica ou método utilizado para a especificação e construção do aplicativo (como a metodologia RMM (Isakowits, 1995)) com a metodologia de desenvolvimento ou ciclo de vida. Deve ser possível aplicar a metodologia de desenvolvimento com certa independência da técnica utilizada. Como exemplo, na fase de análise de um projeto de software, podem ser empregadas técnicas de orientação à objeto ou técnicas estruturadas, porém a fase da metodologia continua a mesma: análise. O que pode mudar são alguns dos produtos da fase em questão, adequados a esta ou aquela técnica.

O desenvolvimento do CBT ocorre no contexto de projeto dentro do ciclo de vida, conforme mostrado Figura 2. Deste modo, a metodologia de desenvolvimento é estruturada a partir deste conjunto de atividades principais.

1. Metodologia de Desenvolvimento

Dentro do contexto de projeto do ciclo de vida, a metodologia de desenvolvimento contempla duas fases principais de projeto: a Definição do Projeto (Fase I) e o Desenvolvimento (Fase II).

1. Definição do Projeto

Na fase de Definição do Projeto, detalhada na Figura 3, existe um evento inicial (Reunião de Início de Projeto) para estabelecer as primeiras diretrizes. A partir daí são levantadas as necessidades do usuário, que levam à definição do projeto. Os requisitos identificados e o escopo do projeto são registrados no Documento de Especificação de Requisitos (DERq ). Este documento, juntamente com uma metodologia definida, permite estabelecer o plano de desenvolvimento do CBT.

O DERq e o Plano de Desenvolvimento são os produtos principais desta fase. Convém observar que são previstos alguns pontos de controle (milestones) além da Reunião de Início do Projeto, que são maneiras de garantir a verificação dos produtos das respectivas atividades, garantindo a qualidade dos mesmos.

2. Desenvolvimento

Na fase de Desenvolvimento, detalhada na Figura 4, ocorre o processo de geração do aplicativo. Cada atividade intermediária gera algum tipo de produto, e pontos de controle também são previstos ao final de cada atividade principal, juntamente com algumas revisões do plano de desenvolvimento, necessárias quando se está tratando de projetos maiores e mais complexos. A consistência do processo de desenvolvimento nesta fase é garantida pelo Documento de Especificação de Projeto (DESP), que mantém todas as informações necessárias para o desenvolvimento do CBT, sendo a principal referência de projeto nesta fase.

Os principais produtos intermediários, e a seqüência em que são gerados, são mostrados na Figura 5. Como já mencionado, dos produtos gerados, dois têm importância central na metodologia: o Documento de Especificação de Requisitos (DERq) e o Documento de Especificação de Projeto (DESP) - ditos Documentos de Especificação.

 

Figura 3: Fase de Definição de Projeto.

2. Documentos de Especificação
1. Documento de Especificação de Requisitos - DERq

O modelo adotado para este documento é baseado nas recomendações das normas ISO-9000/3 (NBR ISO 9000-3, 1993) e ISO-9126 (NBR ISO/IEC 9126, 1994). O objetivo é fazer uma cobertura, o mais abrangente possível, de todos os aspectos envolvidos na especificação do que é o produto, como é a sua estrutura básica, o seu perfil de conteúdo e os requisitos associados ao ambiente operacional, entre outros. O conteúdo básico do DERq está mostrado na Figura 6 . Esse documento pode sofrer alguma adaptação conforme o tipo de aplicativo a ser desenvolvido, mas os itens mostrados nesta figura formam a espinha dorsal do documento.

O seu principal objetivo é estabelecer da melhor maneira possível o escopo do projeto, sendo uma referência importante tanto para o usuário como para o desenvolvedor, e também de grande auxílio na administração de conflitos, devendo ser mantido atualizado ao longo do projeto.

Figura 4: Fase de Desenvolvimento.

 

Figura 5: Seqüência de geração dos principais produtos do processo de desenvolvimento.

 

Objetivo Visão Geral Propósito Descrição Sucinta Público Alvo Especificação Estrutura Básica – Perfil do Conteúdo Descrição do Aplicativo Ambiente Operacional Hardware Software Desempenho Características de Qualidade de Software  Nível de Desempenho Segurança Riscos Privacidade Interfaces Com Outros Produtos de Software Com Outros Hardwares

Figura 6: Principais itens do DERq.

2. Documento de Especificação de Projeto - DESP

Este documento é o alicerce de todo o processo de desenvolvimento, contendo todas as definições e indicações para que os diversos programas e recursos utilizados na construção do aplicativo sejam gerados.

Conforme o modelo mostrado neste trabalho, o DESP se constitui na especificação de como o produto será construído no que se refere a seu conteúdo e sua estrutura. Quanto ao aspecto de navegação, a seqüência em que as seções e tópicos estão escritos neste documento pode ser utilizada para definir uma seqüência linear para a apresentação do CBT, ou então a navegação pode seguir a estrutura hierárquica sugerida no documento. A utilização de uma metodologia como a RMM (cf. Isakowits, 1995) pode ser útil neste ponto caso se pretenda especificar uma estrutura de navegação mais elaborada.

Para a construção do DESP foi estabelecido um modelo de dados que contemplasse o conjunto de informações que este documento deve conter, suficiente para a confecção do aplicativo. Este modelo está representado na Figura 7.

 

Figura 7: Modelo de dados definindo a estrutura de informações contidas no Documento de Especificação de Projeto - DESP.

Conforme mostrado no modelo da dados, um CBT tem uma ou mais seções, cada uma composta por um ou mais tópicos. Estes, por sua vez, podem ter subtópicos, que também podem ter subtópicos, e assim por diante. Cada tópico ou subtópico contém um ou mais quadros que descrevem a apresentação e a funcionalidade do aplicativo. Estes quadros, cada um tendo um objetivo específico, podem estar associados a referências (fontes de informações) e/ou utilizar recursos (mídias). Estes recursos podem, por sua vez, ser implementados a partir das informações contidas nas referências.

Na Figura 8 temos um exemplo genérico de um trecho do DESP definido segundo a estrutura mostrada no modelo de dados.

Seção [m] <Título da Seção>
Descrição: <Descrição sucinta da seção >
:
Tópico (n) <Título do Tópico> (Seção [m] < título da seção >)
	Objetivo: <objetivo do quadro – justificativa da sua inclusão> Título: <título do quadro> Texto: <texto incluso no quadro e nas suas figuras> Imagem: <especificação da imagem contida no quadro> Animação: <especificação da animação a ser incluída> Som: <especificação dos sons a serem incluídos> Locução: <definição se há ou não locução no quadro> Vídeo: <especificação dos vídeos a serem incluídos> Referências: <fontes de informação utilizadas para construir o quadro> Recurso: < recursos (já existentes) a serem utilizados: sons, imagens, vídeo, etc..> Navegação: <como será feita a navegação deste quadro para outros> Observação: <qualquer observação adicional>
Figura 8: Trecho do Documento de Especificação de Projeto – DESP.

3. Considerações Finais

A metodologia apresentada vem sendo aplicada no desenvolvimento de aplicativos CBT no LAMI, sendo que a cada projeto concluído esta proposta é atualizada e complementada, espelhando o caráter dinâmico do desenvolvimento em multimídia e também o melhor entendimento do processo de desenvolvimento. A complexidade na especificação de produtos multimídia, bem como a constante atualização das ferramentas de criação gráfica e dos programas de autoria têm reflexo imediato na exigência da qualidade dos documentos de projeto e na gerência deste documentos. Diante deste fato, as metodologias de apoio devem ser alvo constante de revisões a atualizações.

Não só a existência de metodologias, mas a conscientização de sua necessidade junto aos envolvidos no processo de desenvolvimento e o comprometimento da equipe de trabalho são fundamentais na busca da qualidade do processo e, conseqüentemente, do produto. Sem esse envolvimento, qualquer metodologia, por melhor que seja, pode transformar-se num processo burocrático, cumprida pelo simples fato de ter de ser cumprida, perdendo seu objetivo.

4. Referências Bibliográficas

Fernandes, A. A (1995). Gerência de Software Através de Métricas. São Paulo: Editora Atlas S.A.

Isakowits, Tomás; Stohr, Edward A. e Balasubrmanian, P. (1995). RMM: A Methodology for Structured Hypermedia Design. (http://www.stern.nyu.edu/~tisakowi/rmm/)

NBR ISO 9000-3 (1993). Normas de gestão da qualidade e garantia da qualidade - Parte 3: Diretrizes para a aplicação da NBR 19001 ao desenvolvimento, fornecimento e manutenção de software.

NBR ISO/IEC 9126 (1994). Tecnologia de informação - Avaliação de produto de software - Características de qualidade e diretrizes para o seu uso.

Weinberg, G. M. (1994). Software com Qualidade Volume 2 - Medidas de Primeira Ordem. São Paulo: Makron Books do Brasil.