Hernaski Labs–

Já me perguntaram várias vezes qual a diferença entre WebSite e WebApplication no Visual Studio (onde WebSite está presente apenas nas versões 2005, 2008 e 2010). Se você não está familiarizado com o Visual Studio 2005/2008/2010 pode achar que um WebApplication e WebSite são a mesma coisa. Gostaria de contar uma história para esclarecer ainda mais.

No Visual 2002 e 2003 só havia WebApplication e nunca se falou em WebSite. Com a chegada do Visual Studio 2005, juntamente com o framework .net 2.0, surgiu o que a Microsoft achava ser a salvação do mundo colaborativo de codificação: o WebSite.

Adivinhem o que aconteceu no lançamento do Visual Studio 2005? O VS 2005 para projetos web tinha apenas a opção de WebSite e então começaram as reclamações da comunidade asp.net. As reclamações ganharam força e a Microsoft lançou no Service Pack 1 do Visual Studio 2005 a opção de WebApplication muito similar das versões 2002 e 2003 (Vale lembrar: antes do Service Pack 1 foi lançado uma atualização específica para suportar WebApplication, mas quem ainda utiliza o VS 2005 recomendo atualizar o SP1 e demais atualizações do Microsoft Update).

WebSite no Visual Studio

Um WebSite é apenas um grupo de arquivos em uma pasta e subpastas onde as classes estão em um mesmo namespace (no Java, namespace é similar ao package).

Algo interessante no WebSite é que ao depurar uma aplicação, é possível alterar o código-fonte de uma classe (.cs ou .vb) e continuar depurando obedecendo suas alterações na depuração, algo que o WebApplication não faz.

Você pode criar um WebSite utilizando o menu “File > New> Web Site...”. Há três opções da localização dos arquivos:

• File System: Permite escolher uma pasta física.
• HTTP: Permite escolher uma pasta virtual.
• FTP: Permite escolher um endereço de FTP.

Em qualquer um dos casos acima nenhum arquivo de projeto (.csproj ou .vbproj) é criado automaticamente. Não haverá uma pasta “bin” (exceto no deploy - explicação abaixo) nem um único arquivo assembly (dll).

A maior diferença entre o WebSite e WebApplication está no deployment (“Publish”). O deploy realizado no WebApplication consiste simplesmente em uma DLL para cada projeto em uma solução (.sln). Já no WebSite temos 3 opções de deployment descritas abaixo:

1. Código totalmente aberto: Esse tipo de deployment deixa todo seu código-fonte no servidor de hospedagem, incluindo as classes.
   Para efetuar este tipo de deployment, basta copiar todos os arquivos da pasta do WebSite para o servidor Web ou utilizar a opção "Copy WebSite" que encontra-se no ícone abaixo:
   
    
2. Código-fonte das classes pré-compiladas e páginas (.aspx) com o código aberto.
   Para publicar seu site onde apenas as classes devem ser pré-compiladas, você deve deixar seu "Publish WebSite" assim:
   
    
3. Todo o website pré-compilado, inclusive as páginas (.aspx).
   Nesta opção as páginas (ASPX) estarão com uma linha de código apenas: "This is a marker file generated by the precompilation tool, and should not be deleted!", ou seja, o arquivo serve apenas para o servidor web saber que a página existe, pois todo o conteúdo estará pré-compilado na pasta "bin".
   

Uma dica para quem utiliza os tipos 2 e 3: Utilize a opção "Used fixed naming and single page assemblies". Esta opção vai definir nomes fixos para os arquivos DLL. Se não utilizar esta opção, a cada deploy gerado as DLL mudam de nome e você ficará com arquivos inutilizados dentro da sua pasta BIN (se você apaga todo o seu site antes de publicá-lo, não fará diferença utilizar esta opção).

Web Application no Visual Studio

Para criar um WebApplication: File > New > Project. Selecione Web e escolha o tipo de aplicação ASP.NET Web Application.

Um "Web Application Project" organiza os arquivos do projeto em um arquivo chamado <nomedoprojeto>.csproj (para C#) ou <nomedoprojeto>.vbproj (para VB.net). Esses arquivos podem ser úteis para quem faz deploy automático juntamente com o Source Safe criando "labels", por exemplo.

Seu único tipo de build / deployment gera um único arquivo DLL (pré-compilação) que fica na pasta BIN do projeto. No WebSite tudo que é adicionado participa do deploy, já no Web Application é possível colocar arquivos DOC, por exemplo, e setá-los para não participarem do Deployment. Para isso clique com o botão direito do mouse no arquivo desejado dentro do projeto e em seguida em "Properties", modifique a opção "Build Action" para "None".

WebApplication tem suas classes organizadas por namespaces, podendo ser criada classes em qualquer pasta do projeto, diferentemente do que ocorre no WebSite onde é possível apenas inserir classes na pasta App_Code.

Performance

Sabemos que o .net tem 2 fases de compilação: A primeira quando você faz o Build é a que chamamos de pré-compilação onde os arquivos DLLs estão pré-compilados em uma linguagem comum (Intermediate Language) para o Framework .NET. A segunda é quando a aplicação é executada, neste momento ocorre a compilação binária.

Devido a compilação da aplicação ocorrer 2 vezes, a velocidade no WebSite é questionada e dependerá do tipo de deployment (já visto acima) utilizado. A opção 3 de deploy do WebSite deve ser considerada a mais veloz, mas com testes realizados no cliente (navegador) o resultado é imperceptível comparado ao WebApplication.

Comparação WebSite X Web Application

*é necessário criá-la manualmente com a opção New Folder e, se necessário, mudar a Propriedade "Build Action" das classes dentro da App_Code para "Compile".

Conclusão

Utilizar WebSite ou Web Application pode parecer, dependendo do caso, indiferente, por isso é preciso analisar seu ambiente, seu modo de gerenciar o código-fonte, versionamento e a geração de builds e deployments.

Pela experiência com aplicações ASP.NET, percebi que o WebSite já causou alguns problemas na empresa onde trabalho em relação a referências, deployments e versionamento com Source Safe (às vezes por falta de conhecimento mesmo).

Em um Web Application você tem maior controle de configuração, principalmente porque temos propriedades do projeto e as propriedades de cada arquivo no Visual Studio. Devido a essas propriedades você consegue trabalhar melhor com objetos COM+ (por exemplo, definindo Copy Local = true na referência). Também pode gerar builds em modo Debug e/ou Release e seu código-fonte é organizado em namespaces.

Provavelmente se você utiliza o Visual Studio apenas em casa para projetos pessoais pode acabar gostando do WebSite, mas utilizando em grandes projetos empresariais onde Build e Deployment são peças chaves do processo, o Web Application acaba sendo a melhor opção.

O navegador Internet Explorer 6 vem sendo cada vez menos utilizado, mas ainda é a kriptonita dos desenvolvedores web devido a falta de compatibilidade com os padrões da internet e da W3C.

O ie6 é tão amado pelos desenvolvedores web que há diversas campanhas para a morte do ie6, como o site http://deathtoie6.com/, isso faz com que muitos sites insiram scripts para não suportar o ie6 e recomendar o usuário atualizar seu navegador.

Já trabalhei muito com o ie6 e é complicado construir sites padronizados com o W3C e ao mesmo tempo compatível com o ie6, mas tenho que admitir, há maneiras (mágicas e sem sentido) de corrigir os problemas com o ie6 utilizando padrões W3C, mas também admito que a paciência tem limite e muitas vezes recorremos aos famosos hacks/fixes (algo do tipo "_padding:" ou até mesmo scripts). Veja como um desenvolvedor pode ficar após fazer a compatibilidade com o ie6:

IE6: A Kriptonita dos Desenvolvedores Web
 

Desenvolvedor Web

IE6: A Criptonita

Desenvolvedor Web Após a compatibilidade com o ie6

O sonho de todo desenvolvedor web é que o cliente solicite um site e diga: "Não quero compatibilidade com navegadores antigos como o ie6". Se isso ocorrer, sou capaz de ouvir uma voz: "Oohhh". É claro que também precisamos verificar o ambiente do cliente, pois às vezes não tem jeito. Veja um exemplo fictício e que não pode ser confundido com a realidade :-)

Cliente: Queremos suporte ao ie6 através do site. O site vai ter um monte de JavaScript, elementos dinâmicos, imagens PNG transparentes, etc. ok?

Você: [Enviar mensagens de ódio para a equipe IE6 na Microsoft] Bom, o IE6 é realmente um navegador desatualizado que tem falhas de segurança, um mecanismo de renderização muito pobre e pouquíssimos usuários lá fora o utilizam. Eu recomendo não dar suporte ao ie6, podemos por uma barrinha para o usuário atualizar o navegador, o que acha?

Cliente: Eu mencionei que temos serviços de uma grande indústria de restaurantes e a maioria de seus terminais ainda rodam o IE6?

Você: [Criar um vírus para acabar com todos os computadores que tenham ie6] Ok, vou ter que aumentar o prazo de entrega.

Cliente: Infelizmente não poderemos adiar o prazo.

Você: [Comprar cerveja ou refrigerante e guloseimas para as madrugadas]

É bom citar que os gerentes de projetos quando vendem sites devem ter em mente essas e outras diversas dificuldades (não apenas em relação ao ie6, mas do ambiente web como um todo), portanto, ele deve conhecer sobre tecnologia web ou levar pessoas que possam ajudá-lo junto ao cliente.

Não estou querendo que não façam o que cliente pede, mas é necessário verificar realmente o que ele precisa e oferecer melhores produtos e boas práticas de mercado. Uma boa comunicação com o cliente com certeza ajudará bastante, mas isso já está caminhando para outros assuntos que poderemos ver em outros artigos.

Abraço! :-)

1. INTRODUÇÃO

Percebe-se atualmente um expressivo movimento em busca da qualidade. As organizações têm de produzir produtos e serviços de qualidade, não mais como uma estratégia de diferenciação de mercado, mas como uma condição de preexistência. Engana-se quem pensa que a preocupação com a qualidade dos produtos oferecidos aos clientes é coisa recente, pois o código de Hamurabi (2150 a.C.) já demonstrava uma preocupação com a durabilidade e funcionalidade das habitações produzidas na época, de tal forma que, se um construtor negociasse um imóvel que não fosse sólido o suficiente para atender à sua finalidade e desabasse, ele, construtor, seria sacrificado.

Qualidade é claramente um assunto importante no desenvolvimento de produtos para fins empresariais. Mas qual o caminho para um produto de qualidade? Como atingir a qualidade do produto? Além de responder a estas perguntas, este artigo pretende demonstrar a importância dos processos para a geração de um produto, considerando três modalidades de qualidade: de produto, de processo e de projeto. Embora o foco principal do artigo seja a qualidade nos processos e de projeto não podemos descartar a qualidade do produto.

Além disso, qualidade de software, garantia da qualidade e custo da qualidade também são assuntos deste artigo, complementando a ideia de atingir a qualidade através de processos bem definidos e deixando de lado apenas a inspeção do produto final.

2. DESENVOLVIMENTO

2.1. Qualidade: Produto X Processo

Qualidade tornou-se claramente operacional, ou seja, é a conformidade às especificações. A definição é operacional porque demonstra com clareza o objetivo do processo de produção e como deve ser realizado. Trata-se de reproduzir de modo preciso um bem ou serviço, cujas características importantes para as aplicações cogitadas estão claras e explícitas em especificações acintosamente preparadas. Quem vai produzir sabe exatamente o que deve fazer. Não só os componentes do produto como também seus processos de produção e testes estão previstos e planejados na sua forma de execução.

Um princípio central da moderna gestão de operações, diversas vezes constatado no cotidiano, diz que, se o processo estiver bem projetado, e for bem executado, o produto também sairá sempre de acordo com o especificado. A conformidade à especificação é uma definição operacional porque busca garantir que a operação reproduza sempre o mesmo bem ou serviço.

Qualidade do produto: é a rigorosa definição das características relevantes do produto, estabelecendo os atributos e as variáveis que deve conter cuja dimensão deve ser assegurada. A especificação é o documento que formalizará essas definições.

Há duas formas de alcançar a conformidade à especificação. Uma é a inspeção final rigorosa que segrega os produtos sem qualidade. Essa é uma alternativa cara, já que espera o consumo de material, capital, mão de obra para, só ao final do processo produtivo, separar o bom produto. Gera imenso desperdício. A outra possibilidade é introduzir a qualidade ao longo do processo produtivo, desde a verificação da conformidade dos insumos até suas especificações, evitando a cada fase a má qualidade.

A qualidade no processo procura identificar a má qualidade o quanto antes, o que é feito pelo controle da conformidade à especificação, e corrigir o problema, evitando que continue o desperdício até o fim. Para garantir a conformidade à especificação ao longo do processo, é necessário especificar como executar atividades e seus resultados e controlar sistematicamente todo esse processo que irá atingir a qualidade. É preciso ainda identificar e eliminar as fontes da má qualidade, mediante alterações apropriadas no processo, ou seja, nas especificações de suas atividades. Para tornar isso viável, surgiram os sistemas formais da qualidade, como por exemplo, a série de normas ISO 9000, CMM, MPS.BR e outras.

Qualidade de processo: é a rigorosa especificação dos processos que serão realizados na produção de um bem ou serviço, incluindo as faixas de tolerância desejada dos resultados.

Aqui aparece Joseph Moses Juran com sua famosa definição de qualidade como adequação ao uso. Fica assim expressa a existência de um sujeito, que vai receber o bem ou serviço, cujas necessidades de uso precisam ser satisfeitas. Com o conceito de adequação ao uso, Juran explicita que o produto deve cumprir as funções básicas que resolvem os problemas do cliente e, ao mesmo tempo, atender às características conexas como nível de desempenho, durabilidade, pouca manutenção e facilidade de uso, entre outras.

Abaixo, suas famosas perguntas realçam essa perspectiva e apontam suas consequências para os processos de produção:

• Quem são os clientes visados?
• O que desejam e necessitam?
• O que tais necessidades significam para os produtos e processos?
• Quais características devem ter um produto/serviço para satisfazê-las?
• Como fabricar esse produto ou prestar esse serviço?

Com isso, vemos que o conceito de adequação ao uso também se dirige para a qualidade no processo. A qualidade não pode ser alcançada apenas com a verificação de conformidade dos resultados parciais em pontos escolhidos do processo. A qualidade no processo é mais que isso. Exige que os processos sejam concebidos de forma a maximizar a produção de bens e serviços que atendam às especificações. Nasce a qualidade total. A preocupação é garantir qualidade em cada atividade realizada no processo de produção e evitar erros, de modo a produzir certo da primeira vez e até eliminar a necessidade de inspeções, as quais perdem sentido quando cada etapa entrega seus resultados sem defeitos para a etapa seguinte e se implanta um processo explícito para melhorar sistematicamente os processos, de modo a sempre aumentar a qualidade no processo.

Qualidade total: é a preocupação com a qualidade em todas as atividades da empresa, buscando sistematicamente o zero defeito pela melhoria contínua dos processos de produção.

Os princípios da Qualidade Total estão fundamentados na Administração Científica de Frederick Taylor (1856-1915), no Controle Estatístico de Processos de Walter A. Shewhart (1891-1967) e na Administração por Objetivos de Peter Drucker (1909-2005). Seus primeiros movimentos surgiram e foram consolidados no Japão após o fim da II Guerra Mundial com os Círculos de Controle da Qualidade, sendo difundida nos países ocidentais a partir da década de 1970.

O termo TQM (Total Quality Management ou Gerenciamento da Qualidade Total), amplamente usado nas organizações, também descreve uma abordagem para a melhoria da qualidade. De acordo com Kan (2002), "O termo tem tomado vários significados, dependendo de quem interpreta e como se aplica." (KAN, 2002, p. 30). Independente dos seus vários tipos de implementação, os elementos chave do TQM podem ser resumidos conforme Figura 1, abaixo:

Figura 1: Elementos chave do Gerenciamento da Qualidade Total (TQM).

a) Foco do Cliente (Customer Focus) - O objetivo é atingir a satisfação total do cliente. O foco do cliente inclui o estudo das necessidades e vontades do cliente, coleta de requisitos do cliente e a medição e gerenciamento da satisfação do cliente.

b) Melhoria de Processo (Process Improvement) - O objetivo é reduzir as variações de processo e atingir a melhoria da qualidade contínua. Este elemento inclui ambos os processos de negócio e o processo de desenvolvimento do produto. Através da melhoria de processo, a qualidade do produto será reforçada.

c) Lado Humano da Qualidade (Human Side of Quality) - O objetivo é criar a cultura de qualidade por toda a empresa. As áreas de foco incluem liderança, apoio da alta gerência, participação total de todos os colaboradores da empresa, e outros fatores humanos como sociais e psicológicos.

d) Métricas, Modelos, Medições e Análises (Metrics, Models, Measurement and Analysis) - O objetivo é direcionar a melhoria contínua em todos os parâmetros da qualidade por um sistema de medição orientado a metas.

Na organização moderna, portanto, qualidade significa simultaneamente adequação ao uso, conformidade às especificações e qualidade total no processo. Chega-se assim ao ponto que nos interessa. O processo de gerar as especificações de um produto chama-se desenvolvimento do produto. Por meio desse processo, necessidades e desejos do cliente, muitas vezes denominados requisitos, são transformados em especificações do produto e do processo. Tais especificações devem definir com rigor as características do produto e do processo que permitirá reproduzi-las. Isso implica adequação das especificações ao ambiente operacional de produção ou aos requisitos de manufaturabilidade. Como outro objetivo explícito, permite ainda alcançar baixos custos unitários.

Há muita evidência apontando o alto impacto do projeto do produto sobre a qualidade e os custos do produto. Não há uma estimativa consensual desses números, mas é comum entre especialistas avaliar que 60% a 80% dos custos unitários e da qualidade final do produto são estabelecidos no projeto, sobrando o restante para o processo de melhoria contínua.

Assim, na essência da qualidade de produto está a qualidade do processo de produção. E ambas dependem de uma boa qualidade de projeto, sem a qual se corre o risco de não alcançar nível suficiente de adequação ao às necessidades do cliente.

Qualidade de projeto: é a competência que uma organização apresenta de conceber e desenvolver produtos e processos de forma a alcançar a satisfação do cliente, com custos e prazos compatíveis.

2.2. Qualidade de Software

Diante dessa complexidade na definição da palavra qualidade, Pressman (2005) sugere que a qualidade de software seja colocada em prática e não somente uma ideia ou desejo que uma organização venha a ter. Para tanto, Pressman (2005) faz as seguintes colocações sobre qualidade de software:

a) "Definir explicitamente o termo qualidade de software, quando o mesmo é dito"; (PRESSMAN, 2005, p. 193).

b) "Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade"; (PRESSMAN, 2005, p. 193).

c) "Realizar atividades de segurança da qualidade em cada projeto de software"; (PRESSMAN, 2005, p. 193).

d) "Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como consequência, a qualidade no produto final"; (PRESSMAN, 2005, p. 193).

Sendo assim, a busca constante pela qualidade não se faz apenas no começo do projeto ou no seu final realizando testes, mas sim e um processo que visa abranger toda a engenharia de software bem como a colaboração de todos os membros do time do projeto.

Uma possível definição mais abrangente e completa para qualidade de software seria a proposta por Bartié (2002): "Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos". (BARTIÉ, 2002, p. 16).

Alguns modelos de qualidade de software também são citados por Pressman (2005). Há o que McCall e Cavano (1978) sugerem como métricas para qualidade de software. Conhecido como Fatores da Qualidade, estes fatores avaliam o software em três pontos distintos: Transição do Produto, Revisão do Produto e Operação do Produto. Na Figura 2 são mostrados os Fatores da Qualidade de McCall:

Figura 2: Os Fatores da Qualidade (McCall).

Colocando-se todos esses conceitos dentro do contexto apresentado, podemos dizer que "qualidade não é uma fase do ciclo de desenvolvimento de software... é parte de todas as fases". (BARTIÉ, 2002, p. 16)

Portanto, é necessário um planejamento adequado para que a qualidade de software seja atingida, conforme a definição de qualidade que deverá ser alcançada. Para isso são necessários modelos, padrões, procedimentos e técnicas para atingir essas metas de qualidade propostas. Para tanto, todas as etapas do ciclo de vida de engenharia de software devem ser contempladas com atividades que visam garantir a qualidade tanto do processo quanto do produto.

2.3. Garantia da Qualidade

Podemos definir como Garantia da Qualidade (Quality Assurance) o conjunto de atividades de apoio para fornecer confiança de que os processos estão estabelecidos e estão continuamente melhorados para produzir produtos que atendam as especificações e que sejam adequados para o uso pretendido.

Portanto, isso consiste em realizar a qualidade tanto do processo quanto to produto. No processo, podemos quantificar a sua qualidade através de métricas para qualidade e no produto com as técnicas de verificação e validação. Essas atividades podem ser, por exemplo, avaliações como as citadas pela ISO 9000, auditorias, inspeções formais, testes, revisões. Ainda no processo podemos usar os métodos de garantia da qualidade no formato de auditorias e reportes para a alta gerência, além de avaliações constantes do processo e análise estatística de controle do processo. No produto os métodos de garantia da qualidade são revisões, inspeção formal e testes, além de revisão dos resultados do teste realizada por profissionais altamente capacitados, auditorias do produto e testes realizados pelo cliente.

Não podemos confundir os conceitos e a aplicação dos termos Controle da Qualidade (Quality Control) e Garantia da Qualidade (Quality Assurance). Embora usados erroneamente em muitos lugares, ambos os termos têm propósitos totalmente diferentes.

Vejamos a Tabela 1 que mostra a diferença entre estas duas atividades:

Pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste de software é orientado a produto e está dentro do domínio do controle da qualidade.

2.4. Qualidade segundo PMBOK

De acordo com o PMBOK (Project Management Body Of Knowledge) do PMI (Project Management Institute), na versão 2004, os processos de gerenciamento da qualidade do projeto detêm todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização. Eles desenvolvem o sistema de gerenciamento da qualidade através da política, dos procedimentos e dos processos de planejamento da qualidade, garantia da qualidade e controle da qualidade, com atividades de melhoria contínua dos processos conduzidas do início ao fim, conforme adequado.

Com isso os três principais processos são:

a) Planejamento da Qualidade: Identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfazê-los.

b) Garantia da Qualidade: Aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos.

c) Controle da Qualidade: Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório.

Há diversas semelhanças entre os conceitos usados no PMBOK e os conceitos da própria ISO. Com isso, é possível ainda relacionar estes três processos do PMBOK com as definições de qualidade de processo, qualidade de projeto, controle da qualidade e garantia da qualidade.

3. CONCLUSÃO

Vimos que a qualidade de produto voltada apenas para a inspeção, ou seja, verificação das especificações somente após o produto estar pronto (inspeção), não é uma boa prática, pois perdemos todo o controle da qualidade durante o processo de desenvolvimento do produto, acarretando em retrabalho e maior custo.

A qualidade de processo é aparentemente uma opção muito boa, devido sua avaliação da conformidade ser constantemente avaliada, mas precisamos ter em mente a importância de juntar os conceitos de qualidade de processo com qualidade total, de projeto e outras a fim de obter a qualidade total do produto, utilizando padrões e um bom planejamento.

REFERÊNCIAS

OLIVEIRA, OTAVIO J. Gestão da Qualidade - Tópicos avançados. Cengage Learning Editores, 2006.

PMI. Um Guia de Conhecimentos em Gerenciamento de Projetos - Guia PMBOK. EUA, PMI, 3ª edição, 2004.

QUALIDADE TOTAL. http://pt.wikipedia.org/wiki/Qualidade_total.

Olá pessoal, em breve quero publicar artigos e tutoriais sobre diversos assuntos relacionados à criação de sites e de vez em quando algum assunto diferente.
Estou trabalhando para terminar o blog e começar a postar.

Até+