UM ESTUDO SOBRE A INTEGRAÇÃO DE ASPECTOS DA INTERAÇÃO HUMANO-COMPUTADOR NOS MÉTODOS DE DESENVOLVIMENTO DE SISTEMAS INTERATIVOS Sarah Sther Chagas de Aquino MONOGRAFIA APRESENTADA AO CENTRO DE CIÊNCIAS TECNOLÓGICAS DA UNIVERSIDADE DE FORTALEZA COMO PARTE DOS REQUISITOS PARA A OBTENÇÃO DO GRAU DE BACHAREL EM INFORMÁTICA. Aprovada por: Professora Elizabeth Sucupira Furtado, D.Sc. (UNIFOR) Professor Flávio Horácio Souza Vierira, M.Sc. (UNIFOR) Fortaleza, CE - Brasil. Julho / 2003
AQUINO, SARAH STHER CHAGAS DE Um Estudo sobre a Integração de Aspectos da Interação Humano-Computador nas Metodologias de Desenvolvimento de Sistemas Interativos Software, [Fortaleza] 2003 vi, 79p. 29,7 cm (INFORMÁTICA/UNIFOR, Engenharia de 2003) Monografia Universidade de Fortaleza, Informática. 1. Interação Humano-Computador 2. UML 3. Metodologia de Desenvolvimento de Software I. INFORMÁTICA/UNIFOR II. TÍTULO (série) Os caminhos eu traço, o final Deus decide. O que faz minha vida valer a pena não é onde eu vou chegar, mas o que farei até lá. Desconhecido
AGRADECIMENTOS Os sinceros agradecimentos a todos que ajudaram na realização deste trabalho, em especial: - A Deus, por me fazer perseverar diante das dificuldades; - Aos meus pais, José Eudes Aquino de Oliveira e Aguida Maria Chagas de Oliveira, pelo amor, carinho e dedicação que me criaram e educaram; - A professora Elizabeth Furtado, pela orientação, realizando críticas e sugestões na construção deste trabalho; - Ao Roberto, por estar ao meu lado durante todo o tempo, incentivando para que eu sempre fizesse o melhor; - Aos amigos e professores do Curso de Informática pelo apoio dedicado durante todo o curso. 3
RESUMO Este trabalho propõe mostrar como aspectos da Interação Humano-Computador (IHC), tais como projeto centrado no usuário, modelagem de interfaces e testes de usabilidade, têm se incorporado às novas metodologias de desenvolvimento de software, para construir sistemas mais usáveis e mais voltados para os seus usuários, suas tarefas. As metodologias estudadas utilizam a UML como notação, já que esta linguagem tem se estabelecido como padrão para análise e projeto de sistemas. Este trabalho abrange a definição destes aspectos, das metodologias e uma análise comparativa entre elas. A pesquisa realizada visa futura ponte entre as duas áreas: IHC e engenharia de software, bem como servir de fonte de trabalho para os desenvolvedores de software e projetistas de interfaces de usuário. 4
SUMÁRIO 1. 01 Introdução...... 1.1. Conceitos Iniciais... 1.2. Motivação...... 1.3. Objetivos Principais... 1.3.1. Estudar Conceitos de IHC... 1.3.2. Conhecer Metodologias de Desenvolvimento de Software aplicando UML... 1.3.3. Definir Critérios de Comparação... 1.3.4. Compar...... 1.4. Estrutura da Monografia... 2. Conceitos de 02 09 10 10 11 11 11 11 13 IHC... 2.1. Projeto Centrado no 14 Usuário... 2.2. Sistemas 16 5
Adaptativos... 2.3. Modelagem de Interface... 2.4. Arquitetura de Interface... 2.5. Testes de Usabilidade... 2.6. Conclusão...... 3. Processo de Desenvolvimento de 17 20 24 25 28 Software... 3.1. 28 Definições...... 3.2. Ciclo de 31 Vida.... 3.2.1. Modelo Tradicional ou em 32 Cascata... 3.2.2. Modelo 33 Evolutivo... 3.2.3. Modelo 34 Espiral... 3.3. 35 Abordagens...... 3.3.1. Abordagem 36 Estruturada... 3.3.2. Abordagem Orientada a 37 Objeto... 3.4. Fases de 38 Desenvolvimento... 3.4.1. Análise de 38 Requisitos... 3.4.2. 39 Análise...... 3.4.3. 39 Design...... 3.4.4. 40 Implementação...... 6
3.4.5. Teste...... 3.5. Diagramas UML em gráficos X Fases de desenvolvimento... 3.6. Conclusão...... 40 41 43 4. Métodos de Desenvolvimento... 4.1. Método UML PID... 4.2. ARFDIU...... 4.3. RUPi...... 4.4. UMLi...... 4.5. Comparação resumida descritiva... 5. Conclusão...... 5.1. Cnclusão da Monografia... 5.2. Trabalhos futuros... Referências Bibliográficas...... 7
LISTA DE FIGURAS Figura 01 - Conceitos de IHC relevantes para o design de interfaces de usuário Figura 02 Modelo Seeheim Figura 03 Modelo Arco Figura 04 Modelo MVC Figura 05 Modelo PAC Figura 06 Modelo PAC-Amodeus Figura 07 - Processo de desenvolvimento do método UML PID Figura 08 - Descrição das principais etapas do método ARFDIU 8
Figura 09 - Estrutura do processo RUPi Figura 10 - Modelos declarativos da interface da UMLi. Figura 11 - Elementos do diagrama de interface de usuário. 9
Capítulo 1 INTRODUÇÃO Este trabalho tem o objetivo de apresentar como os aspectos da Interação Humano-Computador (IHC) estão sendo incorporados às novas metodologias de desenvolvimento de software, para a construção de sistemas mais usáveis. Poucas são as metodologias de desenvolvimento que consideram tais aspectos. A maioria das metodologias existentes se preocupa em garantir qualidade para aspectos como custo e cronograma, e acabam deixando de lado os usuários e suas tarefas, não garantindo assim a usabilidade, isto é, facilidade de aprender e usar. As metodologias de desenvolvimento de software estudadas para a realização deste trabalho, incluem em seu processo de desenvolvimento aspectos de IHC, com o intuito de produzir interfaces de usuário de acordo com suas reais necessidades. Fazendo assim com que os usuários considerem o sistema como facilitador de seu trabalho e não um obstáculo, já que os sistemas resultantes foram projetados para se adaptarem a eles, suas tarefas e seu contexto de uso. Foram escolhidas metodologias que utilizem a UML como notação padrão, pois, hoje em dia, a UML tem se estabelecido como a linguagem padrão para especificação e projeto de sistemas. A próxima seção apresenta os conceitos iniciais usados neste trabalho. A seguir são apresentados os objetivos principais, seguidos pela apresentação da estrutura dos capítulos seguintes. 10
1.1 Conceitos iniciais Esta seção contém uma abordagem em torno dos conceitos básicos utilizados ao longo deste trabalho. Em seguida, ela apresenta uma resumida descrição sobre as áreas de Engenharia de Software e Interação Humano- Computador, sistemas interativos, a evolução das metodologias de desenvolvimento e uma introdução a UML. - ES e IHC A área de Interação entre Seres Humanos e Sistemas Computacionais (IHC) tem por objetivo principal fornecer aos pesquisadores e desenvolvedores de sistemas explicações e previsões para fenômenos de interação usuário-sistema e resultados práticos para o design da interface de usuário. Com teorias a respeito dos fenômenos envolvidos seria possível prever antecipadamente se o sistema a ser desenvolvido satisfaz as necessidades de usabilidade dos usuários [LEITE, 2001]. A área de Engenharia de Software (ES) tem por objetivos a aplicação de teoria, modelos, formalismos, técnicas e ferramentas da ciência da computação para o desenvolvimento sistemático de software e o gerenciamento do processo de desenvolvimento [LEITE, 2000]. Existe uma falsa impressão hoje em dia sobre como fazer para desenvolver um sistema interativo que satisfaça às necessidades do usuário. Sistemas que tem como objetivo satisfazer as necessidades do usuário devem, durante as etapas do processo de seu desenvolvimento, envolver pessoas com conhecimento em diversas áreas e não apenas da ciência da computação. Isto porque IHC é uma área multidisciplinar, que tem contribuições significativas para o desenvolvimento de sistemas mais usáveis nas áreas de comunicação, design, 11
ergonomia, etc. Enquanto a engenharia de software se preocupa principalmente com a gerência de projetos e produção de código. No entanto, poucos métodos de desenvolvimento existentes apresentam de forma explícita quando ou como deve ser conduzido o processo de desenvolvimento de software com uma equipe multidisciplinar e levando em conta aspectos de IHC dentro deste processo. - Sistema Interativo Um sistema interativo é um conjunto de programas manipulados pelo usuário cuja realização de suas funções visa resolver um determinado problema [FURTADO, 1997]. Um sistema interativo é composto por uma parte não interativa, chamada aplicação, e uma parte interativa, chamada interface. A engenharia de software tem se direcionado ao desenvolvimento da parte funcional do sistema (a aplicação), enquanto que o IHC se preocupa com a parte que interage com o usuário (a interface). O desenvolvimento de sistemas interativos de qualidade requer o uso de conceitos e técnicas de IHC e de conceitos e métodos de desenvolvimento de sistemas da engenharia de software. Esta separação permite que aplicação e interface sejam alteradas e melhoradas individualmente. Por exemplo, a correção de problemas de funcionalidade do sistema não influi nas melhorias que podem ser feitas no projeto da interface. Assim, projetistas de interface e da aplicação trabalham de forma mais independente. Esta separação garante o respeito ao princípio da independência do diálogo homem-computador. 12
Geralmente, a equipe de desenvolvimento de software envolve analistas e projetistas específicos à aplicação e específicos à interface. Os analistas e projetistas da aplicação têm uma visão interna dos sistemas, dando prioridade a requisitos funcionais como eficiência e manutenibilidade, colocando em segundo plano o desempenho do usuário diante de suas tarefas. Isto pode ocasionar a geração de sistemas que funcionam, mas que muitas vezes são inadequados aos seus usuários. Os projetistas de interface, ao contrário dos analistas, têm uma visão interna do sistema, dando ênfase às características de interação, deixando de lado as funcionalidades e a arquitetura proposta pela engenharia de software. As ferramentas disponíveis para os analistas dão apoio a todas as fases de desenvolvimento. São ferramentas bem elaboradas e baseadas nas boas práticas da engenharia de software. Tais práticas se referem à aplicação de alguns princípios tais como: modularidade e abstração, confiabilidade, robustez e facilidade de manutenção. Os projetistas de interface não dispõem de ferramentas que lhes auxiliem da mesma forma. Seu trabalho emprega ferramentas rudimentares, basicamente editores gráficos, desprovidos de uma lógica mais aprofundada e desconexos face o desenvolvimento da aplicação [CYBIS, 1997]. Um sistema interativo tem que ter funcionalidades bem claras e ser fácil de usar, mas também precisa ser robusto e fácil de manter. Um sistema que não possui estas características não apresenta qualidade, nem do ponto de vista de IHC, nem da engenharia de software. Para conseguir um sistema com as qualidades acima é necessária uma metodologia de desenvolvimento integradora dos processos do design de interfaces, baseados nos conceitos de IHC, e dos processos de analistas e projetistas baseadas na engenharia de software. 13
- Metodologias de Desenvolvimento de software Evolução Esta seção apresenta a evolução das metodologias de desenvolvimento de software [AVISION E FITZGERALD, 2003]. O desenvolvimento de software tem se mostrado uma das atividades mais desafiadoras. Apesar de não ser uma prática nova, ainda é muito difícil conseguir concluir um projeto de desenvolvimento de software dentro do prazo, com o custo programado, com todos os requisitos satisfeitos e com qualidade. Inicialmente o desenvolvimento de software acontecia sem seguir nenhuma metodologia de trabalho. As atividades eram caracterizadas pela codificação e conserto. Os programadores não tinham noção do negócio o qual a aplicação se referia e os requisitos dos usuários não eram levados em consideração. Era preferível manter os sistemas existentes a desenvolver novos sistemas e atender as necessidades dos usuários, que estão sempre em evolução. Em projetos pequenos essa abordagem funcionava. Mas com o passar do tempo, as aplicações computacionais ganharam mais adeptos e assim os softwares se tornaram maiores e mais complexos. Devido à abordagem limitada e individualista que os programadores tinham do sistema, era difícil conseguir um controle e gerenciamento do projeto. As limitações existentes mostraram a necessidade de padrões e de uma abordagem mais disciplinada, eficiente e previsível para o desenvolvimento de sistemas nas organizações. O resultado foi a criação das primeiras técnicas de desenvolvimento baseadas na identificação de fases e estágios, que permitia maior controle do desenvolvimento de sistemas e introduzia disciplina. Essa abordagem tornou-se 14
conhecida como ciclo de vida do desenvolvimento de sistemas. A primeira abordagem ficou conhecida como modelo cascata, e consiste em uma seqüência de estágios de desenvolvimento executados de forma ordenada, onde o resultado de uma era requerido para o início da outra. Esta metodologia possuía limitações que fazia com que os sistemas fossem inadequados às reais necessidades de negócio, instáveis devido às mudanças no negócio, inflexíveis e com problemas de documentação. Várias abordagens apareceram em resposta a uma ou mais dessas limitações. O termo Metodologia foi primeiramente utilizado para descrever o conjunto dessas diferentes abordagens. Ferramentas de apoio às abordagens existentes foram criadas. Entre elas: softwares de gerenciamento de projetos, sistemas repositórios, ferramentas de desenho, e ferramentas assistentes de construção de software. Apesar da propagação do uso de metodologias na época, nem todas as organizações utilizavam-se delas. Pesquisas estatísticas mostravam que as metodologias estavam sendo usadas, mas não as conhecidas comercialmente. A grande maioria afirmava adaptar as metodologias as suas próprias necessidades. Com o passar do tempo algumas organizações continuaram a mudar as abordagens de desenvolvimento, e outras abandonaram por completo. As metodologias não estavam atendendo aos benefícios desejados, como o aumento da produtividade. Os insatisfeitos pregavam que as metodologias eram complexas, e direcionadas para projetos grandes. Elas requeriam pessoas com maiores qualificações técnicas, e suas ferramentas de apoio eram caras e difíceis de usar. 15
O uso das metodologias levava os desenvolvedores a se focarem mais no cumprimento das atividades impostas ao invés de se concentrarem na real constatação dos problemas do negócio. Isso gerou dificuldades em se adotar metodologias nas organizações. Para as organizações o problema é a inadequação dos métodos existentes. Isso faz com que elas procurem por formas diferentes e melhores de conduzir o seu desenvolvimento, ou procurem por alternativas para as metodologias existentes, como o desenvolvimento com ferramentas que incluem a geração automática do código, abordagem orientada a objeto e desenvolvimento incremental. Este trabalho mostrará alternativas para as metodologias OO usando a UML e que visam desenvolver sistemas interativos mais centrados no usuário. - UML Com o surgimento e a aceitação das linguagens de programação orientadas a objeto veio a necessidade de métodos que oferecessem suporte a todas as fases de desenvolvimento contendo as mesmas facilidades que as linguagens de programação. Alguns métodos de orientação a objeto se popularizaram, mas cada um com seus próprios conceitos, notações e terminologias. Um problema para os apreciadores da analise orientada a objeto era a falta de uma notação padrão que englobasse qualquer tipo de aplicação. A Unified Modeling Language 1 (UML) surgiu trazendo a padronização para as notações utilizadas na análise orientada a objeto. E com ela novos conceitos para o desenvolvimento de sistemas, pois não é apenas aprender uma simbologia e seu significado, mas também aprender a modelar orientado a objeto. 1 OMG-Unified Modeling Language, v1.5 16
Seus criadores desenvolveram três metodologias de modelagem orientadas a objeto bem conceituadas, e a UML se caracteriza pela junção do que havia de melhor nestas três metodologias, adicionando novos conceitos e visões da linguagem, de modo que o sistema possa ser modelado corretamente, fácil de se comunicar com outras aplicações e de fácil entendimento a todos. Na UML foram definidas visões, onde cada visão representa uma visão do sistema como um todo. As visões da UML são a visão de casos de uso, visão lógica, visão de componentes, visão de processo e visão de distribuição. A visão de casos de uso mostra a funcionalidade do sistema como é percebida pelo usuário. Esta visão utiliza os diagramas de casos de uso e de seqüência, e consegue traduzir o problema e a solução de uma forma que o usuário pode compreender. A visão lógica utiliza os diagramas de classes e de estado e mostra como as funcionalidades são construídas no sistema através de estruturas estáticas e do seu comportamento. A visão de componentes mostra a organização dos componentes do código e utiliza o diagrama de componentes. A visão de processo mostra a concorrência que ocorre no sistema, apresentando problemas de comunicação e de sincronização. Esta visão utiliza o diagrama de atividades. A visão de distribuição mostra como o sistema está alocado fisicamente pelos computadores e dispositivos. 17
A UML tornou-se a linguagem padrão para especificar, documentar e construir sistemas, podendo ser usada em todas as fases de desenvolvimento dos ciclos de vida e com diferentes linguagens de implementação. UML é uma linguagem e não uma metodologia. Assim suporta diferentes métodos de trabalho, que podem ser criados pelos desenvolvedores que a utilizam. A UML busca criar uma linguagem de modelagem compreensível tanto pelo homem quanto pela máquina, descrevendo o sistema em termos de diagramas, os quais serão vistos mais adiante. 1.2 Motivação Considerando a problemática da utilização de metodologias de desenvolvimento de software apresentada anteriormente, é pertinente uma verificação nas existentes alternativas para se perceber que métodos elas estão propondo para facilitar tal utilização. O fato de utilizarem a UML como linguagem de especificação de software já é uma alternativa para a adoção de uma metodologia. A UML vem sendo considerada como padrão no mercado para especificação de software. A propagação da UML trás a tona questionamentos de como ela poderá ser usada para modelar aspectos de IHC. Assim escolhemos metodologias de desenvolvimento de software que utilizem a UML para representar os produtos. Além de verificar o lado dos desenvolvedores, procurando metodologias de fácil adoção é importante verificar o lado do usuário, analisando que metodologias propõem a construção de software centrados no usuário. Assim a motivação deste trabalho foi fundamentada na necessidade de se analisar metodologias que sejam 18
fáceis de usar pelos desenvolvedores e que apõem a construção de sistemas mais fáceis de usar e aprender. 1.3 Objetivo Principal O principal objetivo deste trabalho é estudar como os aspectos de IHC estão sendo incorporados aos novos processos de desenvolvimento de software, estudando as metodologias de desenvolvimento de software que utilizam a UML como notação de seus produtos e que se baseiam nos conceitos de IHC para produzir sistemas mais usáveis. Para atingir este objetivo será necessário desempenhar as seguintes atividades: estudar conceitos de IHC, conhecer metodologias de desenvolvimento de software que apliquem UML, definir critérios de comparação e comparar. 1.3.1 Estudar conceitos de IHC Os conceitos de IHC estudados são os conceitos que devem ser aplicados às metodologias de desenvolvimento para que desempenhem de forma satisfatória a produção de sistemas usáveis e que reflitam as necessidades de seus usuários. Os conceitos de IHC estudados neste trabalho são: projeto centrado no usuário, sistemas adaptativos, modelagem de interfaces, arquitetura de interfaces de usuário e testes de usabilidade. 1.3.2 Conhecer Metodologias de Desenvolvimento de Software aplicando UML As metodologias de desenvolvimento que foram selecionadas para estudos, utilizam a UML como notação padrão e se fundamentam no princípio de independência do diálogo homem-computador. 1.3.3 Definir critérios de comparação 19
Os critérios de comparação escolhidos podem ser divididos quanto à IHC e quanto à engenharia de software. Quanto à IHC, os conceitos citados são: projeto centrado no usuário, sistemas adaptativos, modelagem de interfaces, arquitetura de interfaces de usuário e testes de usabilidade. Quanto à engenharia de software, os critérios são: fases de desenvolvimento, diagramas de UML e apoio de ferramentas. 1.3.4 Comparar A comparação acontecerá de forma descritiva e resumida. Fornecendo um panorama dos critérios de comparação já apresentados de cada metodologia, destacando o que há de melhor e como cada uma pode ser mais bem utilizada. 1.4 Estrutura da Monografia Para descrever os objetivos usados no transcorrer desta monografia, este trabalho estruturado da seguinte maneira. O primeiro capítulo contém a apresentação dos conceitos iniciais relevantes para este estudo e uma visão geral da organização deste trabalho. No segundo capítulo encontra-se a apresentação dos conceitos de IHC mencionados na seção 1.3.1. O terceiro capítulo apresenta conceitos da engenharia de software que fundamentam os estudos sobre as metodologias de desenvolvimento. O quarto capítulo descreve as características de cada uma das metodologias estudadas. E finalmente, o quinto capítulo faz uma comparação descritiva das metodologias estudadas e descreve a perspectiva para trabalhos futuros. 20
Capítulo 2 CONCEITOS DE IHC Os conceitos de IHC apresentados neste capitulo são: Projeto centrado no usuário, Sistemas adaptativos, Modelagem de interfaces, Arquitetura de interfaces 21
e Testes de usabilidade. A junção destes conceitos de IHC, com as técnicas para construção de sistemas da engenharia de software têm o objetivo de construir de sistemas mais úteis e que se aproximam mais das reais necessidades dos usuários. Como conseqüência, temos a satisfação do usuário, fazendo com que o trabalho em frente aos computadores se torne mais amigável e produtivo e não seja considerado um obstáculo. Figura 01 Conceitos de IHC relevantes para o design de interfaces de usuário. 2.1 Projeto centrado no usuário Inicialmente, os sistemas obrigavam seus usuários a falarem a mesma linguagem do computador. Atualmente, os sistemas e os computadores são ferramentas que auxiliam e aumentam a produção de seus usuários. Um dos objetivos dos pesquisadores de IHC é mostrar aos desenvolvedores que não basta focar seus esforços no sistema e sua interface, mas no usuário e no processo de interação que eles participam. Essa abordagem visa minimizar problemas de interação usuário-sistema, tais como incompatibilidade da interface com as capacidades e limitações dos usuários, interfaces difíceis de usar e aprender, problemas ergonômicos e de usabilidade. Integrar os usuários em todo 22
o processo de desenvolvimento ajuda a desmistificar o processo de implantação de novas tecnologias. O conceito de projeto centrado no usuário tem como característica o envolvimento do usuário durante todo o processo de construção do sistema e tem seu formalismo definido na ISO 13407. Envolver o usuário em todas as fases de desenvolvimento auxilia na construção de sistemas que atendam as expectativas dos seus usuários. Os usuários podem priorizar os requisitos mais essenciais, validar design de interfaces, fazer levantamento de problemas e de requisitos de qualidade. Assim o usuário está no controle, o que lhes proporciona maior aprendizado nos processos contidos no sistema e na ferramenta que está sendo desenvolvida. Essa abordagem centrada nos usuários é uma alternativa para envolvê-los diretamente no processo de desenvolvimento, não os deixando apenas conhecendo a versão final, que pode ser insatisfatória. Nas abordagens tradicionais onde os usuários participam apenas das fases de levantamento de requisitos aumenta o risco de se desenvolver sistemas não bem definidos e mais dispendiosos para futuros reparos. Seguindo os conceitos e métodos definidos pela engenharia de software, o projeto de um sistema é focado na arquitetura e implementação deste. No projeto centrado no usuário, base do trabalho de IHC, o foco passa a ser nas necessidades dos usuários finais e nos aspectos que os cercam. Existem alguns princípios que caracterizam o desenvolvimento centrado no usuário. São eles: entender os usuários, projetar toda a experiência do usuário, avaliar o projeto, avaliar a competitividade e gerenciar usuários [CLEMENTS, 1999]. 23
Os desenvolvedores devem entender os usuários, como eles desempenham suas atividades e como podem melhorá-las. O desenvolvimento de um sistema interativo deve considerar a experiência do seu usuário, tornando-o atraente e de fácil uso. Em projetos centrados no usuário são comuns técnicas de avaliação, onde só é codificado o que é validado pelo usuário, gerando um desenvolvimento eficaz. O novo produto deve ser avaliado também em relação a soluções anteriores e concorrentes. Essas informações devem ser usadas para construção de um produto com maior grau de aceitabilidade. É papel do desenvolvedor despertar o envolvimento dos usuários, deixar os usuários cientes da sua participação na tomada de decisão, escolher usuários apropriados para realização de testes em módulos específicos, motivar os usuários para definição de critérios de avaliação. Algumas atividades do projeto centrado no usuário devem ser desempenhadas no processo de sistemas interativos: especificar o contexto do usuário, especificar os requisitos do usuário e da organização, produzir projetos com propostas de soluções e avaliar o projeto de acordo com os requisitos [BEVAN, 2001]. 2.2 Sistemas adaptativos fatores humanos As interfaces devem ser capazes de se adaptarem às necessidades dos seus operadores, com o intuito de melhorar a comunicação do usuário com o sistema. Os estudos na área de projeto de interfaces adaptativas se baseiam nos modelos cognitivos. Esses modelos tentam entender o comportamento humano. 24
Pesquisadores de IHC defendem a idéia de que os projetistas devem analisar cuidadosamente a comunidade de usuários e o conjunto de tarefas a serem realizadas como base para estabelecer referências aos fatores humanos no projeto de interface [VIEIRA, 2001]. Considerar fatores, como tempo para aprender e grau de erros, ajuda a construir interfaces mais apropriadas ao universo dos usuários da aplicação. Alguns fatores humanos podem ser medidos para avaliar a qualidade de interação do usuário. São eles [VIEIRA, 2001]: Tempo para aprender: quanto tempo o usuário leva para aprender a executar as atividades necessárias para suas tarefas. tarefas. Velocidade da performance: quanto tempo o usuário leva para realizar suas Grau de erro: quantos e quais erros o usuário comete ao realizar uma tarefa. Retenção após tempo: avalia o nível de assimilação do conhecimento pelo usuário sobre suas tarefas no decorrer do tempo. sistema. Satisfação subjetiva: quantifica a aceitação e satisfação do usuário quanto ao No projeto de interfaces adaptativas devem ser considerados critérios ergonômicos para conseguir a adequação aos fatores humanos. A ergonomia propõe soluções para o desenvolvimento de softwares interativos que sejam adaptados a seus usuários e adequados a suas tarefas [CYBIS, 1998]. O critério adaptabilidade é medido por dois conceitos: flexibilidade e consideração da experiência do usuário. 25
A flexibilidade diz respeito às diferentes formas que o usuário pode alcançar um objetivo. É a capacidade da interface de se adaptar às diversas ações que o usuário venha a desempenhar. A flexibilidade leva em consideração as estratégias e hábitos de trabalho dos seus usuários. A implementação deve respeitar o nível de experiência do usuário. Para usuários principiantes a interface deve ser clara e simples, mensagens de erro sucintas e de fácil compreensão. Usuários esporádicos necessitam de interfaces com tarefas que sejam fáceis de recordar e de manuais concisos. Os usuários freqüentes requerem uma interação rápida, comandos poderosos e mensagens de erros breves. 2.3 Modelagem de interfaces estilos de interação A interface de usuário é um combinado de hardware e software que traduzem um modelo de interação. Um modelo de interação é um conjunto de protocolos que permite ao usuário interagir com a aplicação. Determina as atividades mentais e físicas que o usuário deve desempenhar, bem como os processos computacionais que o software da interface deve ter para interpretar os comandos a dados do sistema [LEITE, 2001]. O modelo de interação representa as ações que o usuário executa e como elas podem ser combinadas para que ele possa interagir com o sistema. As características dos modelos de interação são determinadas pela maneira que combinam os padrões, estilos e técnicas de interação. Os padrões de interação se referem aos aspectos da interface que determinam como o usuário deve ver e agir. É um conjunto de regras para manter consistente a aparência e comportamento das interfaces gráficas. 26
Os estilos de interação mais comuns são [LEITE, 2001]: Linguagem de comando: neste estilo as instruções são enviadas ao sistema através de comandos pré-determinados que são interpretados e executados pelo software. Cada comando, ou combinação de comando correspondem a funções especificas da aplicação. Os comandos são construídos a partir da gramática que define a linguagem. Neste estilo de interface o usuário toma a iniciativa, cabendo ao sistema executar a instrução apropriada e apresentar os resultados obtidos. As linguagens de comando oferecem maior flexibilidade aos usuários, mas podem dificultar o aprendizado de usuários iniciantes. A falta de padronização dos sistemas que utilizam esse estilo é um fator para a dificuldade. Mas usuários experientes conseguem maior produtividade através de linguagem de comando. Menus: Neste estilo as funções do sistema são mostradas na tela para que o usuário escolha. Em aplicações contendo grande número de funções, as opções do menu podem ser agrupadas e se apresentam de forma hierárquica. O agrupamento das funções deve ser de forma bem definida e de fácil entendimento pelo usuário, para que ele não acabe se perdendo na navegação. Linguagem natural: as interfaces em linguagem natural permitem que a interação do usuário com o sistema seja feita usando sua própria linguagem. O esforço de interpretação é de responsabilidade do computador e não mais do usuário. Este estilo de interação não se aplica a todos os tipos de sistemas, devido à complexidade da interpretação por parte do computador. É mais utilizado em sistemas de consulta e em sistemas baseados em conhecimento, mesmo assim 27
limitando o vocabulário das sentenças para diminuir a complexidade de processamento. Preenchimento de formulário: este estilo é mais utilizado em aplicações que manipulam e consultam bases de dados e se baseiam no preenchimento de formulários com informações características do domínio da aplicação. As interfaces deste estilo são de fácil aprendizado pelo usuário, já que muitas vezes são baseadas em formulários já conhecidos por ele. Mas não dão muita flexibilidade ao usuário. Manipulação direta: a manipulação direta permite que os objetos que compõe a interface sejam acionados diretamente sem a necessidade de comandos. Isso ocorre, por exemplo, quando o usuário manipula com ícones que representam componentes como arquivos e diretórios. GUI/WINP: este estilo permite a interação através de componentes de interação chamados de widgets. É implementado pela tecnologia de interfaces gráficas, e utiliza janelas, ícones, menus e ponteiros. Por ser uma combinação de hardware e software permite a utilização de vários estilos, sendo assim não é considerado um único estilo, mas a junção de alguns deles. Podem ser utilizados estilos de menus, manipulação direta, preenchimento de formulário e linguagem de comando. Hipertexto: o hipertexto é um modelo de estruturação de documentos que permite ao usuário a visualização de documentos e a navegação para outros documentos que estão, ligados a ele utilizando-se de elos (links). A crescente utilização de hipertexto veio da popularização da internet, onde a construção de sistemas é feita de acordo com este modelo. 28
2.4 Arquitetura de interfaces As arquiteturas são estruturas de organização do sistema segundo um modelo onde estão inseridos e especificados os seus componentes, as interfaces e as formas de comunicação entre estes [SAVIDIS & STEPHANIDIS, 2001]. Dentre os modelos de arquitetura, existem: Seeheim, Arco, MVC, PAC e PAC- Amodeus. Já é consenso no projeto de sistemas interativos a divisão entre a interface de usuário e a aplicação. No modelo Seeheim [COUTAZ, 1993] a interface é dividida em três módulos: Apresentação, Controle de Diálogo e Interface com a Aplicação, além da aplicação. Como mostrado na figura 02. Figura 02 Modelo Seeheim. Na aplicação estão as funções e dados relativos ao domínio do sistema. No módulo de apresentação estão representados os componentes e objetos que compõe a interface do sistema com o usuário. O controle de diálogo é responsável por fazer o intercambio de dados entre a camada de aplicação e apresentação, nele estarão as decisões de quais funções serão executadas dependendo o contexto da interação. O módulo de interface com aplicação é responsável por realizar, explícita e exclusivamente, a comunicação entre a interface e a aplicação. A arquitetura Arco [COUTAZ, 1993] é dividida em camadas: Domínio, Adaptador de domínio, Controle de diálogo, Apresentação e Dispositivos de interação (Toolkit), como apresentado na figura 03. A camada de Domínio realiza 29
as tarefas, armazenando funções e dados da aplicação. O Adaptador de domínio serve como mediador entre o domínio e o Controle de diálogo, cuja função é controlar a comunicação entre Domínio e os Dispositivos de interação. A Apresentação fornece os objetos de interação, independentes dos Dispositivos de interação, por exemplo: um objeto seletor pode ser implementado através de menus ou botões. Figura 03 Modelo Arco. As arquiteturas MVC, PAC e PAC-Amodeus são exemplos de arquiteturas baseadas em agentes. Isto significa que o sistema é organizado em um conjunto de agentes especializados que descentralizam as execuções das funções de um sistema interativo e cooperam entre si para realizá-las. A arquitetura MVC(Model View Controller) [SAVIDIS & STEPHANIDIS, 2001] divide a interface em objetos pertencentes as classes Modelo(Model), Visão(View) e Controle(Controller). Um objeto Modelo representa o modelo de dados manipulados pela aplicação, tais como, as tabelas de uma base de dados. Um objeto Visão é uma apresentação de um objeto modelo. Pode haver vários objetos Visão associados a um objeto modelo, pois podem existir várias apresentações para o mesmo objeto modelo. Os objetos Controle são responsáveis pela interpretação das ações dos usuários. Eles recebem as entradas dos usuários, decidem o que fazer e chamam os métodos de objetos Modelo quando necessário. 30
Figura 04 Modelo MVC. A arquitetura PAC (Presentation Abstraction - Control) [BAS & COUTAZ, 1991] organiza o sistema em uma hierarquia de agentes, como mostra a figura 05. Cada um destes agentes possui três partições: Apresentação, Abstração e Controle. A Apresentação é a interface do agente com o usuário, a Abstração implementa as funções do domínio da aplicação. O controle une a Apresentação e Abstração, pois representa um meio de comunicação entre ambos, e entre agentes PAC. Figura 05 Modelo PAC. A arquitetura PAC-Amodeus [COUTAZ, 1993] [NIGAY, 1994] é uma arquitetura híbrida. Como apresentado na figura 06, esta arquitetura utiliza a arquitetura Arco, vista anteriormente, como base para divisão funcional do 31
sistema. A diferença está no Controle de diálogo, que é organizado em agentes, segundo o modelo PAC. Figura 06 Modelo PAC-Amodeus. 2.5 Testes de usabilidade fatores O conceito de usabilidade foi definido na norma ISO 9241-11 como a capacidade de um produto ser usado por usuários para atingir objetivos específicos com eficácia, eficiência e satisfação em um contexto específico de uso. Em outras palavras, usabilidade é a medida de quanto é utilizável um sistema computacional, se ele atende aos anseios de seus usuários de forma eficaz e se está de acordo com suas tarefas. Essa medição é feita para um contexto específico do sistema. Interfaces onde o usuário trabalha de forma desagradável, ineficiente ou que o impede de atingir seus objetivos está com problemas de usabilidade, o que pode gerar rejeição e abandono do sistema. Alguns exemplos de problemas de 32
usabilidade são os seguintes: erros de projeto que impedem o usuário de atingir suas metas, informações insuficientes ou ambíguas que dificultam o aprendizado do usuário. Ultimamente é crescente a preocupação em atender as boas práticas da usabilidade. Desempenho, satisfação e facilidade de aprendizado são algumas das características exigidas no mercado, pois trazem com elas maior produtividade e eficiência no trabalho. Buscando detectar e minimizar os problemas com usabilidade, avaliações são feitas por meio de testes. O objetivo do teste é medir quantativamente o valor alcançado pelo sistema em cada um dos fatores de usabilidade [SOUZA, 1999]. Segundo Souza alguns desses fatores são: Facilidade de aprendizado: tempo e esforço necessário para que os usuários realizem suas tarefas atingindo seus objetivos. Facilidade de uso: avalia o esforço físico e cognitivo do usuário durante a interação, medindo velocidade e números de erros cometidos durante a execução de uma tarefa. Satisfação do usuário: avalia se o usuário gosta de trabalhar no sistema. Flexibilidade: avalia a possibilidade de o usuário acrescentar e modificar as funcionalidades do sistema. Mede a capacidade do usuário utilizar o sistema de forma criativa, realizando tarefas que não estavam previstas. Produtividade: verifica se o sistema permite ao usuário ser mais produtivo do que seria se não o utilizasse. 33
É complicado alcançar bons resultados em todos os fatores. Sendo assim, cabe ao projetista identificar quais fatores são prioritários, dependendo do contexto de uso da interface em questão. A avaliação de usabilidade pode ser realizada em qualquer fase do desenvolvimento. Na fase inicial, serve para identificar parâmetros ou elementos a serem implementados no sistema; na fase intermediária, é útil na avaliação ou refinamento do projeto; na fase final, assegura que o sistema atenda aos objetivos e necessidades dos usuários [DIAS, 2002]. 2.6 Conclusão Os conceitos de IHC estudados visam a construção de sistemas mais fáceis de usar e aprender seja trazendo o usuário para próximo do processo de desenvolvimento, ou incorporando às interfaces características físicas e cognitivas dos mesmos. O projeto centrado no usuário busca envolver o usuário em todo o processo de desenvolvimento de software, fazendo com que o foco do projeto de software seja as necessidades dos usuários e suas tarefas. Desta forma, a versão final do software estará mais próxima dos requisitos dos usuários. Para melhorar a interação entre o usuário e o sistema, o conceito de sistemas adaptativos deve ser aplicado. Os usuários finais e suas tarefas devem ser analisados para que as interfaces possam ser adaptadas as características dos usuários e de suas tarefas, sendo então avaliados alguns fatores humanos para garantir a qualidade na interação, tais como: tempo para aprender e grau de erros. O modelo de interfaces faz um elo entre as tarefas dos usuários e os componentes de software da interface através da definição dos estilos de 34
interação. As ações que serão executadas pelos usuários indicaram quais processos deverão ser contemplados pelo software. A definição de um modelo de arquitetura de interface apropriada ao software é uma parte importante no projeto de interface de usuário, já que sem uma estrutura adequada a construção de sistemas interativos pode se tornar difícil, o software resultante é difícil de manter e o refinamento iterativo é impossível de ser feito. A aplicação dos conceitos estudados visa atingir a usabilidade do sistema, ou seja, fazer com que o sistema proporcione um trabalho eficaz, eficiente e satisfatório. Tais características têm se tornado um diferencial nos softwares construídos com a aplicação dos conceitos citados e para medir a usabilidade testes são executados, considerando fatores como: facilidade de aprendizado e produtividade. 35
Capítulo 3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Alguns conceitos da engenharia de software são importantes para fundamentar nosso estudo à cerca das metodologias de desenvolvimento de software, que considerem em seu processo aspectos de IHC. Alguns deles são apresentados neste capitulo, como: definição de processo, metodologia e método, ciclo de vida, abordagens de desenvolvimento, fases de desenvolvimento de software do processo tradicional e a relação entres estas fases e os diagramas da UML. 3.1 Definições 36
Nesta seção são apresentadas definições fundamentais para o entendimento do desenvolvimento de sistemas. Normalmente, se faz muita confusão com a terminologia usada. As palavras processo, metodologia e método precisam ser compreendidas de maneira correta. PROCESSO Existem diversas definições para processo, as quais estão descritas abaixo. Um processo de desenvolvimento de software é um conjunto de passos ordenados que devem ser seguidos para atingir um determinado objetivo; em engenharia de software, o objetivo é um produto de software novo ou a evolução de um existente [BALDUINO, 2002]. O processo de desenvolvimento de software define quem faz o quê, como e quando para atingir a meta de construir ou melhorar um produto de software. Ele permite reduzir os riscos e aumentar a previsibilidade. O processo de desenvolvimento deve ser capaz de evoluir para utilizar os avanços das tecnologias, ferramentas e padrões de desenvolvimento de um dado momento. De um modo geral o processo de desenvolvimento deve conter um roteiro para ordenar as atividades da equipe, dirigir as tarefas de cada desenvolvedor e da equipe como um todo, especificar os produtos a serem desenvolvidos e fornecer critérios para monitorar e medir produtos e atividades dos projetos. Adotar um processo de desenvolvimento muitas vezes não é uma tarefa muito fácil de se realizar. O processo de desenvolvimento age diretamente na maneira como os indivíduos trabalham. Portanto, essa adoção deve ocorrer de forma gradativa, onde cada passo deve ser planejado e gerenciado. 37
Um dos processos de desenvolvimento amplamente estudado hoje em dia é o RUP Rational Unified Process. Proposto pelos mesmos criadores da UML, o RUP descreva os papéis e as atividades que a equipe deve desempenhar ao longo do ciclo de desenvolvimento e o que deve ser gerado como resultado dessas atividades, os artefatos, que são na grande maioria modelos que utilizam a UML como notação. O RUP possui três conceitos básicos: é dirigido por casos de uso, é centrado na arquitetura e é iterativo e incremental. No RUP os casos de uso são a base para as atividades de análise, design, implementação e testes, eles capturam os requisitos funcionais de um sistema na perspectiva de cada usuário. A arquitetura do software mostra aspectos estáticos e dinâmicos de um sistema. A arquitetura é influenciada pelos casos de uso, hardware e software, frameworks e sistemas existentes. Enquanto os casos de uso correspondem às funcionalidades do sistema, a arquitetura corresponde à forma do sistema. No RUP o trabalho dos desenvolvedores é dividido em mini projetos, que vão evoluindo através de iterações, até atingirem as metas do projeto. O ciclo de vida do RUP é na verdade uma série de ciclos que são executados até a finalização do projeto. Cada ciclo é dividido em quatro fases: concepção, elaboração, construção e transição. Cada fase se encerra com um marco, que é definido por um conjunto de modelos e documentos e ajudam a controlar a evolução do trabalho de desenvolvimento, já que define critérios para o término de uma fase e o início da outra. 38
Na fase de concepção ocorre o entendimento dos requisitos e a determinação do escopo do desenvolvimento. São executadas atividades como construção simplificada do diagrama de casos de uso, esboço da arquitetura e identificação dos principais riscos. Na fase de elaboração, o domínio do problema é analisado, a arquitetura do sistema é determinada e o planejamento do projeto é desenvolvido. Na fase de construção, o foco é o projeto e a implementação. Ao final desta fase o produto contém todos os casos de uso previstos para aquela versão. A fase de transição consiste em colocar o produto à disposição da comunidade de usuários. Os usuários são treinados e o produto é testado por eles. Neste momento ocorre a validação do produto de acordo com as expectativas dos usuários. METODOLOGIA Metodologia é um conjunto recomendado de fases, procedimentos, regras, técnicas, ferramentas, documentos, gestão e treinamento para desenvolvedores de sistemas [AVISON & FITZGERALD, 2003]. MÉTODO Um método organiza uma série de operações que devem ser realizadas, apontando os possíveis erros, para se chegar a um determinado objetivo. 3.2 Ciclo de Vida O ciclo de vida do software é um modelo que envolve o conjunto de atividades realizadas desde a idéia de concepção, desenvolvimento do software, o 39
processo de manutenção após a sua entrada em operação até o momento em que não será mais útil. O ciclo de vida define as fases que o software passa, o relacionamento entre elas, os produtos gerados em cada uma e os critérios para ir de uma fase a outra. Tem como objetivo integrar aspectos gerenciais e tecnológicos na área de concepção, desenvolvimento e manutenção de software, definir as atividades a serem executadas em um projeto de desenvolvimento de sistemas, oferecer uma padronização aos vários projetos de uma mesma organização e introduzir pontos de verificação durante o andamento do projeto. O ciclo de vida introduziu importantes qualidades ao desenvolvimento como, fazer com que o processo seja conduzido de forma disciplinada, com atividades bem definidas e os requisitos para desempenhá-la permitindo o gerenciamento do projeto. De um modo geral o modelo de ciclo de vida do software compreende as atividades de análise do problema e definição dos requisitos, o desenho da solução, a codificação, os testes e a manutenção. seguir. Os enfoques mais comuns de modelos de ciclo de vida são descritos a 3.2.1 Modelo Tradicional ou Em Cascata Divide o desenvolvimento em fases que são executadas seqüencialmente, especifica o conjunto de documentos que são resultado de cada fase, onde a saída de uma é a entrada para próxima. Suas fases principais são: Análise, Projeto, Implementação, Teste e Manutenção. 40
Na fase de análise são definidos os requisitos do sistema. O analista inicia buscando compreensão do domínio do problema, partindo assim para a documentação dos requisitos que são posteriormente validados pelo usuário. Esta fase está concluída quando se tem uma descrição completa de como o software se comporta, a especificação dos requisitos. A fase de projeto consiste nas atividades que constroem a estrutura de dados, arquitetura do software e projeto de interface. Ela responde como podem ser feitos os requisitos levantados na fase anterior. O projeto traduz os requisitos em uma representação técnica para que possa ser implementado. Na implementação o projeto é codificado usando uma linguagem de programação e cada um dos programas é testado individualmente. A fase de testes valida as funcionalidades do sistema, verificando se ele gera os resultados esperados para cada operação. Tem como objetivo encontrar os erros, mas não podem assegurar a correção total do sistema. Somente após uma avaliação satisfatória do sistema é que poderá ser implantado para operação dos usuários. Mesmo tendo sido testado o sistema ainda poderá passar por alterações devida a erros encontrados pelos usuários, ou mudanças das regras e requisitos, ou por problemas de desempenho. Estas alterações correspondem à fase de manutenção. Este modelo é adequado quando é possível identificar a maior parte dos requisitos no inicio do desenvolvimento. Porém é criticado por ser linear e rígido. O modelo determina que uma fase só pode ser iniciada quando a anterior for terminada. 3.2.2 Modelo Evolutivo (Prototipação) 41
Neste modelo o software é desenvolvido de forma gradativa, mostrando uma perspectiva do funcionamento do sistema antecipadamente. Esta apresentação é feita na forma de protótipos. A prototipagem é uma técnica para desenvolver e produzir, de forma rápida, partes do sistema quer podem ser utilizadas pelos usuários para avaliação ou operação. A idéia é desenvolver partes do software e ir incrementando com novas patês, ou evoluções das partes já disponíveis, até que todos os requisitos sejam contemplados. Como é um modelo alternativo do modelo cascata, as fases de análise, projeto, implementação e teste, são realizadas repetidas vezes, incrementando e agregando valor ao que já foi produzido em fases anteriores, até que se chegue ao produto final esperado. A grande vantagem deste modelo está em permitir a visualização antecipada do produto final, iniciando com isso a detecção e correção de erros. A arquitetura do sistema a ser desenvolvido deve ser flexível para suportar as possíveis mudanças cada vez que um ciclo é percorrido. Essa flexibilidade que modelo dispõe pode levar a softwares mal documentados e com arquitetura mal definida. Como os requisitos podem ser alterados a cada incremento fica muito difícil estimar prazos e custos, e planejar as atividades de desenvolvimento. 3.2.3 Modelo Espiral O modelo espiral assume características dos modelos já discutidos anteriormente, por isso é considerado um MetaModelo. Neste modelo pode-se utilizar prototipação, desenvolvimento evolutivo e as principais fases do modelo cascata. 42
Sua inovação vem da análise de risco e do planejamento que ocorre a cada término de ciclo. Para detecção dos riscos, que são circunstâncias adversas que podem acontecer durante o desenvolvimento, é necessária a participação de gerentes e técnicos experientes, para que desempenhem da melhor forma esta atividade. O modelo espiral começa com a elaboração dos objetivos do produto. Logo após, as alternativas de desenvolvimento, para obtenção dos objetivos levantados, são avaliadas e os riscos são identificados. Quando a abordagem a ser identificada é determinada, se continua o desenvolvimento, após a avaliação, ocorre o planejamento para próxima fase, onde as atividades se repetem: elaboração dos objetivos, desenvolvimento, avaliação dos riscos e planejamento para a próxima fase. Em cada uma das fases é possível escolher um modelo diferente de ciclo de vida que seja mais adequado às características da fase. O modelo define os estágios de planejamento, análise de requisitos, engenharia e avaliação. No planejamento são determinados os objetivos, as alternativas e restrições. A análise avalia as alternativas e identifica os possíveis riscos, com isso permite definir a melhor estratégia a ser adotada. Na engenharia é realizado o desenvolvimento e a verificação do produto. Na avaliação o cliente revisa os resultados obtidos na engenharia e é elaborado o planejamento da próxima fase, se houver. 3.3 Abordagens Como já discutido anteriormente, o processo de desenvolvimento de software acontecia sem nenhuma técnica de projeto, controle de qualidade ou documentação. Sendo a complexidade uma característica inerente aos sistemas de software, a falta de uma abordagem mais disciplinada levava os projetos a atrasos e estouro de orçamento. 43