Roteiro: Desenvolvimento de Soluções de Comércio Eletrônico
Tópicos
Atividades durante o ciclo de vida:
|
Conceitos:
Artigo:
|
Criar aplicativos de comércio eletrônico significa criar soluções de Internet para implementar processos de negócios. Isso inclui o comércio eletrônico, mas estende-se a todos os processos de negócios em toda a organização. As tecnologias e os conceitos básicos usados em uma solução de comércio eletrônico são descritos em Conceitos: Desenvolvimento de Comércio Eletrônico.
Os sistemas de comércio eletrônico podem ser divididos em:
- sistemas de primeira geração que simplesmente usam a Web para publicar as informações
- sistemas de segunda geração que implementam o comércio eletrônico e modelos de transações simples
- sistemas de terceira geração que fazem toda a reengenharia de um processo para fornecer soluções altamente personalizadas (negócio a cliente ou negócio a negócio) que sejam adaptáveis e automatizem todo o processo de negócios. Muitas vezes elas fazem a integração com sistemas legados e com dispositivos de Internet
Quanto mais avançada a geração dos sistemas, mais complexo é seu desenvolvimento.
O fluxo de trabalho básico da Fase de Iniciação se aplica, com as seguintes extensões ou variações.
Modelagem de Negócios
Em geral, o foco na modelagem de negócios é muito maior quando comparado a outros tipos de esforços de desenvolvimento. Desenvolver um aplicativo de comércio eletrônico significa, muitas vezes, desenvolver uma nova maneira de fazer negócios; ele é parte integrante da forma como você conduz seus negócios.
Aqui, o foco é entender os problemas que o novo negócio deve resolver e, também, os efeitos de não desenvolver o novo negócio.
A criação de soluções de comércio eletrônico requer a participação de uma variedade de envolvidos maior que a exigida por outros projetos de desenvolvimento de aplicativos. Geralmente, entre esses envolvidos estão executivos de negócios, equipes de marketing, de design criativo, de suporte ao cliente e de desenvolvimento de tecnologia.
A Atividade: Definir e Ajustar Metas tem como foco a garantia de que o novo negócio atenderá às necessidades desse variado grupo de envolvidos. O principal artefato onde essas necessidades são expressas é a Visão do Negócio. Dados os diferentes backgrounds dos envolvidos, geralmente é necessária a realização de um workshop facilitador conforme o descrito nas Orientações de Trabalho: Workshop de Requisitos, para sincronizar o grupo. O uso extensivo de encenações para descrever a experiência desejada do cliente tende a ser útil para a obtenção de feedback (consulte Orientações de Trabalho: Encenação).
Algumas vezes, os envolvidos não estão disponíveis por estarem apenas na Internet. Nesses casos, um importante papel do documento Visão do Negócio é descrever como os envolvidos ou clientes podem localizar o site da Web e como o feedback do usuário será coletado. Nesses casos, você também pode desenvolver protótipos para aprender como os clientes localizam o site da Web e como o estão usando. A necessidade de obter esse tipo de feedback pode afetar o prolongamento das iterações e o ciclo de vida do produto.
Descreva o negócio atual em detalhes suficientes para determinar onde estão os problemas e onde está o melhor potencial para melhoria.
Concentre-se no entendimento do escopo; restrinja a organização a ser modelada à sua área de influência. Dentro dessas fronteiras, priorize apenas os casos de uso de negócios a serem automatizados.
Faça o detalhamento dos casos de uso de negócios prioritários.
Mesmo que o objetivo seja a automação completa dos processos de negócios, o conceito de trabalhador de negócio é útil. No modelo de objetos de negócios final haverá dois tipos de trabalhadores de negócio, automatizado e não-automatizado. As responsabilidades dos trabalhadores de negócio são descritas no nível de detalhe necessário para a tomada de decisão sobre o que automatizar.
Concentre-se no entendimento de qual nível de automatização pode ser atingido de modo realista e de quais são as limitações dos sistemas legados em relação ao que pode ser feito.
Não é executado separadamente. As informações normalmente capturadas em um modelo de domínio já fazem parte do modelo de objetos de negócios.
Requisitos
Esse tem menor destaque. A maior parte dos problemas já deve ter sido encontrada em Detalhamento do Fluxo de Trabalho: Avaliar Status do Negócio e Detalhamento do Fluxo de Trabalho: Descrever o Negócio Atual a partir da disciplina de modelagem de negócios.
Esse requer menor destaque. A maior parte das necessidades dos envolvidos deve ter sido descoberta durante a modelagem de negócios. Contudo, será necessário fazer alguns exercícios que tenham como objetivo descobrir requisitos não funcionais no sistema.
Esse requer menor destaque. A fronteira do sistema é definida pela fronteira do negócio, já que o sistema reflete o negócio de modo mais fiel que os aplicativos tradicionais (em alguns aspectos, o sistema é o negócio).
A Atividade: Modelar a Interface do Usuário resume os casos de uso e o 'Sumário do Design Criativo' e produz um mapa de navegação. Um mapa de navegação é uma visão da solução da Web que mostra como os usuários do site navegarão nele, representada em um diagrama hierárquico em "árvore". Cada nível do diagrama mostra o número de cliques necessários para chegar a uma determinada tela ou página. Em geral, as pessoas gostariam de, com apenas um clique, ir da primeira página (normalmente conhecida como "home page") até as áreas mais importantes do site da Web. O mapa de navegação é, na verdade, um resumo do Artefato: Encenações de Caso de Uso, que começa identificando as principais janelas ou páginas da Web para cada caso de uso e considera como o usuário navega entre estes elementos.
Ambiente
A importância da Atividade: Desenvolver Guia de Interface do Usuário é amplificada e destaca o que os desenvolvedores da Web denominam 'Sumário do Design Criativo', que é um conjunto de diretrizes que descreve (em um nível alto):
- O tom do site; por exemplo, ele transmite autoridade, bom humor ou serviço? É conservador ou provocativo?
- Como os usuários acessam o site; por exemplo, qual a velocidade de conexão? Há uma velocidade mínima especificada ou suposta no design?
- O grau de interação de usuário; por exemplo, devemos apenas informar o usuário ou devemos tentar nos comunicar com ele (comunicação bidirecional)? O design do aplicativo deve ser diferente dependendo de qual usuário está acessando o aplicativo?
- Os navegadores usados pelos usuários, inclusive as diferenças entre sistemas operacionais
- Se o site usará frames
- Quaisquer limitações de cores do site
- Se aplicável, um guia de padrões gráficos (incluindo padrões de logotipos e de todas as cores corporativas)
- O uso de técnicas da Web específicas, por exemplo, mouse-overs, animação, inserção de notícias, multimídia e assim por diante
O 'Sumário do Design Criativo' evolui para o Artefato: Guia de Interface do Usuário; ele é, em essência, uma versão anterior o guia de interface do usuário.
O fluxo de trabalho básico da Fase de Elaboração se aplica, com as seguintes extensões ou variações.
- Detalhamento do Fluxo de Trabalho: Definir uma Sugestão de Arquitetura
A Atividade: Análise Arquitetural aproveita o conhecimento de que um aplicativo da Web tem uma arquitetura relativamente bem definida, inclusive um conjunto de mecanismos bem definidos (navegadores da Web, applets e servlets Java, ASPs e JSPs etc.). Normalmente, uma estrutura em camadas simples como descrito em Conceitos: Divisão em camadas é suficiente, a menos que o framework de desenvolvimento do aplicativo da Web seja mais específico. Em muitos casos, pode haver arquiteturas predefinidas que podem ser adquiridas prontas ou reutilizadas a partir de projetos de desenvolvimento de Web anteriores. Alguns frameworks de aplicativos da Web, como WebSphere da IBM ou Windows DNA da Microsoft, fornecem esse tipo de modelo arquitetural.
Aplicativos da Web, em geral, não possuem tempo de inatividade programado. A arquitetura pode permitir (e normalmente o faz) a atualização do sistema durante sua execução e a comutação para servidores de reserva durante falhas do servidor principal ou na ocorrência de manutenção ou atualizações do servidor. Alguns frameworks de aplicativos da Web fornecem ferramentas para o suporte à produção. Apesar disso, se o aplicativo requisitar alta disponibilidade, será necessário planejar a compra ou a criação da infra-estrutura necessária para suportar esse requisito e para integrar o suporte dessa capacidade na arquitetura.
- Detalhamento do Fluxo de Trabalho: Analisar Comportamento
A Atividade: Análise de Caso de Uso é relativamente inalterável, exceto pelo fato de ser importante destacar não apenas o comportamento da GUI, mas também a lógica subjacente ao negócio—a parte que normalmente será executada no servidor da Web ou no servidor do aplicativo. Se esse detalhe for esquecido, a parte mais significativa do comportamento do sistema será negligenciada. As próprias páginas da Web são representadas como classes 'fronteira', elementos de dados são representados como classes de 'entidade' e o comportamento no servidor (por exemplo, páginas do servidor ativo, servlets, etc.) é representado por meio de objetos de 'controle'.
Imediatamente após a análise de casos de uso, a Atividade: Identificar Elementos de Desing refina o Artefato: Classes de Análise, os mapeia para mecanismos existentes no framework de desenvolvimento de Web, reutilizando elementos de design existentes em projetos ou iteração anteriores, onde possível. Isso, muitas vezes, requer o reajuste do escopo e a definição das classes de análise identificadas para alcançar o grau de reutilização desejado.
Uma descrição mais detalhada do uso de UML para descrever aplicativos da Web é apresentada em Modelagem de Arquiteturas de Aplicativos da Web com UML.
- Detalhamento do Fluxo de Trabalho: Refinar a Definição do Sistema
A Atividade: Criar um Protótipo da Interface do Usuário é executada de forma iterativa nas iterações de Elaboração. O foco das execuções anteriores dessa atividade é a produção de 'amostras de design criativo', que são representações em maquetes do design das principais páginas da Web no site. Geralmente, essas 'amostras' são figuras "planas" graficamente enquadradas como a janela do navegador para que se pareçam com ela. A principal vantagem das 'amostras' é adiar o investimento em protótipos HTML mais elaborados e caros até que haja um consenso sobre a orientação gráfica específica do site.
As 'Amostras de Design Criativo' são criadas observando-se os requisitos de interface dos casos de uso mais importantes e desenvolvendo-se vários designs alternativos em relação ao aspecto e à impressão causada (talvez 10 ou mais). A partir desse conjunto, são escolhidas as três opções mais promissoras para apresentação aos envolvidos. Isso é feito de forma iterativa até que haja um acordo sobre o design da Web final, resultando em uma versão inicial, não funcional do Artefato: Protótipo de Interface do Usuário.
Após o acordo e a aprovação, as amostras de design criativo evoluem para um protótipo de interface do usuário funcional por meio da repetição da Atividade: Criar um Protótipo da Interface do Usuário. O Protótipo de IU da Web Inicial suporta, normalmente, apenas partes do sistema—os casos de uso mais importantes e com arquitetura significativa. É importante estruturar bem o fluxo de eventos do caso de uso antes de desenvolver protótipos, para garantir que a funcionalidade controle o layout da interface do usuário e não o contrário.
Em iterações subseqüentes, o protótipo da Web é expandido, ampliando-se gradualmente a abrangência dos casos de uso e o emprego maior da arquitetura.
|
