02/10/2012. Referências. Processo visando a Usabilidade. Introdução. Engenharia de Usabilidade. Prof.: Clarindo Isaías Pereira da Silva e Pádua

Documentos relacionados
Introdução. Introdução. Introdução. Planejamento da disciplina. Modelagem de Processos de Negócio. Prof.: Clarindo Isaías Pereira da Silva e Pádua

Introdução 27/9/2005. Prof.: Clarindo Isaías Pereira da Silva e Pádua Departamento de Ciência da Computação UFMG Gestus. Usabilidade.

Introdução. Conteúdo. Usabilidade. Engenharia de software X Usabilidade. Benefícios. Introdução. Introdução. Introdução. Introdução.

Departamento de Sistemas de Computação Universidade de São Paulo Análise e Projeto Orientados a Objetos Aula 2 O Processo Unificado (PU)

UML: Introdução. História Visão geral Modelo conceitual da UML. Bibliografia. UML: introdução

2. Processos em Engenharia de Software

O Processo Unificado (PU) SSC 121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

Processo. Processo unificado. Principais Características do UP. Principais Características do UP RUP. Unified Process (Processo Unificado)

Processos de Software

15/03/2018. Professor Ariel da Silva Dias Modelos de Processo de Software

Rational Unified Process (RUP)

Engenharia de Software II

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS. Nome:

Processos de Software

Engenharia de Software

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

Ainda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existem alguns aspectos que os diferenciam:

Bibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.

INSTITUTO FEDERAL DE SÃO PAULO CAMPUS PRESIDENTE EPITÁCIO MODELO DOS PROCESSOS DE SOFTWARE

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

FUNDAMENTOS DA ANÁLISE E PROJETO DE SISTEMAS. Projeto de Programas PPR0001

Avaliação de Usabilidade Referências

Escolhendo um Modelo de Ciclo de Vida

UNIVERSIDADE FEDERAL DO PARANÁ - UFPR BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

RUP/PSDS. Introdução e Comparação

Engenharia Software. Ení Berbert Camilo Contaiffer

Visão Geral do RUP (Rational Unified Process)

Visão de Comportamento do Negócio

Visão de Comportamento do Negócio

Especificação de Requisitos de Usabilidade

UML 2.0 Método, Linguagem e Ferramenta. Prof. Cesar Augusto Tacla

Introdução ao RUP. Livar Correia de O. C. Cunha Effektiv Solutions

Visão de Processos de Negócio

Engenharia de Software. Herbert Rausch Fernandes

Engenharia de Software. Processos. Desenvolvimento de Software Tradicionais 2014/2. Prof. Luís Fernando Garcia

05/09/2013. Ciclo de vida de um Sistema de Informação

Engenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata

Visão de Processos de Negócio

Princípios da Engenharia de Software aula 03

Engenharia de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

CAPÍTULO 1 O AMBIENTE DE DESENVOLVIMENTO DE SISTEMAS. Tereza Gonçalves Kirner

Engenharia de Software I: Introdução. Graduação em Informática 2009 Profa. Itana Gimenes

Aula 3 - Modelos de Processo - cascata, iterativo e incremental e ágil

14/11/2014. Engenharia de Software. Modelos de software. Modelo Clássico - Cascata

Aula 3.1 Introdução e Visão Geral do Processo Unificado

Professor Emiliano S. Monteiro

Programa Analítico de Disciplina INF323 Engenharia de Software II

02/10/2012 Clarindo Pádua. Avaliação de maturidade em usabilidade de organizações Produtividade do usuário.

O Fluxo de Requisitos

IntroduçãoaoProcesso. Prof. Anderson Cavalcanti UFRN-CT-DCA

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS

4/14/11. Processos de Engenharia de Requisitos. Engenharia de requisitos. Elicitação e análise. A espiral de requisitos

Processo de Desenvolvimento de Software

ALM Aplicações em Linguagem de Montagem. Introdução. A produção de Software é uma atividade build and fix. build. fix

Engenharia de Software II

PDS. Aula 1.6 Modelos de Processo. Prof. Dr. Bruno Moreno

Curso de Sistemas de Informação. Karla Donato Fook DESU / DComp. Modelagem de Dados UML

Processos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de. Desenvolvimento de Software

MODELAGEM DE SISTEMAS Unidade 1 Conceitos Básicos de Modelagem. Luiz Leão

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Instituto Federal Sul-rio-grandense. Placa universal para controle de máquinas de lavar roupa Plano de Projeto - versão 1.0

Disciplina - Requisitos. Grupo Yuni Luiz Eduardo Káthia

Fábricas de Software. Processos de Software. Fábricas de Software. Fábricas de Software 17/08/2010. Jorge Dias

Disciplina que reúne metodologias, métodos e ferramentas a serem utilizados, desde a percepção do problema até o momento em que o sistema

5 METODOLOGIA PROPOSTA

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN

Análise e Projeto Orientados a Objetos Professora: Elisa Yumi Nakagawa PAE: Cristiane Aparecida Lana 2 semestre de 2015

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPI JOÃO CÂMARA RATIONAL UNIFIED PROCESS - RUP

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Unidade VII Ferramentas de PDS. Luiz Leão

CICLO DE VIDA DE SOFTWARE

Introdução à Análise e Projeto de Sistemas

Notas de Aula 03: Introdução a Orientação a Objetos e a UML

Levantamento, Análise e Gestão Requisitos. Aula 02

Desenvolvimento de Projetos

Análise e projeto de sistemas

Processo Unificado. Leonardo Gresta Paulino Murta

Introdução À Engenharia De Software Com Foco No RUP: Rational Unified Process

RUP Unified Process. Profª Jocelma Rios

PROCESSO DE SOFTWARE

Ciclo de vida do projeto x do

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE

Engenharia de Software

Processo de Desenvolvimento

Prof. Ms. Ronaldo Martins da Costa

Agenda TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS. Aula 2 19/08/2012

PDS. Aula 1.4 Modelos de Processo. Prof. Dr. Bruno Moreno

Introdução ao RUP Rational Unified Process

Ciclo de vida: fases x atividades

Ciclo de Vida de Sistemas de Informação

Unidade II MODELAGEM DE PROCESSOS. Profa. Gislaine Stachissini

MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO

14/11/2013. Capítulo 2. Processos de Software. Tópicos apresentados. Oprocessodesoftware. Modelos de processo de software. Atividades de processo.

Requisitos de Sistemas

Engenharia de Software Processo de Desenvolvimento de Software

Definição e Melhoria de Processo na Produção de Software Web

Transcrição:

Engenharia de Usabilidade Prof.: Clarindo Isaías Pereira da Silva e Pádua Gestus Departamento de Ciência da Computação - UFMG Referências Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability through product & process, John Wiley and Sons, 1993. Paula Filho, W. P. Engenharia de Software: Fundamentos, Métodos e Padrões, Editora LTC, Terceira Edição, 2009 Rumbaugh, J.; Jacobson, I.; Booch, G., The Unified Modeling Language Reference Manual, Addison Wesley, 2nd edition, 2004. 2 Introdução Processos de Integração com o Integração com o O Processo de desenvolvimento da interação Introdução Conceito de processo de : conjunto de atividades bem definidas que visam o desenvolvimento de um sistema. Características de um processo: É composto de atividades parcialmente ordenadas ou subprocessos; Envolve métodos, práticas e transformações; Define metas geralmente associadas a um ou mais resultados concretos que são os produtos da execução do processo. Utiliza princípios 3 4 1

> Introdução > Introdução Um processo deve ter documentação que detalha: o que é feito (produto); quando (passos); por quem (agentes); as coisas que usa (insumos); as coisas que produz (resultados). O resultado final de um processo de desenvolvimento é o produto de software. Um projeto corresponde à execução de um processo. Os resultados concretos de um processo são artefatos. Um artefato pode ser: Documento: visa acesso por humanos Relatórios: tipo de documento que relata o resultado de alguma atividade. Modelo: é processado por uma ferramenta de software e corresponde a uma abstração de um fenômeno que se deseja representar. 5 6 > Introdução Princípios O processo de gerenciamento deve verificar e controlar o desenvolvimento completo do ciclo de vida e ser capaz de monitorar cada etapa. O desenvolvimento deve incluir testes empíricos de forma precoce e continuada, centrados em usuários apropriados fazendo tarefas representativas. Necessidade de iteração O desenvolvimento da interação com o usuário deve ser iterativo pelas mesmas razões pelas quais o desenvolvimento de software é iterativo. Existe ainda uma razão adicional: apesar de existir alguns métodos para se predizer o comportamento de um software, pouco ou nada existe para se predizer o comportamento humano! > Processos de 7 8 2

> Processos de > Necessidade de iteração Os métodos de não são necessariamente convenientes para desenvolvimento de interações do usuário. O desenvolvimento da interação com o usuário deve ser essencialmente e inerentemente iterativo - o processo deve ser auto-corretivo. > Processos de Modo de trabalho dos desenvolvedores de software Ondas alternadas de atividades top-down e bottom-up já que ambos detalhes e estrutura são importantes. O ciclo de vida de desenvolvimento da interação deve permitir tanto uma abordagem top-down como bottom-up, tanto inside-out como outside-in e deve suportar uma avaliação e iteração contínua. 9 10 > Processos de > Processos de Top-down Estruturante, com atividades de análise e usando abstração, tende a considerar uma visão do sistema, trabalhando-se em direção ao usuário. Por exemplo, envolve abstração para se fazer uma análise top-down de tarefas, produzindo uma organização hierárquica das tarefas do usuário e do sistema. Bottom-up Concreto, criativo e com atividades sintetizantes que tendem a considerar uma visão do usuário, trabalhando-se em direção ao sistema. Por exemplo, utiliza quadros, cenários e diagramas de estado para representar sequenciamento. Top-down Tende a predominar quando o desenvolvedor possui alguma experiência e um certo conhecimento da estrutura do sistema alvo. Bottom-up Com atividades sintetizantes e de experimentação, é mais conveniente em situações novas onde a estrutura do sistema alvo é pouco conhecida. As atividades de tentativa-e-erro aumentam a experiência e intuição para o desenvolvimento da estrutura do sistema. 11 12 3

> Processos de Processos de Modelo de cascata Modelo espiral Propõe um É essencialmente seqüencial desenvolvimento evolutivo, Permite volta a etapas anteriores Reconhece nossa incapacidade de considerar todos os detalhes de uma só vez. 13 14 > Processos de > Processos de Processo RUP Organizado em duas dimensões: fases e disciplinas Processo RUP As fases são etapas definidas com objetivos gerenciais As disciplinas são subprocessos relacionados a áreas técnicas Nosso processo de Usabilidade seria considerado como outra disciplina na estrutura do RUP 15 16 4

> O processo de desenvolvimento da interação > O processo de desenvolvimento da interação Norma ISo 13407-1999 A norma ISO 13407-1999 define um conjunto de processos de desenho Centrado no Humano para sistemas interativos. Pode ser visto como uma estrutura básica de processos de Escopo. Guia para atividades de através de todo o ciclo de vida de sistemas interativos. Conteúdo: Apresenta processos de desenho centrado no usuário. Planejamento do processo de desenho Descrição das quatro atividades principais de processo. Uma listagem de padrões correntes de processos e produtos para DCU. 17 18 > O processo de desenvolvimento da interação > O processo de desenvolvimento da interação Propósito: ad ISO 13407 Visa ajudar os responsáveis pela gerência de processos de e hardware a identificar e planejar Planeja o processo de Especifica o contexto de uso atividades de DCU de maneira efetiva e tempestiva. Audiência: Gerentes de processos de desenho. OK? Av alia desenho confrontando com requisitos Especifica os requisitos dos usuários e da organização Todas as partes envolvidas no desenvolvimento, incluindo usuários finais de sistemas Produz soluções de desenho 19 20 5

Observar que: > O processo de desenvolvimento da interação não há ordem ou sequência entre os processos; as diversas atividades do processo são distintas porém interdependentes; o processo é iterativo: as atividades podem ser executadas em ciclos onde são feitos detalhamentos e melhorias; em geral, diferentes tipos de avaliação são utilizadas em cada ciclo no desenvolvimento do software. Dada a liberdade em relação a iterações no processo, quando deve-se parar? Mecanismos de controle devem ser usados para que se possa planejar e gerenciar o andamento dos processos de desenvolvimento. É necessário coletar métricas e estabelecer metas para a qualidade da interação. Avaliações somativas são utilizadas durante o desenho da interação para comparar seu estado atual em determinado momento em relação às especificações de. > O processo de desenvolvimento da interação 21 22 > Integração com o Integração com o Tanto o desenvolvimento de interação do usuário como o produzem partes de um sistema interativo. No entanto, no desenvolvimento da interação entra o fator humano, determinante na necessidade de metodologia específica. Os mesmo conceitos, como planejamento, especificação, métricas, documentação e avaliação se aplicam, porém de forma diferente. Visão global das áreas de desenvolvimento de sistemas interativos. O desenvolvimento da interface do usuário é parte do desenvolvimento de um sistema interativo O usuário é parte do sistema, portanto também deve ser desenvolvido, isto é, treinado. O desenvolvimento de dispositivos de interação está fora do escopo desse curso. O desenvolvimento da interface e o desenvolvimento da aplicação estão no domínio construcional; o desenvolvimento da interação está no domínio comportamental. 23 24 6

> Integração com o > Integração com o Estratégia para domínio da complexidade envolvida no desenvolvimento de sistemas: modularização e abstração. Através da modularização, o processo de desenvolvimento e quebrado em subprocessos menores. Através da abstração, eliminando detalhes não relevantes em um determinado domínio, o desenvolvedor consegue controlar a complexidade. 25 26 > Integração com o > Integração com o No entanto, algumas questões atravessam vários domínios, ou seja, existe um acoplamento entre módulos ou subprocessos. A modularização resolve alguns mas introduz outros - o acoplamento entre módulos leva à necessidade de uma formalização da comunicação entre eles. Exemplo: acoplamento entre os subprocessos de desenho e implementação usado no. 27 28 7

> Integração com o > Integração com o Desenho - o projetista trabalha em alto nível de abstração, considerando algoritmos e estruturas de dados. Implementação - o projetista trabalha em baixo nível de abstração, preocupando-se com os detalhes de código. A comunicação entre os dois subprocessos é formalizada através da Especificação e de como mostrado. O desenhista de software e o implementador têm visão e conhecimento diferentes do sistema; por isso, é muito arriscado mecanismos informais em que um pode interferir no trabalho do outro. É importante haver políticas rígidas regulando a comunicação entre os diversos subprocessos mas que estabeleçam canais efetivos de comunicação entre eles. Fisicamente, principalmente em sistemas mais simples, uma mesma pessoa pode fazer os dois papeis, porém com chapéus diferentes. 29 30 > Integração com o > Integração com o Acrescentando análise de sistemas e testes O resultado da análise de sistemas é um conjunto de requisitos de desenho para os projetistas de software. Os requisitos são declarações de alto nível dos objetivos do sistema, incluindo necessidades, funcionalidades desejadas e características (features) nas quais o desenho do software é baseado. Testes - principal feedback é para o desenho do software onde defeitos e outros são corrigidos, produzindo modificações na especificação. O diagrama representa a comunicação entre as diversas atividades; não implica seqüenciamento. 31 32 8

> Integração com o Acrescentando desenho do domínio do problema. Desenho do domínio do problema é a modelagem da aplicação utilizando teoria e conceitos de engenharia. O desenho de software é o projeto de estrutura de dados e algoritmos para converter o projeto de domínio do problema em um programa. A atividade de desenho do domínio do problema recebe e fornece requisitos e recebe e fornece feedback sobre especificações incorretas ou incompletas das atividades de Análise de sistema e Desenho de software. Análise de sistema Desenho: domínio do problema > Integração com o Plano de testes e critérios Requisitos Requisitos Especificações Programas Desenho de software Principal feedback: defeitos de projeto, erros, modificações Implementação de software Erros, bugs Teste de software Maiores reconsiderações 33 34 > Integração com o Diagrama análogo para o desenvolvimento da interface do usuário. > Integração com o Juntando os processos. Análise de sistema Requisitos de desenho de interface, especificações de Desenho interação - interface usuário Plano de testes, especificações de Requisitos Desenho software - interface do usuário Especificações Implementação de software - interface do usuário Programas Erros, bugs Principal feedback é devido a baixa : falhas de projeto, erros, modificações Avaliação baseada no usuário de interface de software Diagrama mostra comunicação envolvendo atividades. Equipes grandes X equipes pequenas. Diagramas servem para estruturar os processos com clareza, definindo papéis e linhas bem definidas de comunicação. A separação entre o desenvolvimento da interface do usuário e o resto do sistema de software não é clara na realidade. Maiores reconsiderações 35 36 9

> Integração com o Plano de teste, critérios Integração com o Acrescentando prototipagem rápida e avaliação formativa Análise de Sistemas Requisitos Requisitos Especificações Programas Projeto de interface, Especificação requisitos de Desenho do Domínio do problema Desenho interação - interface usuário Reconsiderações maiores Requisitos Desenho de aplicação de software Desenho software - interface do usuário Especificação Implementação Implementação Programas Principal feedback é devido a baixa Erros e bugs Erros e bugs Testes baseados no usuário e avaliação do software de interface e nãointerface Análise de Sistemas Especificações de Plano de teste, critérios Requisitos Requisitos Especificações Programas Desenho do Desenho de Implementação da Domínio do aplicação de aplicação problema software Projeto de interface, Especificação requisitos de Desenho interação - interface usuário Reconsiderações maiores Requisitos de desenho software Desenho de interface de software com o usuário Plano de teste, especificação de Especificação de implementação do software Programas Implementação da interface do usuário Principal feedback é devido a baixa Erros e bugs Erros e bugs Testes baseados no usuário e avaliação do software de interface e nãointerface Plano de teste, especificação de Avaliação baseada no usuário Prototipagem rápida 37 38 Processo de desenvolvimento de -u Integrado ao é um processo de criado na UFMG Pode ser considerado como uma disciplina (sub-processo) adicional do Processo de desenvolvimento de -u O, de forma semelhante ao Rup, é organizado em Fases e Disciplinas As Disciplinas podem ser organizadas em sub-processos. 39 40 10

> Integração com o > Elementos do > Integração com o > Elementos do Fase: divisão em etapas de um processo, para fins gerenciais, que corresponde aos pontos principais por parte do cliente. Cada fase deve ter sua duração pré-definida em um projeto. As Fases são subdivididas em Iterações Iteração: subdivisões constituintes de uma fase; corresponde a um conjunto bem definido de metas parciais de um projeto. Fases Concepção Elaboração Construção Transição Iterações Ativação Levantamento de Requisitos Análise de Requisitos Desenho Implementável Liberação 1... Liberação n Teste alfa Teste Beta Operação piloto 41 42 > Integração com o > Elementos do > Integração com o Disciplinas ou Fluxos: são sub-processos caracterizado por um tema técnico. Exemplos de disciplinas: Requisitos Análise Desenho Implementação Testes Usabilidade Gerência de projetos Em cada iteração (ou fase, portanto), podem ser realizadas atividades de quaisquer disciplinas. Fluxo de Usabilidade (ver diagrama) Planejamento Controle Análise de contexto Análise de usuários Análise de tarefas Análise de necessidades Análise de concorrência Definição das funções do produto Prototipação de requisito de interface Definição de requisitos e metas de 43 44 11

> Integração com o > Fluxo de Revisão da análise de Definição do estilo de interação Fluxo de : ver modelo do Processo Processo visando a Usabilidade > Integração com o > Fluxo de Desenho da interação Revisão do desenho da interação Avaliação de 45 46 > Integração com o > Integração com o Planejamento Atividade gerencial, compreende principalmente: personalização do processo com relação aos aspectos do fluxo de, planejamento de atividades com estimativas de esforço, escopo e prazo ao longo do projeto. Controle O Controle compreende o acompanhamento do progresso do projeto, durante sua realização, por meio da confrontação de metas de esforço, escopo, prazo e custo, comparando o previsto no Planejamento com o realizado até um determinado momento. A personalização do processo visa a definição de uma instância do fluxo de a ser utilizada em um projeto específico. Como parte do planejamento, deverão também ser definidos os parâmetros principais das avaliações a serem realizadas. 47 48 12

> Integração com o > Integração com o > Análise de contexto Análise de contexto de uso Análise de usuários Visa o estudo e caracterização do contexto em termos de usuários potencias, tarefas e ambiente de realização das atividades relacionados com o produto em perspectiva. A análise de contexto produz informação muito importante para outras atividades de desenvolvimento Visa a caracterização dos diversos perfis de usuários: atores humanos Combina teoria de cognição de seres humanos e informações específicas sobre funções e tarefas para definir classes representativas de de software usuários. 49 50 > Integração com o > Análise de Contexto > Integração com o > Análise de Contexto Análise de tarefas Visa a análise de: Análise de concorrência Necessidades ou objetivos Análise de sistemas similares para que se possa melhorar Fluxo de trabalho conhecendo suas fraquezas e pontos fortes. Trabalho individual Permite uma visão de um produto semelhante já implementado - Seqüência de tarefas pode dar uma visão mais realista do que a permitida por Hierarquia de tarefas protótipos Procedimentos 51 52 13

> Integração com o > Integração com o Definição dos requisitos e metas de Prototipação de requisito da interface Define metas quantitativas de que são Desenvolvimento do protótipo de usadas para controle do processo: quando a interface interface com o objetivo de validação de é boa o suficiente? requisito. 53 54 > Integração com o > Integração com o Revisão da análise de Definição do estilo de Revisão técnica e de apresentação dos artefatos relacionados à Avaliação do protótipo de requisito da interface interação Definição ou atualização do Guia de Estilo de Usabilidade do Software (GEUSw) 55 56 14

> Integração com o > Integração com o Desenho da interação Revisão do desenho da Desenho da interface como interação protótipo ou como desenho definitivo Revisões diversas do material produzido no desenho da interação 57 58 > Integração com o Avaliação de Avaliação visando verificar-se a qualidade da interface tendo em vista os requisitos e metas de. 59 15