ALGUNS PENSAMENTOS SOBRE PROJETO DE SISTEMA E DESENHO DE INTERFACE DE USUÁRIO
(alguns pensamentos que algum dia poderão ser um artigo, mas estou postando assim incipientes mesmo pra não esquecer!)
(alguns pensamentos que algum dia poderão ser um artigo, mas estou postando assim incipientes mesmo pra não esquecer!)
Uma abordagem possivel para projeto de software é começar pelo desenho do interface com o usuário. Alguns desenham com lápis e papel, outros usam PowerPoint, criam formulários Excel, ou mesmo usam o bom e velho Visual Studio para criar o interface, que depois só precisa ser conectado ao código que proverá o funcionamento desejado.
Eu acho que essa abordagem pode ter excelentes resultados - quando a aplicação é totalmente voltada ao gerenciamento de bases de dados. E que pode ser usada quando a parte da aplicação que não é baseada em dados é muito simples.
Em qualquer outro caso, eu acho que o primeiro passo para o projeto do sistema é
a) Diagrama de Casos de Uso
b) Especificação dos Casos de Uso, incluindo, quando for pertinente
b.1) Diagramas dos Processos de Negócios (com BPMN, não UML)
b.2) Diagramas de Atividades
b.3) Diagramas de Estado
Os Diagramas de Estado são especialmente úteis para formulários (web forms, windows forms) com funcionamento complexo. Com diagramas de estado, podemos construir interações com o usuário que não seguem um protocolo (i.e., não precisam seguir um roteiro pré-estabelecido) oferecendo em lugar disso vários caminhos possíveis, permitindo avançar, recuar e saltar etapas, implementando assim diversos cenários do Caso de Uso que tratam. Se começamos a implementação pelo Diagrama de Estados, teremos um interface com boa usabilidade, adequado ao negócio, versátil e estável ao mesmo tempo.
PARA SABER QUE CONTROLES QUEREMOS NA TELA, TEMOS QUE TER BEM CLARO QUE PROCESSO ESTAREMOS CONTROLANDO!
Estou dizendo que devemos ignorar o UI no estágio inicial do processo?
De forma alguma! Mas eu faria os desenhos das telas com lápis e papel, para deixar bem claro que são projetos iniciais, rascunhos, que podem e provavelmente serão alterados nas etapas posteriores do projeto.
Quanto ao "estilo" gráfico da aplicação, isso é outro assunto. Desde o início do projeto se pode definir um visual característico, que evidencie e apoie a proposta do software.
Para projetos que não se limitem às tradicionais "aplicações administrativas", é também importante definir se a iteração com o usuário vai se basear mais no tradicional texto, se a ênfase vai ser em ícones, ou se vamos usar comandos de voz e/ou gestos.
Ou seja: já nos estágios iniciais do projeto devemos definir "conceitualmente" como será o interface de usuário, isso é um componente fundamental do software. Mas "definir conceitualmente" não é, de forma alguma, o mesmo que definir detalhadamente os controles que serão usados em cada interação com o usuário!
Na verdade poderemos ter uma apresentação diferente para diferentes módulos da aplicação. Imaginemos uma aplicação para Segurança do Trabalho, por exemplo. Podemos ter um módulo para os Gerentes de Segurança, um Web Site que os executivos possam acessar de casa ou de qualquer computador. Este "módulo gerencial" deve ter um interface simples, por exemplo um dashboard baseado em ícones, oferecendo apenas funções de tabulaçãoes estatísticas e visualizações de gráficos. Podemos ter um módulo para os Técnicos de Segurança voltado principalmente às exigências legais e ao gerenciamento operacional da segurança- relatórios de Acidentes/Incidentes, Ações Corretivas/Preventivas, Permissões de Trabalho, etc. Este módulo poderia ser feito em Windows Forms uma vez que a produtividade é maior e os Técnicos geralmente o utilizarão no escritório (ainda assim poderia ser usado remotamente via VPN). Sendo um módulo com menus mais complexos - e muito mais formulários - devido à natureza especializada e à complexidade das tarefas, barras de menus controlando a navegação por formulários com os tradicionais textboxes, comboboxes, datagrids, etc., seriam uma boa abordagem. Finalmente podemos ter um módulo para os Técnicos "em campo", baseado em smartphones, onde eles poderão reportar Incidentes, Não Conformidades, Permissões de Trabalho, etc., inclusive usando seus smartphones para registrar fotos dos eventos.
Cada um destes módulos tem de ter o seu "estilo" próprio e homogêneo.
Decerto que todos os módulos estarão compartilhando a mesma base de dados, e que o Diagrama E-R irá sendo construído paralelamente com o detalhamento dos casos de uso - eu usaria o velho método de procurar os substantivos na descrição dos casos de uso; a maioria das minhas entidades de dados estarão aí.
Mas quero concluir frisando: O WORKFLOW É QUE TEM QUE NORTEAR A ARQUITETURA DA APLICAÇÃO, E NÃO O DESIGN DO INTERFACE! Ao contrário, o interface é uma consequência do workflow! O interface é uma consequencia dos Processos de Negócios que a aplicação vai apoiar!
Eu acho que essa abordagem pode ter excelentes resultados - quando a aplicação é totalmente voltada ao gerenciamento de bases de dados. E que pode ser usada quando a parte da aplicação que não é baseada em dados é muito simples.
Em qualquer outro caso, eu acho que o primeiro passo para o projeto do sistema é
a) Diagrama de Casos de Uso
b) Especificação dos Casos de Uso, incluindo, quando for pertinente
b.1) Diagramas dos Processos de Negócios (com BPMN, não UML)
b.2) Diagramas de Atividades
b.3) Diagramas de Estado
Os Diagramas de Estado são especialmente úteis para formulários (web forms, windows forms) com funcionamento complexo. Com diagramas de estado, podemos construir interações com o usuário que não seguem um protocolo (i.e., não precisam seguir um roteiro pré-estabelecido) oferecendo em lugar disso vários caminhos possíveis, permitindo avançar, recuar e saltar etapas, implementando assim diversos cenários do Caso de Uso que tratam. Se começamos a implementação pelo Diagrama de Estados, teremos um interface com boa usabilidade, adequado ao negócio, versátil e estável ao mesmo tempo.
PARA SABER QUE CONTROLES QUEREMOS NA TELA, TEMOS QUE TER BEM CLARO QUE PROCESSO ESTAREMOS CONTROLANDO!
Estou dizendo que devemos ignorar o UI no estágio inicial do processo?
De forma alguma! Mas eu faria os desenhos das telas com lápis e papel, para deixar bem claro que são projetos iniciais, rascunhos, que podem e provavelmente serão alterados nas etapas posteriores do projeto.
Quanto ao "estilo" gráfico da aplicação, isso é outro assunto. Desde o início do projeto se pode definir um visual característico, que evidencie e apoie a proposta do software.
Para projetos que não se limitem às tradicionais "aplicações administrativas", é também importante definir se a iteração com o usuário vai se basear mais no tradicional texto, se a ênfase vai ser em ícones, ou se vamos usar comandos de voz e/ou gestos.
Ou seja: já nos estágios iniciais do projeto devemos definir "conceitualmente" como será o interface de usuário, isso é um componente fundamental do software. Mas "definir conceitualmente" não é, de forma alguma, o mesmo que definir detalhadamente os controles que serão usados em cada interação com o usuário!
Na verdade poderemos ter uma apresentação diferente para diferentes módulos da aplicação. Imaginemos uma aplicação para Segurança do Trabalho, por exemplo. Podemos ter um módulo para os Gerentes de Segurança, um Web Site que os executivos possam acessar de casa ou de qualquer computador. Este "módulo gerencial" deve ter um interface simples, por exemplo um dashboard baseado em ícones, oferecendo apenas funções de tabulaçãoes estatísticas e visualizações de gráficos. Podemos ter um módulo para os Técnicos de Segurança voltado principalmente às exigências legais e ao gerenciamento operacional da segurança- relatórios de Acidentes/Incidentes, Ações Corretivas/Preventivas, Permissões de Trabalho, etc. Este módulo poderia ser feito em Windows Forms uma vez que a produtividade é maior e os Técnicos geralmente o utilizarão no escritório (ainda assim poderia ser usado remotamente via VPN). Sendo um módulo com menus mais complexos - e muito mais formulários - devido à natureza especializada e à complexidade das tarefas, barras de menus controlando a navegação por formulários com os tradicionais textboxes, comboboxes, datagrids, etc., seriam uma boa abordagem. Finalmente podemos ter um módulo para os Técnicos "em campo", baseado em smartphones, onde eles poderão reportar Incidentes, Não Conformidades, Permissões de Trabalho, etc., inclusive usando seus smartphones para registrar fotos dos eventos.
Cada um destes módulos tem de ter o seu "estilo" próprio e homogêneo.
Decerto que todos os módulos estarão compartilhando a mesma base de dados, e que o Diagrama E-R irá sendo construído paralelamente com o detalhamento dos casos de uso - eu usaria o velho método de procurar os substantivos na descrição dos casos de uso; a maioria das minhas entidades de dados estarão aí.
Mas quero concluir frisando: O WORKFLOW É QUE TEM QUE NORTEAR A ARQUITETURA DA APLICAÇÃO, E NÃO O DESIGN DO INTERFACE! Ao contrário, o interface é uma consequência do workflow! O interface é uma consequencia dos Processos de Negócios que a aplicação vai apoiar!
No comments:
Post a Comment