PROPOSTA DE MÉTODO DE ANÁLISE DA TAREFA PARA ENSINO EM CURSOS DE GRADUAÇÃO EM DESIGN GRÁFICO
|
|
- Ronaldo Lacerda Lisboa
- 7 Há anos
- Visualizações:
Transcrição
1 SSN ISSN Ano V.17 N PROPOSTA DE MÉTODO DE ANÁLISE DA TAREFA PARA ENSINO EM CURSOS DE GRADUAÇÃO EM DESIGN GRÁFICO Stephania Padovani 1 Kelli Cristine Assis Silva Smythe 2 Resumo Este estudo tem como objetivo desenvolver uma nova versão de método de análise da tarefa para ensino em cursos de graduação em Design Gráfico. A intenção é que o método seja o mais abrangente possível para que o aluno possa praticar todas as atividades existentes nos diversos enfoques de análise da tarefa (e.g., identificação de atividades, requisitos funcionais/informacionais e erros potenciais). De modo a atingir tal propósito, o desenvolvimento estruturou-se em quatro fases: identificação de dificuldades na aprendizagem de análise da tarefa; estudo analítico de métodos de análise da tarefa; proposta de método de análise da tarefa e validação do método (junto a 106 estudantes de graduação em Design Gráfico). Palavras-chave: método; análise da tarefa; ensino; design gráfico. Abstract This study aims do develop a new task analysis version to be taught in undergraduate Design courses. Our intention is that the method be as thorough as possible so that the student may practice all the activities comprised by different task analysis approaches (e.g., activity identification, functional and information requirements and potential errors). In order to achieve such purpose, development was structured in four phases: identification of task analysis learning difficulties; analytical study of task analysis methods; method proposal and validation (with 106 undergraduate Graphic Design students). Keywords: method; task analysis; teaching; graphic design. 1 Professora Doutora, PPGDesign - UFPR, s_padovani2@yahoo.co.uk 2 Mestranda, PPGDesign - UFPR, kellicas@gmail.com
2 1. Introdução O método de análise da tarefa é usualmente mencionado na literatura de Design Centrado no Usuário (UCD) como um dos passos fundamentais no design de sistemas. Diaper & Stanton (2004), por exemplo, qualificam-no como potencialmente o mais poderoso de todos os métodos disponíveis para a área de interação humanocomputador, pois tem aplicações em todos os estágios do desenvolvimento de sistemas, desde a especificação de requisitos até a avaliação final do sistema. Benefícios do método também são ressaltados por Stuart & Penn (2004), incluindo: possibilidade em sumariar interação usuário-sistema e atributos do usuário; melhoria na comunicação entre membros do grupo de projeto; e múltipla utilidade dos resultados do método design, treinamento, manuais de instruções, análise de riscos. Apesar dos benefícios citados na literatura, ocorrem dificuldades na seleção e aplicação da análise da tarefa principalmente por analistas menos experientes. No que tange à seleção, a multiplicidade de versões e de enfoques (e.g., descrição das atividades, demandas cognitivas, prevenção de erros, requisitos informacionais) torna difícil escolher uma versão específica do método para aplicar em dado projeto. Mais ainda, a seleção equivocada de uma versão do método pode trazer resultados pouco aproveitáveis para o desenvolvimento do referido projeto. No que se refere à aplicação do método, Arnowitz et al. (2000) citam dentre as principais dificuldades: esforço para sincronizar a hierarquia de tarefas com as representações textuais da mesma informação, além da necessidade de vasta experiência na aplicação do método para que os resultados da análise da tarefa se tornem compreensíveis. Além das dificuldades citadas na literatura, a primeira autora do presente artigo, havendo lecionado o referido método em quatro instituições de ensino (UniCarioca, PUC-Rio, UFPE e UFPR) a aproximadamente 15 turmas, observou uma série de problemas durante o processo de aprendizagem do método de análise da tarefa por estudantes de Design. As dificuldades variam desde a transferência de comportamento observado para uma representação diagramática até a transformação dos resultados da análise da tarefa em requisitos para o desenvolvimento de um sistema de informação. Diante do exposto, este estudo tem como objetivo desenvolver uma nova versão de método de análise da tarefa para ensino em cursos de Design Gráfico. A intenção é que este método seja o mais abrangente possível para que o aluno possa praticar todas as atividades existentes nos diversos enfoques de análise da tarefa, passando pela identificação de atividades, requisitos funcionais e informacionais e erros potencias. 2. Fundamentação Teórica A análise da tarefa é um dos métodos empregados na fase inicial do processo de design para entender os objetivos e atividades envolvidas na realização das atividades a serem executadas utilizando determinado sistema. De acordo com Crystal e Ellington (2004), a análise da tarefa inclui uma série de técnicas visando à obtenção de descrições do que as pessoas fazer usando um sistema, representação dessas descrições, estimativa de dificuldades e demandas, além da avaliação de sistemas com base em requisitos funcionais. O método pode ser utilizado tanto no design de sistemas novos, quanto na avaliação (e re-design) de sistemas já implementados. O processo de aplicação deste 159
3 método envolve um conjunto de atividades auxiliadas por uma série de técnicas de prospecção e representação de dados (vide figura 01). A maior diferenciação entre as versões de método de análise da tarefa ocorre nas fases de decomposição e análise. A forma de decomposição pode variar entre hierárquica e sequencial, sendo representada de forma diagramática, tabular ou mesmo textual. Já na fase de análise, o método pode ter caráter estimativo ou verificatório e enfocar desde o desempenho do usuário, erros cometidos ou previstos, necessidades funcionais ou informacionais e demandas físicas ou cognitivas. Neste contexto, podemos identificar quatro principais vertentes de análise da tarefa: a análise funcional da tarefa, a análise cognitiva da tarefa, a análise informacional da tarefa e a análise da tarefa para identificação de erros. Figura 1: Processo de Aplicação do Método de Análise da Tarefa. Fonte: Crystal e Ellington (2004) 2.1. Análise Funcional da Tarefa A análise da tarefa, quando realizada sob uma perspectiva exclusivamente funcional, divide a tarefa em subaéreas, operações e/ou ações que interagem com várias entradas e saídas e são representadas através de uma estrutura gráfica (hierárquica ou sequencial). É bastante útil para a decomposição de tarefas complexas, porém possui uma visão mais abstrata (focando nas metas da tarefa e não nos artefatos utilizados para cumpri-las). Descreve-se apenas a parte observável da tarefa, desconsiderando, portanto, o processo cognitivo do usuário. O resultado de uma análise funcional da tarefa serve mais como um quadro analítico da estrutura da tarefa do que como um instrumento prático para os designers. 160
4 2.2. Análise Cognitiva da Tarefa Em contraste com a análise funcional da tarefa, cujo foco é totalmente operacional, a Análise Cognitiva da Tarefa (CTA) busca identificar as demandas mentais envolvidas na realização das atividades da tarefa. Em ACTA (Applied Cognitive Task Analysis, Militello e Hutton, 1998), por exemplo, constrói-se inicialmente um diagrama de visão geral da tarefa e identificam-se partes difíceis a serem elucidadas posteriormente. Em seguida, busca-se identificar a expertise necessária para a realização de cada uma das subtarefas, assim como estratégias e desafios enfrentados por usuários inexperientes. Em um terceiro estágio, analisam-se cenários reais onde a tarefa esteja sendo realizada. Por fim, produz-se uma tabela síntese de demandas cognitivas, a qual serve para orientar decisões de projeto Análise Informacional da Tarefa A abordagem de análise informacional da tarefa visa extrair requisitos informacionais diretamente associados a cada atividade da tarefa, podendo ainda sugerir formatos de representação para cada uma das informações identificadas. Em SGT (Sub-goal template, Richardson et al., 1998), por exemplo, os autores buscam uniformizar os tipos de informação necessários à realização de cada tipo de atividade (vide exemplo no quadro 01). Já em TRIA (Task-related information analysis, Sutcliffe, 1997), utiliza-se uma única representação que engloba todas as informações, ou seja, associa diretamente atividades, agentes e informações envolvidos na realização da tarefa. Tabela 1: Exemplos de Atividades e Requisitos Informacionais Associados em SGT Código Atividade Requisito Informacional A1 Ação (preparar) Indicação de estados alternativos de operação A2 Ação (ativar) Feedback de que a ação foi efetiva A3 Ação (ajustar) Feedback confirmando estado atual do sistema C1 Comunicar (ler) Sugestão de item a ser consultado C2 C3 Comunicar (escrever) Comunicar (instrução) Indicação de local para armazenar registros Indicação de canal para recebimento Fonte: Richardson et al Análise da Tarefa para Identificação de Erros Nesta perspectiva, as versões de análise da tarefa visam identificar e caracterizar os erros passíveis de ocorrência durante a realização da tarefa, com vistas à implementação de mecanismos de prevenção de erros. Em TAFEI (Task analysis for error identification Stanton & Young, 1999), por exemplo, considera-se a interação como uma sequência de transições entre estados do sistema e assume-se que o sistema deve 161
5 prover informações sobre cada um de seus estados e funcionalidades disponíveis. A partir de uma matriz de transição, identificam-se transições indesejáveis entre estados do sistema, as quais são desabilitadas para prevenir a ocorrência de erros. Em PHEA (Predictive human error analysis), as atividades são classificadas em uma taxonomia predefinida (ação, busca, verificação, seleção e comunicação) e possíveis erros são identificados para cada atividade (exemplo na Tabela 2). Para cada erro previsto, o analista deve propor correção e mecanismos de prevenção no próprio sistema. Tabela 2: Possibilidades de erro de verificação Tipo de Erro Código Descrição C1 verificação omitida C2 verificação incompleta verificação C3 verificação correta no objeto errado C4 verificação errada no objeto certo C5 verificação no tempo errado Fonte: Stanton & Young, Conforme mencionado anteriormente, o método proposto considera as atividades da tarefa, seus aspectos funcionais, informacionais e erros associados, ou seja, caracteriza-se como um híbrido das quatro vertentes descritas anteriormente. Cumpre ressaltar que aspectos cognitivos restringem-se à identificação de atividades de maior nível de dificuldade, mas não à carga cognitiva e detalhamento de demanda (e.g., orientação espacial, velocidade perceptual, memória, atenção dividida). Tal decisão deve-se ao fato de considerarmos que tal detalhamento não é função do designer. 3. Desenvolvimento do Método O desenvolvimento do método de análise da tarefa compôs-se de 4 fases, as quais são listadas e brevemente descritas a seguir: Identificação de dificuldades na aprendizagem de análise da tarefa; Estudo analítico de métodos de análise da tarefa; Proposta de método de análise da tarefa; Validação do método proposto junto a alunos de Design Gráfico Identificação de Dificuldades na Aprendizagem de Análise da Tarefa A identificação das dificuldades na aprendizagem de análise da tarefa foi realizada pela primeira autora deste trabalho, no decorrer de aulas específicas sobre o método em disciplinas de Interação Humano-Computador (IHC), Ergonomia Informacional e Web Design em cursos de Design Gráfico. Todos os alunos realizaram exercício de aplicação do método de análise em grupo. Durante o exercício e após sua conclusão, a professora realizou anotações acerca das principais dúvidas e dificuldades encontradas pelos 162
6 estudantes. A seguir, detalham-se os procedimentos de ensino do método de análise da tarefa pela professora. Inicialmente, a professora realizou uma exposição visual-oral sobre o método de análise da tarefa (e.g., objetivos, procedimentos, diferenciação em relação a outros métodos de análise) e algumas de suas versões (as mesmas citadas na parte 2 deste artigo). Em seguida, propôs-se aos estudantes que, trabalhando em grupo, observassem a realização de uma tarefa e/ou entrevistassem a pessoa que realizava a tarefa e transferissem os dados diretamente para um diagrama de atividades (seqüencial ou hierárquico). Este estágio se mostrou dificultoso para a maioria dos estudantes, os quais optaram por listar linearmente as atividades (na forma de uma lista de tópicos ou palavras e setas) para então conferir se todas as atividades estavam incluídas e se a seqüência estava correta. Apenas após essa verificação, os estudantes passaram à construção do diagrama. Durante a construção do diagrama, a maioria dos estudantes preferiu a modalidade sequencial, ao invés da hierárquica (resultados na íntegra em Padovani & Smythe, 2012). Grande parte dos estudantes não conseguiu entender como construir o diagrama hierárquico, acabando por produzir uma árvore de sequências. Mesmo no diagrama sequencial houve dúvidas na notação utilizada, no nível de especificidade das atividades e na forma de redação do enunciado das atividades. Após a construção do diagrama, solicitou-se que os estudantes associassem a cada uma das atividades as necessidades informacionais, funções/ferramentas, feedback do sistema e potenciais desvios ou erros. Este estágio também se mostrou dificultoso, com sucessivas tentativas abandonadas de integração das informações em um único diagrama. Em resumo, os principais problemas identificados junto aos estudantes durante o processo de aprendizagem de análise da tarefa foram: Dificuldade em transcrever o comportamento observado ou relatado diretamente para um diagrama de atividades da tarefa; Dificuldade em entender a lógica de construção e a notação a utilizar nos diagramas de atividades da tarefa; Dificuldade de associação entre as atividades da tarefa e seus requisitos funcionais, informacionais e potenciais erros Estudo Analítico de Métodos de Análise da Tarefa Neste estágio, buscou-se conhecer as versões de métodos de análise da tarefa publicadas na literatura. Para tal, realizou-se uma análise pormenorizada de 20 métodos, de acordo com os seguintes parâmetros: Relação do método com o processo de design; Fase do processo de análise da tarefa que o método contempla; Decomposição da tarefa (forma, especificidade, nível de abstração); Parâmetros de análise da tarefa; Representações utilizadas; 163
7 Aplicabilidade ao design de sistemas de informação. Como síntese dos resultados (na íntegra em Padovani, 2007), pudemos verificar que a grande maioria dos métodos de análise da tarefa analisados se direciona à concepção de novos sistemas de informação e não à avaliação dos mesmos. Dezessete incluem a fase de decomposição da tarefa, mas apenas onze se preocupam em produzir uma síntese dos resultados, visando facilitar sua aplicação ao sistema em questão. Isso requer um re-trabalho dos resultados, para que realmente possam ser utilizados no (re)design de um sistema de informação. A forma mais frequente de decomposição da tarefa foi o a sequencial, utilizando-se de atividades bastante específicas, cujo enunciado inclui os artefatos utilizados para realizá-las. Por fim, a maioria dos métodos não apresenta regras para finalizar a decomposição, ficando a critério do analista o nível de especificidade / detalhamento da estrutura da tarefa gerada pelo processo de decomposição. A maioria dos métodos utiliza mais de uma forma de representação, sendo a combinação mais frequente o uso de representação esquemática aliada a texto estruturado e/ou códigos. Representações tabulares são utilizadas com menor frequência, seguidas das representações pictóricas, cujo uso se mostrou extremamente raro entre os métodos analisados. Uma avaliação específica das representações gráficas revelou deficiências tanto de conteúdo informacional, quanto na organização e apresentação das informações. No conteúdo informacional, as maiores deficiências observadas foram a falta de indicação de início e final da tarefa e falta de clareza no uso de siglas e legendas. Na organização das informações, os principais problemas estão relacionados à não indicação da ordem de leitura, hierarquia pouco evidente e quantidade excessiva de níveis hierárquicos. Na apresentação das informações, as falhas mais recorrentes dizem respeito à falta de destaque para informações importantes, diferenciação tipográfica e falta de legendas para explicar as figuras. No que se refere à aplicabilidade, dentre os métodos analisados, a maioria se direciona apenas ao plano da estratégia do sistema, fornecendo geralmente informações sobre as necessidades dos usuários. No plano do escopo, apenas cinco fornecem especificações de conteúdo informacional e oito geram especificações de funções para o sistema. Com relação ao plano da estrutura, a aplicabilidade diminui ainda mais, tendo apenas cinco dos vinte métodos analisados proposto recomendações para a arquitetura da informação do sistema Proposta de Método de Análise da Tarefa Com base no estudo sobre aprendizagem de análise da tarefa e na análise de métodos publicados na literatura, foi possível estabelecer o seguinte conjunto de requisitos para a proposta do novo método: Possibilidade de aplicação à concepção e avaliação de sistemas; Transição gradual entre observação do comportamento e diagrama; Representação das atividades da tarefa por diagrama seqüencial; Uso de múltiplas representações gráficas que são incrementadas em complexidade conforme as informações são coletadas e associadas; 164
8 Aplicabilidade direta dos resultados ao design do sistema de informação, pelo menos no nível da arquitetura da informação. Com base nesses requisitos, propôs-se uma estrutura geral para o método, a qual foi refinada a partir de sua aplicação junto a duas turmas de aproximadamente 30 estudantes de graduação em Design (habilitação em Design Gráfico) durante as atividades da disciplina de Projeto 6 - Web Design na UFPR. A Figura 02 apresenta a estrutura geral do método. Figura 2: Estrutura Geral do Método de Análise da Tarefa Proposto. coleta de dados fluxos de atividades unificação de fluxos lista de requisitos documentação entrevista observação verbalização representação sequências diferentes perfis preferências representação fusão de possibilidades funcionais informacionais pontos críticos unificação resultados ou pré-arquitetura situação de concepção dificuldades erros responsabilidade representação associações destaques teste com usuários situação de avaliação Fonte: os autores É possível observar que a análise da tarefa ocorre de forma gradual, tendo início com a coleta de dados sobre a tarefa a partir de diferentes fontes e técnicas, passando pela criação de diagrama de atividades, ao qual se adicionam os requisitos e pontos críticos. Unificam-se os resultados em uma única representação que serve de subsídio para a geração de um diagrama preliminar de arquitetura da informação ou para orientar testes com usuários. Na fase inicial de coleta de dados, cumpre buscar informações sobre como a tarefa é realizada a partir da consulta a múltiplas fontes (e.g., documentação (e.g., manual de treinamento), supervisores e usuários). Podem-se aplicar as técnicas de entrevista, observação ou verbalização. Como pauta para a condução da entrevista ou para intercalar perguntas com a verbalização, propõe-se a seguinte: Para que faz a tarefa (meta)? Como faz a tarefa (etapas)? Por que faz dessa forma? Há formas alternativas? Do que precisa para fazer cada atividade (informações, artefatos)? Como você sabe que cada atividade foi concluída com êxito? Quais são as atividades mais difíceis, por quê? Ocorrem erros? Como os descobre? Como os corrige? 165
9 Após a coleta de dados, produzem-se uma série de fluxos de submetas ou atividades, ou seja, listas ou diagramas que representam em que ordem as submetas ou atividades são realizadas por diferentes grupos de usuários (e.g., conforme perfil, experiência ou preferência)(vide Figura 03). Esses fluxos são posteriormente unificados em uma representação com todas as possibilidades de realização da tarefa (Figura 04). Figura 3: Exemplo de Fluxo de Sub-Metas para a Tarefa de Envio de Mensagem. Fonte: os autores Figura 4: Fluxograma Unificando Possibilidades de Realização da Tarefa (Observe as Diferentes Opções de Atividades para uma Mesma Sub-Meta, Unidas pelo Conector OU ). Fonte: os autores De posse do diagrama de atividades da tarefa, inicia-se o processo de identificação de requisitos. Para cada uma das atividades, identificam-se as informações e os artefatos utilizados e, quando necessário, as precondições para que cada atividade seja realizada da forma correta. Por exemplo, ao administrar um medicamento, deve-se atentar para a correta dosagem. Ou ainda, ao abrir a embalagem do medicamento, deve-se pressionar e girar a tampa ao mesmo tempo. Sinalizam-se, ainda, as atividades consideradas críticas (e.g., pela dificuldade, pela ocorrência de erros). Finaliza-se a análise da tarefa com uma representação (exemplos nas figuras 05 e 06) que conjugue todas as informações anteriores (atividades, requisitos informacionais, artefatos, desvios e erros). 166
10 Figura 5: Exemplo de Representação Gráfica Unificando os Resultados Fonte: os autores Figura 6: Exemplo de Representação Gráfica Unificando Resultados Fonte: os autores 167
11 Após a produção de representação de síntese, os desdobramentos da análise diferenciam-se de acordo com a situação em que o método esteja sendo aplicado. Para a situação de concepção, produz-se um diagrama preliminar de arquitetura da informação em que cada nó tenha associado um conjunto de informações e funções. Já para a situação de avaliação, inicia-se a observação de usuários realizando a tarefa associada à verbalização. Sugere-se que os resultados dessa observação (associados à transcrição da verbalização) sejam tratados de modo a possibilitar: (a) comparação entre a sequencial ideal e as sequências reais de realização da tarefa (para identificar pontos de desvio); (b) comparação entre as necessidades dos usuários e a disponibilidade informacional/ funcional do sistema (vide quadro 03); (c) identificação de erros e dificuldades associados a cada atividade. Tabela 3: Escala para Avaliação de Disponibilidade Informacional/Funcional Situação Intervenção Descrição ótima boa regular regular ruim péssima desnecessária facultativa necessária necessária essencial essencial informação/função disponível no sistema no local/momento de realização da atividades informação/função disponível no sistema em outro local mas com indicação de acesso informação/função disponível no sistema em outro local sem indicação de acesso informação/função disponível no sistema em vários locais, necessitando de integração pelo usuário informação/função não disponível no sistema, mas em sistema a ele associado informação/função não disponível no sistema, nem em sistema a ele associado Fonte: os autores 3.4. Validação do Método de Análise da Tarefa Proposto A proposta de método de análise foi aplicada por 106 alunos de Design Gráfico da UFPR, divididos em três turmas de 6º período (36, 36 e 34 alunos) cursando a disciplina Projeto Gráfico 6 Web Design. O método foi aplicado em situação de concepção de um web site em desenvolvimento pelos próprios alunos. Os procedimentos de aplicação são os mesmos apresentados no item 3.1. Todos os alunos conseguiram concluir a aplicação do método com êxito. O novo método foi capaz de resolver os principais problemas observados anteriormente quando os alunos aplicaram versões tradicionais do método de análise da tarefa: 168
12 Dificuldade em transcrever o comportamento observado ou relatado diretamente para um diagrama de atividades da tarefa: o novo método realiza essa transposição gradualmente e o aluno pode escolher a forma de representação com a qual se sente mais confortável (e.g., sequencial, hierárquico, tabular, SPP); Dificuldade em entender a lógica de construção e a notação a utilizar nos diagramas de atividades da tarefa: o aluno tem liberdade para criar uma representação com notação própria (desde que adicione legenda); Dificuldade de associação entre as atividades da tarefa e seus requisitos funcionais, informacionais e pontos críticos: o aluno acrescenta inicialmente os requisitos funcionais e informacionais e só então os pontos críticos - demandas cognitivas (e.g., memória, atenção), probabilidade de ocorrência de erros, pré-condições para precisão e correção na realização da subtarefa. Cumpre ressaltar que a fusão de todas as informações em uma única representação gráfica (último estágio de aplicação do método) ainda se configura como uma tarefa considerada complexa pelos alunos, principalmente quando o diagrama de atividades possui múltiplas bifurcações. Alguns alunos propuseram a inclusão de siglas e codificação cromática nos diagramas, enquanto outros associaram o diagrama a uma tabela com informações complementares. Esse ponto, portanto, ainda carece de maior investigação. 4. Conclusões e Desdobramentos Este estudo teve como objetivo desenvolver um método de análise da tarefa para ensino em cursos de graduação em Design Gráfico. Para tanto, utilizou-se uma abordagem de desenvolvimento centrada no usuário, com envolvimento dos estudantes ao longo de processo. O trabalho junto aos alunos, de forma etnográfica e contextual, permitiu definir melhor as atividades a serem incluídas em cada fase do método e as formas de representação das informações coletadas. O resultado é uma nova versão de método de análise da tarefa que trabalha de forma gradual a transição entre comportamento observado e decomposição da tarefa, além de incluir múltiplas representações que são incrementadas conforme aumenta a complexidade dos resultados. Até o presente momento, o método foi validado apenas com estudantes que desenvolviam web sites e apenas em situação de concepção. O método também foi explanado pela própria professora que o criou. Como desdobramento, vislumbra-se a validação do método junto a outros estudantes de Design Gráfico, com orientação de outros professores, nas situações de concepção e avaliação de sistemas de informação em suporte tanto impresso quanto digital. Agradecimentos Estudo desenvolvido com o apoio do CNPq, Processo /
13 Referências ARNOWITZ, J.; FIJMA, D.; VERLINDEN, J. Communicating a task analysis with task layer maps. Proceedings of DIS New York: ACM Press, CRYSTAL, A.; ELLINGTON, B. Task analysis and human-computer interaction: approaches, techniques, and levels of analysis. AMCIS 2004 Proceedings, DIAPER, D.; STANTON, N. A. The handbook of task analysis for human-computer interaction. New York: Lawrence Erlbaum, MILITELLO, L. G.; HUTTON, R. J. B. Applied cognitive task analysis (ACTA): a practitioner s toolkit for understanding cognitive task demands. Ergonomics, vol 41. no 11, p PADOVANI, S. Estudo descritivo de métodos de análise da tarefa: uma abordagem de design da informação. In: Anais do III Congresso Internacional de Design da Informação. São Paulo: SBDI - Sociedade Brasileira de Design da Informação, PADOVANI, S.; SMYTHE, K. C. A. S. Investigando a compreensão de representações diagramáticas utilizadas em análise da tarefa: um estudo comparativo entre modelagem hierárquica e seqüencial. Infodesign (SBDI. Online), v. 08, p , RICHARDSON, J.; ORMEROD, T. C.; SHEPHERD, A. The role of task analysis in capturing requirements for interface design. Interacting with Computers, 9, p STANTON, N.; YOUNG, M. A guide to methodology in ergonomics. London: Taylor & Francis, STUART, J.; PENN, R. TaskArchitect: Taking the Work out of Task Analysis. Proceedings of TAMODIA Prague: ACM Press, SUTCLIFFE, A. (1997). Task-related information analysis. International Journal of Human-Computer Studies, vol. 47. p
AVALIAÇÃO DE REPRESENTAÇÕES GRÁFICAS UTILIZADAS EM MÉTODOS DE ANÁLISE DA TAREFA
ação ergonômica, volume5, número1 AVALIAÇÃO DE REPRESENTAÇÕES GRÁFICAS UTILIZADAS EM MÉTODOS DE ANÁLISE DA TAREFA Stephania Padovani Universidade Federal do Paraná s_padovani2@yahoo.co.uk Kelli Cristine
Leia maisProfessor Emiliano S. Monteiro
Professor Emiliano S. Monteiro To-Do Doing Done Conhecer os processos de desenvolvimento habilita o aluno a realizar uma melhor escolha de processo para uso em projetos futuros. A vantagem de conhecer
Leia maisALM Aplicações em Linguagem de Montagem. Introdução. A produção de Software é uma atividade build and fix. build. fix
Introdução A produção de Software é uma atividade build and fix. 1 Introdução build 2 Introdução fix 3 1 Introdução 4 P s Só pessoas motivadas e comprometidas com o projeto garantem o respectivo sucesso;
Leia maisBibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.
Bibliografia Quais são os problemas? 4 A sofisticação do software ultrapassou nossa capacidade de construção. 4 Nossa capacidade de construir programas não acompanha a demanda por novos programas. 4 Nossa
Leia maisrelembrando: cenário de problema
relembrando: cenário de problema exemplo de cenário de problema Transferência bancária > Qual é mesmo o número daquela conta? Dia 10 chegou evento, e Marta ator se lembra evento que precisa transferir
Leia maisRequisitos de Software
Requisitos de Software Engenharia de requisitos Estabelece os serviços que o cliente requer de um sistema e as restrições sob as quais tal sistema operará e será desenvolvido. Tais serviços e restrições
Leia maisVerificação e Validação (V & V)
Verificação e Validação (V & V) Objetivo: assegurar que o software que o software cumpra as suas especificações e atenda às necessidades dos usuários e clientes. Verificação: Estamos construindo certo
Leia maisGerenciamento do Tempo de Projetos. Parte 05. Gerenciamento de Projetos Espaciais CSE-301. Docente: Petrônio Noronha de Souza
Gerenciamento do Tempo de Projetos Parte 05 Gerenciamento de Projetos Espaciais CSE-301 Docente: Petrônio Noronha de Souza Curso: Engenharia e Tecnologia Espaciais Concentração: Engenharia e Gerenciamento
Leia maisENGENHARIA DE USABILIDADE Unidade I Conceituação. Luiz Leão
Luiz Leão luizleao@gmail.com http://www.luizleao.com Introdução 1.1 Ergonomia 1.1.1 Ergonomia física e cognitiva 1.2 Usabilidade e Engenharia de Usabilidade 1.3 Interação Humano-Computador. Unidade II
Leia mais6 Considerações Finais
6 Considerações Finais Este capítulo apresenta as contribuições desta tese e os trabalhos que podem dar continuidade à pesquisa nela apresentada. 6.1 Contribuições Este trabalho tinha como objetivo propor,
Leia maisNo dicionário: Local bem determinado a que se aposta atingir; Objetivo; Limite ou abrangência de uma operação.
Aula 06 1 2 No dicionário: Local bem determinado a que se aposta atingir; Objetivo; Limite ou abrangência de uma operação. No contexto projeto, escopo pode se referir a: Escopo do produto: as características
Leia maisENGENHARIA DE USABILIDADE
ENGENHARIA DE USABILIDADE Aula 02 Bruna Patrícia da Silva Braga PRINCÍPIOS ERGONÔMICOS PARA IHC HEURÍSTICA DE USABILIDADE A avaliação heurística é um método de inspeção sistemático de usabilidade que leva
Leia mais1. INTRODUÇÃO A MODELAGEM DE DADOS
1. INTRODUÇÃO A MODELAGEM DE DADOS Para se construir uma casa ou um prédio de qualidade, é essencial fazer um planejamento detalhado, com a finalidade de pensar sobre as formas de construção, fazer estimativas
Leia maisRequisitos de Software
Engenharia de requisitos Requisitos de Software Estabelece os serviços que o cliente requer de um sistema e as restrições sob as quais tal sistema operará e será desenvolvido. Tais serviços e restrições
Leia mais5 Processo de Reificação e de Desenvolvimento com ACCA
Uma Arquitetura para a Coordenação e a Composição de Artefatos de Software 53 5 Processo de Reificação e de Desenvolvimento com ACCA Resumo Este capítulo visa esclarecer e descrever atividades existentes
Leia maisEngenharia de Software
Engenharia de Software Requisitos de Software Professor: Charles Leite Engenharia de requisitos Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições
Leia mais! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado
Agenda Rodrigo Reis Cleidson de Souza! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados!
Leia maisCadeira: Engenharia de Software
Cadeira: Engenharia de Software Aulas 9, 10 15/08/15 Docente: Cláudia Ivete F. Jovo cifjovo@gmail.com or cjovo@up.ac.mz M.Sc. Cláudia Jovo 2017/DI 0 Definição de Eng. Software; Eng. Software Tecnologia
Leia maisInteração Humano-Computador Avaliação em IHC: Hierarquia de Metas e Testes com Usuários
Interação Humano-Computador Avaliação em IHC: Hierarquia de Metas e Testes com Usuários www.inf.puc-rio.br/~inf1403 Análise de Tarefas Usada para se ter um entendimento sobre qual é o trabalho dos usuários,
Leia maisUniversidade Luterana do Brasil- ULBRA- Campus GUAÍBA. Implementação de Objetos de Aprendizagem Aplicada sobre questões do ENEM
Universidade Luterana do Brasil- ULBRA- Campus GUAÍBA Implementação de Objetos de Aprendizagem Aplicada sobre questões do ENEM GOMES, T 1, SCHÜNKE, M.A 2, ZEVE, C.M.D. 3. Palavras-Chave: Objetos de Aprendizagem,
Leia maisGuia do Processo de Teste Metodologia Celepar
Guia do Processo de Teste Metodologia Celepar Agosto de 2009 Sumário de Informações do Documento Documento: guiaprocessoteste.odt Número de páginas: 11 Versão Data Mudanças Autor 1.0 26/12/07 Criação.
Leia maisPDS. Aula 1.5 Modelos de Processo. Prof. Dr. Bruno Moreno
PDS Aula 1.5 Modelos de Processo Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br Tipos de Modelos Modelo em Cascata; Prototipação; RAD; Modelo Incremental; Desenvolvimento Evolucionário; Desenvolvimento
Leia maisCiclo de vida: fases x atividades
Ciclo de vida Fase de definição Análise e Especificação Estudo de Viabilidade Estimativas Planejamento Fase de desenvolvimento Design Implementação e integração Verificação e Validação Fase de operação
Leia maisRUP Unified Process. Profª Jocelma Rios
RUP Unified Process Profª Jocelma Rios Nov/2012 O que pretendemos: Reforçar os aspectos que caracterizam o processo iterativo e incremental Identificar como atingir os objetivos dos projetos de software
Leia maisEngenharia de Software
1 Engenharia de Software CURSO: Sistemas de Informação PERÍODO LETIVO: 2009-1 SEMESTRE: 4º PROFESSOR(A): Francisco Ildisvan de Araújo Introdução METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS Uma metodologia
Leia maisRequisitos de Software e UML Básico. Janaína Horácio
Requisitos de Software e UML Básico Janaína Horácio janaina@les.inf.puc-rio.br Agenda Requisitos O que é? Objetivos? Atividades?... UML O que é? Modelos... Casos de Uso O que é? Componentes 2 Requisitos
Leia maisEngenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata
Processo de Desenvolvimento Também chamado de ciclo de vida do software Reflete os passos necessários para se construir um produto de software Existem vários modelos de ciclo de vida Cascata (1956) Iterativo
Leia maisCAPÍTULO 7 CONCLUSÕES E RECOMENDAÇÕES
103 CAPÍTULO 7 CONCLUSÕES E RECOMENDAÇÕES "A verdadeira dificuldade não está em aceitar idéias novas, mas em escapar das antigas. John Maynard Keynes A pesquisa orientada à visualização cartográfica visa
Leia maisInstruções para o projeto final
Instruções para o projeto final MCTA016 - Paradigmas de Programação 2018-Q2 Profs. Diogo S. Martins e Emilio Francesquini v. 12/06/2018 Resumo dos prazos Parte 0: 19/06 Parte 1: 26/06 Parte 2: 17/07 Parte
Leia maisAinda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existem alguns aspectos que os diferenciam:
Prof. Edson dos Santos Cordeiro 1 Tópico: Objetivo: Introdução a Ciclo de Vida do Software Conhecer os principais conceitos relacionados a ciclo de vida do software. Bibliog. Base: McCONNEL, Steve. Rapid
Leia maisRELATÓRIO DE ESTÁGIO 1 CONCEITO
MINISTÉRIO DA EDUCAÇÃO SECRETARIA DE EDUCAÇÃO TECNOLÓGICA INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA BAIANO CAMPUS CATU DEPARTAMENTO DE EDUCAÇÃO COORDENAÇÃO GERAL DE ENSINO DISCIPLINA: Redação
Leia mais6 Conclusão. 6.1 Trabalhos relacionados
Conclusão 112 6 Conclusão 6.1 Trabalhos relacionados A primeira versão do método SHDM apresentada por Lima (2003) empregava um modelo orientado a objetos como a base estrutural do modelo conceitual de
Leia maisIntrodução INTRODUÇÃO AO SWEBOK. Origens do corpo de conhecimentos da Engenharia de Software: Introdução a Computação e Engenharia de Software
INTRODUÇÃO AO SWEBOK Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Introdução Origens do corpo de conhecimentos da Engenharia de Software: Engenharia da Computação Ciência da
Leia maisAnálise e Projeto de Sistemas de Informação (APSI)
COTIL Análise e Projeto de Sistemas de Informação (APSI) Profa. Simone Berbert Rodrigues Dapólito CAP. 2 FASES DO DESENVOLVIMENTO DE SISTEMAS Introdução O software/sistema de informação(si) é um produto
Leia mais4/14/11. Processos de Engenharia de Requisitos. Engenharia de requisitos. Elicitação e análise. A espiral de requisitos
Processos de engenharia de requisitos Processos de Engenharia de Requisitos Os requisitos e as formas de obtê-los e documentálos variam drasticamente de um projeto para o outro Contudo, existe uma série
Leia maisDocumentação e Ajudas
Interfaces Pessoa Máquina Documentação e Ajudas Cap. 12 Manuais e Documentação 20 Melhor e Pior? Melhor e Pior? Resumo Aula Anterior Multiplicidade de Dispositivos de Interação Entrada de Texto Introdução
Leia maisSOCIEDADE PARANAENSE DE ENSINO E TECNOLOGIA SPET PROGRAMA DE EVOLUÇÃO CONTÍNUA DE QUALIDADE. ES 60 DISCIPLINA: Engenharia de Software II
ES 60 DISCIPLINA: Engenharia de Software II AULA NÚMERO: 6 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar, discutir e exercitar a visão de um sistema a ser projetado. Os principais
Leia mais4 Caso de Uso no Ambiente Oracle
4 Caso de Uso no Ambiente Oracle No capítulo anterior foi definido o processo para definição de uma estratégia de rastreabilidade. Neste capítulo será realizada uma instanciação do processo em um ambiente
Leia maisEngenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS. Nome:
Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS Nome: 1. A figura abaixo representa, simplificadamente, as fases do Modelo de Ciclo de Vida Cascata.
Leia maisINF1404 MODELAGEM DE SISTEMAS
INF1404 MODELAGEM DE SISTEMAS Bacharelado em Sistemas de Informação Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 2 Modelagem de Casos de Uso 1ª Parte Programa Capítulo 2 Modelagem de Casos
Leia maisINSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE
1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE Nickerson Fonseca Ferreira nickerson.ferreira@ifrn.edu.br Introdução 2 Antes de qualquer
Leia maisEngenharia Cognitiva; Golfos de Execução e Avaliação; Distâncias Semânticas e Articulatórias
1 Engenharia Cognitiva; Golfos de Execução e Avaliação; Distâncias Semânticas e Articulatórias Aula 9 03/04/2013 2 O modelo de IHC segundo a Engenharia Cognitiva Descreve o que é IHC Ações Mentais Ações
Leia maisRequisitos de Sistemas
Requisitos de Sistemas Unidade II - Processos de Negócio Identificação Conceitos Modelagem - BPM - UML Processos x Requisitos 1 Processo de negócio CONCEITO Um processo de negócio, processo organizacional
Leia maisÁreas de Conhecimento, Técnicas de Análise de Negócio e Conceitos-Chave
Primeiro Módulo: Parte 3 Áreas de Conhecimento, Técnicas de Análise de Negócio e Conceitos-Chave AN V 3.0 [60] Rildo F Santos (@rildosan) rildo.santos@etecnologia.com.br www.etecnologia.com.br http://etecnologia.ning.com
Leia maisPDS. Aula 1.4 Modelos de Processo. Prof. Dr. Bruno Moreno
PDS Aula 1.4 Modelos de Processo Prof. Dr. Bruno Moreno bruno.moreno@ifrn.edu.br 2 Introdução Há alguns anos, o desenvolvimento de softwares era muito obsoleto; Existiam diversos problemas relacionados
Leia maisCONTPATRI Plano de Garantia de Qualidade. Versão 1.1
CONTPATRI Plano de Garantia de Qualidade Versão 1.1 Histórico da Revisão Data Versão Descrição Autor 04/05/2013 1.0 Verificação do documento Emerson José Porfírio 21/04/2013 1.0 Elaboração do documento
Leia maisTópicos da Aula. O que é anunciado. Falha de Comunicação no Desenvolvimento de Software. Engenharia de Software: Conceitos Fundamentais
Engenharia de Software Aula 02 Tópicos da Aula Engenharia de Software: Conceitos Fundamentais Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 07 Março 2012 Motivação e Conceitos
Leia mais06/02/2014. Engenharia de requisitos. Requisitos de Software. Capítulo 6. O que é um requisito? Objetivos. Abstração de requisitos (Davis)
Engenharia de requisitos Requisitos de Software O processo de estabelecer os serviços que o cliente requer a partir de um sistema e as restrições sob as quais ele opera e é desenvolvido. Os próprios requisitos
Leia maisAvaliação de Usabilidade Referências
Avaliação de Usabilidade Referências Avaliação de usabilidade Engenharia de Usabilidade Prof.: Clarindo Isaías Pereira da Silva e Pádua Departamento de Ciência da Computação - UFMG Hix, D.; Hartson, H.
Leia maisRequisitos de Software
Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais
Leia maisCurso de Engenharia Industrial Madeireira UFPR Prof. Umberto Klock
Curso de Engenharia Industrial Madeireira UFPR Prof. Umberto Klock Introdução à Gestão de Projetos; Gestão de Escopo; Gestão de Prazos; Gestão de Custos; Gestão de Pessoas; Gestão de Comunicação; Gestão
Leia maisGERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO
GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO Planejar o Gerenciamento das Comunicações O gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que as informações do projeto
Leia maisIntrodução a Teste de Software
Universidade Católica de Pelotas Tecnólogo em Análise e Desenvolvimento de Sistemas Disciplina de Qualidade de Software Introdução a Teste de Software Prof. Luthiano Venecian 1 Conceitos Teste de software
Leia maisUML. Modelando um sistema
UML Modelando um sistema Fases do desenvolvimento de Software Análise de requisitos Análise Projeto Programação Análise de Requisitos Esta fase captura as intenções e necessidades dos usuários do sistema
Leia mais1 Introdução Motivações
1 Introdução O processo de design de interação envolve quatro atividades básicas (Preece et al. 2005): identificação das necessidades e estabelecimento dos requisitos, o desenvolvimento de designs alternativos
Leia maisAnálise e Modelos de tarefas. INF1403 Introdução à Interação Humano-Computador Prof. Alberto Raposo
Análise e Modelos de tarefas INF1403 Introdução à Interação Humano-Computador Prof. Alberto Raposo abraposo@inf.puc-rio.br sala 413 RDC ciclo de vida simples: atividades e artefatos avaliação empírica
Leia maisModelagem de Tarefas
Introdução à Interação Humano-Computador Modelagem de Tarefas Professora: Raquel Oliveira Prates http://www.dcc.ufmg.br/~rprates/ihc Aula 14: 06/11 1 Modelagem de Tarefas Objetivo Definir o plano de ações
Leia maisEngenharia de Software Processo de Desenvolvimento de Software
Engenharia de Software Processo de Desenvolvimento de Software Prof. Elias Ferreira Elaborador por: Prof. Edison A. M. Morais Objetivo (1/1) Conceituar PROCESSO E CICLO DE VIDA, identificar e conceituar
Leia maisUnidade VI. Inspeção de software
1/06/20 Unidade VI Validação e Verificação de Software Profa. Dra. Sandra Fabbri de software Definição é um método de análise estática para verificar propriedades de qualidade de produtos de software.
Leia maisEngenharia de Software
Instituto Superior Politécnico de Ciências e Tecnologia Engenharia de Software Prof Pedro Vunge www.pedrovunge.com I Semestre de 2018 Capítulo 1 Introdução SUMÁRIO Engenharia de Software Definição; Objectivos
Leia maisGerência de Projetos de Software. Prof. Dr. João Dovicchi INE / CTC / UFSC.
Prof. Dr. João Dovicchi INE / CTC / UFSC dovicchi@inf.ufsc.br http://www.inf.ufsc.br/~dovicchi Programa Projetos e Metodologias Tipos e abordagens Organização Estimativas de Esforço e Gerência de Riscos
Leia maisEscopo: PROCESSOS FUNDAMENTAIS
Escopo: PROCESSOS FUNDAMENTAIS Etapa:Desenvolvimento de software Disciplina: Auditoria & Qualidade em Sistemas de Informação Professor: Lucas Topofalo Integrantes: Joel Soares de Jesus Luiz R. Bandeira
Leia maisEngenharia de Computação Disciplina: Projeto de Interação Professor: Luis Retondaro Turma: 1 Período
Engenharia de Computação Disciplina: Projeto de Interação Professor: Luis Retondaro Turma: 1 Período 2018-1 CONTEÚDO Conceituação de mídias. Fundamentos de sistemas multimídia. Mídias discretas e contínuas.
Leia maisProfessor Leandro Augusto Frata Fernandes
Interface Homem/Máquina Aula 9 Professor Leandro Augusto Frata Fernandes laffernandes@ic.uff.br Material disponível em http://www.ic.uff.br/~laffernandes/teaching/2011.2/tcc-00.184 Modelo Simples de Design
Leia maisMANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO
MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO Sumário PREFÁCIO...3 MODELO DA DOCUMENTAÇÃO...3 1. INTRODUÇÃO AO DOCUMENTO...3 1.1. Tema...3 2. DESCRIÇÃO
Leia maisINF1013 MODELAGEM DE SOFTWARE
INF1013 MODELAGEM DE SOFTWARE Departamento de Informática PUC-Rio Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 1 O Paradigma Orientado a Objetos A Linguagem UML Descrição da Arquitetura 1 Programa
Leia maisIntrodução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.
Diagramas UML Classe, Seqüência e Atividades Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 15 de maio
Leia maisErgonomia e Usabilidade
Ergonomia e Usabilidade Professor: José Durval Pacheco durval.pacheco@ifrn.edu.br Usabilidade - Definição Usabilidade é a capacidade de um produto ser usado por usuários específicos para atingir objetivos
Leia maisEngenharia de Software.
Engenharia de Software Prof. Raquel Silveira O que é (Rational Unified Process)? É um modelo de processo moderno derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software
Leia maisCAPÍTULO 1 O AMBIENTE DE DESENVOLVIMENTO DE SISTEMAS. Tereza Gonçalves Kirner
CAPÍTULO 1 O AMBIENTE DE DESENVOLVIMENTO DE SISTEMAS Tereza Gonçalves Kirner Apresentação elaborada com base em: Hoffer, Jeffrey A., George, Joey F. Modern Systems Analysis and Design (Capítulo 1), Pearson,
Leia maisIntrodução à Engenharia de Software
Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia
Leia maisProf. Esp. Fabiano Taguchi
UML Prof. Esp. Fabiano Taguchi http://fabianotaguchi.wordpress.com fabianotaguchi@hotmail.com UML COMPETÊNCIA: Conhecer e desenvolver estudos de caso usando modelagem orientada a objeto. HABILIDADE: Conhecer
Leia maisAnálise do problema. Desenvolvimento de programas. Desenvolvimento do algoritmo. Análise do problema
Desenvolvimento de programas 1 Análise do problema 2 Análise do problema Desenvolvimento do algoritmo Codificação do programa Compilação e execução Teste e depuração Conhecer exatamente o que o problema
Leia maisPerspectivas em IHC. Introdução à Interação Humano-Computador. Conceitos Básicos
Introdução à Interação Humano-Computador Conceitos Básicos Professora: Raquel Oliveira Prates http://www.dcc.ufmg.br/~rprates/ihc \ Aula 1: 14/05 Perspectivas em IHC usuário como máquina computador como
Leia maisPrincípios da Engenharia de Software aula 03
Princípios da Engenharia de Software aula 03 Prof.: José Honorato Ferreira Nunes Material cedido por: Prof.: Franklin M. Correia Na aula anterior... Modelos de processos de software: Evolucionário Tipos
Leia maisAnálise de Sistemas. Aula 5
Análise de Sistemas Aula 5 Prof. Emerson Klisiewicz CONTEXTUALIZAÇÃO Aula 5 Análise Orientada a Objetos Introdução a UML Histórico e Visão Geral Ferramentas CASE O Sucesso... Clientes satisfeitos Eles
Leia maisDocumentação de Software. Simone Vasconcelos
Documentação de Software Simone Vasconcelos 1 Contexto Qualquer software deve ter uma quantidade razoável de documentação.! Documentos de trabalho.! Manuais de usuário produzidos profissionalmente. Em
Leia maisEngenharia de Software
Universidade São Judas Tadeu Prof. André Luiz Ribeiro Prof. Jorge Luis Pirolla Introdução à Computação Engenharia de Software Tópicos O que é Engenharia de Software? Engenharia de Software em camadas Processo
Leia mais6.CONCLUSÕES CONCLUSÕES
6.CONCLUSÕES 193 6 CONCLUSÕES Este trabalho apresentou uma proposta para modelagem e análise de Sistemas de Controle envolvidos na geração de energia elétrica hidráulica, tendo como base dois desenvolvimentos:
Leia maisInteração Humano-Computador
Interação Humano-Computador Avaliação Preditiva Danielle Freitas 2015.1 http://docente.ifrn.edu.br/daniellefreitas Agenda Tipos de avaliação Modelos preditivos GOMS KLM Características e vantagens Avaliação
Leia maisMODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro
MODELAGEM DE SISTEMAS Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Introdução Modelagem de Sistemas: A modelagem de um sistema auxilia o analista a entender a funcionalidade
Leia maisLaboratório de Engenharia de Software I
Laboratório de Engenharia de Software I Turma 01: Profa. Lucia Vilela Leite Filgueiras Turma 02: Profa. Maria Alice Grigas Varela Ferreira Aula 01 Casos de uso e protótipo da interface de usuário Roteiro
Leia maisORGANIZAÇÃO CURRICULAR TÉCNICO NA ÁREA DE INFORMÁTICA: HABILITAÇÃO TÉCNICO EM INFORMÁTICA NA MODALIDADE A DISTÂNCIA /1
ORGANIZAÇÃO CURRICULAR TÉCNICO NA ÁREA DE INFORMÁTICA: HABILITAÇÃO TÉCNICO EM INFORMÁTICA NA MODALIDADE A DISTÂNCIA - 2008/1 DC 9481 03/10/07 Rev. 00 1. Dados Legais Autorizado pelo Parecer 278 do Conselho
Leia maisEngenharia de Requisitos
DCC / ICEx / UFMG Engenharia de Requisitos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Motivação Motivação Porque levantar Requisitos é importante? Motivação Porque levantar Requisitos é importante?
Leia maisENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE Teste de Software Verificação e validação Testes de desenvolvimento Testes de release Testes de usuário Desenvolvimento dirigido a testes Kele Teixeira Belloze kelebelloze@gmail.com
Leia maisDesenvolvimento de programas. Análise do problema. Análise do problema. Análise do problema. Desenvolvimento do algoritmo. Codificação do programa
Desenvolvimento de programas 1 Análise do problema Desenvolvimento do algoritmo Codificação do programa Compilação e execução Teste e depuração Análise do problema 2 Conhecer exatamente o que o problema
Leia maisEngenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios
Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana
Leia maisEngenharia Software. Ení Berbert Camilo Contaiffer
Engenharia Software Ení Berbert Camilo Contaiffer Características do Software Software não é um elemento físico, é um elemento lógico; Software é desenvolvido ou projetado por engenharia, não manufaturado
Leia mais05/09/2013. Ciclo de vida de um Sistema de Informação
Ciclo de vida de um Sistema de Informação Objetivos dessa aula: 1. O conceito de ciclo de vida de um projeto 2. As características do ciclo de vida do projeto clássico 3. As diferenças entre projetos clássicos
Leia maisGQM. Goal Question Metric. 14 de agosto de Carlos Vinícius Pereira da Silva. Déborah Carvalho de Moura. Danylo de Castro Campos.
2009 GQM Goal Question Metric 14deagostode2009 CarlosViníciusPereiradaSilva DanylodeCastroCampos DéborahCarvalhodeMoura PauloNery SUMÁRIO GQM Goal Question Metric INTRODUÇÃO... 3 CARACTERÍSTICAS... 4 DESCRIÇÃODAPRÁTICA...
Leia maisA modelagem de Negócio com UML
A modelagem de Negócio com UML Introdução A passagem do Modelo do Negócio para o Modelo do Sistema envolve a definição de quais Casos de Uso do Negócio deverão ser automatizados; No momento em que os requisitos
Leia maisPROJETO DE PROGRAMAS. Projeto de Programas PPR0001
PROJETO DE PROGRAMAS Projeto de Programas PPR0001 Desenvolvimento de Software 2 3 Desenvolvimento de Software Análise de Requisitos Distinguir e dividir o sistema em componentes: Analisar os componentes
Leia maisMetodologia Científica. Construindo Saberes
Metodologia Científica Construindo Saberes Trabalho com Projetos A pesquisa promove saberes Estímulo ao desenvolvimento da ciência Construção e busca por novos conhecimentos Buscar novos horizontes Desenvolvimento
Leia maisConstruMED Metodologia para a Construção de Materiais Educacionais Digitais Baseados no Design Pedagógico. Usabilidade
Metodologia para a Construção de Materiais Educacionais Digitais Baseados no Design Pedagógico Usabilidade A usabilidade é um princípio conceituado por vários autores. Para Nielsen (2000) ela é identificada
Leia maisInstituto Federal Sul-rio-grandense. Placa universal para controle de máquinas de lavar roupa Plano de Projeto - versão 1.0
Instituto Federal Sul-rio-grandense Campus Pelotas Curso de Engenharia Elétrica Planejamento e Gerenciamento de Projetos Placa universal para controle de máquinas de lavar roupa Plano de Projeto - versão
Leia mais