Professional Documents
Culture Documents
1386
ABSTRACT. WAEI/MSE: an instance of the WAE process for micro and small
software enterprises. In Micro and Small Enterprises (MSE) of software, there is usually
not a systematic software development process. One of the reasons is that these enterprises
consider the traditional processes extensive. Thus, these enterprises are usually classified in
level 1 of maturity of the CMMI (Capability Maturity Model Integration). The objective of
this paper is to present a proposal for a software development process, in order to aid
specifically MSEs that build Web software, to help them increase the capacity level of their
processes. The process was validated during its application in development of software with
the support of the Unoeste Web Coordination.
Key words: Web engineering, UML, CMMI, micro and small enterprises.
Modelagem de aplicações Web para micro e pequenas De forma geral, na Fase de Requisitos são
empresas descritos o domínio do projeto, as funções que o
Considerando os processos de software estudados, sistema realizará, as restrições do projeto e os
que aplicações Web exigem ciclos mais otimizados de recursos necessários para o desenvolvimento. Na
desenvolvimento (NORTON, 1999 apud Fase de Análise, as funcionalidades são descritas
PRESSMAN, 2002) e, ainda, considerando pesquisas detalhadamente, os recursos necessários e as
realizadas sobre a importância da documentação de restrições levantadas são analisados. A Fase de
software para o entendimento do domínio do negócio, Projeto utiliza os artefatos desenvolvidos nas fases
da implementação e da aplicação (ARISHOLM et al., anteriores para mostrar os detalhes internos do
2006), a WAEI/MSE procura ser enxuta inserindo sistema, de acordo com o comportamento do
somente os artefatos considerados de alta importância negócio requerido, mostrando, por exemplo, as
nas pesquisas para o entendimento dos domínios classes necessárias para cada funcionalidade. A Fase
anteriormente citados. O processo WAEI/MSE utiliza
de Implementação utiliza-se dos artefatos já
o processo WAE como metamodelo, uma vez que se
produzidos e de ferramentas para iniciar a
trata de um processo voltado especificamente para o
implementação do projeto. A Fase de Teste visa à
desenvolvimento de software Web. Entretanto,
realização de validações e testes com o intuito de
poderiam ter sido utilizados outros modelos de
processo, tal como o UP, ou até mesmo metodologias aumentar a confiabilidade do produto.
e diretrizes ágeis como o XP, integradas à instância. As próximas subseções descrevem cada fase do
Seguindo os mesmos princípios do WAE, a WAEI/MSE e o que deve ser realizado em cada uma
instância WAEI/MSE propõe um processo de delas. Para ilustrar a sua aplicação são mostrados os
desenvolvimento incremental, baseado em casos de artefatos produzidos em um estudo de caso
uso, e indica o desenvolvimento do protótipo do desenvolvido, que é apresentado parcialmente, por
produto. Essa instância consiste em cinco fases: uma questão de limitação de espaço, mas pode ser
Requisitos, Análise, Projeto, Implementação e Teste, encontrado na íntegra em http://www.din.uem.br/
apresentadas nas subseções a seguir. As atividades de ~teclopes.
cada fase são realizadas em paralelo pelas equipes de Fase de requisitos
UX e de projeto. A equipe de UX é responsável pelo
design gráfico que a aplicação deverá ter para A Fase de Requisitos inicia-se pela definição do
satisfazer as necessidades dos usuários finais, cujo escopo do sistema que deve abordar, em linhas gerais, o
objetivo é melhor acessibilidade e usabilidade do domínio no qual o sistema está inserido, os benefícios
sistema a ser desenvolvido (LARSEN; que o sistema trará e suas funcionalidades, sem
CONALLEN, 2002). Já a equipe de projeto é mencionar aspectos tecnológicos. Uma vez definido o
responsável por realizar a análise de negócio, escopo do sistema é necessário realizar a elicitação dos
requisitos funcionais e não-funcionais do sistema. requisitos necessários para o seu desenvolvimento. Essa
A Figura 2 ilustra os artefatos das fases do atividade é realizada pela equipe de projeto e permite o
processo WAEI/MSE por equipe. Assim como o desenvolvimento do documento de requisitos, descrito
WAE, para cada incremento, todas as fases são por meio de declarações das funcionalidades do sistema
executadas de forma sequencial, e a cada iteração são denominadas requisitos funcionais, das tecnologias
refinados os artefatos de cada fase até que cada um necessárias para a sua implementação e dos requisitos
não-funcionais. Sugere-se o padrão IEEE Standard
deles esteja conforme o desejado. Nesta figura, as
830-1998 (POSTON, 1985) como formato para o
setas indicam as dependências entre os artefatos.
Documento de Requisitos de Software.
É possível e recomendado incluir um estudo de
viabilidade técnica e econômica para o projeto neste
artefato. Na Figura 3, é apresentado um fragmento do
Documento de Requisitos do ConfSystem, um sistema
para controle administrativo e financeiro de uma
empresa de confecções, que é utilizado neste trabalho
de pesquisa para ilustrar vários outros artefatos.
Após elaborar o documento de requisitos, a
equipe de projeto deve desenvolver o diagrama de
caso de uso e suas descrições em alto nível,
Figura 2. Artefatos produzidos no processo WAEI/MSE. descrevendo, assim, as funcionalidades do sistema.
Acta Scientiarum. Technology Maringá, v. 31, n. 2, p. 141-149, 2009
144 Maracci et al.
Larman (2000) afirma que a descrição em alto nível duas sequências de eventos: a típica que descreve os
dos casos de uso deve possuir identificação, os atores eventos ocorridos quando o caso de uso é executado
participantes e uma descrição das ações dos atores e normalmente e as sequências alternativas que
respostas do sistema ao realizar o caso de uso. Na descrevem as possíveis exceções (LARMAN, 2000).
Figura 4, pode-se observar a descrição do caso de A Figura 5 ilustra este artefato para o Caso de Uso
uso Vender Produtos (à cima) e o diagrama de caso Vender Produtos.
de uso do ConfSystem (à baixo). O Diagrama de Classes de Análise é utilizado
Cadastros:
para mostrar as classes que poderão ser
Produtos: destina-se a cadastrar os produtos que serão fabricados e
vendidos pela empresa. Dados necessários: tipo do produto, descrição do
implementadas pelo sistema (Figura 6). Este
produto, tamanho, cor, modelo, quantidade, preço de venda, preço de custo, diagrama ilustra as classes sem informar os detalhes
margem de lucro, estoque mínimo e foto do produto.
que elas possuirão, como proposto por Larman
Movimentações:
Venda: registra as vendas realizadas aos clientes. Ocorre quando um cliente (2000). Dessa forma, as classes deste artefato são
efetua uma compra, confirma um orçamento previamente efetuado ou faz
um pedido. Sendo assim, o funcionário deverá informar os seguintes dados: consideradas conceitos do domínio e, por isso, não
orçamento, representante, pedido, cliente, data da venda, itens (quantidade,
valor unitário e valor total) e condição de pagamento. Para pagamento, à têm métodos.
vista deverá ser informada também a data do pagamento. O sistema deverá
atualizar o estoque de produtos, gerar contas a receber (no caso de
pagamento a prazo) e calcular a comissão do representante, gerando uma Caso de Uso: Vender Produtos
conta a pagar. Atores: Cliente, Usuário
Relatórios: Sequência Típica de Eventos Resposta do Sistema
Pessoas em débito: o relatório informará quais são os clientes que estão em 1 Este caso de uso inicia quando o
débito com a empresa. Para tanto, é necessário informar uma data de início cliente informa seus dados pessoais
e término para a pesquisa que exibirá o nome do cliente, telefone, fatura, ao funcionário da empresa.(usuário).
data do vencimento e valor total dos débitos. 2 Cliente confirma os dados.
3 Sistema busca e mostra os dados
do cliente.
Figura 3. Exemplo parcial do documento de requisitos do 4 Sistema redireciona para a página
ConfSystem. de itens de venda.
5 Para cada produto que deseja
adquirir, o Usuário informa os dados e
Caso de uso: Vender Produtos. confirma a inclusão do item.
Atores: Clientes, Usuário. 6 Para cada produto confirmado, o
Descrição: O Cliente informa os dados pessoais e dos produtos que deseja adquirir. O Sistema verifica a quantidade
usuário deve informar ao sistema cada produto e a respectiva quantidade desejada. Quando disponível.
terminar o registro dos produtos , o sistema deverá informar o total da venda e as opções de 7 Usuário confirma o final da inclusão
pagamento. O usuário seleciona a opção de pagamento e, com a venda confirmada, o sistema de produtos.
deverá imprimir a nota fiscal de venda.
8 Sistema redireciona para a página
de opções de pagamento e informa o
total da venda.
9 Usuário seleciona e confirma a
Exibir Movimento de Caixa opção desejada pelo cliente.
Efetuar Pedido 10 Sistema registra a venda com suas
Usuário Representante
parcelas e imprime a nota fiscal.
Fase de análise
A Fase de Análise refina os artefatos produzidos
anteriormente com o intuito de detalhar o Figura 6. Diagrama de classes de análise (parcial).
comportamento esperado do software. Nesta fase, os
artefatos produzidos pela equipe de projeto são: O Layout do Sistema é constituído por
Descrição Expandida dos Casos de Uso, Diagrama representações gráficas das páginas Web,
de Classes de Análise. A equipe de UX desenvolve o construídas pela equipe de UX, que, reunidas,
Layout do Sistema e o Mapa de Navegação. constituirão a interface do sistema. Este layout
As descrições Alto Nível dos Casos de Uso auxilia as partes interessadas a compreenderem
realizadas na Fase de Requisitos agora são detalhadas melhor o projeto e a identificarem falhas ou
e denominadas de Descrição Expandida de Caso de características ainda não observadas. No
Uso. Este modelo de descrição é estruturado em desenvolvimento do layout, deve-se aplicar testes
O Layout Final do Sistema representa, por meio sequência explicitada no Mapa de Navegação e
de imagens, o design gráfico final do sistema, depois Diagrama de Sequência, ou seja, a relação entre os
de aprovado pelo cliente. Para tanto, devem ser arquivos html, css e php.
detalhados, quando necessário, as fontes, tamanhos,
cores e outros atributos necessários à construção do Fase de implementação
software. No desenvolvimento de um software Web, ainda
A Fase de Implementação inicia-se após o que o escopo seja pequeno, a quantidade de arquivos
término da Fase de Projeto e os artefatos produzidos produzida é relativamente grande. A documentação
são: Diagrama de Componentes e Comentários em do inter-relacionamento destes arquivos é um ponto
Código Fonte. forte proposto pelos artefatos produzidos nesta fase.
Os Diagramas de Componentes são utilizados A Figura 10 ilustra um Diagrama de Componentes
neste processo com o intuito de representar a relação para o caso de uso Cadastrar Produto, em que são
entre os arquivos client script, server script e class que um apresentados os arquivos de conexão com o banco de
caso de uso implementa e utiliza. As dependências
dados (Conexao.php e CBanco.php), arquivos para
representam a utilização de um arquivo pelo outro.
efetivação do cadastro (CadastrodeProduto.php,
O estereótipo <<implements>> indica que um
GravaProduto.php, ExcluiProduto.php e
determinado arquivo implementa as classes ligadas a
ele. Quando, na modelagem de um sistema, o ConProduto.php) e o arquivo que implementa as
Diagrama de Componentes tiver muitos arquivos, é classes (Cproduto.php). O arquivo Conexao.php
aconselhável utilizar vários Diagramas de realiza a conexão com o banco de dados e o arquivo
Componentes parciais ou pacotes (por exemplo, um Cbanco.php é responsável por implementar a classe
diagrama de componentes por pacote de classes). Banco que realiza as operações de SQL no banco de
Este diagrama também contempla a navegação entre dados. A representação proposta não apresenta o
os arquivos de sistema, dando continuidade à mesmo conceito de componentes da UML.
Os Comentários em Código Fonte são Contudo, para sistemas mais complexos, as equipes
recomendados pelo processo WAEI/MSE, pois são de desenvolvimento podem optar por incluir o
considerados muito importantes para entendimento documento de arquitetura no processo WAEI/MSE.
posterior, objetivando a evolução do sistema, A Tabela 1 apresenta a comparação entre os artefatos
implementação de mudanças e manutenções. É produzidos pelo WAE e pela sua instância.
necessário comentar classes, métodos, atributos,
laços e funções que sejam de difícil compreensão, ou Tabela 1. Comparação dos artefatos produzidos em WAE e
WAEI/MSE.
cujo objetivo não seja claramente entendido.
WAE WAEI/MSE
Fase de teste Conjuntos Artefatos Artefatos Fases
Gerenciamento Plano de Gerenciamento Escopo Fase de
O processo WAEI/MSE recomenda que de Projeto de Alteração Doc. de Requisitos Requisitos
Plano de Projeto Diag. de Casos de
atividades de verificação, validação e teste (VV&T) Plano de Iteração Uso
sejam realizadas durante todo o ciclo de vida do Conjunto Glossário Descrição Alto
software. Especificamente, foi introduzida uma Fase de Domínio Modelo de Domínio Nível dos
Conjunto Visão Casos de Uso
de Teste na qual devem ser conduzidas estas de Requisitos Diretrizes de Experiência
atividades. do Usuário
Casos de Uso e
Colanzi (1999) apud Maldonado et al. (2007) e Especificações
Vincenzi et al. (2003) afirmam que as atividades de Diagrama de Sequência
Diagrama de Atividades
teste de software devem acontecer em níveis Conjunto Doc. de Arquitetura de Descrição Fase de
diferentes, verificando primeiramente as unidades de Análise Software Expandida dos Análise
Protótipo de Arquitetura Casos de Uso
do software, posteriormente a integração do software Diagrama de Sequência Diag. de Classes de
e, finalmente, o teste de sistema que direciona os Classe de Análise Análise
Diagrama de Estado Layout do Sistema
esforços de teste para quando o software já está Roteiro Mapa de Navegação
totalmente integrado, identificando erros e Diagrama de Colaboração
Conjunto Classe de Projeto Diagrama de Fase de
características que estejam contra a especificação do de Projeto Página Web Sequência Projeto
sistema. Recomenda-se, adicionalmente, a aplicação Diag. de Classes de
do teste de aceitação conduzido com o usuário final. Projeto
Layout Final do
No processo WAEI/MSE, a Fase de Teste deve Sistema
iniciar com a definição do plano de teste a ser Conjunto de Código-Fonte Diag. de Fase de
Implementação Componente Binário Componentes Implementa-
aplicado, no qual devem estar mencionados os casos Página Web com Script Comentários em ção
de teste a serem realizados, os objetivos a serem Código Fonte
alcançados, como e quando realizá-los. Após a Conjunto Plano e Procedimento de Plano de Teste Fase de Teste
de Teste Teste Relatório dos Testes
realização de cada caso de teste, deve ser Script de Teste
desenvolvido um relatório do teste realizado. O Resultados de Teste
Conjunto de Plano de Implantação Não-existente
processo WAEI/MSE, porém, não enfatiza quais os Implantação Componente Binário
tipos de atividades de VV&T a serem realizados. Arquivos de Implantação
organizações que utilizaram o processo destacaram JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The
que, dentre as principais colaborações do unified process (Reprinted from The Unified Software
WAEI/MSE para a melhoria do processo de Development Process). IEEE Software, v. 16, n. 3, p. 96,
desenvolvimento de software da organização, estão: 1999.
o melhor controle das atividades e do cronograma LARMAN, C. Utilizando UML e padrões: uma
do projeto e a maior facilidade de entendimento do introdução a análise e projeto orientados a objetos. Porto
Alegre: Bookman, 2000.
processo e dos artefatos produzidos, o que
influenciou positivamente no momento de realizar LARSEN, G.; CONALLEN, J. Engineering web-based
systems with UML assets. Annals of Software
as manutenções. Observa-se, ainda, que os pontos
Engineering, v. 13, n. 1-4, p. 203-230, 2002.
fortes apresentados na seção anterior sobressaem aos
MALDONADO, J. C.; DELAMARO, M. E.; JINO, M.
pontos fracos, de acordo com as organizações
Introdução ao teste de software. Rio de Janeiro:
envolvidas; quanto aos pontos fracos, pesquisas estão Campus, 2007.
sendo realizadas para a melhoria das características
POSTON, R. M. Preventing software requirements
apontadas por estas organizações. As organizações specification errors with IEEE-830. IEEE Software, v. 2,
destacaram que continuarão a utilizar o WAEI/MSE n. 1, p. 83-86, 1985.
para o desenvolvimento de seus projetos. PRESSMAN, R. S. Engenharia de software. 5. ed. Rio
Finalmente, esta pesquisa contribuiu para o de Janeiro: McGraw-Hill, 2002.
desenvolvimento tecnológico científico e para que VINCENZI, A. M. R.; MALDONADO, J. C.;
novas pesquisas sejam realizadas, tendo como base DELAMARO, M. E.; SPOTO, E. S.; WONG, W. E.
os resultados obtidos. Component-based software: an overview of testing. In:
CECHICH, A.; PIATTINI, M.; VALLECILLO, A. (Ed.).
Referências
Referências Component-based software quality: methods and
techniques. Heidelberg: Springer, 2003. p. 99-127. (Series
ARISHOLM, E.; BRIAND, L. C.; HOVE, S. E. The Lecture Notes in Computer Science, v. 2693).
impact of UML documentation on software maintenance:
YOO, C.; YOON, J.; LEE, B. A Unified model for
an experimental evaluation. IEEE Transactions on
implementation of both ISO 9001: 2000 and CMMI by
Software Engineering, v. 32, n. 6, p. 365-381, 2006.
ISO-certified organizations. Journal of Systems and
BECK, K. Extreme programming: a humanistic discipline Software, v. 79, n. 7, p. 954-961, 2006.
of software development. Fundamental Approaches to
Software Engineering, v. 1382, p. 1-6, 1998.
CONALLEN, J. Building Web Applications with
Received on March 25, 2008.
UML. 2. ed. [s/l]: Addison-Wesley, 2002. Accepted on July 3, 2008.
HABRA, N.; ALEXANDRE, S.; DESHARNAIS, J. M.;
LAPORTE, C. Y.; RENAULT, A. Initiating software
improvement in very small enterprises – Experience with
License information: This is an open-access article distributed under the terms of the
a light assessment tool. Information and Software Creative Commons Attribution License, which permits unrestricted use, distribution,
Technology, v. 50, n. 7-8, p. 763-771, 2008. and reproduction in any medium, provided the original work is properly cited.