Paulo Eduardo

Continuando a falar sobre a documentação dos projetos ainda usando o exemplo do novo visual do blog, falarei um pouco de como o wireframe inicial se transformou no layout.

Com o wireframe em mãos a proxima etapa para o desenvolvimento do novo visual era o layout, o layout e a representação grafica mais proxima da realidade efetiva do site, nele é são dispostas as cores, fontes e tamanhos de fontes a serem utilizadas no site assim como os elementos graficos como logomarca, imagens e outros elementos.

No caso do novo visual, a ideia era manter a proximidade de cores com a primeira versão do site, com o intuito de com o tempo criar uma identidade visual do site, simplicidade, usabilidade e acessibilidade eram fatores importantes a serem considerados no desenvolvimento do layout.

Com isso o degrade de azul foi mantido no topo e no rodapé, na area de conteudo o preto no branco foi a escolha devido a maior facilidade de leitura quando essas duas cores são usadas, outras cores com alto contraste também proporcionam essa facilidade de leitura, tomando cuidado com o uso de cores muito fortes que podem causar ofuscamento.

A primeira versão do layout seguia a risca a disposição dos elementos do wireframe, porem ao conlui-la optei pela mudança de lados entre menu e conteudo, o menu que no wireframe ficaria a esquerda passou a direita e o conteudo para a esquerda, tambem foi feita uma sobreposição do menu no topo da pagina, com isso um espaço vazio apareceu entre o topo e o conteudo, na altura da sobreposição do menu, optei então pela colocação dos links para as paginas estaticas a baixo do logo com aparencia de abas.

A versão final então está representada abaixo:

Com isso foi finalizado o desenvolvimento do novo layout, as proximas etapa seriam a codificação das telas em XHTML + CSS e a adequação ao wordpress porem essas não fazem mais parte da nossa serie de documentação de projetos, já que não se tratam mais da fase de documentação e sim da fase de desenvolvimento, porem vou contar tudinho como foi essa experiencia em posts futuros.

Esse post tem como finalidade duas coisas, falar um pouco mais sobre o processo de desenvolvimento do novo visual do blog, e dar continuidade a seria de Documentação de Projetos.

Como estive um tempo parado para desenvolver o novo visual e a serie ficou parada justamente na etapa de wireframe, juntarei as duas coisas e falarei sobre wireframe utilizando como exemplo o proprio desenvolvido para o novo visual.

Tudo começo com a ideia de trocar um visual antes desenvolvido por terceiros por um visual proprio desenvolvido por mim mesmo, com isso queria aprender a desenvolver temas para wordpress e ter meu proprio tema no blog.

Por um tempo foi só uma ideia que ficou na minha cabeça ate que numa bela noite durante uma leitura uma ideia surgiu de como seria a nova estrutura, rapidamente peguei um papel e a desenhei, no dia seguinte transformei isso no wireframe do blog:

Otimo, mas o que é mesmo um wireframe?

Wireframes fazem parte da Arquitetura da Informação de um site e têm como finalidade mostrar a disposição dos elementos na tela assim como os tamanhos de fontes a serem utilizados.

Existem tres tipos de wireframe, baseados no grau de fidelidade dos mesmo, baixa, media e alta fidelidade, o wireframe do blog foi elaborado em baixa fidelidade, o que significa que nela não constam os elementos graficos, tonalidades das cores a serem utilizadas e estrutura de navegação.

Os wireframes de media fidelidade já contem elementos que o aproximam mais do produto final, enquando os de alta fidelidade são os mais proximos a estrutura de layout.

Voltando ao exemplo do novo visual, a ideia inicial mostrada no wireframe e de que haveria um topo do site onde ficariam contidos o logo do blog, seu titulo e subtitulo e o campo de busca, numa area lateral estaria o menu de acesso as demais areas do blog, logo ao seu lado os topicos em questão seguidos de uma area publicitaria e um rodapé com tres areas para assuntos diversos.

Da ideia inicial do wireframe o projeto sofreu algumas modificações, mas isso já é assunto para um proximo artigo, enquanto isso quem se interessou por wireframe pode conferir mais informações nos endereço abaixo:

Como construir wireframes – Fator W
Quanto mais simples o wireframe melhor – Usabilidoido
Wireframes – Ivo Gomes
Wireframe – Codigo Laranja

Continnuando a falar sobre o Diagrama Entidade Relacionamento, nesse post vamos explicar as chaves primarias, estrangeiras e terminar nosso exemplo da locadora.

As Chaves Primarias são o atributo identificador da identidade, por isso sao únicos, ou seja não se repetem, e geralmente sao sequenciais, ou, como são chamados no SGBD, auto-increment, pois caso um atributo seja setado como auto-increment o propeio SGBD se incarrega de, caso um nova linha seja iserida a essa tabela utilizar o numero inteiro positivo imediatamente apos o ultimo utilizado. porem outros dados podem ser usados como chave primaria, como RG e CPF para cadastros pessoais e CNPJ para cadastros de empresas, pois já se sabe que esses atributos respeitam a condição de serem unicos.

Como já foi dito a representação das chaves primarias no DER e feita pelo circulo cheio seguido do nome do atributo identificador, porem na representação usado pelo DBDesigner as chaves primarias são mostradas com um desenho de chave ao lado esuqerdo do nome do atributo identificador, dentro da entidade.

Ainda existe a possibilidade de existirem chaves primarias compostas, ou seja, formadas por dois ou mais atributos, como acontece frequentemente nas entidades fracas, assim como na entidade fraca mostrada na parte anterior, nesse caso a combinação entre todas as chaves primarias não pode se repetir, porem as chaves primarias isoladamente podem se repetir.

Chaves estrangeiras são o elo de ligação entre as entidades, quando ocorre um relacionamento as chaves estrangeiras são “importadas” de uma entidade para outro, por exemplo, na ultima figura da parte anterior, no relacionamento entre cliente e aluguel a chave primaria de cliente é importada pela entidade aluguel, mostrando que aquele aluguel foi feito pelo client.

Porem como saber de que lado será colocado a chave estrangeira? É simples, num relacionamento 1-1 a chave estrangeira pode ficar em qualquer um dos lados, porem no caso de uma entidade para dados opcionais como foi dito anteriormente é recomendavel que a chave estrangeira esteja na entidade com os dados opcionais e nao na entidade com os dados obrigatorios, pois no caso de nenhum dado opcional ser inserido não ha necessidade de criação dessa chave estrangeira.

Já no relacionamento 1-N a chave estrangeira deve ficar do lado N, como no exemplo de clientes e alugueis, onde cada cliente pode fazer varios alugueis, a chave estrangeira fica na entidade alugueis (repare nonvamente no uso da palavra “cada”). Já no caso de relacionamento N-N, onde ocorre a criação de uma entidade fraca, as chaves estrangeiras ficam nessa entidade fraca, formando uma chave primaria composta, sim, é isso mesmo, a chave primaria é formada por duas chaves estrangeiras.

Com essas informações você já é capaz de realizar a sua propria documentação de banco de dados, porem nosso exemplo ainda está incompleto, faltando a seção de reserva de filmes, mostrada na figura abaixo:

Como havia dito na segunda parte da serie, nessa terceira parte iremos falar sobre como relacionar uma entidade com a outra os casos de relacionamento e como identificar cada um.

O relacionamento entre as entidades é reprentado por uma reta ligando as duas entidades com um losango localizado no centro dessa reta.

Seguindo nosso exemplo anterior um cliente, seja ele pessoa física ou jurídica, realiza locações de fitas de video ou DVD, cada locação tem sua identificação e e um atributo data, representando a data de retirada portanto a representação grafica disso, complementando a representação anterior ficaria dessa forma:

Com já havia sido falado, um losango faz a ligação entre as entidades relacionadas, porem a um detalhe que ainda não foi expllicado, a cor de cada uma das metades desse losango, essa divisão de cores representa o tipo de relacionamento entre as entidades.

No caso da locadora, cada cliente pode realizar varios alugueis, porem cada aluguel é feito por apenas um cliente (repare o uso da palavra “cada” que auxilia bastante na hora de classificar os relacionamento). Essa represntação e feita pelo DBDesigner, colorindo a metade chamada de ‘muitos’ de preto, ou seja, como cada cliente pode realizar muitos alugueis, o lado dos alugueis fica com a metade preta do losango, enquanto, como cada emprestimo e realizado por apenas um cliente, por isso a metade branca do losango aponta para a entidade cliente.

Porem essa representação é um pouco diferente da representação padrão onde teriamos algo assim:

Nessa imagem foram omitidos os atributos de cada entidade.

Como você pode ver ao inves de colorir os losangos indicando o tipo de relacionamento, em cada entidade é colocado um conjunto composto por dois caracteres entre virgulas, o primeiro caracter antes da virgula mostra o minimo do relacionamento, e o caracter apos a virgula o maximo do relacionamento.

No nosso exemplo, cada cliente pode fazer no minimo 1 e no maximo N (muitos) alugueis (1,N) e cada aluguel é realizado por no minimo 1 e no maximo 1 cliente (1,1). Essa metodologia mostra tanto o minimo quanto o maximo de um relacionamento, enquanto o DBDesigner só demonstra o maximo.

Alguns de voces podem estar pensando que um cliente pode ter um cadastro na locadora e nunca ter alugado nenhum filme, realmente isso pode acontecer, o que mudaria o minimo para 0 ao inves de 1, mas isso dependeria do modo como a locadora trabalha o cadastro de clientes, dado esse que deve ser levantado junto ao cliente em cada caso.

Apesar da metodologia padrão usar o minimo e o maximo, o mais importante num relacionamento é o seu maximo, que vai definir em qual das duas entidades será colocada a chave estrangeira, que faz a ligação entre as duas entidades no SGBD.

Mas antes de explicar as chaves estranjeiras vou mostrar todos os tipo de relacionamentos possiveis e uma explicação sobre eles:

Relacionamento 1-1

Esse relacionamento ocorre quando ambas as entidades se relacionam com maximo 1 para com a outra, não é um relacionamento muito usado já que na maioria dos casos quando uma entidade se relaciona dessa forma com a outra elas podem ser fundidas em apenas uma entidade, porem em alguns casos pode-se guardar infomaçoes opcionais sobre uma entidade em outra entidade, evitando assim que uma tabela de banco de dados tenha muitos atributos com valor nulo, caso todos esses valores opcionais fossem nulos não haveria nem a necessidade da criação de uma nova linha na entidade que porta esses dados opcionais

Relacionamento 1-N

É o tipo de relacionamento mais usado em banco de dados relacionais ocorrendo com o relacionamento maximo de uma tabela para outra é 1 e na ordem inversa é N, sendo esse o que foi usado no exemplo anterior e explicado atravez dele

Relacionamento N-N

Ocore quando ambas as entidades se relacionam com no maximo N para com a outra, nesse caso ocorre a criação de uma entidade fraca entre essas entidades para guardar o relacionamento entre essas duas atravez de suas chaves extrangeiras, no exemplo da locadora esse relacionamento pode ser encontrado no relacionamento entre alugueis e filmes representado abaixo:

Como se pode perceber, o DBDesigner transforma altomaticamente um Relacionamento N-N em dois relacionamento 1-N, a entidade fraca possui somente os ID`s das duas entidades com as quais se relaciona, porem pode ter outros atributos tambem.

No proximo topico iremos falar sobre Chaves Primarias e Estrangeiras e terminar nosso exemplo.

Como prometi no artigo anterior, vamos ao exemplo:

O primeiro passo para definir um banco de dados é encontrar no seu levantamento as entidades que o compões, no caso da locadora citada no artigo anterior elas são: cliente (pessoa fisica ou juridica), filmes, aluguel, e reserva. Em seguida definimos os atributos de cada entidade, os atributos são os dados que ficaram salvos sobre cada entidade.

Vamos usar o exemplo de clientes: os clientes tem nome, endereço, telefone e etc, porem no caso de clientes, alguns possuem CNPJ e outros CPF, por isso nesse momento é necessário o uso da especialização, como mostra a img abaixo:

Como vocês podem ver a simbologia utilizada pelo DBDesigner é um pouco diferente da teoria apresentada, mas em resumo, os atributos sao colocadas dentro da entidade, juntamente com o tipo de dados que sera utilizado para esse atributo, e o triangulo que representa uma especialização é representado por uma seta apontando da especialidade para sua entidade generalizadora.

Usando a metodologia padrão representariamos da seguinte forma:

Na proxima parte veremos como relacionar uma unidade com a outra, os casos de relacionamento e como identificar cada um.

Depois de um tempo sem escrever, envolvido com um projeto, vou voltar a falar sobre a documentação de projetos como havia prometido terminar a serie, só espero que esses tempinhos longos sem aparecer não se tornem frequentes.

Como proximo tema da serie temos o DER, ou Diagrama Entidade Relacionamento, velho conhecido dos administradores de banco de dados e de muitos desenvolvedores que utilizam bancos de dados relacionais em sua aplicações.

Em equipes e projetos grandes o o profissional responsavel pela construção de DER`s é o DBA porem em projetos pequenos e com poucos profissionais essa tarefa geralmente acaba nas mãos do programador.

Tambem existem varios softwares que facilitam o trabalho de diagramação do banco de dados, as imagens que vocês veram aqui são screenshots do DBDesigner que é o software de minha preferencia, outro software que tem recursos para tanto é o MS Visio, porem até mesmo softwares de imagens como Photoshop e Fireworks, e até mesmo o Paint podem ser usados, claro que para usar esse ultimo é necessario um pouco mais de, digamos, paciencia.

O DER é a representação grafica do MER, sendo representado por um conjunto muito pequeno de simbolos, o retangulo, representando a entidade, de onde saem pequenos traços com circulos em sua ponta para cada atributo dessa identidade, sendo que o circulo escuro representa a chave primaria dessa identidade, um losango, ligando atraves de retas duas entidades representando seu relacionamento e um triangulo representando as especializações de determinada entidade.

Apesar de parecer algo simples de desenhar, o DER consegue representar nesses poucos simbolos a estrutura completa de todo o banco de dados que será usada em determinada aplicação, mas para entender-mos melhor vou usar de exemplo um banco de dados simples para representar uma video locadora que loca filmes para clientes pessoa fisica e pessoa juridica armazenando nesse banco de dados as informações sobre reserva e alugueis realizados, mas isso você só vai ver no proximo post.

Voltando a falar sobre o modo como realizo as documentações dos meus projetos vou falar um pouco sobre AI

A AI é a documentação do projeto que define a estrutura das paginas de um projeto, assim como o fluxo de navegação de cada pagina, definindo a importancia dos elementos em cada pagina.

Inicialmente quando defino a Arquitetura da Informação de uma pagina começo por definir, quais serão as paginas que esse projeto deve conter já tendo pelo menos um noção do conteudo que o cliente irá enviar, o que cada pagina dessa deve conter, e qual é a hierarquia que existe entre essas paginas.

Vamos facilitar um pouco as coisas com um exmplo simples:
Supomos que em um determinado projeto, todas as paginas devem ter o menu, localizado de forma vertical ao lado esquero do conteudo e um rodapé, com as informações necessarias localizada no final da pagina, portanto já sabemos o que todas as paginas devem ter alem do conteudo e o posicionamento desses elementos na pagina.

Esse projeto, por exemplo, um site de uma agencia de desenvolvimento deve conter a home, uma pagina falando sobre a empresa, uma pagina para contato com a empresa e uma pagina com os projetos já realizados por essa agencia. Essa pagina de projetos deve ter internamente a ela paginas com um descritivo completo para cada projeto, portanto temos uma estrutura parecida com essa:

Home

Sobre

Projetos

Projeto 1

Projeto 2

Projeto 3

Contato

Sabemos tambem que a pagina home deve conter os ultimos projetos realizados por ordem decrescente de datas (do mais novo para o mais antigo) e que a pagina da empresa deve ter alem do texto apresentativo algumas fotos da agencia e ao final desse apresentação uma mensagem do presidente.

A pagina de contato deve ter um formulario para contato e alguns telefones para setores especificos da empresa logo a baixo.

Temos então um exemplo de arquitetura da informação de um projeto de desenvolvimento para web, com isso, alem de evitar duvidas sobre a futura localização das paginas e dos elementos na pagina frente ao cliente se torna bem mais facil a confecção do wireframe e do layout, que são os proximos itens da serie.

Mais uma paradinha nos posts sobre a metodologia de trabalho para falar um pouco de outro assunto que me chamou um pouco de atenção nesses ultimos meses.

Atualmente no mercado, existem muitos toolkits e bibliotecas javascript que auxiliam na criação de paginas com Ajax, porem nesse post, vou falar de que para uma ferramenta conseguir seu lugar no mercado ela nprecisa, não somente ser uma boa ferramenta como tambem ter uma grande documentação disponivel na web para consultas.

Já testei diversas dessas ferramentas como xajax, porem essa, apesar de ser bem documentada não atendia algumas das coisas de que eu necessitava, iniciei enton uma busca na web a procura de ferramentas desse tipo que pudessem atender-me.

A primeira ferramenta que eu encontrei foi o Dojo, a principio achei muito interessante, a ferramenta parece ser muito poderosa e auxiliar em varias coisas uteis no dia a dia, comecei enton a procurar a documentação da ferramenta, ou algo que me ajudasse a entender como usa-la, encontrei muitos artigoas falando sobre o poder da ferramenta, o que era possível fazer como ela, mas nenhum sobre como utiliza-la, depois de uma semana descobri que não iria conseguir nada com aquilo.

Voltei desde o inicio, procurando novamente a ferramenta desejada, foi quando encontrei a jQuery, sinceramente falando, pelos elogios encontrados na internet, o Dojo parece ser muito mais poderosa do que a jQuery, mas a falta de algum texto, artigo, materia, etc, falando sobre como utilizar a ferramenta me fez descobrir o quanto é importante, e as vezes muito mais do que a ferramenta ser boa, ela ser bem documentada.

Conclusão: Estou usando jQuery e muito satisfeito com ela, boa, simples de usar, e bem documentada.

Pretendo falar um pouco dela aqui no blog tambem, mas enquanto isso se alguem quiser conhecer melhor consulte os links abaixo:

Links Interessantes sobre jQuery

Blog do Vitor Prado
Comunidade jQuery Brasil
API da Ferramenta (em inglês)

Esse, acho eu, é um dos pontos mais diferentes do modo como eu documento meus projetos, acredito na maioria das metodologias de trabalho conhecidas o proximo documento apos o briefing é a arquitetura da informação, porem eu ainda passo por uma etapa antes disso, que me ajuda bastante ate mesmo na AI.

Esou falando do levantamento de funcionalidades, que é a descrição por escrito de toda e qualquer funcionalidade que o projeto contiver, esse deve conter o que a funcionalidade deve realizar, como serão tratados os usuarios por essa funcionalidade, como ficaram contidos os elementos basicos dessa funcionalidade na pagina e talvez mais algumas coisas dependendo do projeto.

No inicio do documento costumo definir quais serão os tipos de usuarios que o projeto irá conter, isso varia muito de projeto para projeto, alguns clientes já possuem uma estrutura de usuarios já definida, as vezes ate mesmo falando do nivel do cliente fora da internet, um banco por exemplo, possui seus clientes poupança, conta-corrente, conta-corrente especial, empresas e etc, esses niveis de usuarios já são previamente definidos independentemente da existencia ou não de um site/portal, porem devem ser levados em conta no projeto.

Definidos os tipos de usuario, precisamos definir quem se encaixa em cada um desses perfis, no caso do banco é um pouco obvio, um usuario poupança é, obviamente, aquele usuario que possui uma conta poupança no banco citado, mas nem sempre é assim, um e-commerce de livros pode ter seus usuario bronze, prata e ouro, sendo bronze aqueles que somente realizaram o cadastro e fizeram uma unica compra, prata aqueles que já realizaram mais de uma compra e costumam voltar aleatoriamente ao site para novas aquisições e ouro os que mantem compras frequentemente no site, nesse caso, essa seria a definição de quem se encaixa em cada um desses perfis

O proximo passo e definir o que cada usuario poderá fazer e a qual conteudo ele terá acesso, vamos continuar no exemplo da livraria on-line, o cliente ouro, por realizar comprar frequentemente no site, tem um desconto de 10% em compras acima de R$ 100,00, esse dado portanto se encaixaria no que o usuario pode fazer (receber descontos em compras acima de R$ 100,00) alem disso, ele tem acesso aos primeiros capitulos de cada livro em formato digital, o que se encaixaria em qual conteudo ele terá acesso

Costumo alem desses tipos de usuario sempre adcionar um usuario “visitante” que é aquele que não tem nem o cadastro no site e que está passando ali somente para olhar, sendo portanto um consumidor em potencial.

Apos definidos os usuarios a proxima fase seria a descrição das ações nas funcionalidades, a ação compra, por exemplo (continuando com o exemplo da livraria) o usuario entraria no site, escolheria o livro em uma das categorias, clicaria em comprar e seria transferido para uma tela solicitando seu login e senha (caso ele ainda não esteja logado), sendo redirecionado para o carrinho de compras (essas duas partes podem vir em ordens diferentes) ele então teria a opção de continuar comprando, na qual ele voltaria para a vitrine, ou finalizar a compra, quando seriam solocitados os dados de cobrança e envio, essa então seria a descrição da ação de efetuar compra.

Tendo todas as funcionalidades, seus respectivos levantamentos, eu finalizo essa etapa, e envio o documento para a aprovação do cliente pois assim qualquer coisa que estiver incorreta é corrigida ainda no momento de descrição e eu teria apenas o trabalho de alterar o texto.

Isso ainda continua com as outras etapas…

Como falei no post anterior iria dar prosseguimento detalhando cada uma das etapas de documentação de projetos citadas pois bem, começarei pelo briefing, pois acredito que ele seja por onde se deve começar um projeto em si (descontando-se as conversas anteriores com o cliente que visam conhecer melhor a empresa e/ou o profissional do que o projeto em si)

O briefing é o “levantamento junto ao cliente de informações sobre produtos, serviços, publico alvo, conteúdo do site, informações sobre concorrência, cores, logo, material gráfico que posso auxiliar no desenvolvimento, etc.” (extraido do documento que uso para me auxiliar com as etapas do desenvolvimento de projetos – sim, eu documento até como faço pra documentar, e isso me é muito util).

O Frederick van Amstel do usabilidoido.com.br já escreveu, e escreveu muito bem, sobre Como fazer um bom briefing de website
porem aqui gostaria de colocar a minha opinião de quais são os principais pontos de um briefing e que te acompanharam e ajudarão em decisões por todo o projeto.

O primeiro ponto de todos é o publico alvo, pois ele e nele que se baseiam desde a fonte utilizada no site até o conteudo que será disponibilizado e como será, o levantamento de publico alvo se possivel deve levar em consideração dados anteriores do proprio site, dados da marca (uma marca que vende acessorios para surf tem geralmente um publico alvo mais descontraido, já uma que vende peças de xadrez tem um publico alvo mais conservador), e qualquer outro dado que posso auxiliar na descrição do publico alvo.

São dados importantes do publico alvo: idade media, sexo, condição economica e muitos outros pontos. porem, mesmo tendo um publico alvo muito bem definido, não se deve focar um projeto eexcluindo os outros usuarios que por ventura poderão ter acesso a esse site.

Outro ponto importante de um briefing diz respeito ao produto ou serviço que será vendido e/ou a marca que etá por tras do projeto, conhecer o cliente a marca e o produto/serviço não diz respeito somente ao contratante do projeto, para isso tambem é preciso analisar o mercado, os concorrentes do cliente, e quais vantagens e desvantagens esse cliente leva em relação aos concorrente, pois as vantagens se bem exploradas no projeto poderão trazer um crescimento para marca gerando a satisfação do cliente, e cliente satisfeito volta.

Por outro lado as desvantagens competitivas dessa marca/cliente não deverão ser focadas, ficando em segundo plano dentro de um projeto, a não ser que o objetivo do cliente seja diminuir ou ate mesmo eliminar essa desvantagem competitiva, mas isso requer não somente uma iniciativa do projeto como uma movimentação geral do cliente para aprimoramento das desvantagens competitivas.

E por falar em objetivos, esse é outra parte importante de um briefing, o que o cliente deseja com esse projeto, o objetivo dele pode variar desde criar um institucional somente para divulgação do nome da empresa para que ela fique conhecida tambem no mundo geek, ate a criação de um e-commerce para aumentar o potencial de vendas dessa empresa

Outros pontos importantes de um briefing são:

• Disponibilidade de recursos financeiros para custiar o projeto
• Prazo do projeto
• Hospedagem
• Tecnologia utilizada
• Qualquer outra informação/arquivo que posso auxiliar no desenvolvimento

Para concluir, o briefing pode surgir desde um formulario que o cliente preenche com todas essas informações (o que pode se tornar muito generalista) até de uma conversa entre o desenvolvedor e o cliente onde as informações vão sendo anotadas e que depois se transforma num documento oficial (essa ultima na minha opinião permite um estudo melhor do caso já que o desenvolvedor pode ir dando rumo a conversa a medida em que ela caminha).

Nos proximos posts darei prosseguimento ao detalhamento das outras fases do projeto.