GALBER PORTELA DA COSTA ALMEIDA GRAZIELA GÖEDERT DE SOUZA
ESTUDO DE ENGENHARIA DE SOFTWARE E MÉTODOS PARA WEB, COM APLICAÇÃO NO DESENVOLVIMENTO DE UM PROTÓTIPO
PALHOÇA 2009
GALBER PORTELA DA COSTA ALMEIDA GRAZIELA GÖEDERT DE SOUZA
ESTUDO DE ENGENHARIA DE SOFTWARE E MÉTODOS PARA WEB, COM APLICAÇÃO NO DESENVOLVIMENTO DE UM PROTÓTIPO
Projeto de Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharelado em Ciência da Computação.
Orientador: Profª. Drª. Maria Inês Castiñeira.
Palhoça 2009
GALBER PORTELA DA COSTA ALMEIDA GRAZIELA GÖEDERT DE SOUZA
ESTUDO DE ENGENHARIA DE SOFTWARE E MÉTODOS PARA WEB, COM APLICAÇÃO NO DESENVOLVIMENTO DE UM PROTÓTIPO
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Ciência da Computação, da Universidade do Sul de Santa Catarina.
_____________, ______ de ____________________ de 2009 Local, dia mês ano
__________________________________________________ Profª. Drª. Maria Inés Castiñeira
Universidade do Sul de Santa Catarina – UNISUL
__________________________________________________ Profª. Msc. Vera Rejane Niedersberg Schuhmacher
Universidade do Sul de Santa Catarina - UNISUL
__________________________________________________ Prof. Dr. Engº. Aran Bey Tcholakian Morales
Dedico este trabalho às pessoas que foram e que são os maiores responsáveis pela minha formação acadêmica e apoiadores desta longa caminhada: meus pais, Marcos e Irlanda.
Galber Portela da Costa Almeida
Dedico este trabalho às pessoas que foram e que são os maiores responsáveis pela minha formação acadêmica e apoiadores desta longa caminhada: meus pais, Rudinei e Eliane.
AGRADECIMENTOS
Primeiramente agradecermos a Deus, por ter nos concedido a vida e a coragem. Temos certeza de que sempre esteve ao nosso lado.
As nossas famílias, pelos esforços nunca poupados, buscando sempre nos oferecer o melhor, pelo amor incondicional, presente em todas as horas e, principalmente, por terem sempre acreditado em nós. Merecedores de todo nosso afeto, pelo que fazem e pelo que são: dignos, trabalhadores e vitoriosos.
A nossa orientadora Profª. Dr. Maria Inês Castiñeira, pelos esforços empenhados em nos orientar sempre que possível e por sua disposição a cada encontro, fazendo de nossas dúvidas, certeza.
As pessoas especiais que sempre estiveram conosco e que, pela presença, pela palavra, pela atenção, ou pelo simples sorriso, nos deram coragem e determinação para traçar caminhos em busca de nossos ideais.
“Copiar a idéia de um autor é plágio, copiar a idéia de vários autores é monografia!” (Autor desconhecido)
RESUMO
Os objetivos deste trabalho foram identificar metodologias de Engenharia de Software específicas para web e selecionar uma dessas metodologias para aplicá-la no desenvolvimento de um protótipo. A primeira etapa foi o estudo das particularidades da engenharia de software para web. Os métodos OOHDM, OOWS, WAE e UWE foram estudados. Entre eles foi escolhido o método UWE para desenvolver a modelagem do protótipo. Um sistema, já existente, “Vale um Convite” foi analisado para obtenção dos requisitos. Na seqüência foi escolhida a ferramenta para realizar a modelagem: Magic Draw UWE. Sendo assim, foi realizada a modelagem de casos de uso e de banco de dados, Foram elaborados os modelos de navegação, de processamento e de apresentação, para por fim ser iniciado o desenvolvimento do protótipo. O aplicativo foi validado pela equipe, e por integrantes do público alvo. Além de aprofundar os conhecimentos em engenharia de software para web, necessitou-se aprender novas ferramentas, como o Magic Draw UWE para o desenvolvimento da modelagem. Esse processo foi de fácil entendimento devido à existência de diversos exemplos na literatura. A construção dos modelos de apresentação e de navegação mostraram-se muito eficientes pois auxiliam à equipe de desenvolvimento no planejamento do aplicativo.
Palavras-chave: Engenharia de Software Web. Métodos de desenvolvimento para web. UWE: UML Web Engineering.
LISTA DE ILUSTRAÇÕES
Figura 1: Classificações de aplicações baseadas na web. ... 22
Figura 2: Modelo de processo de desenvolvimento de aplicações Web. ... 26
Figura 3: Integração do processo criativo de design e o Rational Unified Process (RUP) ... 27
Figura 4: Modelo Cascata para Web. ... 28
Figura 5: Modelo evolutivo. ... 28
Figura 6: Modelo de desenvolvimento de aplicações Web. ... 29
Figura 7: Árvore de requisitos de qualidade. ... 36
Figura 8: Pirâmide de projeto da WebE. ... 39
Figura 9: Mapeamento dos Objetivos do usuário nas ações de interface. ... 45
Figura 10: Estruturas Lineares. ... 49
Figura 11: Estruturas em Malha. ... 50
Figura 12: Estruturas Hierárquicas. ... 51
Figura 13: Estrutura em Rede. ... 51
Figura 14: A arquitetura MVC. ... 52
Figura 15: Métodos de desenvolvimento web. ... 55
Figura 16: Resumo do método OOHDM ... 57
Figura 17: Processo do método UWE. ... 59
Figura 18: Abordagem do método OOWS. ... 60
Figura 19: Padrões de projetos para Web... 63
Figura 20: Representação das etapas metodológicas. ... 69
Figura 21: Representação da arquitetura do protótipo. ... 70
Figura 22: Imagem da tela com os estados e cidades do Vale um Convite. ... 71
Figura 23: Imagem da tela do vale um convite. ... 73
Figura 24: Imagem da tela com os dados básicos do usuário do vale um convite. ... 74
Figura 25: Imagem da tela de seleção de uma categoria de Quiz do vale um convite. ... 74
Figura 26: Imagem da tela das perguntas do Quiz do vale um convite. ... 75
Figura 27: Imagem da tela de devolução dos convites do vale um convite. ... 75
Figura 28: Imagem da tela dos parceiros do vale um convite. ... 76
Figura 29: Imagem da tela dos locais de entrega dos convites do vale um convite. ... 76
Figura 30: Imagem da tela da Agenda do vale um convite. ... 77
Figura 32: Diagrama estrutural do meta-modelo UWE ... 80
Figura 33: Diagrama de caso de uso do ator Visitante. ... 85
Figura 34: Diagrama de caso de uso do ator Usuário. ... 86
Figura 35: Diagrama de caso de uso do ator Apoio. ... 86
Figura 36: Diagrama de caso de uso do ator Administrador. ... 86
Figura 37: Diagrama Com. ... 102
Figura 38: Diagrama Entidades. ... 103
Figura 39: Diagrama Processa Quiz. ... 103
Figura 40: Diagrama Dao do Quiz. ... 104
Figura 41: Diagrama Consulta Troca. ... 105
Figura 42: Diagrama Converter Pontos... 106
Figura 43: Diagrama Entidade Relacionamento. ... 107
Figura 44: Diagrama do modelo de Navegação sem processamento. ... 108
Figura 45: Diagrama do modelo de Navegação com processamento. ... 109
Figura 46: Diagrama do modelo de Apresentação da Home, visão do administrador. ... 110
Figura 47: Diagrama do modelo de Apresentação da Home, visão do usuário. ... 111
Figura 48: Diagrama do modelo de Apresentação do Index. ... 112
Figura 49: Representação das tecnologias utilizadas. ... 114
Figura 50: Tela de login. ... 116
Figura 51: Tela de cadastro de usuário. ... 117
Figura 52: Tela do menu usuário. ... 117
Figura 53: Tela de quiz. ... 118
Figura 54: Tela de conversão. ... 118
Figura 55: Tela de parceiro. ... 119
LISTA DE QUADROS
Quadro 1: Elaboração do problema. ... 67
Quadro 2: Descrição caso de uso: Cadastro de usuário. ... 87
Quadro 3: Descrição caso de uso: Consultar eventos. ... 88
Quadro 4: Descrição caso de uso: Responder quiz. ... 89
Quadro 5: Descrição caso de uso: Trocar pontos. ... 90
Quadro 6: Descrição caso de uso: Emitir convite. ... 91
Quadro 7: Descrição caso de uso - controle apoio... 92
Quadro 8: Descrição caso de uso - controle parceiro... 93
Quadro 9: Descrição caso de uso - controle foto. ... 94
Quadro 10: Descrição caso de uso - controle agenda. ... 95
Quadro 11: Descrição caso de uso - controle quiz... 96
Quadro 12: Descrição caso de uso - controle pergunta. ... 97
Quadro 13: Descrição caso de uso – realizar multa. ... 98
Quadro 14: Descrição caso de uso – emitir convite. ... 99
Quadro 15: Descrição caso de uso – seja parceiro... 100
LISTA DE SIGLAS
CPF – Cadastro de pessoas físicas DDL – Data Definition Language ECO – Enterprise Core Objects HDM – Hypertext Design Model
HMBS/M – Hypertext Model Based on Statecharts IBGE – Instituto Brasileiro de Geografia e Estatística OMG – Object Management Group
OMT – Opal Mirror Tool
OO-H – Object-Oriented. Hypermidia
OOHDM – Object-Oriented. Hypermidia Design Method OOWS – Object-Oriented Web Solutions
Quiz – Jogo de perguntas e respostas
RMM – Relationship Management Methodology RUP – Rational Unified Process
SWM – Simple Web Markup UML - Unified Modeling Language UWE – UML-based Web Engineering
W2000 – UML Extension for Modeling Web Applications WAE – Web Application Extension
WebApp – Web Aplication WebE – Web Engineering
1 INTRODUÇÃO ...15 1.1 PROBLEMA ...16 1.2 OBJETIVOS ...16 1.2.1 Objetivo Geral ...16 1.2.2 Objetivos Específicos ...17 1.3 JUSTIFICATIVA ...17 1.4 ESTRUTURA DA MONOGRAFIA ...18 2 REFERENCIAL TEÓRICO...19 2.1 ENGENHARIA DE SOFTWARE ...19 2.2 ENGENHARIA DA WEB ...20
2.2.1 Tipos de Sistemas para Web ...21
2.2.2 Processos da Engenharia da Web ...23
2.2.3 Personagens ...24
2.2.4 Modelos de Desenvolvimento da Web ...25
2.3 MODELAGEMDEANÁLISEPARAAPLICAÇÕESWEB ...29
2.3.1 Análise de requisitos para WebApp ...29
2.3.2 Modelo de análise para WebApp ...30
2.3.3 O modelo de Conteúdo ...30
2.3.3.1 Definição dos Objetos de Conteúdo ...31
2.3.4 O modelo de interação ...31
2.3.5 O modelo funcional...32
2.3.6 O modelo de configuração ...32
2.3.7 Análise de relacionamento-navegação ...33
2.4 MODELAGEMDE PROJETO PARAAPLICAÇÕESWEB ...34
2.4.1 Tópicos de projetos para engenharia da web ...34
2.4.1.1 Projeto e qualidade da WebApp ...35
2.4.1.2 Características do Projeto ...37
2.4.2 A Pirâmide de Projeto da WebE ...38
2.4.3 Projeto de interface de WebApp ...40
2.4.3.1 Princípios e Diretrizes de Projeto de Interface ...40
2.4.3.2 Mecanismo de Controle de Interface ...43
2.4.4 Projeto Estético...45
2.4.4.1 Tópicos de Leiaute ...46
2.4.4.2 Tópicos de Projeto Gráfico ...47
2.4.5 Projeto de Conteúdo ...47
2.4.5.1 Objetos de Conteúdo ...47
2.4.5.2 Tópicos de Projeto de Conteúdo ...48
2.4.6 Projeto de Arquitetura ...48 2.4.6.1 Arquitetura de Conteúdo ...49 2.4.6.2 Arquitetura de WebApp ...52 2.4.7 Projeto de Navegação ...53 2.4.7.1 Semântica Navegacional ...53 2.4.7.2 Sintaxe Navegacional ...54
2.4.8 Projeto no Nível de Componente...54
2.5 MÉTODOS DE DESENVOLVIMENTO PARA APLICAÇÕES WEB ...54
2.5.1 Método OOHDM ...56
2.5.1.1 Projeto Conceitual para OOHDM ...56
2.5.1.2 Projeto Navegacional de OOHDM ...56
2.5.1.3 Projeto e Implementação de Interface Abstrata...57
2.5.2 Método UWE ...58
2.5.3 Método OOWS ...59
2.5.4 Método WAE ...61
2.6 PADRÕES DE PROJETO NO DESENVOLVIMENTO WEB ...62
2.7 MODELOS DE TESTES ...63
2.8 CONSIDERAÇÕES FINAIS DO CAPÍTULO ...65
3 METODOLOGIA ...66
3.1 CARACTERIZAÇÃO DA METODOLOGIA UTILIZADA ...66
3.2 ETAPAS METODOLÓGICAS ...68
3.3 ARQUITETURA DO PROTÓTIPO ...69
3.4 DELIMITAÇÕES DA PROPOSTA ...70
3.5 CONSIDERAÇÕES FINAIS SOBRE O CAPÍTULO ...70
4 ANÁLISE DE REQUISITOS E MÉTODO UWE ...71
4.1 APRESENTAÇÃO DO SISTEMA VALE UM CONVITE ...71
4.2 MÉTODO DE DESENVOLVIMENTO UTILIZADO ...77
4.3 MODELAGEM ...80
4.3.1 Levantamento de Requisitos ...80
4.3.1.2 Requisitos Funcionais ...81
4.3.1.3 Requisitos não Funcionais ...83
4.3.1.4 Regras de Negócio ...84
4.3.2 Modelagem de Casos de Uso ...85
4.3.2.1 Casos de uso ...85
4.3.3 Definição do modelo de conteúdo ... 102
4.3.3.1 Diagrama de Classes Pertinentes ... 102
4.3.3.2 Diagrama Entidade Relacionamento ... 106
4.3.4 Definição do modelo de navegação... 108
4.3.5 Definição do modelo de apresentação ... 109
4.4 CONSIDERAÇÕES FINAIS SOBRE O CAPÍTULO ... 112
5 DESENVOLVIMENTO, FERRAMENTAS, TECNOLOGIAS E VALIDAÇÃO ... 113
5.1 TECNOLOGIAS E FERRAMENTAS ... 113
5.2 DESCRIÇÃO DO PROCESSO DE DESENVOLVIMENTO ... 114
5.3 APRESENTAÇÃO DO PROTÓTIPO ... 115
5.4 VALIDAÇÃO DO PROTÓTIPO ... 120
5.4.1 Resultados da Validação pela Equipe ... 120
5.4.2 Resultados da Validação pelos usuários finais. ... 120
5.5 CONSIDERAÇÕESSOBREAMETODOLOGIA ... 121
5.6 CONSIDERAÇÕES FINAIS SOBRE O CAPÍTULO ... 122
6 CONCLUSÕES ... 123
1 INTRODUÇÃO
Vivemos em uma sociedade moderna. Segundo o IBGE (2006), no Brasil cerca de 21% da população possui acesso à internet e está ligado diretamente ou indiretamente a algum tipo de sistema web. Alguns desses sistemas apresentam inconsistências ou resultados difíceis de serem utilizados pelo usuário. Será que nesses casos o processo de desenvolvimento de sistemas foi realizado de forma apropriada? A disciplina que aborda sua problemática é chamada de engenharia de software.
Segundo Fritz Bauer (apud PRESSMAN 2006, p.17), “Engenharia de software é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais.”
A utilização de práticas de engenharia de software é claramente associada à intenção de economizar na manutenção e aumentar a eficiência, fazendo o que é esperado. Nada a mais nem a menos do que aquilo que foi planejado para ser realizado.
A manutenção de software é um importante problema para a maioria das empresas, de 50% a 80% do trabalho realizado na maior parte das organizações de desenvolvimento de sistemas estão associados à revisão, à modificação, à conversão, ao aperfeiçoamento ou à depuração de um programa que alguém escreveu tempos atrás. E esse é um trabalho caro. No princípio dos anos 70, o Departamento de Defesa dos EUA relatou que o custo de desenvolvimento de programas de processamento de um projeto atingia em média $75 por instrução e o custo da manutenção do sistema atingia $4000 por instrução. (YOURDON 2000 p.142).
Assim, a utilização de práticas de engenharia de software é importante para produzir software de qualidade e dentro dos prazos e custos estabelecidos. Será que o desenvolvimento de sistemas para web segue as mesmas diretrizes? A engenharia de software em sistemas web (WebE) não é completamente igual à engenharia de software, porém traz alguns princípios básicos iguais.
A WebE não é um clone perfeito da Engenharia de Software, mas toma emprestados muitos dos conceitos e princípios fundamentais da engenharia de software. Além disso, o processo WebE enfatiza atividades técnicas e de gestão similares. Há diferenças sutis no modo pelo qual essas atividades são conduzidas, mas a filosofia dominante determina uma abordagem disciplinada para o desenvolvimento de um sistema baseado em computador. (PRESSMAN 2006 p.378).
Com o intuito de desenvolver um protótipo de um sistema web, o qual deverá suportar um número muito grande de transações, precisa-se de um sistema previamente planejado, seguindo os princípios da WebE.
Diante deste problema e com o intuito de entender os critérios de qualidade desses sistemas, pensou-se em mostrar quais são as técnicas e os modelos de Engenharia de Software que podem ser aplicadas durante o desenvolvimento desses sistemas web. Dessa forma poderá se aumentar a confiabilidade destes, pois, como afirma Pressman (2006, p.378), “... Muitos desenvolvedores da Web não discutem isso, eles apenas pensam que seu mundo é realmente diferente e que as abordagens convencionais de engenharia de software simplesmente não se aplicam”.
1.1 PROBLEMA
Resumindo a situação anteriormente descrita a pergunta de pesquisa pode ser expressa da seguinte forma: quais são os modelos, métodos e as técnicas da Engenharia de Software que podem ser aplicados no desenvolvimento de um sistema web?
1.2 OBJETIVOS
A seguir, serão apresentados o objetivo geral e os objetivos específicos.
1.2.1 Objetivo Geral
Estudar modelos e métodos de Engenharia de Software específicos para Web e aplicá-los no desenvolvimento de um protótipo.
1.2.2 Objetivos Específicos
identificar metodologias de Engenharia de Software específicas para web;
selecionar uma dessas metodologias para aplicá-la no desenvolvimento de um protótipo;
aprofundar os conhecimentos adquiridos no curso.
1.3 JUSTIFICATIVA
Como mostra Pressman (2006), o desenvolvimento de sistemas web é uma tendência, pois, desde os primeiros dias da World Wide Web, na década de 90, a web começou a fazer parte da nossa vida de uma forma tão intensa que hoje muitas pessoas não conseguem ficar muito tempo sem ela.
A internet surgiu trazendo conjuntos de arquivos de hipertexto ligados entre si (com hyperlinks), trazendo textos e alguns gráficos. Com o passar dos anos, a estrutura e ferramenta de desenvolvimento foram evoluindo, por exemplo: XML, Java, o que resultou no fornecimento de capacidades computacionais juntamente com informação. Depois, surgiram os “WebApp”1 (Sistemas e aplicações baseados na Web), que evoluíram para ferramentas computacionais sofisticadas, que não atendem somente funções isoladas para usuários finais, mas também estão integradas a bancos de dados coorporativos e aplicações de negócios (PRESSMAN, 2006).
Assim, a utilização e o desenvolvimento de sistemas web são uma tendência, mas esses sistemas devem ser desenvolvidos com padrões de qualidade. O presente trabalho justifica-se pelos benefícios advindos da utilização das práticas da Engenharia de Software para Web, resultando em softwares mais econômicos e confiáveis. Como já foi descrito, quando não se leva em conta a Engenharia da Web, muitas vezes, têm-se resultados catastróficos, precisando-se gastar mais, para consertar ou realizar melhoramentos no sistema.
1
O uso da Engenharia de Software para Web é importante para as empresas evitarem vender produtos sem os estudos necessários na etapa prévia do projeto, entregando produtos mais econômicos, mas que não atingem os requisitos de qualidade. Diversos métodos para desenvolvimento de aplicativos web foram propostos na literatura (BIANCHINI, 2008), mas se tem pouco conhecimento sobre as seguintes questões: como eles são aplicados, como escolher um deles, e quais são as vantagens e desvantagens de cada método. Este trabalho pretende esclarecer algumas dessas questões.
Este trabalho servirá como um estudo abrangente e de forma aplicada, consolidando o que foi aprendido no decorrer do curso.
Os conceitos e práticas utilizadas serão aproveitados, após a conclusão do curso, para aplicar em projetos futuros, para uma melhor elaboração dos projetos e implementação. Por isso, é importante os autores se especializarem e se aprofundarem nesse tema através de um exemplo prático.
1.4 ESTRUTURA DA MONOGRAFIA
O capítulo 1 – Introdução – apresenta o problema, os objetivos, geral e específico, e justificativa.
O capítulo 2 - Revisão Bibliográfica – abrangerá os tipos de sistemas para web, Engenharia de software e Engenharia para Web, com maior foco neste assunto.
O capítulo 3 – Metodologia - é composto pela caracterização da metodologia científica utilizada, as etapas metodológicas, a arquitetura do projeto e as delimitações do projeto.
O capítulo 4 – Análise de Requisitos e método UWE – apresentação do sistema vele 1 convite, método de desenvolvimento utilizado, modelagem de requisitos, modelo de conteúdo, modelo de navegação e modelo de apresentação.
O Capítulo 5 – Desenvolvimento, Ferramentas, Tecnologias e Validação – Compreenderá as tecnologias e ferramentas, descrição do processo de desenvolvimento, apresentação do sistema e validação do protótipo e da metodologia.
2 REFERENCIAL TEÓRICO
Este capítulo apresenta os conceitos teóricos, fundamentais para o entendimento do trabalho. Serão abordados os tipos de sistemas para web, uma breve explicação de cada um deles, engenharia de software, uma explicação genérica sobre o tema e engenharia web, o principal assunto deste trabalho.
2.1 ENGENHARIA DE SOFTWARE
Segundo Sommerville (2008), “A engenharia de software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que este entrar em operação”.
A Engenharia de Software, também, é conhecida por ser responsável pela parte de resolução de problemas ao longo do processo de desenvolvimento.
Como engenheiros de software, utilizamos nossos conhecimentos sobre computadores e computação para ajudar a resolver problemas. Freqüentemente, o problema com o qual estamos lidando está relacionado a um computador ou a um sistema computacional já existente, mas, algumas vezes, as dificuldades que são apresentadas não têm relação com computadores. Portanto, é essencial entender primeiro a natureza do problema. Devemos ser muito cautelosos para não impor máquinas e técnicas computacionais a toda questão que aparecer em nosso caminho. Primeiro, deve-mos resolvê-la. Então, se necessário, utilizar a tecnologia como ferramenta para implementar a nossa solução. (PFLEEFER 2004 p.378).
Sommerville (2008) nos apresenta a seguir a definição de um processo de software.
Um processo de software é um conjunto de atividades que leva à produção de um produto de software. Essas atividades podem envolver o desenvolvimento de software propriamente dito, usando uma linguagem de programação como Java ou C.
Na Engenharia de Software, os modelos de processos de desenvolvimento podem ser classificados em dois grandes grupos (PRESSMAN, 2006): os modelos prescritivos de processo, ou tradicionais como o cascata, espiral e RUP, entre outros, e os modelos ágeis (Scrum, XP, Crystal, etc.).
O estudo do desenvolvimento de sistemas de software para internet está se consolidando como uma área, chamada Engenharia da Web ou WebE. Esse tema será abordado a seguir.
2.2 ENGENHARIA DA WEB
O aumento significativo do uso da Internet e a criação de sistemas Web levam a repensar sobre como devem ser os sistemas web, pois, como questiona Pressman (2006, p.379), “... os princípios de engenharia de software, seus conceitos e métodos podem ser aplicados ao desenvolvimento na web? Muitos deles podem, mas sua aplicação de certo modo pode exigir uma abordagem diferente”.
Pressman (2006) faz a seguinte afirmação sobre a necessidade da Engenharia de Software: Como não há um processo disciplinado para o desenvolvimento de sistemas web, cresce a preocupação de que possam ocorrer diversos problemas no desenvolvimento, implantação e manutenção bem-sucedidos. A infra-estrutura de aplicação que está a ser criada, hoje em dia, pode se tornar algo que poderia ser chamado “Web entrelaçada” 2. Um amontoado de aplicações da web mal desenvolvidas (conseqüentemente) podem gerar diversas falhas, podendo se agravar ainda mais, pois, à medida que estes sistemas web se tornam mais e mais complexos, a ocorrência de falha, em um deles, pode e vai alastrar problemas para muitos outros.
Quando isso ocorrer, a confiança em toda a rede da internet pode ser abalada irreparavelmente. Com o intuito de evitar uma web entrelaçada e realizar o maior número de operações com sucesso no desenvolvimento e na aplicação de sistemas complexos e de grande escala em sistemas para web, observa-se a extrema necessidade de abordagens disciplinadas de Engenharia da Web e novos procedimentos e ferramentas para o desenvolvimento, implantação e avaliação de sistemas na Web.
Segundo Pressman, existem 4 diferentes tipos de estrutura de WebApp. São elas: • estrutura linear: Usada quando se possui uma ordem previsível de interações; • estrutura em malha: Utilizada quando o conteúdo pode ser categorizado em duas ou mais dimensões;
• estrutura hierárquica: Estrutura mais comum e utilizada com uma navegação veloz. O usuário consegue navegar por toda a hierarquia tanto vertical quanto horizontal;
• estrutura em rede ou “pura teia”: Semelhante ao conceito de arquitetura de sistemas orientado a objetos; cada componente é criado de modo que permite passar comandos para qualquer outro componente do sistema; esse modelo cria flexibilidade na navegação podendo confundir o usuário.
O foco é a criação de uma estrutura ideal para o conteúdo ser apresentado em uma WebApp, podendo combinar diferentes estruturas apresentadas.
Pressman (2006) afirma que tudo está em transformação na Engenharia de Software Web quando afirma: “É importante notar que muitos métodos da WebE foram adaptados diretamente de seus correlatos da Engenharia de Software. Outros estão em seus estágios de formação. Alguns deles irão sobreviver, outros serão descartados à medida que melhores abordagens forem sugeridas.”
De certa forma, isso não deixa de ser verdade, já que tudo é passageiro em nossa vida, então, por que não optarmos por melhorias, para ver se no futuro terá softwares e aplicações Web cada vez mais confiáveis seguros e mais simples, podendo, assim, toda a população ter acesso a estes com facilidade e comodidade.
A Engenharia de Software para web está começando, e por isso tem que passar por muitas provações ainda, é o que nos fala Doug Wallace et al. (apud PRESSMAN, 2006, p.383), no trecho a seguir:
O desenvolvimento Web está na adolescência... Como a maioria dos adolescentes, quer ser aceito como um adulto quando tenta se afastar de seus pais. Se estiver caminhando para atingir todo o seu potencial, precisa aprender algumas lições do mundo maduro de desenvolvimento de software.
A seção a seguir descreve as características gerais dos processos da WebE.
2.2.1 Tipos de Sistemas para Web
A seguir, serão apresentados alguns dos diversos tipos de sistemas web existentes, para, assim, poder entender um pouco mais sobre esse universo web.
2
Para Bolchini (apud GONÇALVES et al, 2000), existem mais de 30 tipos de aplicação web, como, por exemplo: sistemas de comércio eletrônico, catálogos de produtos, Web Sites, portais corporativos, etc., podendo também aparecer novos tipos.
A figura, a seguir, proposta por Domingues (apud BIANCHINI, 2008), resume as características de classificação de sistemas web indicadas por alguns autores.
Figura 1: Classificações de aplicações baseadas na web. Fonte: Domingues (apud BIANCHINI, 2008).
Breve (2002) caracteriza e categoriza os aplicativos Web da seguinte forma: informacional. Conteúdo apenas para leitura é fornecido com navegação
simples e links;
download. Um usuário faz o download de informações dos servidores apropriados;
personalizável. O usuário personaliza o conteúdo para suas necessidades específicas;
interação. Comunicação entre uma comunidade de usuários ocorre em salas de bate-papo, fóruns ou mensagens instantâneas;
entrada de Usuário. Entradas baseadas em formulários são os mecanismos primários para a comunicação necessária;
orientado a transações. O usuário faz um pedido que é atendido pelo aplicativo;
portal. O aplicativo direciona o usuário para outros conteúdos ou serviços fora do domínio do portal do aplicativo;
acesso a Banco de Dados. O usuário faz uma consulta em um banco de dados e extrai informações;
data warehousing. O usuário consulta uma coleção de grandes bancos de dados e extrai informações.
No contexto deste trabalho, será utilizado o termo aplicativo web segundo a concepção de Conallen (2002 apud Bianchini, 2008) e Araújo (2001, apud Bianchini, 2008), isto é, sistemas que utilizam banco de dados e apóiam as transações do negócio da organização.
2.2.2 Processos da Engenharia da Web
Os modelos de processo WebE são caracterizados pelo desenvolvimento ágil, utilizando-se de uma abordagem de desenvolvimento simples composta por ciclos rápidos de desenvolvimento (PRESSMAN, 2006).
Precisa-se de abordagens simples para se fazer algo com a qualidade e rapidez necessária para o desenvolvimento de aplicações web.
Os engenheiros de Software optam por modelos de processos que lhes ajudarão, tomando como base os atributos do software que devem ser desenvolvidos. Quando deparados com situações requerendo imediatismo e evoluções contínuas, a equipe de Engenheiros Web pode optar por modelo de processo ágil, por outro lado, se necessitar de um período maior para o desenvolvimento, como, por exemplo, um e-commerce, deve-se optar pelo modelo de processo incremental (PRESSMAN, 2006).
Essas escolhas se devem a confiabilidade que esses processos asseguram, pois, numa aplicação que requer um tempo muito curto para ser desenvolvida, o processo ágil permite o desenvolvimento simples num tempo muito curto. Já o modelo de processo incremental é apropriado para aplicações com uma demanda muito grande de transações que será desenvolvida em um tempo mais longo. Podemos observar a necessidade do conhecimento desses processos para a escolha do melhor.
A diversificação do usuário em aplicações na rede requer um olhar especial à elicitação e modelagem de requisitos e uma arquitetura especializada, influindo, assim, no projeto de software (PRESSMAN, 2006).
Através da internet, pode se ter uma demanda muito diversificada, atingindo usuários muito diversos entre si. Por isso, é preciso ter um olhar especial para saber exatamente que público irá ser atingido com a criação dessa aplicação Web para, posteriormente, realizar a identificação e a modelagem dos requisitos com base no estudo dos usuários, feito anteriormente.
Qualquer um dos modelos ágeis de processo para Engenharia de software podem ser aplicados com sucesso em processos WebE, porém devem sofrer adaptações necessárias (PRESSMAN, 2006).
2.2.3 Personagens
Segundo Pressman (2006), para uma equipe de engenharia web obter sucesso em suas atividades, necessita de diferentes talentos, para trabalhar, assim, como uma equipe em um projeto de alta pressão. O tempo para elaboração de um projeto é curto, existem modificações o tempo todo para serem realizadas no projeto, e as tecnologias estão em constante evolução. Por isso, criar uma equipe que se integre não é muito simples.
Os papéis, a seguir, foram identificados entre os membros da equipe de WebE (Pressman, 2006):
desenvolvedores/provedores de conteúdo: São os responsáveis pelo conteúdo contido na aplicação. Não são necessariamente especialistas em tecnologia;
editor da Web: São os responsáveis pela edição e organização do conteúdo desenvolvido pelos desenvolvedores/provedores de conteúdo, e serve como um papel de integração entre os que constroem a WebApp e os desenvolvedores/provedores de conteúdo, que não são técnicos;
engenheiro da Web: São os responsáveis pelas análises do sistema, as ferramentas utilizadas, a modelagem, a arquitetura, a navegação, a interface, a implementação e os testes de uma WebApp. Necessita-se ter conhecimentos de
tecnologias, como banco de dados, multimídia, plataformas de hardware/software, segurança de redes, html/xml, arquitetura cliente/servidor e tópicos de suporte a sites web;
especialistas no domínio do negócio: São responsáveis pelas questões relativas às metas, aos objetivos e aos requisitos de negócio associados à WebApp.
especialista de Suporte: São responsáveis por dar continuidade ao suporte da WebApp. São de sua responsabilidade as alterações necessárias para que a WebApp se adapte e seja aperfeiçoada, inclusive as alterações de conteúdo, formulários, implementação de novos procedimentos e modificações nos padrões de navegação para melhor;
administrador: São os chamados “Web Master”, responsáveis pela manutenção diária do WebApp com tarefas de desenvolvimento, implementação, de políticas de operação, suporte e realimentação, implementação de segurança, verificação de tráfego no site, controle de modificações e coordenação com especialistas em suporte.
2.2.4 Modelos de Desenvolvimento da Web
Para que todas as etapas de desenvolvimento web sejam cumpridas, necessita-se de um processo de desenvolvimento. Pressman (apud BIANCHINI, 2008 p.12) sugere um processo de desenvolvimento evolutivo e incremental, similar ao ciclo de vida espiral da Engenharia de Software tradicional. A Figura 2 ilustra esse modelo de processo.
Figura 2: Modelo de processo de desenvolvimento de aplicações Web. Fonte: Pressman (apud BIANCHINI, 2008 p.12).
As etapas compreendidas são:
a iniciação do processo deve-se a atividade de formulação que consiste na identificação de metas e objetivos da aplicação web e do estabelecimento do escopo inicial;
na etapa seguinte, fase esta de planejamento, em que se estima o custo do projeto, é feita a avaliação dos riscos, associando com os esforços, no desenvolvimento, é feita a definição de cronogramas para as fases iniciais e subsequentes;
na análise, é feito o levantamento dos requisitos técnicos dessa aplicação web e é feita a identificação dos itens que serão incorporados, assim, como o levantamento dos requisitos de estética;
a atividade de Engenharia compreende a criação de aplicações web, faz-se uso de ferramentas, combinando os projetos de interface, arquitetura e navegação para a produção de páginas executáveis;
a seguir vem a etapa de testes em que serão realizados os testes necessários;
por fim, na fase de avaliação pelo cliente, podem ser solicitadas alterações, que modifiquem o projeto, para serem integradas em uma futura interação pelo fluxo de processo evolutivo.
Ward Kroll (1999 apud GONÇALVES et al, 2005) apresenta um modelo de processo diferente. Ele consiste em uma mistura do processo de engenharia de software proposto pelo Rational Unified Process (RUP) com atividades típicas do design. Utilizam-se
os métodos e fases do modelo RUP como levantamento de requisitos, usando modelo de Casos de Uso; a definição dos requisitos não-funcionais, depois, passa-se para a área de design com as seguintes etapas: briefing de design; criação do diagrama de navegação inicial; composição gráfica (leiaute); criação dos elementos de Web design (menus, fundos, elementos gráficos, etc.), Protótipo inicial de interface Web, linhas-mestras de interface, protótipo completo das interfaces; diagrama completo de navegação.
A principal característica desse modelo, é que na construção de uma aplicação web surge um novo ator, além do engenheiro de software, aparece a figura do “designer”. Boa parte da atenção do modelo é voltada para o design da aplicação.
A figura 3 ilustra o modelo proposto por Ward Kroll:
Figura 3: Integração do processo criativo de design e o Rational Unified Process (RUP) Fonte: Ward Kroll (1999 apud GONÇALVES et al, 2005).
O modelo cascata para Web proposto por Leite (2002 apud Cechelero e Volpi 2005, p.51), é basicamente igual ao modelo cascata de engenharia de software tradicional, acrescentando uma atividade chamada “Design do web site e prototipação” entre as atividades de análise e implementação. O modelo ocorre de forma sequencial em que a saída de uma atividade é a entrada de outra. A figura 4 apresenta esse método.
Figura 4: Modelo Cascata para Web.
Fonte: Leite (2002 apud CECHELERO e VOLPI 2005, p.51).
O modelo evolutivo apresentado por Leite (2002 apud CECHELERO e VOLPI 2005, p.51), segue a teoria de que um software deve evoluir a partir de um protótipo. A vantagem desse modelo deve-se a verificação antecipada do produto final, já que, a cada fim de uma etapa, esse será apresentado ao cliente e usuário, permitindo, assim, a correção de problemas encontrados. Porém, como os requisitos são revistos a cada inicio de um novo ciclo, é difícil estimar, ao certo, os custos do projeto. A figura abaixo apresenta esse modelo detalhado.
Figura 5: Modelo evolutivo.
Fonte: Leite (2002 apud CECHELERO e VOLPI 2005, p.51).
Outro processo, para aplicações Web, é o proposto por Murugesan e Ginige (2005 apud BIANCHINI, 2008). Assim, como o processo apresentado, anteriormente, esse processo também é considerado processo evolutivo, auxiliando, assim, na compreensão do contexto em que a aplicação será desenvolvida, promovendo a facilidade na elicitação de requisitos, ajuda
na integração de diferentes disciplinas e na comunicação entre diferentes membros. Apóia a evolução contínua, facilitando o gerenciamento de conteúdo e ajuda a controlar a complexidade e a diversidade no processo de desenvolvimento das aplicações Web. A seguir, a figura mostra esse modelo de desenvolvimento de aplicações web.
Figura 6: Modelo de desenvolvimento de aplicações Web. Fonte: Murugesan e Ginige (2005 apud BIANCHINI, 2008).
2.3 MODELAGEM DE ANÁLISE PARA APLICAÇÕES WEB
Segundo Pressman, há uma certa contradição, quando se considera modelagem de análise no contexto de engenharia da web. Pois como se pode observar, a WebApp tem certo imediatismo e uma volatilidade, que impedem uma modelagem detalhada, tanto no nível de análise, quanto no nível de projeto.
2.3.1 Análise de requisitos para WebApp
Para Pressman (2006), análise de requisitos de WebApp está associada, principalmente, a três tarefas: formulação, coleta de requisitos e modelagem de análise. Durante a formulação, são identificadas as metas, os objetivos para a WebApp e as categorias de usuários. No início da coleta de requisitos, a comunicação entre equipe de Engenharia da Web e os interessados na WebApp é mais intensa. É realizada uma lista de requisitos de conteúdos funcionais. Cenários de interação são desenvolvidos, de acordo com o ponto de
vista do usuário final. O objetivo é o entendimento do por quê a WebApp é necessária, quem irá utilizá-la e quais problemas serão resolvidos para seus usuários.
2.3.2 Modelo de análise para WebApp
Segundo Pressman (2006), esse modelo é focado nas informações existentes nos casos de uso, desenvolvidos para essa aplicação. Os casos de uso são analisados cuidadosamente com o intuito de identificar classes potenciais de análise de operações e atributos associados a cada classe. São extraídas funções que serão apresentadas na WebApp através do conteúdo. Contudo, serão desenvolvidos os requisitos específicos para implementação de modo que um ambiente e a infra-estrutura de base de um WebApp possam ser desenvolvidas.
São quatro as atividades de análise propostas por Pressman (2006):
• análise de conteúdo: é analisado todo o conteúdo que será apresentado pela aplicação; esse conteúdo pode estar dividido através dos diversos componentes: gráficos, imagens, vídeo ou áudio;
• análise de interação: compreende a descrição da maneira em que o usuário irá interagir com a aplicação;
• análise funcional: nela ocorre a descrição de todas as funções e operações da aplicação;
• análise de configuração: são expostos detalhes sobre o ambiente e a infra-estrutura em que a aplicação será instalada, podendo ser na internet, Intranet ou em uma Extranet.
2.3.3 O modelo de Conteúdo
Segundo Pressman (2006), o modelo de conteúdo pode conter os seguintes componentes apresentados como parte da WebApp: texto, imagens gráficas, fotografias,
imagens de vídeo e áudio. O modelo de conteúdo possui todas as classes de análise – entidades ao alcance do usuário, criadas ou modificadas à medida que o usuário interage com a WebApp.
Pressman (2006) mostra que, assim como os elementos do modelo de análise, o modelo de conteúdo deve ser desenvolvido a partir de uma análise cuidadosa dos casos de uso, desenvolvidos para WebApp.
2.3.3.1 Definição dos Objetos de Conteúdo
Para Pressman (2006), as aplicações web apresentam informações para o usuário com tipo e forma de conteúdo sofisticado e complexo. O objeto de conteúdo pode ser texto sobre um produto, um artigo, uma fotografia, uma representação animada, um vídeo curto ou uma cobertura de áudio.
O autor afirma que os objetos de conteúdo são criados, a partir de casos de uso, pela análise, descrição e cenário, procurando referências diretas ou indiretas ao conteúdo. Cada um desses objetos de conteúdo precisa ser desenvolvido (por profissionais de conteúdo, e não pelos engenheiros da web) ou adquiridos para a integração na arquitetura WebApp.
2.3.4 O modelo de interação
Segundo Pressman (2006), a maior parte das WebApp possui a possibilidade de “comunicação” entre um usuário final e a funcionalidade e o conteúdo da aplicação.
Esse autor define que o modelo de interação é constituído por 4 elementos:
caso de uso: é o elemento predominante no modelo de interação para WebApp. Em WebApp grandes e complexas, existe a necessidade da construção de muitos casos de uso, porém alguns deles refinam as interações entre as categorias de usuário final do sistema;
diagrama de seqüência: é uma abreviação das ações (elementos dinâmicos) de um usuário, que auxiliam na classe de análise (elementos estruturais). Pelo fato das classes de análise serem extraídas de casos de uso, necessita-se rastrear as classes que foram identificadas e os casos de uso que fornecem a interação do sistema;
diagramas de estados: o diagrama de estado descreve um outro comportamento dinâmico da WebApp, conforme a interação é realizada, podendo conter diferentes níveis de abstração;
protótipo de interface com o usuário: os elementos (leiaute da interface, conteúdo, mecanismo de interação e a estética global) são de fundamental importância para a interação com o usuário, já que, assim, aumenta a chance do usuário conseguir o que ele deseja;
2.3.5 O modelo funcional
Para Pressman (2006), o modelo funcional é necessário para o entendimento de dois diferentes níveis de abstração do desenvolvimento:
a funcionalidade observável pelo usuário. Consiste nas funções de processamento que são iniciadas pelo usuário;
as operações, encontradas em um nível mais baixo de abstração procedimental. Consiste na colaboração das classes umas com as outras, para atingir um comportamento necessário.
2.3.6 O modelo de configuração
Segundo Pressman (2006), o modelo de configuração para WebApp significa que as WebApp devem ser projetadas e implementadas para atender vários ambientes, tanto do lado do servidor, quanto do lado do cliente. Do lado do servidor, a WebApp deve conter flexibilidade para residir em diferentes condições de rede, de hardware e software. Do lado do
cliente, cada navegador possui suas peculiaridades, portanto a WebApp deve ser testada com cada configuração de navegador. Essas características fazem parte do modelo de configuração.
Em WebApp mais complexas, existe um detalhe maior de configuração (por exemplo, distribuição de carga entre vários servidores, arquitetura de cachê, banco de dados remoto, vários servidores servindo a vários objetos de mesma página web) que pode influenciar sobre a análise e o projeto.
2.3.7 Análise de relacionamento-navegação
Segundo Pressman (2006), os elementos descritos, anteriormente, são identificados como elementos de conteúdo e funcionais, seu modo de utilização deve ser descrito para implementar a interação do usuário. Esses elementos tornam-se parte da arquitetura da WebApp. A aplicação contém ligações entre os elementos arquiteturais, porém, à medida que aumenta a complexidade, aumenta também o número de ligações entre esses elementos. O desafio é como realizar as ligações adequadas entre objetos de conteúdo e as funções que implementam os requisitos solicitados pelo usuário.
Para Pressman (2006), a abordagem de análise de relacionamento-navegação está organizada em cinco passos:
análise de Interessados: descreve várias categorias de usuários e fornece uma hierarquia de interessados;
análise de elementos: descreve os objetos de conteúdo e elementos funcionais que são de necessidade para os usuários finais;
análise de relacionamentos: identifica os relacionamentos existentes entre os elementos da WebApp;
análise de navegação: define como os usuários podem acessar elementos individuais ou grupos de elementos;
análise de avaliação: consiste de tópicos práticos (por exemplo, custo/benefício) associados com a implementação dos relacionamentos definidos anteriormente.
2.4 MODELAGEM DE PROJETO PARA APLICAÇÕES WEB
Para Jakob Nielsen (apud PRESSMAN, 2006), “Há essencialmente duas abordagens básicas de projeto: o ideal artístico de auto-expressão e o ideal de engenharia para resolver um problema para o cliente”.
Pressman afirma que hoje em dia ainda são utilizadas aplicações Web como modelo de propaganda para projeto limitado. O imediatismo e a volatilidade são contraditórios com projetos formais, a evolução do projeto ocorre à medida que a aplicação é construída e que pouco tempo deveria ser gasto na criação de um projeto detalhado. Isso só vale para projetos simples. Quando o conteúdo é complexo, quando o tamanho da WebApp engloba centenas de objetos de conteúdo, funções e classes de análise, quando o sucesso da WebApp influenciar diretamente no sucesso do negócio, o projeto não pode e não deve ser feito às pressas e levianamente.
2.4.1 Tópicos de projetos para engenharia da web
Para Pressman, quando o projeto é desenvolvido com o apoio da engenharia da web, devem ser considerados tanto tópicos genéricos quanto tópicos específicos. Os genéricos são modelos que orientam a construção da WebApp. O modelo de projeto, independentemente de sua forma, deve possuir informações para a reflexão de como os requisitos do interessado devem ser traduzidos em conteúdo e código executável. Porém o projeto deve ser também específico, atendendo a atributos-chave para que um engenheiro web possa construir e testar o projeto efetivamente.
2.4.1.1 Projeto e qualidade da WebApp
Todo mundo que já utilizou a internet ou intranet tem uma opinião sobre o que faz a WebApp ser “boa”. Os gostos pessoais são muito variáveis. Alguns usuários preferem que a aplicação possua gráficos grandes, para poder analisar melhor as informações, outros preferem textos simples e curtos para não perder tempo. Alguns gostam de aplicações que possuam acesso a banco de dados. A percepção do usuário poder ser mais importante que qualquer discussão técnica de qualidade de WebApp.
Pressman questiona: como é percebida a qualidade da aplicação?
Quais os atributos devem ser exibidos para atingir a excelência aos olhos dos usuários finais e ao mesmo tempo exibir características técnicas de qualidade que vão habilitar um engenheiro da Web a corrigir, adaptar, melhorar e manter a aplicação em longo prazo?
Esse autor afirma que todas as características de qualidade de software aplicadas em Engenharia de Software tradicional aplicam-se na Engenharia Web. Porém, as mais relevantes dessas características são: usabilidade, funcionalidade, confiabilidade, eficiência e manutenibilidade, fornecendo, assim, uma base útil para avaliar a qualidade de sistemas baseados na Web.
Olsina (apud PRESSMAN, 2006) apresenta uma árvore de requisitos de qualidade, que identifica um conjunto de atributos técnicos como: usabilidade, funcionalidade, confiabilidade, eficiência e manutenibilidade, levando, assim, a alta qualidade de WebApp. A figura, a seguir, resume seu trabalho. Os critérios apresentados na figura são de interesse particular dos engenheiros da web que precisam projetar, desenvolver e manter WebApp durante longos prazos.
Figura 7: Árvore de requisitos de qualidade. Fonte: Olsina (apud PRESSMAN, 2006).
Offutt (apud PRESSMAN, 2006) adicionou aos cinco principais atributos de qualidade, observados acima, os seguintes atributos:
segurança. Devido ao aumento no número de armazenamento de informações confidenciais em banco de dados, a segurança em uma WebApp é de vital importância em muitas situações. Uma medida de segurança proposta é a não permissão à entrada de pessoas não autorizadas, outra é o rebatimento de ataques mal-intencionados;
disponibilidade. É o tempo no qual a WebApp está disponível. Os usuários pretendem que esteja 24/7/365 (24 horas no dia, 7 dias na semana, 365 dias no ano), ou seja, que nunca esteja fora do ar. Porém estar “no ar” não é o único problema, muitas vezes, o navegador do usuário não está configurado para entrar ou carregar algumas informações, porém isso já basta para que nunca mais tente entrar nesse site;
escalabilidade: Não basta apenas possibilitar a entrada de milhares de usuários no site, o mais importante é uma quantidade maior de usuários, alcançando os seus objetivos finais, e tornar-se ainda mais bem-sucedida no decorrer do tempo, pois pode ser liberado acesso para 10000 usuários e apenas 1 conseguir finalizar o desejado;
prazo de colocação no mercado. Mesmo não sendo um atributo real de qualidade no sentido técnico, essa é uma medida de qualidade no sentido de negócio.;
Tillman (apud PRESSMAN, 2006) sugere um conjunto útil de critérios para avaliar a qualidade do conteúdo:
O escopo e a profundidade do conteúdo podem facilmente ser determinados para garantir que atendam às necessidades do usuário? A autoridade e a experiência dos autores do conteúdo podem ser
facilmente identificadas?
É possível determinar a atualidade do conteúdo, a última atualização e o que foi atualizado?
O conteúdo e sua localização são estáveis (isto é, vão permanecer na URL referida?
Pressman adiciona outras questões relacionadas ao conteúdo: O conteúdo é confiável?
O conteúdo é exclusivo, isto é, a WebApp fornece algum benefício exclusivo àqueles que a utilizam?
O conteúdo tem valor para a comunidade de usuários visada? O conteúdo é bem organizado? Indexado? De fácil acesso?
Segundo Pressman, essas questões levantadas acima deveriam ser tratadas à medida que o projeto de uma WebApp evolui. É de maior importância, na Engenharia da Web, o desenvolvimento de sistemas nos quais respostas afirmativas são fornecidas para todas as questões relacionadas à qualidade.
2.4.1.2 Características do Projeto
Para Jean Kaiser (apud PRESSMAN, 2006), o projeto de uma aplicação web deveria atender as seguintes características independentemente do domínio da aplicação, tamanho ou complexidade:
simplicidade: consiste na tarefa de fornecer informação limpa, ou seja, sem o uso exaustivo de recursos visuais;
consistência: consiste na tarefa de construir um projeto que tenha ligação entre si, o conteúdo deve ser formatado do início ao fim com o mesmo padrão;
identidade: consiste na tarefa de projetar a estética, a interface e forma navegacional de WebApp com as características próprias para o grupo de usuários alvo. Ex.: Um projeto web de hip-hop possui formas diferentes, do que um projeto web financeiro;
robustez: baseado na identidade estabelecida, o usuário espera encontrar conteúdo concreto e que faz sentido de acordo com sua necessidade. Se esses requisitos não forem atendidos, provavelmente a WebApp irá falhar; navegabilidade: deve-se obter no projeto uma navegabilidade simples,
consistente, projetada de modo que seja intuitiva e previsível, de forma que a navegação fique simples e o usuário não seja forçado a processar links ou instruções de navegação;
atração visual: indiscutivelmente entre as categorias de softwares, as aplicações da Web são mais visuais, dinâmicas e estéticas. A beleza sempre chama atenção do cliente e muitos elementos (aspecto do conteúdo, leiaute da interface, combinações de cores, proporção de texto, gráfico e outras mídias, mecanismos de navegação) contribuem para a atração visual;
compatibilidade: uma WebApp irá residir em diferentes ambientes (por exemplo, diferentes hardware, tipos de conexão com a internet, sistemas operacionais, navegadores), assim, tem que ser projetado para possuir compatibilidade com cada um deles.
2.4.2 A Pirâmide de Projeto da WebE
Pressman (2006) afirma que um projeto leva embutido um modelo que possui ligação adequada de estética, conteúdo e tecnologia. A ligação varia dependendo das características de WebApp e, consequentemente, as tarefas do projeto que são ressaltadas também variam.
A figura a seguir apresenta uma pirâmide de projeto Web.
Figura 8: Pirâmide de projeto da WebE. Fonte: Pressman, 2006.
Cada tarefa do projeto é representada por um nível da pirâmide:
projeto de interface: essa tarefa consiste na estrutura e organização da interface com o usuário. Contém também uma apresentação do leiaute da tela, um modelo dos modos de interação e apresenta os mecanismos de navegação;
projeto estético: conhecido também como projeto gráfico, propõe o “aspecto” da WebApp. Contém esquemas de cor, leiaute geométrico, tamanho, fonte e colocação de texto, uso de gráficos e decisões estéticas; projeto de conteúdo: consiste na tarefa de descrever o leiaute, a estrutura
e o esboço de todo o conteúdo que contém uma WebApp. São estabelecidas as ligações entre os objetos de conteúdo;
projeto de navegação: consiste em determinar o fluxo de navegação entre objetos de conteúdo e todas as funcionalidades;
projeto arquitetural: essa tarefa consiste na identificação da estrutura de hipermídia;
projeto de componente: essa tarefa consiste no desenvolvimento da lógica de processamento necessária para implementar os elementos funcionais.
2.4.3 Projeto de interface de WebApp
Para Pressman, qualquer interface, seja para Web, aplicação de software tradicional, um produto de consumo ou um dispositivo industrial, deve apresentar as seguintes características: fácil de usar, fácil de aprender, fácil de navegar, intuitiva, consistente, eficiente, livre de erros e funcional. O usuário deve se sentir satisfeito com o trabalho realizado. Os conceitos, princípios e métodos de projeto de interface oferecem ao engenheiro da Web as ferramentas necessárias para conseguir essa lista de atributos.
Segundo Dix (apud PRESSMAN, 2006), um engenheiro web deve projetar uma interface de modo que responda as três questões principais do usuário final:
onde estou? A interface deve apresentar uma indicação que permita ao usuário obter a sua localização na hierarquia de conteúdo;
o que posso fazer agora? A interface deve sempre ajudar o usuário a entender as suas opções, quais funções existem disponíveis, quais ligações estão ativas, quais conteúdos são relevantes;
onde estive; para onde vou? A interface deve ser facilitada para a navegação, fornecendo, assim, um “mapa” (implementado, de um modo fácil do usuário entender), mostrando onde o usuário esteve e quais outros caminhos poderão ser tomados para se dirigir a outro lugar dentro da WebApp.
Uma interface de WebApp, para apresentar ao usuário o que ele deseja, deve responder a cada uma das questões acima, à medida que o usuário navega pelo conteúdo e funcionalidade.
2.4.3.1 Princípios e Diretrizes de Projeto de Interface
Tognozzi (apud PRESSMAN, 2006) descreve um conjunto de características necessárias que todas as interfaces devem exibir. Pode-se identificar uma filosofia que deveria ser utilizada por todo projetista de interface da web:
Interfaces efetivas são visualmente inteligentes e “generosas”, instilando em seus usuários uma sensação de controle. Os usuários rapidamente vêem a amplitude de suas opções, compreendem como atingir suas metas e fazem seu trabalho.
Interfaces efetivas não preocupam o usuário com o trabalho interno do sistema. O trabalho é cuidadoso e continuamente poupado, com plena opção para o usuário desfazer uma atividade a qualquer momento.
Aplicações e serviços realizam um máximo de trabalho, enquanto exigem um mínimo de informação dos usuários.
Com propósito de projetar interfaces que possuam essas características, Tognozzi (apud PRESSMAN, 2006) ressalta um conjunto de princípios que são:
antecipação – uma WebApp tem que ser projetada com intuito de antecipar o próximo movimento do usuário. A interface deve sempre possuir recursos para auxiliar ao usuário em determinadas tarefas;
comunicação - a interface deve exigir o andamento de qualquer atividade iniciada pelo usuário. A comunicação pode ser óbvia ou sutil. A interface também deve exibir a localização do usuário dentro da WebApp e o estado do usuário;
consistência – a utilização de controles de navegação, menus, ícones e estéticas devem possuir a mesma formatação durante toda a WebApp. As características da interface devem conter uma resposta para atender as expectativas do usuário;
autonomia controlada – a interface deve proporciona uma facilidade de movimento ao usuário durante a WebApp, mas deve ser construída de modo que obedeça as convenções de navegação estabelecidas para aplicação;
flexibilidade – a interface deve possuir satisfatoriamente uma flexibilidade para garantir que alguns usuários consigam atingir diretamente tarefas e outros explorem a WebApp de forma um tanto aleatória. Em ambos os casos deve-se garantir ao usuário compreender onde ele está e lhe oferecer funcionalidades que possam desfazer erros e refazer caminhos de navegação mal escolhidos;
enfoque – a interface da WebApp deve continuar focada nas atividades que o usuário realiza no momento. Toda hipermídia contém uma intenção de levar o usuário a um determinado conteúdo. Esta característica é importante para usuário não perder de vista o conteúdo original que ele procurava;
lei de Fit - a interface deve apresentar recursos próximos e semelhantes para que o usuário possa realizar determinada atividade sem perder tempo e foco. Essa atividade consiste em um método de modelar movimentos rápidos;
objetos de interface humana – existe uma biblioteca extensa de objetos de interface humana que foram desenvolvidos para reutilização em WebApp. Objetos que podem
ser “vistos, ouvidos, tocados ou percebidos de outro modo por um usuário” podem ser obtidos em bibliotecas de objetos;
redução de latência – a interface deve permitir que o usuário realize outras tarefas enquanto uma tarefa está em andamento, ou seja, o usuário não precisa esperar uma tarefa se concluir para realizar outras. A WebApp deve possuir processamento multitarefas para fornecer ao usuário continuidade no trabalho como se a operação tivesse sido concluída. Desse modo para diminuir latência, atrasos devem ser exibidos de modo que o usuário compreenda o que está ocorrendo. Introduzir uma realimentação de áudio quando uma operação não terá uma ação imediata da WebApp; exibir formas de progresso do processamento em curso como relógio animado ou barra de progressão; oferecer algum entretenimento enquanto se conclui o processamento;
aprendizado – uma interface de WebApp deve ser construída com intuito de diminuir o tempo de aprendizado quando revisitada;
metáforas - uma interface que utiliza metáfora de interação é muito mais fácil de se compreender e usar, porém a metáfora tem que ser adequada para aplicação e para o usuário;
legibilidade – todo conteúdo da interface apresentado deve ser legível para todas as faixas etárias;
rastrear estado – quando necessário o estado da interação de um usuário deve ser rastreado e armazenado com intuito de que um usuário possa sair e retornar no mesmo ponto em que se localizava quando saiu;
navegação visível – uma interface bem projetada de WebApp traz a ilusão de que o trabalho foi trazido até o usuário sem ele sair do lugar.
Nilsen e Wagner (apud PRESSMAN, 2006), fornecem algumas deritrizes pragmáticas de projeto de interface:
não faça com que o usuário tenha necessidade de ler textos volumosos, principalmente se o texto explica operações da WebApp ou apóia navegação, pois a velocidade de leitura no computador é 25% menor do que no papel.
evite rótulos “em construção”, pois criam expectativas desnecessárias; focar informações importantes dentro das dimensões da janela de um
menus de navegação e barras de topo devem ser consistentes e devem aparecer em todas as páginas da WebApp;
a beleza nunca deve superar o objetivo, ou seja, o botão não deve ser mais bonito do que a eficiência de seu objetivo;
opções de navegação devem estar projetadas de maneira simples.
2.4.3.2 Mecanismo de Controle de Interface
Pressman (2006) afirma que as intenções de uma interface de WebApp são: estabelecer uma janela consistente com o conteúdo e a funcionalidade
fornecidos pela interface;
guiar o usuário ao longo de uma série de interações com a WebApp; organizar as opções de navegação e o conteúdo disponíveis ao usuário. Com intuito de implementar opção de navegação, o projetista escolhe um mecanismo de interação:
menu de navegação: são menus de palavras chaves que possibilitam ao usuário selecionar uma opção de uma hierarquia de subtópicos;
ícones gráficos: botões, chaves e imagens gráficas semelhantes que possibilitam ao usuário escolher alguma propriedade ou explicitar uma decisão;
imagens gráficas: apresentação gráfica que pode ser escolhida pelo usuário, contendo uma ligação para um objeto de conteúdo ou uma tarefa da WebApp.
2.4.3.3 Projeto de Fluxo de Trabalho de Interface
A seguir será apresentado um fluxo de trabalho de projeto de interface de WebApp apresentado por Pressman (2006):
revisar a informação contida no modelo de análise e refiná-lo quando necessário;
desenvolver um esboço do leiaute da interface de WebApp (desenvolvimento de um protótipo);
mapear os objetivos do usuário em ações específicas da interface. (Mapeamento dos objetivos principais do usuário);
definir um conjunto de tarefas de usuário que estão associadas a cada ação. (Mapeamento das interações específicas que englobam tópicos de navegação, objetivo de conteúdo e funções da WebApp);
pranchas com imagens de tela para cada ação de interface. (É criada uma seqüência de imagem de como a interface responderá a uma determinada interação com o usuário);
refinar o leiaute de interface e pranchas, usando entradas do projeto de estética. (O esboço do leiaute e as pranchas são melhoradas pelos engenheiros da Web, mas o aspecto estético é desenvolvido por um profissional de arte);
identificar os objetos de interface com o usuário que são necessários para implementar a interface. (Nesta tarefa pode haver a necessidade de se buscar, em uma biblioteca de objetos, os elementos reusáveis adequados para a interface);
desenvolver uma representação procedimental da interação do usuário com a interface. (Nesta tarefa é tratada o fluxo de atividade à medida que o usuário interage com a WebApp, baseado em diagramas de atividade e/ou digramas de seqüência);
desenvolver uma representação comportamental da interface. (É utilizada para representar transições de estado, os eventos que as causam e a definição de mecanismo de controle);
descrever o leiaute da interface de cada estado. É associado um leiaute ou imagem de tela a cada estado da WebApp;
refinar e revisar o modelo de projeto de interface. (A revisão deve ser focada na usabilidade).
A figura, a seguir, apresenta o mapeamento dos objetivos do usuário nas ações de interface, segundo Pressman (2006).
Figura 9: Mapeamento dos Objetivos do usuário nas ações de interface. Fonte: Pressman, 2006.
2.4.4 Projeto Estético
Segundo Pressman, projeto artístico ou projeto gráfico é um esforço artístico que complementa aspectos técnicos da engenharia da web. Sem ele, a WebApp poderá ser funcional, porém não atraente.
Mas o que é estética? Pressman descreve um velho ditado que diz: “beleza existe nos olhos do observador”. Para saber que aparência deve possuir a aplicação, primeiro deve-se saber que tipo de usuário irá acessá-la, para assim analisar suas preferências e poder criar o leiaute.
