UNIVERSIDADE DO SUL DE SANTA CATARINA - UNISUL GALBER PORTELA DA COSTA ALMEIDA GRAZIELA GÖEDERT DE SOUZA

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA - UNISUL 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

2 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

3 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 Universidade do Sul de Santa Catarina - UNISUL

4 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. Graziela Göedert de Souza

5 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.

6 Copiar a idéia de um autor é plágio, copiar a idéia de vários autores é monografia! (Autor desconhecido)

7 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.

8 LISTA DE ILUSTRAÇÕES Figura 1: Classificações de aplicações baseadas na web Figura 2: Modelo de processo de desenvolvimento de aplicações Web Figura 3: Integração do processo criativo de design e o Rational Unified Process (RUP) Figura 4: Modelo Cascata para Web Figura 5: Modelo evolutivo Figura 6: Modelo de desenvolvimento de aplicações Web Figura 7: Árvore de requisitos de qualidade Figura 8: Pirâmide de projeto da WebE Figura 9: Mapeamento dos Objetivos do usuário nas ações de interface Figura 10: Estruturas Lineares Figura 11: Estruturas em Malha Figura 12: Estruturas Hierárquicas Figura 13: Estrutura em Rede Figura 14: A arquitetura MVC Figura 15: Métodos de desenvolvimento web Figura 16: Resumo do método OOHDM Figura 17: Processo do método UWE Figura 18: Abordagem do método OOWS Figura 19: Padrões de projetos para Web Figura 20: Representação das etapas metodológicas Figura 21: Representação da arquitetura do protótipo Figura 22: Imagem da tela com os estados e cidades do Vale um Convite Figura 23: Imagem da tela do vale um convite Figura 24: Imagem da tela com os dados básicos do usuário do vale um convite Figura 25: Imagem da tela de seleção de uma categoria de Quiz do vale um convite Figura 26: Imagem da tela das perguntas do Quiz do vale um convite Figura 27: Imagem da tela de devolução dos convites do vale um convite Figura 28: Imagem da tela dos parceiros do vale um convite Figura 29: Imagem da tela dos locais de entrega dos convites do vale um convite Figura 30: Imagem da tela da Agenda do vale um convite Figura 31: Estereótipos e notação simbólicas da UWE

9 Figura 32: Diagrama estrutural do meta-modelo UWE Figura 33: Diagrama de caso de uso do ator Visitante Figura 34: Diagrama de caso de uso do ator Usuário Figura 35: Diagrama de caso de uso do ator Apoio Figura 36: Diagrama de caso de uso do ator Administrador Figura 37: Diagrama Com Figura 38: Diagrama Entidades Figura 39: Diagrama Processa Quiz Figura 40: Diagrama Dao do Quiz Figura 41: Diagrama Consulta Troca Figura 42: Diagrama Converter Pontos Figura 43: Diagrama Entidade Relacionamento Figura 44: Diagrama do modelo de Navegação sem processamento Figura 45: Diagrama do modelo de Navegação com processamento Figura 46: Diagrama do modelo de Apresentação da Home, visão do administrador Figura 47: Diagrama do modelo de Apresentação da Home, visão do usuário Figura 48: Diagrama do modelo de Apresentação do Index Figura 49: Representação das tecnologias utilizadas Figura 50: Tela de login Figura 51: Tela de cadastro de usuário Figura 52: Tela do menu usuário Figura 53: Tela de quiz Figura 54: Tela de conversão Figura 55: Tela de parceiro Figura 56: Tela de agenda

10 LISTA DE QUADROS Quadro 1: Elaboração do problema Quadro 2: Descrição caso de uso: Cadastro de usuário Quadro 3: Descrição caso de uso: Consultar eventos Quadro 4: Descrição caso de uso: Responder quiz Quadro 5: Descrição caso de uso: Trocar pontos Quadro 6: Descrição caso de uso: Emitir convite Quadro 7: Descrição caso de uso - controle apoio Quadro 8: Descrição caso de uso - controle parceiro Quadro 9: Descrição caso de uso - controle foto Quadro 10: Descrição caso de uso - controle agenda Quadro 11: Descrição caso de uso - controle quiz Quadro 12: Descrição caso de uso - controle pergunta Quadro 13: Descrição caso de uso realizar multa Quadro 14: Descrição caso de uso emitir convite Quadro 15: Descrição caso de uso seja parceiro Quadro 16: Descrição caso de uso - login

11 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 WebML Web. Modeling Language

12 SUMÁRIO 1 INTRODUÇÃO PROBLEMA OBJETIVOS Objetivo Geral Objetivos Específicos JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA REFERENCIAL TEÓRICO ENGENHARIA DE SOFTWARE ENGENHARIA DA WEB Tipos de Sistemas para Web Processos da Engenharia da Web Personagens Modelos de Desenvolvimento da Web MODELAGEM DE ANÁLISE PARA APLICAÇÕES WEB Análise de requisitos para WebApp Modelo de análise para WebApp O modelo de Conteúdo Definição dos Objetos de Conteúdo O modelo de interação O modelo funcional O modelo de configuração Análise de relacionamento-navegação MODELAGEM DE PROJETO PARA APLICAÇÕES WEB Tópicos de projetos para engenharia da web Projeto e qualidade da WebApp Características do Projeto A Pirâmide de Projeto da WebE Projeto de interface de WebApp Princípios e Diretrizes de Projeto de Interface Mecanismo de Controle de Interface Projeto de Fluxo de Trabalho de Interface...43

13 2.4.4 Projeto Estético Tópicos de Leiaute Tópicos de Projeto Gráfico Projeto de Conteúdo Objetos de Conteúdo Tópicos de Projeto de Conteúdo Projeto de Arquitetura Arquitetura de Conteúdo Arquitetura de WebApp Projeto de Navegação Semântica Navegacional Sintaxe Navegacional Projeto no Nível de Componente MÉTODOS DE DESENVOLVIMENTO PARA APLICAÇÕES WEB Método OOHDM Projeto Conceitual para OOHDM Projeto Navegacional de OOHDM Projeto e Implementação de Interface Abstrata Método UWE Método OOWS Método WAE PADRÕES DE PROJETO NO DESENVOLVIMENTO WEB MODELOS DE TESTES CONSIDERAÇÕES FINAIS DO CAPÍTULO METODOLOGIA CARACTERIZAÇÃO DA METODOLOGIA UTILIZADA ETAPAS METODOLÓGICAS ARQUITETURA DO PROTÓTIPO DELIMITAÇÕES DA PROPOSTA CONSIDERAÇÕES FINAIS SOBRE O CAPÍTULO ANÁLISE DE REQUISITOS E MÉTODO UWE APRESENTAÇÃO DO SISTEMA VALE UM CONVITE MÉTODO DE DESENVOLVIMENTO UTILIZADO MODELAGEM Levantamento de Requisitos Atores...81

14 Requisitos Funcionais Requisitos não Funcionais Regras de Negócio Modelagem de Casos de Uso Casos de uso Definição do modelo de conteúdo Diagrama de Classes Pertinentes Diagrama Entidade Relacionamento Definição do modelo de navegação Definição do modelo de apresentação CONSIDERAÇÕES FINAIS SOBRE O CAPÍTULO DESENVOLVIMENTO, FERRAMENTAS, TECNOLOGIAS E VALIDAÇÃO TECNOLOGIAS E FERRAMENTAS DESCRIÇÃO DO PROCESSO DE DESENVOLVIMENTO APRESENTAÇÃO DO PROTÓTIPO VALIDAÇÃO DO PROTÓTIPO Resultados da Validação pela Equipe Resultados da Validação pelos usuários finais CONSIDERAÇÕES SOBRE A METODOLOGIA CONSIDERAÇÕES FINAIS SOBRE O CAPÍTULO CONCLUSÕES REFERÊNCIAS

15 15 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.

16 16 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 Objetivo Geral Estudar modelos e métodos de Engenharia de Software específicos para Web e aplicá-los no desenvolvimento de um protótipo.

17 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 WebApp : termo usado para abreviação de Aplicação Web (Web Application).

18 18 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. O Capítulo 6 Compreenderá a parte de conclusão do projeto.

19 19 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). software. Sommerville (2008) nos apresenta a seguir a definição de um processo de 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.).

20 20 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;

21 21 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 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 Web entrelaçada : termo usado pelos tradutores de Pressman, 2006.

22 22 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; orientado a serviços. O aplicativo fornece um serviço para o usuário;

23 23 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 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.

24 24 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) 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

25 25 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 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.

26 26 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, fazse 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

27 27 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.

28 28 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

29 29 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 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

30 30 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 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 infraestrutura em que a aplicação será instalada, podendo ser na internet, Intranet ou em uma Extranet 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,

31 31 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 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 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;

32 32 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; 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 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

33 33 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 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.

34 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 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.

35 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.

36 36 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 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.;

37 37 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 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;

38 38 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 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.