Documentação de Projetos Web – Briefing

26 11 2008

A série sobre documentação de projetos é a primeira que eu escrevo no iMasters e visa mostrar o processo de documentação de projetos, iniciando no briefing e indo até o início da codificação de um projeto web.

Os tópicos estudados no decorrer da série serão:

  • Briefing
  • Arquitetura da Informação
  • Diagrama Entidade Relacionamento
  • Wireframe
  • Layout

O Briefing.

O briefing é o levantamento, junto ao cliente, de informações sobre produtos, serviços, público alvo, conteúdo do site, informações sobre concorrência, cores, logo, material gráfico que possa auxiliar no desenvolvimento, etc.

Essas informações devem ser levantadas junto ao cliente (ou a pessoa responsável pela intermediação entre o cliente e o desenvolvedor) logo nas primeiras entrevistas.

O Objetivo.

Uma das informações mais importantes a serem consideradas no preenchimento do briefing é o objetivo do projeto, e ele pode ser de vários tipos: um site, um hotsite, uma animação institucional, um e-commerce, dentre muitos outros.

Ao definir o objetivo do projeto, esse pode ser encaixado em um ou mais desses tipos, e caso consista de mais de um, deve ficar claramente definido para que não restem dúvidas posteriores na etapa de desenvolvimento.

Por exemplo, um site institucional pode conter um blog, onde serão divulgadas as notícias mais importantes sobre a empresa, mas repare que nesse exemplo o principal objetivo do projeto é o site institucional, e não o blog. Um descuido nessa informação poderá produzir um blog com uma página institucional “sobre”, ao invés de um site institucional com uma área de notícias.

Público Alvo.

Nesse ponto existem duas coisas principais a se considerar. A primeira, caso o cliente já possua um site e esse tenha um sistema de estatísticas, são as próprias estatísticas que deverão conter informações sobre resoluções dos usuários que acessam o site, navegador utilizado, sistema operacional, e se o visitante possui ou não javascript habilitado, essas são informações importantes para definir melhor os recursos que serão utilizados no projeto.

Outro fator a se considerar é o tipo de público alvo que freqüenta o site. Por exemplo, um site de vendas de equipamentos para produtos ortopédicos tem grande chance de ser freqüentado por pessoas com algum tipo de deficiência física e/ou idosos. Já um site de venda de equipamentos esportivos tem maior chance de ser visitado por jovens e pessoas em plena condição física.

Esses dados podem ser levados em conta no estudo de cores a serem utilizados, no posicionamento dos elementos na página, dentre outras coisas.

O importante nesse ponto e lembrar que mesmo um site destinado a uma maioria de jovens sem nenhum tipo de deficiência física e que em sua maioria acessa por um navegador standard, como opera, por exemplo, não deve ter seu funcionamento restrito a ações de mouse e ao navegador em questão, o projeto deve ter condições de acessibilidade e usabilidade para que qualquer pessoa, utilizando qualquer navegador possa acessá-lo sem ter suas funções comprometidas.

Domínio e Servidor.

Na etapa de brifagem também são levantadas as informações sobre domínio próprio da empresa e tipo de hospedagem contratada, caso exista. Assim como se há do lado do cliente algum tipo de preferência por tecnologia a ser a utilizada no desenvolvimento do projeto, que permita integração com outras aplicações.

Concorrência.

Não só informações sobre o cliente são importantes na etapa de brifagem. Informações sobre a concorrência também são muito importantes para auxiliar no desenvolvimento do projeto. Nesse item podem ser levantadas informações como sites dos concorrentes, vantagens e desvantagens competitivas do cliente em relação aos concorrentes.

Durante o desenvolvimento do projeto essas informações serão úteis para que não seja colocado em destaque uma área de atuação da empresa que sofre desvantagem em relação aos concorrentes, por exemplo. O ideal seria que fosse destacada a área que tivesse vantagens competitivas ou áreas nas quais o cliente deseja efetuar um trabalho de melhorias competitivas.

Informações sobre a Empresa.

Por último, mas não menos importante, os dados da empresa, como CNPJ, Razão Social, Telefone, Nome do Contato na Empresa também devem ser anotados para que não seja necessário futuramente um contato telefônico apenas para pedir o número do CNPJ que deverá constar na nota fiscal.

Também é importante adquirir informações sobre cores e marcas da empresa caso essa já tenha uma e queira manter a identidade visual. Outros documentos e arquivos também podem ser incluídos ao briefing, como histórico da empresa, e o próprio logo da empresa.

Dados como orçamento reservado para o projeto e tempo necessário para que esse seja concluído também entram no item de informações da empresa.

Além de todos esses dados, qualquer outro dado que possa ser considerado de importância para o projeto deve ser incluído no briefing.

Conclusão.

Com todas essas informações em mão será bem mais fácil desenvolver o projeto sem erros ou mudanças inesperadas durante o percurso.

Com isso terminamos a primeira etapa da documentação de um projeto. Nos próximos artigos continuaremos a série falando um pouco mais dessa área tão importante que as vezes e deixada de lado.

Em anexo, um exemplo de briefing para que pode ser usado na entrevista com o cliente. Clique aqui para baixar.





MVC para agilizar projetos Web

26 11 2008

Nesse artigo abordarei um assunto de interesse a todos os participantes de um projeto dando ênfase a projetos de sistemas para a Internet: o padrão de arquitetura da aplicação. MVC significa Model-View-Controller e tem como tarefa aumentar a produtividade de projetos por meio de divisão de tarefas especificas dentro de um sistema de forma a facilitar a identificação e alteração de algum módulo ou visual, o que sempre ocorre em um projeto real.

Um padrão é algo que seguimos do inicio ao fim da mesma forma, ou seja, a forma que iniciamos um processo é a mesma forma que terminamos o mesmo, e essa forma é utilizada em todos os passos no ciclo de vida intermediários que os ligam. Manter um padrão de arquitetura é extremamente importante por vários motivos

inerentes a um projeto. Explicarei alguns dos mais importantes mostrando alguns exemplos práticos.Nos primórdios da era da informática, computadores não eram populares na maioria das empresas, muito menos para pessoas comuns. Mas isso mudou da ultima década do século passado até os dias de hoje numa velocidade impressionante. Com o início da Internet, a quantidade de informação aumentou e muitas profissões como engenharia de software e arquitetura da informação são indispensáveis para a gerência correta de projetos.

Temos etapas em comum em todos os projetos web atuais: definição dos requisitos de clientes, preparação de conteúdos e imagens, estruturação dos dados, criação e modelagem de banco de dados, criação de layout e criação da parte de programação de funcionalidades do sistema. No início da Internet essas etapas eram mais simples, focando-se apenas em poucas páginas fixas simples e quase sem funcionalidades extras.

E é aí que temos o padrão de arquitetura para o auxílio de todo esse processo. Existem vários tipos de padrão de arquitetura, mas o padrão MVC é o mais interessante para Internet, pois trabalha com a divisão correta entre todas as áreas citadas. Vamos a um exemplo…

Projeto: Sistema de login e senha.

Descrição: Área de acesso restrito, onde o usuário poderá entrar com um nome de usuário e senha.Funcionalidades extras:

- Usuário pode pedir sua senha para que o sistema retorne via correio eletrônico.- Caso o cliente entre em uma página em que precise estar logado, pedir nome de usuário e senha e, após isso, redirecioná-lo automaticamente para essa página.

Esse é um exemplo simples e trivial, mas que é suficiente para mostrar o quanto os padrões de projeto ajudam no desenvolvimento web. Caso desenvolvessemos esse sistema sem padronizarmos a codificação do mesmo teríamos algo como:01. Criar uma página com um formulário, com todo o visual definido, algum tipo de validação cliente para o sistema saber se está na hora de enviar para o lugar de destino ou se é pra voltar e se logar com usuário correto.

02. criar uma pagina de destino (ou várias) em que cada uma irá ter um sistema de verificação para saber se o usuário é um usuário válido para a página específica, caso não seja, volta para a página de formulário. Nessa mesma página teríamos todo o visual inerente à página e acesso ao banco de dados.

Para muitos desenvolvedores, essa forma é bastante comum e devem estar se perguntando o que pode estar errado nisso.

A primeira coisa que temos que pensar nos dias de hoje é que os clientes são muito indecisos em relação ao que foi definido no início do projeto. Isso ocorre por vários motivos, dentre eles: visualmente o sistema não ficou como o esperado, mudança nos campos do formulário (podendo ser adicionar ou retirar campos), etc. Então caso aconteça um desses imprevistos, ficaria difícil para serem alterados, pois estão juntos o visual do site, a parte de validação e a consulta ao banco de dados.

Em um sistema simples como o citado acima, já temos muitos detalhes que ficam difíceis para se alterar, mas em um sistema com muitos componentes e funcionalidades ficaria quase impossível uma alteração em um dos módulos! Se estivéssemos trabalhando com padrões de arquitetura seria muito mais fácil. Vejamos o mesmo exemplo:

01. criar um formulário apenas com os campos de acesso

02. criar arquivo com todo o visual do site (módulos para todo site)03. criar uma etapa intermediária para a validação

04. criar a parte de comunicação com o banco de dados (disponível para qualquer parte do sistema)05. criar páginas que serão restritas (que solicitam a etapa 2 e, por sua vez, a 3)

Dessa forma, temos um sistema bem simples de ser alterado e funcionando corretamente. Se o cliente quiser, por exemplo, alterar o visual do formulário, podemos alterar um arquivo apenas (o da etapa 2). Se quisesse mudar o sistema gerenciado do banco de dados, teríamos que mudar novamente um arquivo apenas (a etapa 4), sem afetar em nada o restante do sistema.

Assim, seguindo os padrões de MVC, temos um sistema muito fácil de ser mantido por uma equipe de pequeno, médio ou grande porte.