3ª prova pós web 1ª chamada

3ª Prova Pós Web - INGRESSO: 08/08/2014 - A sua prova presencial de Recuperação - ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES WEB ocorrera em:Dia: 27/06/2015Horario: 08:30 as 10:00 (Horario de Brasilia)Disciplinas: PROJETOS ÁGEIS, ANÁLISE DE SISTEMAS, BANCO DE DADOS, DESIGN DE INTERFACES, INTERAÇÃO HUMANO-COMPUTADOR

TECNOLOGIA EM ANÁLISE DE SISTEMAS

WEB AULA 1Unidade 1 – INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS

RESUMO:

O objetivo da presente unidade é apresentar os principais fundamentos sobre gerenciamento de projetos. Nesse sentido, será abordado o ciclo de vida básico de um projeto, suas principais tarefas e como esse processo contribui para o sucesso de um projeto. Além disso, de forma resumida, será apresentado como estruturar um projeto aplicando princípios básicos considerados boas práticas de gestão de projetos. Ao final, será possível entender e aplicar ferramentas essenciais à gestão eficiente de projetos desoftware. DEFINIÇÃO DE PROJETOAfinal de contas, o que é um projeto? Segundo o PMI (2008), projeto é “[...] um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. Ainda segundo o PMI:

Temporário significa que todos os projetos possuem um início e um final definidos. Embora não recomendado, muitos projetos ou não definem claramente uma data de início ou terminam muito além do programado.

Temporário não significa necessariamente de curta duração; muitos projetos duram vários anos. Exemplo de projetos longos são as missões espaciais que podem durar mais de uma década para serem concluídas.

Temporário não se aplica ao resultado do projeto, que poderá perdurar por muitos anos após a conclusão do projeto. As pirâmides do Egito são um exemplo claro do resultado duradouro de um projeto.

O resultado de um projeto é exclusivo, único.

Saiba mais sobre os principais conceitos em gestão de projetos:http://www.gestaodeprojeto.info/introducao

Mas o que pode ser administrado como um projeto?

Projetos surgem, por exemplo, de problemas ou oportunidades pessoais ou organizacionais. Logo, projetos lidam com situações não muito comuns. Por exemplo, uma empresa de software deseja implantar um novo procedimento de teste de software. Nesse sentido, projetos envolvem muitas incertezas e geralmente geram mudanças ao acrescentarem algo novo.Então, projetos não lidam com situações do dia a dia, ou seja, projetos não administram rotina. Rotinas geralmente não envolvem incertezas e o resultado é previsível.

Muitas palavras novas? Baixe um pequeno dicionário de “Projetês” no

endereço:http://www.gestaodeprojeto.info/arquivos/PMBOK_Port_glossario.zip?attredirects=0

Entretanto, gerenciar por meio de projetos não se aplica somente no ambiente organizacional, você pode administrar determinados objetivos pessoais por meio de projetos. Por exemplo, o curso de especialização que você está fazendo poderia ser administrado por meio de um projeto. Note que o curso é algo novo em sua vida, irá acrescentar algo à sua vida profissional, deverá ser realizado num determinado prazo, envolverá custos, riscos, ou seja, exigirá um planejamento que possibilite que você atinja seu objetivo: ser um especialista em Desenvolvimento de Aplicações Web Baseadas na Tecnologia JAVA.

Vídeo: o que é um projeto: O quadro 1 apresenta algumas diferenças entre rotina e projeto.

Saiba mais:Maximiano (2010, p. 4-13) apresenta uma visão geral sobre projetos. CICLO DE VIDA DO PROJETO

Como os projetos são organizados? Projetos podem ser divididos em fases que possibilitam melhor controle gerencial. O ciclo de vida do projeto define as fases que conectam o início de um projeto ao seu final.

Segundo o PMI (2008), um ciclo de vida (vide figura 1) é um processo que determina um conjunto de ações e atividades inter-relacionadas realizadas para obter um conjunto pré-especificado de produtos, resultados ou serviços.

Cada uma das fases define um grupo de processos que são aplicados iterativamente (de forma incremental) e repetitivamente. Segundo Trentim (2011), o grupo de processo de Inicialização é responsável pela definição e autorização de um novo projeto; o grupo de processos de Planejamento define o que será feito e como será realizado; o grupo de processos de Execução coloca em prática o planejamento; o grupo de processo de Monitoramento e Controle verifica se a execução está em conformidade com o planejado e o grupo de processo de Encerramento é responsável pela finalização do projeto.

Como pode ser percebido, o ciclo de vida do projeto ajuda a organizar todos os processos necessários à realização do projeto. Ele estabelece uma sequência, agrupa processos comuns, dá uma visão geral sobre todo o percurso que deverá ser realizado entre o início e o término do projeto entre outras vantagens.Então, o ciclo de vida de um projeto é um fator importante para o sucesso do projeto. O ciclo de vida do projeto é similar a um mapa: um mapa indica o início, o destino, a rota que conduz ao destino, os locais pelos quais deveremos passar, dá uma noção do progresso, ou seja, onde estou no trajeto?

Ao pensar sobre o ciclo de vida de um determinado projeto, considere algumas questões que deverão ser respondidas:

» Que trabalho técnico deve ser realizado em cada fase. Por exemplo, em qual fase deve ser realizado o trabalho do Analista de Sistema, Programador, Administrador do Banco de Dados (DBA), etc.» Quando as entregas devem ser geradas em cada fase e como cada entrega é revisada, verificada e validada. Por exemplo, quando o diagrama Entidade Relacionamento (DER) deverá ser entregue? Quem irá revisá-lo? Quando será revisado?» Quem está envolvido em cada fase. Por exemplo, na fase de planejamento do projeto deverá ser coletado os requisitos do software, então, quais são os interessados (stakeholders)?

» Como controlar e aprovar cada fase. Por exemplo, quando sei que a atividade Engenharia de Requisitos foi concluída, como saberei se a atividade está dentro do prazo? Como saberei se realmente a atividade foi concluída? Quais critérios indicam que a atividade foi concluída dentro das expectativas?

Saiba mais:Ciclo de vida do projeto de software:

http://www.oficinadanet.com.br/artigo/1912/o_ciclo_de_vida_de_um_projeto_de_informatica

Vídeo: ciclo de vida do projeto: Normalmente um projeto envolve diretamente e indiretamente vários interessados (stakeholders[1]) e saber quem está envolvido no projeto é um fator importantíssimo para o sucesso do projeto. Por exemplo: imagine que você irá construir uma casa nova para sua família. Esse projeto irá envolver diversas pessoas, principalmente sua família. Então, imagine que você deixou de ouvir sua família sobre quais características a casa deveria ter. O que você acha que aconteceria quando sua família se mudasse para a nova casa? Será que eles a aprovariam? Bom, talvez sim, ou talvez a desaprovassem por completo, ou talvez dissessem “acho que poderia ser assim”, etc., etc.

Partes interessadas no projeto podem ser pessoas ou organizações ativamente envolvidas no projeto ou cujos interesses podem ser afetados com o resultado da execução ou do término do projeto. Eles podem também exercer influência (positiva ou negativa) sobre os objetivos e resultados do projeto.

[1] Stakeholders é um termo em inglês muito utilizado na literatura. Nesse material, stakeholder será empregado comointeressado.

Exemplo de interessados:Clientes que comprarão e/ou usarão o produto resultante do projeto, órgãos ou agências regulamentadoras que podem interferir no projeto, pessoas ou organizações que disponibilizarão recursos ao projeto, pessoas ou organizações afetadas pelo projeto, parceiros ou terceiros que participarão do projeto, equipe de Projeto, fornecedores de produtos ou serviços ao projeto, competidores/concorrentes, etc.

Trentim (2011) apresenta um exemplo resumido no formato de uma tabela (vide figura 2) de informações que poderiam ser registradas sobre as partes interessadas no projeto. A tabela destaca, por exemplo, o interesse de cada parte interessada, a influência dessa parte interessada no projeto e o impacto que essa parte poderia provocar no projeto.

Quer saber mais sobre as partes interessadas? Acesse o endereço:http://www.gestaodeprojeto.info/analise-dos-stakeholders

Gerente de ProjetoO gerente de projeto (ou GP) desempenha um papel fundamental no projeto, ele é o responsável global por todo trabalho realizado no projeto. Além disso, o gerente atua como um meio, uma interface, entre o projeto e os interessados nele. O GP é um cargo temporário, ou seja, ele existe enquanto o projeto existir. Normalmente o gerente é definido logo nas etapas iniciais do projeto.

Dentre tantas responsabilidades, o GP supervisiona o planejamento, desenvolvimento e operação do projeto. Cleland; Ireland (2007) listam outras responsabilidades atribuídas aos gerentes de projeto: » redistribuem recursos conforme a necessidade do projeto;» monitoram a competência da equipe do projeto;» gerenciam mudanças;» monitoram o prazo, custo, risco, qualidade, etc. do projeto;» relatam o andamento do projeto aos interessados;

» motivam a equipe.

Saiba mais:Ouça o PODCAST de Ricardo Vargas sobre as responsabilidade do

GP: http://www.ricardo-vargas.com/pt/podcasts/projectmanagerresponsibilities/

Vídeo: Perfil profissional do GP:

OS DESAFIOS DO PROJETOGerenciar projetos implica numa “batalha” diária entre algumas restrições: tempo, custo, qualidade, escopo e satisfação do cliente. Note que essas variáveis reagem quando se modifica uma delas.

Por exemplo, o que aconteceria se você percebesse que o projeto está atrasado e que precisa recuperar o tempo para entregar no prazo? Bom, você poderia apontar algumas alternativas, por exemplo: contratar mais pessoas ou trabalhar um pouco mais (hora extra). Acredito que você tenha percebido que essas duas medidas

podem provocar um impacto na outra variável: o custo. Logo, para recuperar o tempo terei que aumentar o custo.

Vamos assistir a vídeo aula 1

Outra alternativa para realizar o projeto dentro do tempo estimado sem aumentar o custo seria deixar de realizar algumas tarefas. Entretanto, isso poderia impactar na qualidade do projeto. Então, caberá ao gerente de projeto a árdua habilidade de equilibrar essas variáveis, de decidir se aumentará o custo ou diminuirá a qualidade. Ou melhor, qual o ponto de equilíbrio entre entre custo, tempo, qualidade e escopo que resulte na satisfação do cliente.

PMI e PMBOKComo você percebeu, gerenciar projetos envolve muito conhecimento, apresenta muitos desafios e envolve muitos riscos. Logo, você poderia se perguntar, diante de tanta complexidade, serei eu capaz de administrar um projeto? Realmente, é muito difícil e quase sempre, diante de uma nova área, nos sentimos incapazes.

Entretanto, em 1969, na Pensilvânia (EUA), cinco voluntários também se depararam com as mesmas questões. Então, eles decidiram fundar o PMI – Project Management Institute (ou, em português, Instituto de Gerenciamento de Projetos). O PMI é uma organização sem fins lucrativos e atualmente está presente em mais de 185 países com mais de 650.000 membros associados.

O PMI está organizado em capítulos que são estabelecidos nos mais diferentes países. São mais de 250 capítulos estabelecidos em todo mundo. No Brasil já foram estabelecidos 13 capítulos. Segundo o PMI, essas comunidades, abertas a membros do PMI e dirigidas por voluntários, dão suporte para a troca de conhecimento e para redes de trabalho, pontos centrais da missão do PMI.

Saiba mais sobre o PMI:Acesse o endereço: http://brasil.pmi.org

Entre os principais objetivos do PMI encontra-se o desenvolvimento de conhecimentos para gerenciamento de projetos e, certamente, uma das principais contribuições do PMI é o guia PMBOK – Project Management Body of Knowledge (ou, em português, Guia para o Corpo de Conhecimento em Gerenciamento de Projetos).

PODCAST: PMBOK quarta edição:http://www.ricardo-vargas.com/pt/podcasts/newpmbok/

Segundo o PMI (2008), o Guia PMBOK identifica um conjunto de conhecimento em gerenciamento de projetos amplamente reconhecido como uma boa prática. O PMI ainda enfatiza que “boa prática” significa que existe um consenso geral de que a aplicação correta dessas habilidades, ferramentas e técnicas pode aumentar as chances de sucesso em uma ampla gama de projetos.Logo, o Guia PMBOK é uma fonte indispensável de conhecimento para quem pretende gerenciar um projeto. Os conteúdos do Guia PMBOK estão separados por

área de conhecimento para as quais são definidos e explicados os processos necessários à sua aplicação. Deve-se deixar claro, entretanto, que cabe ao usuário do Guia definir como o conhecimento será aplicado, então, o Guia apenas sugere boas práticas e, portanto, cabe ao usuário avaliar sua pertinência em relação ao projeto ao qual se pretende aplicar as boas práticas propostas pelo Guia.

O Guia é constantemente atualizado e encontra-se atualmente em sua 4ª edição, distribuída em 2008. Nessa edição, o conteúdo do Guia apresenta 42 processos. Os 42 processos podem ser divididos de duas formas (vide figura 3): agrupados por áreas de conhecimento ou agrupados por grupos de processos.

Fonte: http://www.pmtech.com.br/artigos/Processos_PMBOK_4a_Mauro_Sotille.pdf. Na figura 3, do lado direito, pode-se observar uma legenda. Nessa legenda são apresentadas as 9 áreas de conhecimento com sua respectiva cor e ícone: Integração, Escopo, Tempo, Custos, Qualidade, RH (Recursos Humanos), Comunicação, Riscos e Aquisição. Pode-se perceber ainda na figura 3 que os processos (retângulos numerados) possuem uma cor e um ícone (Figura 4).

Considerando esses dados e tomando como exemplo o processo “4.1 Desenvolver o termo de abertura do projeto” localizado no topo do lado esquerdo da figura, podemos classificar esse processo na área de conhecimento Integração. Então, todo retângulo na cor “amarelo claro” e que apresenta o ícone “estrela” é classificado como um processo de Integração. Você perceberá que existem 6 processos de integração espalhados pela figura.

Também perceberá que os processos espalhados pela figura, na verdade, estão contidos dentro de uma divisão. Cada uma das divisões é um grupo de processos. Tomando ainda como exemplo o processo 4.1 “Desenvolver o termo de abertura do projeto”, você perceberá que ele está numa divisão intitulada “Processos de Iniciação”. Você notará ainda que apenas dois processos são classificados como processo de Iniciação.

Vídeo: Grupos de processos PMBOK: Esses dois modos de visualizar os processos de gerenciamento sugeridos pelo PMBOK estão relacionados e são úteis da seguinte forma, por exemplo: Se você estiver na fase de Planejamento de um projeto, quais processos você poderia empregar para planejar seu projeto? Considerando a figura 3, você perceberá que o PMBOK sugere 20 processos que podem ser realizados no planejamento de um projeto.

Quer saber mais sobre o PMI e PMBOK? Acesse o endereço:http://www.linhadecodigo.com.br/artigo/974/iniciacao-ao-pmbok-no-

gerenciamento-de-projetos.aspx Por outro lado, se você estiver avaliando os possíveis riscos de seu projeto, quais processos poderiam ser realizados? Nesse caso você irá localizar na figura 3 todos os seis processos que possuem o ícone “raio” (eles estão distribuídos em dois

grupos de processos: “Planejamento” e “Monitoramento e Controle”). Esses processos são processos relacionados ao gerenciamento de riscos de um projeto.

O Guia PMBOK é um tema relativamente extenso. O propósito aqui foi propiciar uma visão ampla sobre seu conteúdo e organização. Conhecer as boas práticas apresentadas pelo Guia certamente é uma leitura recomendada para todos aqueles que querem aprofundar seus conhecimentos em gerenciamento de projetos.

O Guia PMBOK é uma leitura obrigatória para quem tem interesse em gestão de projetos.

Você pode obter mais informações sobre a aquisição do Guia PMBOK no endereço:http://brasil.pmi.org/brazil/PMBOKGuideAndStandards.aspx GRUPOS DE PROCESSOComo apresentado anteriormente, os 42 processos do PMBOK estão agrupados em 5 grupos: Iniciação, Planejamento, Monitoramento e Controle, Execução e Finalização. A intenção em agrupar os 42 processos é organizá-los e permitir que se tenha uma visão do progresso do andamento do projeto.

Segundo o PMI (2008), cada grupo de processo possui, de modo geral, as seguintes responsabilidades.Grupo de Processos de inicialização: Os processos desse grupo têm por objetivo definir, iniciar um novo projeto ou nova etapa do projeto. Uma vez o projeto seja autorizado a iniciar, nessa etapa é definido o gerente do projeto, identificadas as partes interessadas e alocado os recursos entre outros processos.Grupo de processos de planejamento: Define o escopo do projeto, ou seja, o que será responsabilidade do projeto, refina os objetivos e estabelece as ações que conduzirão ao objetivo geral do projeto.Grupo de processos de execução: é formado pelos processos responsáveis pela execução do trabalho definido no planejamento.Grupo de processos de monitoramento e controle: nesse grupo estão os processos responsáveis pelo monitoramento do projeto, ou seja, averigua se tudo está ocorrendo como previsto, realizado como planejado e, caso contrário, toma medidas para contornar da melhor forma possível eventuais problemas.Grupo de processos de encerramento: Agrupa os processos encarregados de finalizar todos os procedimentos, documentar as lições aprendidas, registrar todas as informações entre outros.

Definir os processos de um projeto é como um jogo de xadrez, cada projeto (partida) exige uma estratégia diferente.

CERTIFICAÇÕES DO PMIPara os interessados em gerenciamento de projetos, o PMI oferece seis certificações profissionais que tem por objetivo demonstrar que o profissional possui

conhecimento, experiência e competências em determinadas áreas do gerenciamento de projetos.

As certificações emitidas pelo PMI são reconhecidas mundialmente e os profissionais que as possui são muito valorizados no mercado. Atualmente o PMI oferece seis certificações.

Certificação PMP – Profissional de Gerenciamento de Projetos (PMP). Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos. Certificação PgMP – Profissional de Gerenciamento de Programas. Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI. Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI. Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI.

PODCAST: Ouça o podcast sobre a certificação CAPM:http://www.ricardo-vargas.com/pt/podcasts/capm-certification-part-1-of-2/

Para obter uma certificação do PMI, você deve primeiramente atender aos requisitos de elegibilidade delineados no portal do PMI e detalhados nos manuais de

certificações. A seguir, você deve fazer três avaliações – a revisão da inscrição, o exame da certificação e a avaliação múltipla.

Quer saber mais sobre as certificações do PMI? Acesse o endereço:http://brasil.pmi.org/brazil/FAQ/CertificationFAQ.aspx

PROJETOS DE SUCESSOSegundo o PMI (2008), o ciclo de vida do projeto apresenta algumas características comuns entre diferentes projetos (Figura 6). Essas informações são valiosas principalmente para quem está iniciando em gestão de projetos.Vamos assistir a vídeo aula 2Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante as fases intermediárias e caem rapidamente conforme o projeto é finalizado.Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as características finais do produto do projeto, sem impacto significativo sobre os custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos das mudanças e correções de erros geralmente aumentam significativamente conforme o projeto se aproxima do término.

Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante as fases intermediárias e caem rapidamente conforme o projeto é finalizado. Para saber mais sobre a importância do planejamento, leia o artigo disponível em

Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as características finais do produto do projeto, sem impacto significativo sobre os custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos das mudanças e correções de erros geralmente aumentam significativamente conforme o projeto se aproxima do término.Segundo o PMI (2008), para que um projeto seja bem sucedido, a equipe deve:» Selecionar processos adequados;» Usar uma abordagem apropriada;» Cumprir os requisitos dos interessados;» Equilibrar as demandas (escopo, tempo, custo, qualidade e satisfação do cliente). Vídeo: Obtendo resultados com Gerenciamento de Projetos:

. RESUMONessa unidade foi apresentado a definição de projeto, seus benefícios e aplicações e diferenças em relação às rotinas. Assim como outras áreas, os projetos possuem um ciclo de vida comum, genérico, composto pelas etapas: iniciação, planejamento, execução, acompanhamento e controle e finalização. Também foi enfatizado que é fundamental identificar todas as partes interessadas no projeto, bem como as principais atribuições do responsável direto pelo projeto: o gerente de projeto. Além disso, foi apresentado a norma internacional PMBOK, mantida pelo PMI, a qual apresenta boas práticas em gestão de projetos. Também foi descrito como os profissionais podem obter maior aceitação no mercado por meio de certificações profissionais. Finalmente, foram destacadas algumas características gerais sobre projetos e fatores de sucesso.

http://www.pmtech.com.br/artigos/O_Desafio-Revista_Amanha.pdf

http://www.ricardo-vargas.com/pt/videos/47/

Primeiros passos, acesse o endereço: http://www.gestaodeprojeto.info/7passos

CLELAND, David, I.; IRELAND, Lewis R. Gerenciamento de projetos. Rio de Janeiro: LTC, 2007.MAXIMIANO, Antonio Cesar Amaru. Administração de projetos: como transformar ideias em resultados. 4. ed. São Paulo: Atlas, 2010.MOURA, Dácio Guimarães de; BARBOSA, Eduardo F. Trabalhando com projetos: planejamento e gestão de projetos educacionais. 2. ed. Petrópolis: Vozes, 2007.PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento de projetos, 4. ed. Newton Square, PA: PMI, 2008.TRENTIM, Mário Henrique. Gerenciamento de projetos: guia para certificações CAPM e PMP. São Paulo: Atlas, 2011.

TECNOLOGIA EM ANÁLISE DE SISTEMAS

WEB AULA 1Unidade 2 – PLANEJANDO UM PROJETO

RESUMO:

O objetivo da presente unidade é apresentar os passos básicos sobre o planejamento de um projeto e uma visão geral sobre métodos ágeis. Nesse sentido, será discutido o objetivo do projeto e seu papel no planejamento do projeto. Você também irá conhecer como definir as responsabilidades de um projeto por meio da definição do escopo. Além disso, aprenderá como dividir todo o trabalho necessário para realizar um projeto por meio da Estrutura Analítica do Projeto (EAP). Também entenderá porque a EAP é um dos instrumentos fundamentais para planejar um projeto: tempo, responsabilidades, estimativas de custo, tarefas, etc. Finalmente, será apresentada uma visão geral sobre os métodos ágeis e, em particular, uma visão um pouco mais aprofundada sobre a abordagem ágil SCRUM.

INICIANDO UM PROJETO: O OBJETIVO

“Nenhum caminho adiantará se você não sabe aonde ir.”

Definir o objetivo do projeto certamente é um dos principais passos para um projeto. Os objetivos são descrições concretas do que o projeto está tentando alcançar. Iniciar um projeto sem tê-lo definido claramente é praticamente sentenciar o projeto ao fracasso.

Os objetivos do projeto (geral e específico) devem incluir os critérios mensuráveis do sucesso do projeto: técnicos, de negócios, custo, cronograma e qualidade. Isto é, deve ser descrito de tal forma que seja possível verificar ao final do projeto se eles foram ou não atingidos. Nesse sentido, os objetivos do projeto podem incluir metas de custo, cronograma e qualidade. Ou seja, Um objetivo bem escrito será específico, mensurável, alcançável/realizável, realístico e com uma clara indicação do tempo.

Um contraexemplo de escrita de um objetivo: “Melhorar a qualidade no atendimento ao cliente por meio da implantação de um call center”. Nesse contraexemplo não está claro como o objetivo poderá ser verificado, pois não faz referência a custo, tempo, datas ou critérios de qualidade. Deste modo, não seria possível verificar se o projeto atendeu aos critérios.

Agora, leia a escrita de um objetivo que contém elementos que podem ser verificados: “O projeto objetiva entregar no prazo de 180 dias a contar a partir da data de 01/10/2008, com custo de investimento de R$ 5 milhões dentro do padrão internacional NPCS 3001 atualmente praticados pela corporação um serviço de call center para suportar o atendimento à clientes da rede de Lojas Fictícia”.

Note que na descrição do objetivo constam a entrega do projeto (sublinhado contínuo) e elementos mensuráveis (sublinhado pontilhado), ou seja, possíveis de serem verificados: valores, prazo, data e norma de qualidade. Portanto, um objetivo atua como um farol para um navio, um ponto de referência para onde se quer chegar. Logo, o objetivo deve ser escrito de tal forma que fique claro o resultado pretendido.

Ouça o PODCAST sobre objetivo de um projeto:

http://www.ricardo-vargas.com/pt/podcasts/smart_objective/ O objetivo do projeto pode ser subdividido em objetivos menores. Por exemplo, imagine que você pretenda viajar para um determinado destino, você mora em São Paulo e pretende ir para Osasco – SP (Figura 1). Por se tratar de um trajeto curto, aproximadamente 23 Km, normalmente, você não se preocuparia muito, pois se trata de um trajeto relativamente simples.

http://www.ricardo-vargas.com/pt/podcasts/smart_objective/

Agora, imagine que você pretende ir de São Paulo para Dourados no Mato Grosso do Sul (Figura 2). Bom, agora você vai pensar, é uma rota relativamente extensa, aproximadamente 1000 Km e, para complicar, você não conhece muito bem o trajeto. Então, o que você faria? Provavelmente, você estabeleceria a rota, ou seja, pontos intermediários até o ponto final: São Paulo a Ourinhos, Ourinhos a Presidente Prudente, Presidente Prudente a Presidente Epitácio, Presidente Epitácio a Glória de Dourados e, finalmente, Glória de Dourados a Dourados. Bom, por que você varia dessa maneira? Porque seria mais seguro você alcançar seu destino final por meio do alcance de destinos mais curtos. A soma dos objetivos mais curtos é igual à soma de todo o trajeto até o destino final. Essa estratégia diminui a complexidade ao lidar com problemas menores, você resolve um problema de cada vez e, ao resolver todos os problemas menores, você teoricamente resolveria todo o problema.

Então, considerando o exemplo acima, o destino final é nosso objetivo geral, e os destinos intermediários são nossos objetivos intermediários. ESCOPOApós definir o objetivo ou objetivos do projeto, devemos reunir todos os interessados no projeto e tratar do escopo do projeto. Mas, o que é escopo?

Segundo Maximiano (2010), escopo do projeto é o produto ou conjunto de produtos que o projeto deve entregar – a um cliente, patrocinador ou usuário.

Uma analogia: imagine que o escopo do projeto é como um quebra-cabeça de montagem de peças. Somente estará completo e terá significado se todas as peças estiverem no seu devido lugar. Agora, considere um exemplo real: é comum empresas de software desenvolverem para um cliente um produto de software, mas será apenas o software a única entrega do projeto? Acredito que na maioria dos casos não. Por exemplo, não basta apenas entregar o software, em muitos casos é necessário instalá-lo no ambiente do cliente, logo, a implantação/instalação do software também é uma entrega do projeto. Outras possíveis entregas seriam: treinamento dos usuários, entrega do manual do sistema, entrega do instalador, migração de dados do sistema antigo para o novo sistema (quando se tratar de uma atualização), etc.

Percebe-se, portanto, que a definição do escopo, ou seja, das entregas (em inglês, no singular,delivery) é uma parte fundamental do processo de gerenciamento de projetos. A definição incorreta do escopo pode provocar o fracasso de um projeto. Pensar no escopo é definir realmente o deve ser entregue. Muitos projetos definem entregas desnecessárias que não contribuem para o objetivo do projeto. É comum na descrição do escopo do projeto, para torná-lo mais claro ainda, não só a descrição das entregas, mas também a descrição do que NÃO será entregue, ou seja, àquelas entregas que não farão parte do escopo. Por exemplo: não faz parte

do escopo do projeto: » Fornecer licenças de qualquer tipo de software necessário ao funcionamento do software objeto do projeto.» Projetar, instalar e configurar qualquer tipo de infraestrutura de redes de computadores.» Fornecedor qualquer tipo de hardware necessário ao funcionamento do software objeto do projeto.

» Realizar qualquer tipo de treinamento, exceto o treinamento de uso do software objeto do projeto.

Saiba mais.Veja um exemplo de declaração do escopo do projeto:

https://docs.google.com/viewer?a=v&pid=sites&srcid=Zmd2Z3AxMC5tYXVyaWNpb3ZpZWlyYS5uZXR8bG9naXN0aWNhLXN

hbHZhZG9yLTIwMTR8Z3g6NTU2NzE0MzU2NmY0NTU

ESTRUTURA ANALÍTICA DO PROJETO (EAP)Relembrando a analogia do mapa, o projeto possui um objetivo geral que pode ser subdividido em objetivos menores. Essa estratégia permite diminuir a complexidade do projeto pois, geralmente, partes menores são mais fáceis de administrar. E, após concluir cada uma das partes, a soma delas formaria o todo, ou seja, o projeto. Segundo Trentim (2011, p. 99), EAP é o “Processo de subdivisão das entregas e do trabalho do projeto em componentes menores de modo a facilitar as estimativas e o gerenciamento do trabalho”.

A EAP permite decompor todo o trabalho do projeto em partes menores que serão mais fáceis de estimar e gerenciar.

A EAP – Estrutura Analítica do Projeto (ou, em inglês, WBS – Work Breakdown Structure) é uma abordagem que permite decompor todo o trabalho do projeto em partes menores, mais fáceis de gerenciar. Existe diversas representações para a EAP, mas a mais comum é na forma de uma árvore invertida (Figura 3).

https://docs.google.com/viewer?a=v&pid=sites&srcid=Zmd2Z3AxMC5tYXVyaWNpb3ZpZWlyYS5uZXR8bG9naXN0aWNhLXNhbHZhZG9yLTIwMTR8Z3g6NTU2NzE0MzU2NmY0NTU



Nessa representação, como pode ser observado na Figura 3, o primeiro nível pode representar o produto final, ou serviço, ou ainda todo o trabalho do projeto. O segundo nível representa a primeira decomposição do primeiro nível, ou seja, “Pintar uma sala” foi dividida em: Preparação de materiais, preparação da sala, pintura da sala e limpeza da sala. O terceiro nível representa a divisão de cada elemento do segundo nível. Por exemplo, a “Preparação de materiais” ainda foi dividida em: comprar tintas, comprar escada, comprar rolos e comprar removedor de papel de parede.

Quer saber mais sobre a EAP? Leia o material disponível em:http://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto

A EAP pode ter vários níveis. Sua profundidade dependerá do nível de detalhamento necessário que se deseja dar ao projeto. Alguns níveis podem ser mais detalhados que outros, por exemplo, considerando a Figura 4, a qual apresenta uma outra forma de representar uma EAP, “Pesquisa” e “Escrita” foram subdivididas para o terceiro nível. Entretanto, a “Apresentação” não foi dividida.

http://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto

A cada nível da EAP pode ser atribuído um número. Os números também obedecem a hierarquia dos níveis (Figura 5). Como ainda pode ser percebido na Figura 5, uma EAP também pode ser representada no formato textual. Você já percebeu, portanto, que a divisão dos trabalhos acadêmicos normalmente empregam a abordagem da EAP. A EAP de um projeto pode ser representada em diversos formatos: gráfico, textual, tabular,

hierarquia, etc.

Regra dos 100%A regra dos 100% é um princípio aplicado à EAP a qual define que a soma de cada elemento imediatamente abaixo de um nível decomposto é igual a 100% do elemento imediatamente acima. Segundo o PMI (2008), a aplicação desta regra vale para todos os níveis na hierarquia: a soma de todo o trabalho dos níveis "filhos" deve ser igual a 100% do trabalho representado pelo "pai" e a EAP não deve incluir qualquer trabalho que saia do escopo existente do projeto, isto é, ele não pode incluir mais do que 100% do trabalho...”.

Vídeo sobre EAP


Para ilustrar, considerando a Figura 7 (parte do exemplo apresentado na Figura 6), você deve ter notado que o nível 1, “Trabalho da disciplina” representa o projeto inteiro. Entretanto, todo esse projeto foi dividido em três partes. Cada uma das partes representa uma porção do projeto inteiro, logo, a soma dessas partes deve ser igual a todo o trabalho do projeto. Também deve ter notado que as partes possuem quantidade de trabalho diferentes, ou seja, as partes não precisam ter a mesma quantidade de trabalho, entretanto, a soma de trabalho dessas partes deve totalizar 100% do trabalho total.

Você também deve ter notado na Figura 6 que a regra dos 100% pode ser aplicada para todos os níveis da EAP. Por exemplo, considerando a Figura 8, todo trabalho do item “Pesquisa” foi dividido ainda em duas tarefas: “Resumo Livros” e “Resumo Artigos”. Note que o trabalho “Pesquisa” representa 40% de todo o trabalho do projeto. Entretanto, todo esse trabalho, ou seja, 100% do trabalho “pesquisa” foi dividido em duas tarefas e cada uma delas representará 50% de todo o trabalho “Pesquisa”. Nesse caso, o trabalho foi dividido em duas tarefas com a mesma quantidade de trabalho. Esse raciocínio pode ser aplicado os demais níveis da EAP e é o gerente de projeto junto ao interessado que deve definir o nível de detalhamento da EAP, bem como as estimativas de trabalho de cada nível.

Até quando decompor a EAP?Segundo o PMI (2008), os responsáveis pelo escopo devem “subdividir as entregas do projeto em componentes menores e mais GERENCIÁVEIS, até que as entregas do trabalho estejam definidas no nível de PACOTES DE TRABALHO” (PMBOK, 2004).


Saiba mais.

Ouça o PODCAST sobre EAP e uma técnica de decomposição:

http://www.ricardo-vargas.com/pt/podcasts/wbs/

E, o que é pacote de trabalho?Segundo Maximiano (2010), pacote de trabalho é o “conjunto delimitado de atividades do projeto […] atribuídas a uma pessoa ou unidade funcional”. Em outras palavras, o pacote de trabalho é o último nível da EAP, a folha, e é sobre o pacote de trabalho que se deve embasar o planejamento e estimativas do projeto.

Um nível, ao ser dividido, deve gerar pelo menos dois outros subníveis, ou seja, um nível não pode ser subdividido em apenas mais um nível (veja contraexemplo na Figura 9 – Nível 4). Mas a principal do pacote de trabalho é facilitar o planejamento.

http://www.ricardo-vargas.com/pt/podcasts/wbs/

Vamos assistir a vídeo aula 3Para cada pacote de trabalho pode ser definido, por exemplo: objetivo, tarefa(s), entrega(s), recurso(s), orçamento, duração e critérios de aceitação.

O pacote de trabalho é a unidade que permite estimar com mais precisão diversos indicadores do projeto, como: tempo, custo, recursos, etc.

Quer saber mais? Ouça um PODCAST sobre como definir o tamanho de um pacote

de trabalho:http://www.ricardo-vargas.com/pt/podcasts/when-much-sometimes-is-too-much/

http://www.ricardo-vargas.com/pt/podcasts/when-much-sometimes-is-too-much/

Tomando como exemplo a Figura 11, que apresenta a EAP para uma coleta de dados, teríamos seis pacotes de trabalho. Para cada um deles poderíamos definir: objetivo, tarefa(s), entrega(s), recurso(s), entregas, orçamento, duração, critérios de aceitação.

A Figura 12 ilustra o planejamento do pacote de trabalho “Roteiro” da EAP apresentada na Figura 11. A EAP apresentada na Figura 11 associada ao detalhamento do pacote de trabalho apresentado na Figura 12 pode ser utilizado como referência para a elaboração do cronograma do projeto. O cronograma do projeto é uma ferramenta indispensável que permite o controle e acompanhamento do projeto pelo gerente do projeto. A Figura 13 apresenta um exemplo de cronograma elaborado com base na EAP da Figura 11 e pacote de trabalho ilustrado na Figura 12. Cada nó (item que é desmembrado) é transformado numa tarefa agrupadora (tarefa resumo) e os pacotes de trabalho são transformados em tarefas do projeto. Saiba mais.Ouça o PODCAST e saiba mais sobre EAP e Pacote de Trabalho:http://www.ricardo-vargas.com/pt/podcasts/work_package_tasks_dictionary/

http://www.ricardo-vargas.com/pt/podcasts/work_package_tasks_dictionary/

MÉTODOS ÁGEISOs método ágeis surgiram do encontro de 17 metodologistas, em 2001. O grupo formou a Aliança Ágil. Com base em um manifesto, o grupo definiu um conjunto de princípios que deveria dar uma resposta aos seguintes pontos:» Aos chamados métodos pesados (ou peso pesados) que tornavam o desenvolvimento desoftware moroso e complexo.» Alto índice de fracasso dos projetos da área de TI.» Distanciamento dos interessados, ou seja, as metodologias de desenvolvimento mantinham os interessados distantes do processo de desenvolvimento de software.» Paradigma comando e controle (gerência e equipe). Essa abordagem torna a equipe apenas uma executora de tarefas.

Métodos ágeis foi a resposta que a comunidade encontrou como alternativa para o gerenciamento de projetos mais flexível.Pesquisas apontam (Figura 14) que os método ágeis são mais efetivos que os métodos tradicionais. Pesquisa realizada pelo Standish Group apontou que 42% dos projetos ágeis alcançaram sucesso frente a apenas 14% dos métodos tradicionais, no caso, o método Cascata (Waterfall).

As abordagens tradicionais focam o tempo e custo e, como você sabe, quando nós direcionamos maior prioridade para uma dessas variáveis, a outra ou outras variáveis sofrem as consequências. Por exemplo, para cumprir os contratos principalmente em relação ao custo e tempo, muitas empresas acabam por diminuir as entregas, ou seja, o escopo. Então, o cliente recebe um produto bem menor que o combinado inicialmente.

Os métodos ágeis buscam o equilíbrio das variáveis escopo, tempo e custo com foco maior

na variável escopo, ou seja, é uma abordagem orientada ao produto.

Diferentemente das abordagens tradicionais, os métodos ágeis focam o escopo, ou seja, é dada a preferência para as entregas do projeto. Mas, você poderia perguntar? Como fica o tempo e o custo? Bom, funciona assim: uma lista de necessidades por ordem de prioridade é definida e, se o tempo ou o custo forem atingidos antes de terminar a lista, teoricamente, todas as necessidades de maior prioridade foram entregues ao cliente restando, portanto, as necessidades de menor prioridade. Alguns dos principais métodos ágeis:

» Programação Extrema – eXtreme Programming (XP).» Framework Scrum.» Desenvolvimento Dirigido à Funcionalidade (FDD – Feature Driven Development).» Método de desevolvimento de Sistemas Dinâmicos – DSDM (Dynamic Systems Development Method).» Desevolvimento Adaptável de Software – Adaptive Software Development.» Crystal.» Programação Pragmática – Pragmatic Programming.» Desenvolvimento Dirigido a Teste – Test Driven Development.» Modelagem ágil – Agile Modeling.

As abordagens ágeis são estruturadas segundo alguns valores (Figura 16) e princípios estabelecidos pelos metodologistas no encontro de 2001. Esses valores, no total 4, e princípios, no total 12, formam a base dessas metodologias. Saiba mais sobre os princípios ágeis:http://agilemanifesto.org/iso/ptbr/principles.html

Vamos assistir a vídeo aula 4SCRUMScrum é um framework de gerenciamento ágil de projeto de software proposto por Jeff Sutherland em 1993. Todo trabalho é dividido em pequenos ciclos de desenvolvimento chamados Sprints. CadaSprint dura entre uma a quatro semanas. Ao final de cada Sprint é entregue uma parte funcional do produto.

http://agilemanifesto.org/iso/ptbr/principles.html

SCRUM aceita que inevitavelmente haverá mudanças no projeto.

O processo de gerenciamento proposto pelo Scrum é relativamente simples:

1. Inicialmente é eleito um responsável pelos requisitos, ou proprietário do produto (product owner) que define a mantém atualizada uma lista com todos os requisitos (product backlog) do usuário ou cliente.

2. Numa 1ª reunião (Sprint Planning Meeting), são selecionados o “mediador” (Scrum Master) e os requisitos (prioridade e tempo).

3. Numa 2ª reunião, a equipe (Scrum Team) calcula e divide as tarefas (sprint Backlog). Essa porção de requisitos (interação) que será desenvolvida é chamada de sprint e dura entre 1 e 4 semanas. Ao final de um sprint é entregue uma parte funcional do produto.

4. Durante uma sprint são realizadas reuniões diárias com duração de 15 minutos. Ao final da sprint é realizada a reunião de revisão e preparação para o próximo sprint.

Vídeo sobre a implantação do Scrum na

Globo.com:

http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video

Equipe Scrum e seus PapéisO Product Owner (proprietário do produto) é a única pessoa responsável pelo gerenciamento doBacklog do Produto e por garantir o valor do trabalho realizado pelo Time. O Product Owner (ou PO) pode ser o cliente, um gerente de produto, um usuário, etc. É recomendado que o Product Owner conheça o produto que será desenvolvido e que tenha uma boa interação com os demais interessados no projeto, visto somente ele ser o responsável pelos requisitos do produto.

Times (multifuncionais) auto-organizados de desenvolvedores, analistas, engenheiros, especialista em banco de dados, etc. transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. É importante destacar que os Times Scrum devem ser pequenos para que de fato produzam resultados satisfatórios. Muitas experiências com Times grandes (com 10 ou mais integrantes) tem mostrado que a produtividade diminui significativamente. Isto porque o Time Scrum deve se comunicar intensamente e, Times com muitos integrantes tendem a ter dificuldades no processo de comunicação.

O Scrum Master é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras. Ele não tem autoridade (no sentido de chefe), mas é o responsável pela equipe, coordena os eventos, avalia os resultados (produtividade), ou seja, é a interface da equipe perante os demais interessados, assim como o Product Owner é a interface dos interessados (lado cliente/usuário).

TimeBoxTimebox (caixa do tempo) significa a delimitação no tempo de uma tarefa/evento. Vários eventos no Scrum são limitados no tempo, por exemplo, uma Sprint deve ser realizada entre 1 e quatro semanas e as reuniões tem duração entre 15 minutos a 4 horas (dependendo da reunião).

Quer saber mais sobre Timebox? Leia o artigo disponível em:http://blog.myscrumhalf.com/2011/11/time-box-no-scrum/

Planejando a Sprint

http://blog.myscrumhalf.com/2011/11/time-box-no-scrum/

Como você já deve ter percebido, Sprint (Figura 18) é uma porção de todo o processo supostamente necessário para desenvolver o produto final. Geralmente, uma Sprint deve durar entre duas e quatro semanas. As Sprints de um projeto devem ter a mesma duração.Vamos assistir a vídeo aula 5

Como você deve ter percebido na Figura 18, uma Sprint implementa uma parte dos requisitos (ou histórias) listados no Product Backlog, essa porção de requisitos que será implementado na Sprint é chamado de Sprint Backlog. Ao final de uma Sprint, deve-se entregar o resultado planejado para a Sprint e, esse resultado, deve acrescentar algo ao produto, incrementá-lo, além, é claro, de ser funcional.

Saiba mais sobre o que são histórias de usuários:

Antes de ser iniciada, a Sprint é planejada na Reunião de Planejamento 1. Nessa reunião os requisitos ou histórias são selecionados de tal forma que caibam dentro do tempo definido para a Sprint. Os requisitos ou histórias selecionados devem ser sempre os de maior prioridade. A prioridade dos requisitos é definida pelo Product

http://blog.myscrumhalf.com/2011/10/

Owner. Uma vez a lista esteja pronta (Sprint Backlog), é realizada a Reunião de Planejamento 2. Essa reunião tem por objetivo subdividir os requisitos ou histórias em tarefas. Os integrantes do Time selecionam as tarefas que desejam realizar.

Executando a SprintUma vez definidas as tarefas e seus responsáveis, é iniciada a execução da Sprint. À medida que aSprint é executada, o Time compara o planejado ao realizado. Diariamente são realizadas reuniões pelo Time, os quais discutem o andamento e impedimentos da Sprint. Essas reuniões, normalmente realizadas em pé, ocorrem no início da manhã ou final da tarde e duram em média 15 minutos. A reunião aborda os seguintes temas: 1) O que você fez ontem? 2) O que você fará hoje? E, 3) Há impedimentos no seu caminho?

Finalizando a SprintApós o término da Sprint, é realizada a reunião de Revisão. Participam dessa reunião o Time, Scrum Master (SM) e Product Owner (PO). O Time apresenta os resultados ao PO que por sua vez avalia se os requisitos (histórias) foram implementadas satisfatoriamente. Se não for aceito, os requisitos reprovados voltam para o Product Backlog e farão parte de uma nova Sprint. Após o término da reunião de Revisão também é realizada a reunião de Retrospectiva. Nessa reunião

são discutidos os pontos negativos e positivos da Sprint. São propostas melhorias que farão parte da nova Sprint.

Quer saber mais?Leia o glossário SCRUM:

http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario/ RESUMONessa unidade, nós discutimos um pouco sobre como iniciar um projeto, bem como a importância sobre a definição clara, mensurável e precisa do objetivo do projeto. Vimos também que todo projeto deve definir o escopo do projeto, ou seja, o que faz e o que não faz parte do projeto. Aprendemos que a EAP ou Estrutura Analítica do Projeto é um instrumento fundamental para descrever e planejar um projeto. Finalmente, discutimos sobre um pouco sobre uma nova abordagem de gestão de projeto: os métodos ágeis. Percebemos que os métodos ágeis tem apresentado, nos últimos anos, resultados melhores que métodos tradicionais como o método Cascata. Vimos também sobre o Scrum, uma abordagem ágil muito utilizada por empresas de desenvolvimento de software. Finalmente, discutimos alguns detalhes sobre o Scrum: valores, princípios, processo, papéis envolvidos e dinâmicas.

Revisão sobre o Scrum, Assista ao vídeo que apresenta um resumo sobre o Scrum:

Visão geralApresentação da disciplina:

CURSO: especialização em Tecnologias para Aplicações WEBDISCIPLINA: ANÁLISE DE SISTEMASDOCENTE: iolanda cláudia sanches catarinoApresentação do Professor:Sou a professora Iolanda, mestre em Ciência da Computação pela UFSCar, docente da UNOPAR na graduação e pós-graduação desde 1996 e atuo na área de engenharia de software como analista de sistemas.Sejam bem-vindos à disciplina de Análise de Sistemas!Primeiramente, abordarei uma contextualização do paradigma orientado a objetos, daUnified Modeling Language (UML), do Processo Unificado e uma visão geral da metodologia Enterprise Knowledge Development (EKD) que é uma abordagem para a modelagem organizacional, facilitando a compreensão do negócio para iniciar a modelagem das atividades de Análise de Requisitos e

http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario/

Análise.Na sequência, trabalharemos com os dois principais diagramas da atividade de Análise – o Diagrama de Casos de Uso e o Diagrama de Classes, integrando-os com o Diagrama de Atividades que se aplica a qualquer domínio de software.

Objetivos: Conhecer fundamentos sobre o paradigma orientado a

objetos; Conhecer a Linguagem de Modelagem Unificada – UML e

suas técnicas de modelagem; Conhecer e aplicar técnicas de modelagem da atividade de

análise de sistemas, priorizando os dois principais diagramas da UML – Diagrama de Casos de Uso e Diagrama de Classes.

Conteúdo Programático: Paradigma Orientado a Objetos: histórico, características e

conceitos; A Linguagem de Modelagem Unificada - Unified Modeling

Language (UML): histórico e visão geral das técnicas de modelagem;

Modelo de Use Cases: Diagrama de Use Cases e Documentação de Use Cases;

Diagrama de Classes; Diagrama de Atividades; Diagrama de Sequência; Diagrama de Máquina de Estados; Especificação das técnicas de modelagem com

ferramenta CASE.

Metodologia:Na unidade utilizaremos todos os recursos necessários e disponíveis para o desenvolvimento da discussão do conteúdo, sendo assim, faremos uso de:

Textos da própria Web Aula e de outros sites que possam contribuir para a discussão;

Vídeos que possam esclarecer ou aprofundar determinados conteúdos;

Fóruns para discussão de tópicos onde seja possível a troca de ideias e conteúdos entre os discentes e docentes;

Avaliações virtuais onde será realizada a verificação do aprendizado;

Entre outros recursos que poderão ser utilizados visando maior entendimento da matéria.

Avaliação Prevista:Cada web aula conterá uma avaliação virtual composta de 5 questões (sendo assim, temos 2 web-aulas com 5 questões cada). Quando houver fórum de discussão o aluno será avaliado quanto

ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação.

Critérios para Participação dos Alunos no Fórum:

Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação. Textos apenas concordando ou discordando de comentários de outros participantes do fórum sem a devida justificativa ou complementação não acrescentam em nada ao debate da disciplina, sendo assim, devem ser evitados. Os textos devem sempre vir acompanhados das justificativas para a opinião do discente sobre o conteúdo discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além disso, podem ser utilizados citações de artigos, livros e outros recursos que fundamentem a opinião ou deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico principal do fórum, evitando debates que não tem relação com o tema selecionado pelo professor.

Habilidades e competênciasAmpliar seus conhecimentos sobre os aspectos teóricos contidos nas diversas correntes do pensamento sobre a temática discutida na disciplina;Compreender a importância dos temas trabalhados para a formação profissional;Articular a relação teoria e prática no exercício da profissão, por meio do entendimento da visão do mundo moderno e globalizado.

1

TECNOLOGIAS PARA APLICAÇÕES WEB

WEB AULA 1Unidade 1 – Análise de Sistemas

Atualmente, a transformação organizacional tem sido amplamente discutida e praticada, pois a transição entre negócios e tecnologias de informação, bem como a integração das funcionalidades de um Sistema de Informação (SI) com os requisitos organizacionais tem sido o grande problema das organizações e da engenharia de

sistemas. Então, iniciamos esclarecendo dois conceitos: Engenharia de Sistemas e Engenharia de Software!

Figura 1 – Engenharia de Sistemas.

Fonte: Thinkstock (2012).A Engenharia de Sistemas contempla todos os aspectos relacionados ao desenvolvimento de sistemas com base em computadores, incluindo hardware, software e engenharia de processos, e aEngenharia de Software é uma parte da Engenharia de Sistemas que se ocupa de todos os aspectos da produção de software (SOMMERVILLE, 2003). Para Pressman (2002), a Engenharia de Software abrange um conjunto de 3 elementos fundamentais (métodos, ferramentas e procedimentos), que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade.O método proporciona os detalhes de “como fazer” para construir o software. Envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos, análise e projeto, implementação e testes. Sommerville (2003) define que um método é uma abordagem estruturada para o desenvolvimento de software, para facilitar a produção de software de alta qualidade, apresentando uma boa relação custo-benefício.Todos os métodos apresentam modelos de um sistema (técnicas de modelagem) que possam ser representados graficamente por diagramas, na maioria, ou de forma descritiva, sendo que cada técnica de modelagem tem um objetivo e aplicabilidade para melhor especificar o projeto. Na literatura, há vários métodos de desenvolvimento renomados e reconhecidos pelo mercado. Não existe o método ideal e diferentes métodos têm áreas de aplicação diversificada.As ferramentas proporcionam apoio automatizado ou semi-automatizado aos métodos de desenvolvimento de software, como por exemplo, as ferramentas Computer Assited Software Engineering (CASE) - Engenharia de Software Auxiliada por Computador, de modelagem, de banco de dados e de linguagens de programação.Os procedimentos definem o planejamento do projeto, a sequência de execução das atividades, as técnicas de modelagem que são adotadas do método escolhido, a sequência de execução das atividades e demais regras e padrões adotados no desenvolvimento do software.

Podemos concluir que o desenvolvimento de um SI deve abranger a definição de uma metodologia que contemple métodos, técnicas de modelagem, arquitetura e tecnologias a serem adotados no desenvolvimento do sistema, visando um software com qualidade que atenda plenamente os requisitos dos usuários e assim, agregue inteligência ao negócio.

2

Os vários métodos e metodologias de desenvolvimento de sistemas dos paradigmas Estruturado e Orientado a Objetos abrangem um conjunto de técnicas de modelagem específicas para documentar as principais fases de um processo de desenvolvimento – Levantamento de Dados, Análise, Projeto e Implementação, conforme ilustra a figura a seguir.

Figura 2 – Processo de Desenvolvimento.

Fonte: Do autor (2012).

A atividade de Análise consiste em documentar o quê o sistema deve fazer em uma visão lógica do negócio e independente de tecnologias de desenvolvimento.

Muitos modelos de requisitos existentes descrevem o ambiente organizacional por meio de entidades e atividades, porém não representam as razões envolvidas nos processos de decisões, o qual dificulta o desenvolvimento de um SI que atenda

plenamente os requisitos da organização. Assim, para garantir a identificação dos requisitos de um SI, sugere-se adotar a modelagem organizacional, previamente, visando identificar, definir e especificar os objetivos e processos próprios da organização (CATARINO; CAZARINI, 2008).A Modelagem Organizacional é um processo de modelagem complexa, pois envolve questões que necessitam de conhecimentos específicos ou tácitos dos participantes envolvidos nos processos de negócio, questões de gestão de pessoas e questões técnicas relacionadas aos objetos ou serviços da organização. A metodologia Enterprise Knowledge Development (EKD) (BUBENKO, 1998) é uma abordagem para a Modelagem Organizacional que facilita a aquisição do conhecimento da estrutura organizacional e estratégica, auxiliando na identificação dos requisitos organizacionais para, assim, melhorar a compreensão do domínio e a interação entre os usuários e o SI.

Para continuar aprendendo sobre EKD, acesse os links:

http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-530X2004000200006

http://www.teses.usp.br/teses/disponiveis/18/18135/tde-25112008-153952/pt-br.php

3

1. Paradigma Orientado a ObjetosO paradigma Orientado a Objetos é uma abordagem para o desenvolvimento de aplicações, ou seja, é uma estratégia de desenvolvimento de software que organiza o software como uma coleção de objetos que contém tanto a estrutura dos dados como o comportamento. É uma maneira de pensar nos problemas, utilizando modelos organizados a partir de conceitos do mundo real.A programação orientada a objetos teve início nos anos 1970 com a linguagem SIMULA, parte da linguagem Smalltalk desenvolvida pela Xerox PARC, mas ganhou grande visibilidade durante a década de 1980. Os conceitos básicos do desenvolvimento de software orientado a objetos levaram mais de 10 anos para amadurecerem. Da mesma forma que era difícil pensar em programação estruturada quando as linguagens disponíveis eram Assembler e Fortran, também ficava difícil pensar em programação orientada a objetos quando não se dispunha de linguagens como C++, Ada e Java.A abordagem orientada a objetos baseia-se nos conceitos da orientação a objetos, apresentando melhorias significativas de qualidade e um aumento constante da produtividade para o desenvolvimento de aplicações. A complexidade do desenvolvimento de sistemas tem aumentado em função de mudanças tecnológicas expressivas em poder de processamento e facilidade de uso, face à demanda por um mercado competitivo e dinâmico. Sua principal característica é a uniformização dos formalismos utilizados na análise, no projeto e na implementação. Outras características se destacam, como:a) Reusabilidade: refere-se à diminuição de custos por meio do reaproveitamento (reutilização) de componentes de software e diminuição do tempo de desenvolvimento do sistema. Segundo Booch; Jacobson e Rumbaugh (2000, p. 20), “[...] os componentes são partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces”;

b) Manutenibilidade: refere-se ao grau de impacto de alterações corretivas e evolutivas, nosoftware , para realizar mudanças bem localizadas dos objetos, não acarretando propagações descontroladas por todo o software;

c) Confiabilidade: refere-se a um controle de segurança e organização que é estabelecido às classes de objetos, obtido pelo encapsulamento, tornando o acesso às estruturas de dados privado aos objetos;

d) Extensibilidade: refere-se às partes do software que têm o seu uso estendido a objetos pertencentes às classes criadas posteriormente. Classes genéricas podem ser acrescidas de funcionalidades, gerando classes mais especializadas, aplicando o conceito de herança.Acompanhando a evolução das linguagens de programação orientadas a objetos, os métodos de modelagem orientados a objeto surgiram entre meados da década de 1980 e 1990. Os métodos suportam os mesmos conceitos básicos da orientação a objetos, apresentando técnicas de modelagem com notação e interpretação particular dos elementos que compõem a técnica.Os diversos métodos que surgiram para apoiar o paradigma orientado a objetos, tiveram uma grande diversidade de autores. No início da década de 1990, os pesquisadores James Rumbaugh, Ivar Jacobson e Grady Booch uniram as melhores características destacadas em suas técnicas de modelagem e construíram um padrão de referência para modelagem orientada a objetos, surgindo aUnified Modeling Language (UML) – Linguagem de Modelagem Unificada.4

O elemento principal da abordagem orientada a objetos é o conceito de objeto. Na definição de Booch; Jacobson e Rumbaugh (2000, p. 456), um objeto é “[...] uma entidade com uma fronteira bem-definida e uma identidade que encapsula o estado e comportamento”. Para Rumbaugh (1994, p. 31), um objeto é “[...] um conceito, uma abstração, algo com limites nítidos e significado em relação ao problema em causa”. A figura a seguir ilustra um objeto.

Figura 3 – Exemplo de Objeto.

Fonte: Thinkstock (2012).

Podemos definir um objeto como sendo qualquer coisa concreta ou abstrata com existência perceptível no mundo real que possa ser individualizado por possuir

características e comportamento próprio, ou seja, todos os objetos têm identidade e são distinguíveis.

Para rever os conceitos da orientação a objetos, acesse o link:

http://books.google.com.br/books?id=BPVHsG17bAYC&printsec=frontcover&dq=conceitos+da+orienta%C3%A7%C3%A3o+a+objetos&hl=pt-BR&sa=X&ei=TviYUNLgFIf28wSOpICYCw&ved=0CDkQ6AEwAQ#v=onepage&q=conceitos%20da%20orienta%C3%A7%C3%A3o%20a%20objetos&f=false

2. Introdução à Unified Modeling Language (UML)A UML consiste da fusão dos métodos de Booch, Rumbaugh (OMT- Object Modeling Technique) e Jacobson (OOSE – Object-Oriented Software Engineering). A fusão iniciou com o trabalho de Rumbaugh e Booch, que criaram um método a partir de pontos fortes de cada um, surgindo o Unified Method – UM 0.8, apresentado ao público em 1995. Logo a seguir, em meados de 1996, Jacobson integrou-se ao grupo e lançaram a UML versão 0.9. A partir daí, criaram forças com cooperação de grandes empresas, lançando no mercado com aprovação da Agência Americana de Padrões – Object Management Group (OMG) em julho de 1997, considerando um padrão mundial. A concretização da UML aconteceu em 1997.Conforme Booch; Jacobson e Rumbaugh (2000, p. 13), a UML é “[...] uma linguagem padrão para a elaboração da estrutura de projetos de software . A UML é uma linguagem para visualização, especificação, construção e documentação de artefatos que façam uso de sistemas complexos desoftware ”.A UML contempla uma representação gráfica por meio das técnicas de modelagem que especificam vários elementos (objetos, classes, atributos etc) da abordagem orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas se apoia no desenvolvimento incremental, por meio de modelos que podem evoluir com a inclusão de novos detalhes.

VÍDEO 100:0000:00

Atualmente, a OMG é a organização responsável em manter e administrar a UML.

Para mais informações sobre a OMG, acesse o link:

http://www.omg.org/

Segue-se um resumo da evolução da UML:Quadro 1 – Cronograma de evolução da UML.

Ano Versão

1995 UML 0.8 (Booch e OMT)

1996 UML 0.9 (Booch, OMT e OOSE)

1997UML 1.0 (padronizada pelo OMG – Object Management Group)

UML 1.1 (revisada e adotada pelo OMG)

1998 UML 1.3 (nova revisão)

2001 UML 1.4

2003 UML 1.5

2005 UML 2.0

2007 UML 2.1.1 (setembro)e 2.1.2 (novembro)

2009 UML 2.2

2010 UML 2.3

2011 UML 2.4.1 (agosto)Fonte: Do autor (2012).

Veja o vídeo a seguir que apresenta a evolução das tecnologias.https://www.youtube.com/watch?v=WDFkHCfVe5Y

E a UML, porque evolui?A UML contempla uma representação gráfica, por meio das técnicas de modelagem que especificam vários elementos (objetos, classes, atributos etc) da abordagem orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas se apoia no desenvolvimento incremental, a partir de modelos que podem evoluir com a inclusão de novos detalhes.Um modelo é uma descrição simplificada da realidade, apresentado a partir de uma perspectiva específica e criado para proporcionar uma melhor compreensão do sistema. Cada modelo pode ser expresso em diferentes níveis de precisão, constituindo um conjunto de diagramas consistentes entre si e acompanhados de técnicas de modelagem textuais. Um diagrama é uma visão sobre um modelo, o qual proporciona uma representação parcial do sistema.

Figura 4 – Modelo x Diagrama.

Fonte: Do autor (2012).Booch, Jacobson e Rumbaugh (2000) consideram as principais características da UML:

a) centrado na arquitetura: a arquitetura do sistema é utilizada como principal artefato para a conceituação, construção, gerenciamento e evolução do sistema em desenvolvimento, representando uma visão do projeto como um todo. O conceito de arquitetura de software incorpora os aspectos estáticos e dinâmicos mais importantes do sistema. A arquitetura é influenciada por muitos fatores, tais como a plataforma de software sobre a qual o sistema vai rodar (sistema operacional, sistema gerenciador de banco de dados, protocolos para comunicação em rede, etc.), blocos de construção reutilizáveis (frameworks, componentes e patterns), considerações de distribuição, sistemas legado e requisitos não funcionais;

b) orientado a Casos de Uso: os casos de uso são utilizados como o principal artefato para o estabelecimento do comportamento desejado do sistema;

c) processo iterativo: contempla o gerenciamento de sequências de versões executáveis e incrementais, sendo que cada nova versão incorpora os aprimoramentos incrementais em relação às demais. Uma versão do sistema liberada resulta em uma iteração concluída.De uma forma geral, a UML privilegia a descrição de um sistema segundo três perspectivas:estrutural – representa a visão estática do sistema; funcional – representa as funcionalidades do sistema, ou seja, os serviços que o sistema disponibiliza aos usuários; dinâmica – representa o comportamento dos objetos em tempo de execução.

Para mais informações sobre a UML, acesse o link:

http://www.uml.org/

6

A UML 2.0 abrange quatorze técnicas de modelagem, classificadas em estrutural e comportamental. As técnicas de modela Modularidade gem estruturais enfatizam a estrutura dos elementos a partir da identificação dos objetos, colaborando para modelagem estática do sistema. As técnicas de modelagem comportamentais enfatizam o comportamento e a interação entre os elementos do sistema, colaborando para modelagem dinâmica do sistema.

Quadro 2 – Relação das técnicas de modelagem da UML 2.0Estruturais Comportamentais

Diagrama de Classes Diagrama de Casos de Uso

Diagrama de Objetos Documentação de Casos de Uso

Diagrama de Estruturas Compostas Diagrama de Atividade

Diagrama de Pacotes Diagrama de Máquina de Estados

Diagrama de Componentes Diagrama de Sequência

Diagrama de Implantação Diagrama de Comunicação

Diagrama de Interação Geral

Diagrama de Tempo


Figura 5 – Técnicas de Modelagem da UML.


Para conhecer e saber mais sobre as técnicas de modelagem da UML,

acesse o link: .

A arquitetura da UML 2.0 é composta de duas bibliotecas, a Infrastructure – metamodelo superior – e a Superstructure, que define os elementos que compõem as notações de modelagem da UML, criadas pela extensão e acréscimo dos elementos básicos definidos na Infrastructure. Para facilitar a reutilização de um software , essa arquitetura assegura que o projeto do software seja especificado com:a) modularidade: organizam-se os elementos da modelagem em pacotes, ou seja, em unidades pequenas, bem definidas e fáceis de usar;

b) camadas: representa o refinamento dos elementos de um modelo para organizar e facilitar o uso, obtendo um refinamento dos modelos por meio da abstração dos elementos;

c) extensibilidade: permite a personalização dos elementos existentes de um modelo, para que, assim, novos elementos não tenham que ser criados para solucionar novos problemas.

Para continuar aprendendo, acesse os links:

OMG Unified Modeling LanguageTM(OMG UML), Infrastructure:

http://pt.wikipedia.org/wiki/UML

http://www.omg.org/spec/UML/2.4.1/Infrastructure

OMG Unified Modeling LanguageTM(OMG UML), Superstructure:

http://www.omg.org/spec/UML/2.4/Superstructure

7

2.1 O Processo UnificadoO Unified Process (BOOCH, JACOBSON; RUMBAUGH, 2000) surgiu para apoiar o desenvolvimento desoftware s orientado a objetos, fornecendo uma forma sistemática e evolutiva de modelar sistemas com a UML.O Processo Unificado consiste na repetição de uma série de ciclos durante o processo de desenvolvimento de um sistema, permitindo uma gerência mais efetiva de projetos complexos. Cada ciclo é concluído com uma versão do produto pronta para distribuição e é subdividido em quatro fases sucessivas: Concepção, Elaboração, Construção e Transição. Cada fase, por sua vez, é subdivida em iterações que passam por todos os cincos workflows (fluxo de trabalho, atividades) do processo: Requisitos, Análise e Projeto, Implementação e Teste.As fases representam os aspectos dinâmicos do processo e tratam a dimensão do tempo de execução. As atividades são executadas de forma incremental e evolutiva, representando os aspectos estáticos do processo. A ênfase sobre as várias atividades muda em cada fase do processo, como mostra a figura a seguir.

Figura 6 – Ciclo de vida do Processo Unificado.

Fonte: Adaptado de Medeiros (2010, p. 16).Na fase de Concepção define-se a ideia inicial do negócio, o domínio do problema e a delimitação do escopo do projeto. É feita a identificação dos atores que irão interagir com o sistema, definindo a natureza dessa interação em uma perspectiva de alto nível, destacando os principais casos de uso do sistema. Assim, esta fase

evidencia o planejamento, sendo necessário, posteriormente, identificar, definir e analisar os requisitos do sistema. Ao término desta fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento, ou seja, a viabilidade do projeto.

A atividade principal da fase de Concepção está no entendimento dos requisitos e a determinação do escopo do projeto.

Na fase de Elaboração define-se o comportamento funcional dos requisitos do sistema, estabelecendo a arquitetura e mecanismos para tratar aspectos abrangentes do sistema, conforme o domínio do problema. Assim consolida-se a fase de concepção, agregando valor a cada iteração-incremento que sofre. As atividades da fase de Elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis, podendo prever com precisão os custos e prazos para a conclusão do desenvolvimento.

A atividade principal da fase de Elaboração é a definição e modelagem dos requisitos, ainda que algum trabalho de projeto e implementação seja realizado

para prototipar uma versão dosoftware.

Na fase de Construção define-se uma arquitetura executável do sistema para implementação, validação e testes do software.

As atividades principais da fase de Construção concentra-se no projeto e na implementação, visando evoluir e melhorar o protótipo inicial, até obter o primeiro

produto operacional.

Na fase de Transição o sistema é disponibilizado à comunidade usuária com acompanhamento constante, devido à demanda de novas funções ou ajustes do sistema.

A atividade principal da fase de Transição é a de testes, visando garantir que o sistema atenda os requisitos do usuário com qualidade. Além disso, usuários devem

ser treinados, características ajustadas e elementos esquecidos adicionados ao projeto, fazendo a realimentação das atividades por fase.

Para mais informações sobre o Processo Unificado, acesse o link:

http://books.google.com.br/books?id=B1fy5scNtaIC&printsec=frontcover&hl=pt-BR#v=onepage&q&f=false

8

3. Atividade: Análise de RequisitosNesta seção vamos abordar uma breve revisão da Engenharia de Requisitos para relembrar o conceito de requisitos funcionais, que na atividade de Análise de Requisitos ou apenas Requisitos é especificado como casos de uso.

A Engenharia de Requisitos (Requirements Engineering) preocupa-se com o quê deve ser feito, ou seja, a compreensão do problema e não como fazer, considerando o domínio do sistema. A Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar os serviços e restrições (SOMMERVILLE, 2011).O domínio de um sistema engloba o contexto para o qual será provida uma solução, sendo que o processo de reconhecimento do domínio caracteriza a definição de sua fronteira. O conteúdo de um domínio compreende fatos, regras, necessidades, conceitos, agentes etc.

Veja o vídeo a seguir:https://www.youtube.com/user/IBMbrasil?v=LQ5RlWMNtB0

Como o projeto de um software pode atender plenamente as necessidades do usuário?

Considerando um modelo de engenharia de software como o Processo Unificado, a atividade de Análise de Requisitos ou, simplesmente, Requisitos visa identificar, analisar, definir e especificar os requisitos do sistema. 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 a seu funcionamento (SOMMERVILLE, 2011).Sommerville (2011) classifica previamente os requisitos de um sistema em: requisitos de usuário erequisitos de sistema. Requisitos de usuário são declarações em uma linguagem natural com complemento de diagramas ou não, de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar. Requisitos de sistema são descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software, sendo que o documento de requisito de sistema (especificação funcional) deve definir exatamente o que deve ser implementado.CONCLUINDO:

Requisitos de Usuário: expressa os requisitos abstratos de alto nível;

Requisitos de Sistema: expressa a descrição detalhada do quê o sistema deve fazer.Exemplo:

Os requisitos de sistema são classificados em dois tipos: Requisitos Funcionais (RF): são declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações. Requisitos Não Funcionais (RNF): são restrições aos serviços ou funções oferecidos pelo sistema. Incluem restrições de tempo, restrições no processo de desenvolvimento e restrições impostas pelas normas organizacionais. Muitas vezes, aplicam-se ao sistema com o um todo. Surgem por meio das necessidades dos usuários, devido a restrições de orçamentos, políticas organizacionais etc.CONCLUINDO:

Requisitos Funcionais: descrevem o que o sistema deve fazer – funcionalidades;

Requisitos Não Funcionais: expressam restrições que o software deve atender ou qualidades específicas que o software deve ter.9

Exemplos de definição de requisitos em linguagem natural:

O sistema deve prover um cadastro de cursos de extensão – RF;

O sistema deve prover um cadastro de autores (professor responsável pelo curso) dos cursos – RF;

O sistema deve prover um cadastro dos candidatos (internos: alunos e externos: pessoas da comunidade externa) – RF;

O sistema deve prover um cadastro das inscrições para os cursos de extensão – RF;

O sistema deve prover um relatório de inscritos nos cursos de extensão diariamente e por período – RF;

O sistema deve prover um relatório dos cursos de extensão por situação (Ativo, Confirmado, Encerrado ou Cancelado) – RF;

O período mínimo de inscrições de um curso de extensão deve ser de 20 dias – RNF;

O cadastro de candidatos externos deve ser via Web – RNF;

O cadastro das inscrições para um curso de extensão dever ser via Web – RNF;

O cadastro dos candidatos internos deve ser integrado com o sistema acadêmico (cadastro de funcionários – professores) – RNF;

O candidato ao se inscrever em um curso deve receber um e-mail de confirmação como tempo máximo de 10 segundos após a transação – RNF.

Para modelar os requisitos funcionais de um sistema podemos adotar o Diagrama de Casos de Uso que, posteriormente, guiará o processo de desenvolvimento,

conforme o Processo Unificado. Das técnicas da UML, o Diagrama de Sequência também pode ser adotado para especificar o cenário de cada caso de

uso.

Para continuar aprendendo sobre Requisitos, acesse o link:

http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0210666_06_cap_02.pdf

RESUMO:Com a competitividade na era do conhecimento as organizações contam com sistemas computacionais, principalmente, os Sistemas de Informação para prover apoio à tomada de decisão de gestores táticos e estratégicos de forma que agregue inteligência ao negócio. Esta Web Aula apresentou uma contextualização da Engenharia de Sistemas, uma introdução da Unified Modeling Language (UML), descrevendo seu histórico, principais características e técnicas de modelagem da UML 2.0, uma visão do Processo Unificado com suas fases e atividades de desenvolvimento e uma introdução à atividade de Análise de Requisitos.

Vamos iniciar o nosso fórum!

As técnicas de modelagem da UML atendem a documentação de todos os tipos de sistemas de software? Qual a sua opinião?

Figura 7 – Sistemas de Software.


BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. UML: guia do usuário. Rio de Janeiro: Campus, 2000.BUBENKO Janis; STIRNA, Janis; BRASH, Danny. EKD user guide. Dpt of computer and systems sciences. Stockholm: Royal Institute of Technology, 1998.CATARINO, I. C. S.; CAZARINI, E. W. Utilizando a metodologia enterprise knowledge development no processo de desenvolvimento de sistemas de apoio à decisão. UNOPAR Científica Ciências Exatas Tecnológicas. Londrina, v. 7, p. 77-84, nov. 2008. Disponível em:. Aceso em: nov. 2012.MEDEIROS, Ernani. Desenvolvendo software com UML 2.0 - definitivo. São Paulo: Pearson Brasil, 2010.PRESSMAN, Roger S. Engenharia de software. 5. ed. São Paulo: Makron Books, 2002.SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Addison-Wesley, 2003.SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.THINKSTOCK. Logical graph webshop, online store, internet shop. 2012. Disponível em: <http://www.thinkstockphotos.com/image/stock-photo-logical-graph-webshop-online-store-internet/140810423/popup?al=140810423&sq=140810423/c=431,253,632,254,93,28,34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,623,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696,344,629,614,647/f=PIHVX/s=DynamicRank>. Acesso em: nov. 2012.THINKSTOCK. Smartphone with cloud of application icons. 2012. Disponível em: <http://www.thinkstockphotos.com/image/stock-photo-smartphone-with-cloud-of-application-icons/131404860/popup?al=131404860&sq=131404860/f=PIHVX/s=DynamicRank>. Acesso em: nov. 2012.THINKSTOCK. Software architecture class diagram. 2012. Disponível em: http://www.thinkstockphotos.com/image/stock-photo-software -architecture-class-diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28,34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,623,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696,344,629,614,647/f=PIHVX/s=DynamicRank Acesso em: nov. 2012.THINKSTOCK. Software architecture class diagram. Disponível em:http://www.thinkstockphotos.com/image/stock-photo-software -architecture-class-diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28,34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,623,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696,344,629,614,647/f=PIHVX/s=DynamicRankAcesso em: nov. 2012.THINKSTOCK. Software engineering word cloud. 2012. Disponível em:

SUGESTÕES DE LEITURABEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The unified modeling language: user guide. Massachussets: Longman, 2000.BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2006.GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2008.JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James.The unified software development process. New York: Addison-Wesley, 2000.LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007.MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2: do conceitual à implementação. Rio de Janeiro: Brasport, 2010.PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro: Campus, 1994.


WEB AULA 1Unidade 2 – Análise de Sistemas 4. Atividade: AnáliseA atividade de Análise consiste em documentar o quê o sistema deve fazer em uma visão lógica do negócio e independente de tecnologias de desenvolvimento.As técnicas de modelagem propostas pela UML não estão vinculadas, diretamente, a uma atividade (Análise, Projeto, Implementação e Testes) do processo de desenvolvimento de software e não dizem quem deve fazer o quê, quando e como. Alguns autores como Ernani Medeiros (2010) e Bezerra (2007) sugerem a adoção do Diagrama e Documentação de Casos de Uso, do Diagrama de Classes, do Diagrama de Objetos e do Diagrama de Estruturas Compostas para modelar a atividade de Análise e, posteriormente, fazer um refinamento dessas técnicas e complementar com os diagramas de iteração para modelar a atividade de Projeto, representando uma visão física de desenvolvimento.

Para mais informações sobre a UML acesse o catálogo da OMG:

http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

Na UML, os agrupamentos que organizam um modelo (conjunto de diagramas) são chamados de pacotes. O Diagrama de Pacotes tem por objetivo representar os subsistemas ou submódulos englobados por um sistema de forma a determinar as partes que o compõem. Demonstra como os elementos estão organizados nos

pacotes e as dependências que existem entre os elementos e os próprios pacotes (GUEDES, 2008).A notação do Diagrama de Pacotes contempla a representação dos pacotes e da dependência entre os pacotes. Pacotes são utilizados para agrupar elementos, para modelar subsistemas e para a modelagem de subdivisões da arquitetura de uma linguagem. Um Pacote pode se subdividir em outros pacotes. O nome do Pacote deve ser representativo e único. Um relacionamento de Dependência representa as dependências entre os pacotes, indicando que o elemento necessita, de alguma forma, do elemento do qual depende. A Figura 8 exemplifica um Diagrama de Pacotes.

Figura 8 – Exemplo de Diagrama de Pacotes:

Fonte: Do autor (2012).1

4.1 Diagrama de Casos de UsoPara melhorar a compreensão do domínio e garantir que um sistema atenda às reais necessidades dos usuários, o Diagrama de Casos de Uso auxilia a fase de Análise de Requisitos, ajudando a especificar, visualizar e documentar as características e serviços do sistema. Na fase de Análise, o Diagrama de Casos de Uso representa um refinamento dos requisitos funcionais do sistema. A técnica de modelagem de casos de uso foi idealizada por Ivar Jacobson, na década de 1970.Segundo Bezerra (2007), o Modelo de Casos de Uso (MCU) é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele. O MCU é um modelo de análise que representa um refinamento dos requisitos funcionais do sistema em desenvolvimento.Segundo Guedes (2008), o Diagrama de Casos de Uso demonstra o comportamento externo do sistema, procurando apresentar o sistema por meio de uma perspectiva do usuário, demonstrando as funções e serviços (casos de uso) oferecidos e quais usuários (atores) poderão utilizar cada serviço. Para Booch; Jacobson e Rumbaugh (2006), o Diagrama de Casos de Uso representa os aspectos dinâmicos do sistema, tendo um papel central para a modelagem do

comportamento de um sistema, de um subsistema ou de uma classe. Cada um mostra um conjunto de casos de uso e atores e seus relacionamentos.

O Diagrama de Casos de Uso representa as funcionalidades do sistema e os elementos externos ao sistema que interagem com ele. É o diagrama mais abstrato, flexível e informal da UML, sendo utilizado no início da modelagem do sistema, na atividade de análise, embora venha a ser consultado e, possivelmente, modificado durante todo o processo de engenharia do software. Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar, sendo um modelo com uma perspectiva externa do sistema.

Um Diagrama de Casos de Uso é representado pelos elementos. Atores, Casos de Uso eRelacionamentos. Um Diagrama de Casos de Uso deve ser feito com base na especificação da fronteira do sistema, permitindo identificar um subsistema ou o sistema completo, assim delimitando o contexto do sistema.Atores: os Atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar ou interagir com os serviços (funcionalidades) do sistema, ou seja, é qualquer elemento externo ao sistema que interage com ele. A interação significa que um Ator troca informações com o sistema, enviando dados para o sistema processar ou recebendo informações processadas. Normalmente, o Ator inicia a interação com o sistema.Eventualmente um Ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Assim, um ator pode ser qualquer elemento externo que interaja com osoftware (GUEDES, 2008).Os Atores são representados por símbolos de “bonecos magros”, contendo uma breve descrição logo abaixo do seu símbolo que identifica qual o papel que o Ator assume dentro do diagrama. Cada ator deve representar um único papel. A Figura 9 ilustra a notação de Ator e a Figura 9 ilustra o exemplo de alguns Atores.

Figura 9 – Exemplo de Atores.

Fonte: Do autor (2012).Casos de Uso: um Caso de Uso (use case) representa qualquer interação de serviços entre um Ator e o sistema, sem revelar a estrutura e o comportamento interno do sistema. Cada serviço deve ser representado, individualmente, como um Caso de Uso. A Figura 10 ilustra o exemplo de alguns Casos de Uso.Os Casos de Uso referem-se aos serviços, tarefas ou funções oferecidas pelo sistema. São utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema (GUEDES, 2008).2

Os Casos de Uso são documentados, demonstrando o comportamento pretendido para o Caso de Uso e quais funções ele executará quando for solicitado. Os Casos de Uso são representados por uma elipse, contendo uma breve descrição dentro do seu símbolo que identifica qual serviço o Caso de Uso assume. Recomenda-se

nomear um Caso de Uso com verbo no infinitivo mais substantivo(s). Exemplo: Cadastrar Curso ou Manter Curso, Realizar Avaliação, Lançar Nota de Avaliação.

Figura 10 – Exemplo de Casos de Uso.

Fonte: Do autor (2012).Relacionamentos: a interação entre um Ator e um Caso de Uso é representada por um relacionamento. Os relacionamentos possíveis são: associação, generalização, extensão e inclusão.Associação: é um tipo de relacionamento entre os Atores que interagem com o sistema, entre os Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Uma associação entre um Ator e um Caso de Uso demonstra que o Ator utiliza-se, de alguma maneira, da função representada pelo Caso de Uso (GUEDES, 2011).Uma Associação é representada por uma reta, ligando o Ator ao Caso de Uso, podendo indicar a Navegabilidade da Associação, que indica se as informações são fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator ou ambos (não indica a navegabilidade). Uma Associação pode possuir uma descrição própria ou um nome, quando há necessidade de esclarecer alguma informação que está sendo transmitida. A Figura 11 ilustra a notação de Associações e a Figura 12 ilustra o exemplo de associações entre os Atores e Casos de Uso.No relacionamento de Associação entre um Ator e Caso de Uso pode-se indicar a multiplicidade, o qual especifica o número de vezes que um Ator pode utilizar um determinado Caso de Uso.

Figura 11 – Notação de Associação.


Figura 12 – Exemplo de Associação entre Atores e Casos de Uso.


Generalização é um tipo de relacionamento entre Casos de Uso ou entre Atores. A Generalização de Atores é uma representação abstrata de papéis e a Generalização de Casos de Uso representa dois ou mais Casos de Uso que apresentam características semelhantes. Representa-se um Caso de Uso Geral (Generalização), que descreve as características compartilhadas por todos os Casos de Uso Especializados (Especialização). A estrutura do Caso de Uso Geral é herdada pelos Casos de Usos Especializados. A Figura 13 ilustra o exemplo de Generalização de Atores e Casos de Uso.

Figura 13 – Exemplo de Generalização entre Atores e Casos de Uso.

Fonte: Do autor (2012).A Extensão representa um relacionamento estendido entre Casos de Uso, indicando que o Caso de Uso “base” incorpora implicitamente o comportamento de outro Caso de Uso em um local especificado pelo Caso de Uso “estendido”. Um relacionamento estendido é utilizado para a modelagem da parte de um Caso de

Uso que o usuário poderá considerar como um comportamento opcional do sistema ou de um subfluxo separado, que é executado somente sob determinada condição. O relacionamento de dependência <<extend>> é representado por uma seta que parte do Caso de Uso “estendido” para o Caso de Uso “base”. A Figura 14 ilustra um exemplo de Extensão entre os Casos de Uso.Às vezes, não está claro qual é a condição para que um Caso de Uso estendido seja executado, assim, pode-se acrescentar uma Restrição. Restrições são representadas por uma nota explicativa, contendo o texto que determina a condição entre chaves.

Figura 14 – Exemplo do Relacionamento de Extensão.

Fonte: Do autor (2012).O relacionamento de Inclusão representa um relacionamento de dependência entre Casos de Uso, indicado pelo estereótipo <<include>>. Esse relacionamento é utilizado quando existe uma situação ou rotina comum a mais de um Caso de Uso. A inclusão indica uma obrigatoriedade com outro Caso de Uso, sendo que a execução do primeiro obriga também a execução do segundo. Um relacionamento de Inclusão pode ser comparado à chamada de uma sub-rotina. O relacionamento de dependência <<include>> é representado por uma seta que parte do Caso de Uso “base” para o Caso de Uso “incluído”. A Figura 15 ilustra um exemplo de Inclusão entre os Casos de Uso.

Figura 15 – Exemplo do Relacionamento de Inclusão.


Para mais informações sobre Use Cases acesse:

http://www.ivarjacobson.com/resource.aspx?id=1282

4

Após a criação do Diagrama de Casos de Uso, complementam-se os Casos de Uso com uma documentação. O formato de documentação de um Caso de Uso é flexível, permitindo que se documente o Caso de Uso da forma que se considerar melhor, até mesmo pelo uso de pseudocódigo ou de código de uma linguagem de programação. O formato usual é em cenários – principal e alternativos.

Para continuar aprendendo sobre Documentação de Casos de Uso, acesse os links:

http://books.google.com/books?isbn=8574524441


VÍDEO 200:0000:00

4.2 Diagrama de ClassesConsiderando que o Diagrama de Casos de Uso está concluído, a próxima etapa é analisar os Casos de Uso para iniciar o trabalho de identificação das classes de objetos, o qual se faz necessário compreender como o sistema está estruturado internamente para que as funcionalidades sejam executadas. As classes de objetos muitas vezes podem ser identificadas, também, como substantivos nas descrições do domínio do problema.A partir da elaboração de um primeiro estágio do Diagrama de Classes, o mesmo evoluirá à medida que o sistema é desenvolvido, o qual o diagrama deve ser incrementado com novos detalhes, assim tendo novos estágios refinados do Diagrama de Classes.O Diagrama de Classes representa a modelagem da parte estática do sistema, representando um conjunto de Classes com seus atributos, operações e relacionamentos.O objetivo do Diagrama de Classes é permitir a visualização das classes utilizadas pelo sistema e como estas se relacionam. Esse diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-se em definir sua estrutura lógica (GUEDES, 2008).

O Diagrama de Classes é a principal técnica de modelagem da UML, assim vamos explorar nesta seção os principais componentes do Diagrama de Classes, tratando-o como um diagrama da atividade Análise. Posteriormente, recomendo evoluir o Diagrama de Classes em várias visões até obter um grau de refinamento com

detalhes de implementação, sendo considerado um Diagrama de Classes da atividade Projeto.

A seguir apresentamos os principais elementos do Diagrama de Classes.Classe: uma Classe é representada por um retângulo com, no máximo, três partes. Na primeira parte (de cima para baixo) é exibido o nome da Classe. Por convenção, o nome é apresentado no singular e com as palavras compostas começando por letra maiúscula. Na segunda parte são declarados os atributos que correspondem aos dados que um objeto armazena. Para cada atributo está associado um valor que esse atributo pode assumir. E na terceira parte, são declaradas as operações que correspondem às ações que um objeto sabe realizar, sendo que os objetos de uma classe compartilham as mesmas operações.O nome de um atributo é declarado por um substantivo ou expressão que representa alguma propriedade da classe, tipicamente, em letra minúscula e, para palavras compostas, usa-se concatená-las, sendo que a partir da segunda palavra inicia-se com letra maiúscula, por exemplo,dataNascimento. O nome de uma operação é declarado por um verbo ou uma locução verbal breve, usando a mesma convenção de letras minúsculas e maiúsculas dos atributos. A Figura 16 ilustra a notação de Classe e a Figura 17 ilustra alguns exemplos de representação de Classes.

Figura 16 – Notação de Classe.


Figura 17 – Exemplos de Classes com Notações Diferentes.


Relacionamentos: na UML, os modos pelos quais os itens podem estar conectados a outros, isto é, logicamente ou fisicamente, são modelados como relacionamentos,

que permitem compartilhar informações e colaboram para a execução dos processos pelo sistema (GUEDES, 2008).Existem 4 tipos de relacionamentos:a) Associações: são relacionamentos estruturais entre instâncias. Tipos de associações: Unária (autoassociação ou reflexiva), binária, ternária, classe associativa e agregação.

b) Generalizações: conectam classes generalizadas a outras mais especializadas, o que é conhecido como relacionamento Generalização e Especialização;

c) Dependências: são relacionamentos de utilização entre casos de uso, classes, pacotes e anotações;

d) Realizações: são relacionamentos que especificam um contrato de execução entre classes e interfaces.O relacionamento do tipo Associação é representado por uma reta, ligando as classes envolvidas, podendo também possuir setas em suas extremidades para indicar a navegabilidade da associação, o que representa o sentido em que as informações são transmitidas entre os objetos das classes envolvidas. As Associações podem também possuir nomes (títulos). A Figura 18 ilustra a notação de Associação.

Figura 18 – Notação de Associação

Fonte: Do autor (2012).O atributo a ser transmitido na Associação é um atributo implícito, não sendo apresentado na classe para a qual foi transmitido. Em cada extremidade da associação deve ser definida a multiplicidade da associação.A multiplicidade procura determinar o número mínimo e máximo de objetos envolvidos em cada extremidade da Associação, especificando quantas instâncias de uma classe relacionam-se a uma única instância de uma classe associada.A multiplicidade depende de pressupostos e de como são definidas as fronteiras de um problema, conforme as regras de negócio. O quadro a seguir ilustra os tipos de multiplicidade.

Quadro 1 – Tipos de Multiplicidades.Multiplicidade Significado

0..1No mínimo zero (nenhum e no máximo um). Indica que os objetos das classes associadas não precisam obrigatoriamente estar relacionados, mas se houver relacionamento indica que apenas uma instância da classe se relaciona com as instâncias da outra classe.

1..1 Um e somente um. Indica que apenas um objeto da classe se relaciona com os objetos de outra classe.

0..* No mínimo nenhum e no máximo muitos. Indica que pode ou não haver

instâncias da classe participando do relacionamento.

* Muitos. Indica que muitos objetos da classe estão envolvidos no relacionamento.

1..* No mínimo 1 e no máximo muitos. Indica que há pelo menos um objeto envolvido no relacionamento, podendo haver muitos objetos envolvidos.

Intervalo específico

Define-se um intervalo inicial e final, indicando que existem pelo menos um número específico inicial de instância envolvidas no relacionamento com um número limite de instâncias.


A Associação Unária ou Reflexiva ocorre quando existe um relacionamento de um objeto de uma classe com objetos da mesma classe. Cada objeto tem um papel distinto nessa associação. A associação reflexiva é representada por uma linha, iniciando e terminando na mesma classe. A Figura 19 ilustra um exemplo de Associação Unária.

Figura 19 – Notação e Exemplo de Associação Unária.

Fonte: Do autor (2012).A Associação Binária ocorre quando são identificados relacionamentos entre objetos de duas classes. A existência de uma associação entre dois objetos possibilita a troca de mensagens entre eles. Uma associação é representada por uma linha reta, ligando as classes às quais pertencem os objetos relacionados. A Figura 20 ilustra um exemplo de Associação Binária.

Figura 20 – Notação e Exemplo de Associação Binária.


A Associação Ternária ou N-ária ocorre quando conectam objetos de mais de duas classes, ou seja, uma associação pode ter grau maior que dois. São representadas por um losango para onde convergem todas as ligações da Associação. A Figura 21 ilustra um exemplo de Associação Ternária.

Figura 21 – Notação e Exemplo de Associação Ternária.


A Classe Associativa também é chamada de classes de associação. É uma classe que está ligada à associação, em vez de estar ligada a outras classes. Essa associação, normalmente, aparece quando duas ou mais classes estão associadas e é necessário manter características (atributos) específicas da Associação, sendo que uma classe associativa pode participar de outros relacionamentos. Uma classe associativa é representada por uma seta tracejada partindo do meio da associação e atingindo uma classe. A Figura 22 ilustra um exemplo de Classe Associativa.

Figura 22 – Notação e Exemplo de Classe Associativa.


A Agregação demonstra que as informações de um objeto (chamado objeto-todo) precisam ser complementadas pelas informações contidas em um ou mais objetos de outra classe (chamados objeto-parte), essa associação é conhecida como “Todo-Parte”. Ambas as classes podem “viver” de forma independente, ou seja, não existe uma ligação forte entre as duas. O símbolo de Agregação difere do de Associação por conter um losango na extremidade da classe que contém os objetos-todo. Objetos da parte constituinte ou da parte agregado são independentes em termos de vida, porém, são partes de um único todo. Essa análise dependerá do domínio do problema em estudo.O símbolo de Agregação difere do de Associação por conter um losango na extremidade da classe que contém os objetos-todo. A Figura 23 ilustra um exemplo de Agregação.

Figura 23 – Notação e Exemplo de Agregação.

Fonte: Do autor (2012).Outro tipo de Agregação é a Composição. Segundo Guedes (2011) esta Associação é uma variação da Agregação, onde é apresentado um vínculo mais forte entre objetos-todo e os objetos-parte, procurando demonstrar que os objetos-parte têm de estar associados a um único objeto-todo. Utiliza-se um losango preenchido para indicar a Composição. A Figura 24 ilustra um exemplo de Associação Composição.Ambas as classes “vivem” unidas de forma dependente, ou seja, existe uma ligação forte entre as duas. Os objetos da classe parte são dependentes, em termos de existência, da classe todo, ambas são partes de um único todo. Os objetos da classe parte não podem viver quando o todo é destruído. Utiliza-se um losango preenchido para indicar a Composição.

Figura 24 – Notação e Exemplo de Composição.

Fonte: Do autor (2012).O relacionamento do tipo Generalização representa classes-mãe, chamadas gerais e classes-filhas, chamadas especializadas, demonstrando a ocorrência de herança e possivelmente de métodos polimórficos nas classes especializadas. A herança é a possibilidade de uma classe utilizar os atributos e métodos de uma outra como se fossem seus.Na representação desse relacionamento, a classe generalizada é chamada de “superclasse” e as classes especializadas são chamadas de “subclasses”. Ainda na representação desse relacionamento pode ocorrer que uma subclasse herde atributos e operações de duas ou mais superclasses, o qual indica uma herança múltipla. A Figura 25 ilustra um exemplo de Herança e Herança Múltipla, o qual a subclasse Extensão herda características das superclasses Curso e Evento.

VÍDEO 300:0000:00

Figura 25 – Notação e Exemplo de Herança e Herança Múltipla.


Para completar a representação do relacionamento de Generalização deve-se indicar a restrição ou discriminadores de classificação. Os discriminadores são utilizados para definir melhor a semântica de classes especializadas derivadas de classes gerais, sendo classificados em: Completa ou Total,Incompleta ou Parcial, Disjunção ou Exclusiva, e Sobreposição. Os discriminadores são escritos entre chaves e próximos à seta de generalização.8

O discriminador do tipo Restrição Completa ou Total indica que qualquer instância da superclasse (abstrata) será uma instância de uma das subclasses. Uma classe abstrata não pode ser instanciada diretamente.O discriminador do tipo Incompleta ou Parcial indica que o conjunto pode esperar novas subclasses e uma instância de seu tipo pode não ser de uma de suas subclasses e sim da própria superclasse (concreta). Uma classe concreta pode ser instanciada diretamente.O discriminador do tipo Disjunção ou Exclusiva indica que qualquer instância da superclasse pode ser uma instância de apenas uma das subclasses, nunca poderá ser mais do que uma e o discriminador do tipo Sobreposição indica que uma instância pode pertencer a mais de uma subclasse.O relacionamento do tipo Dependência é um relacionamento de utilização, especificando que uma alteração na especificação de um item pode afetar outro item que a utilize.Uma dependência entre classes mostra que uma classe usa outra como argumento na assinatura de uma operação. Se a classe utilizada for modificada, a operação da outra classe será afetada. O relacionamento de dependência é representado por uma reta tracejada entre duas classes, contendo uma seta apontando o item do qual o outro depende, conforme ilustra o exemplo da Figura 26.

Figura 26 – Dependência entre Classes.

Fonte: Do autor (2012).Uma Realização é um tipo de relacionamento especial que mistura características dos relacionamentos de generalização e dependência, sendo usada para identificar classes responsáveis por executar funções para classes que representam interfaces. Esse tipo de relacionamento herda o comportamento de uma classe, mas não sua estrutura.O relacionamento de Realização é representado por uma seta tracejada contendo uma seta vazia que aponta para a classe de interface, conforme ilustra o exemplo da Figura 27.

Figura 27 – Relacionamento do Tipo Realização.

Fonte: Do autor (2012).Neste exemplo, a classe Extensão herda valores da classe Curso e implementa a interface intEvento.No diagrama de classes da atividade de projeto, a indicação da Navegabilidade em uma associação é representada por uma seta em uma das extremidades da associação, identificando os sentidos em que as informações são transmitidas entre os objetos das classes envolvidas, ou seja, o sentido em que os métodos poderão ser disparados. Porém, a navegabilidade não é obrigatória, mesmo porque, se não houver setas, significa que as informações podem trafegar entre os objetos de todas as classes da associação (GUEDES, 2011).

Figura 28 – Associação com navegabilidade.

Fonte: Do autor (2012).A figura acima indica que uma Inscrição tem a responsabilidade de lhe dizer qual é o seu Participante, mas um Participante não tem a responsabilidade para dizer que Inscrição ele tem. Ainda, uma Inscrição tem a responsabilidade de indicar qual é o seu Curso, mas um Curso não tem a responsabilidade de indicar em qual Inscrição está.

VÍDEO 400:0000:00

9

CONCLUINDO:

Após a identificação das classes e atributos deve-se verificar a consistência entre as classes e os casos de usos já definidos previamente e, assim, observar a necessidade de novas classes ou eliminar incoerências e redundâncias. Considerando os diversos elementos apresentados, é possível elaborar um primeiro estágio do Diagrama de Classes, aplicando e respeitando as regras de negócio do domínio do problema e, posteriormente, refiná-lo até obter um modelo ideal que atenda todos os requisitos do sistema.

Concorda? Vamos discutir isso no fórum!O próximo passo seria fazer o Diagrama de Objetos, porém, a utilização deste diagrama é opcional. O Diagrama de Objetos é uma instância do Diagrama de

Classes. Cada classe mostra seu objeto em um determinado ponto de tempo. É relevante adotá-lo para domínios complexos de software para facilitar a compreensão do sistema.

Para continuar aprendendo sobre o Diagrama de Objetos, acesse o link:


Na sequência, recomenda-se documentar a atividade de Análise com o Diagrama de Estruturas Compostas que é utilizado para representar Colaborações, ilustrando o relacionamento entre os elementos participantes para executar uma função. Uma Colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma função específica (GUEDES, 2008).Ainda na atividade de Análise, recomendo especificar os casos de uso com o Diagrama de Atividades. Um Diagrama de Atividades descreve uma sequência de atividades. Uma atividade é composta por um conjunto de ações, ou seja, os passos necessários para que as atividades sejam concluídas, assim representando a execução de cada Caso de Uso.

Para saber mais sobre o Diagrama de Estruturas Compostas, Diagrama de Atividades e os demais diagramas de interação, acesse os links:

.


VÍDEO 500:0000:00

RESUMO:A UML não faz grande distinção entre a notação da atividade de Análise e da atividade de Projeto. A atividade de Projeto é uma extensão dos diagramas criados na Análise para implementação. Os diagramas criados durante a Análise são refinados com mais detalhes, apresentando várias visões da especificação do sistema. O Diagrama de Casos de Uso e o Diagrama de Classes são os dois principais diagramas que são adotados na atividade de Análise.10

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2006.

http://pic.dhe.ibm.com/infocenter/rsmhelp/v7r5m0/index.jsp?topic=/com.ibm.xtools.modeler.doc/topics/ccompstruc.html

GUEDES, Gilleanes T. A. UML: uma abordagem prática. São Paulo: Novatec, 2008.______. UML2: uma abordagem prática. 2. ed. São Paulo: Novatec, 2011.MEDEIROS, Ernani. Desenvolvendo software com UML 2.0 – definitivo. São Paulo: Pearson Brasil, 2010.

SUGESTÕES DE LEITURABOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The unified modeling language: user guide. Massachussets: Longman, 2000.JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified software development process. New York: Addison-Wesley, 2000.LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007.MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2: do conceitual à implementação. Rio de Janeiro: Brasport, 2010.PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro: Campus, 1994.


A disciplina Banco de Dados na Web tem a finalidade de apresentar os conceitos do modelo entidade relacionamento, modelo relacional normalizado, debater sobre a importância destas etapas e também conceitual os principais comandos padrão SQL com as operações CRUD e as propriedades ACID de uma transação. Finalizamos com os controles de acesso aos dados, que garantem a segurança da informação.Todas estas etapas são fundamentais pois os sistemas voltadas para a Web necessitam de maior atenção por parte dos analistas de sistemas e desenvolvedores, uma vez que este tipo de sistema é muito diferente do modelo Cliente/Servidor.

Objetivos:Conceituar ao aluno os principais pontos a serem observados no item banco de dados durante o projeto e desenvolvimento de um sistema voltado para a Web.

Conteúdo Programático:Modelo Entidade Relacionamento.- modelagem entidade relacionamento.- diagrama entidade relacionamento.

Modelo Relacional Normalizado.- 1ª Forma Normal.- 2ª Forma Normal.- 3ª Forma Normal.- Boyce Codd Forma Normal.- 4ª Forma Normal.Operações CRUD (CERA).- Create (Criar).- Read (Recuperar).- Update (Atualizar).- Delete (Eliminar).Estrutura de comandos SQL.- tradutor de consultas.- analisador de estratégia.- dicionário de dados.Propriedades ACID.- Atomicidade.- Consistência.- Integridade.- Durabilidade.- conceitos de transação.- operações DML.Direitos de acesso.- concessão de direitos (Grant).- revogação de direitos (Revoke).- papéis / perfis (Role).


Textos da própria web-aula e de outros sites que possam contribuir para a discussão;

Vídeos que podem esclarecer ou aprofundar determinados conteúdos;




Avaliação Prevista:Cada web-aula conterá uma avaliação virtual composta de 5 questões (sendo assim, temos 2 web-aulas com 5 questões cada). Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação

pertinente ao nível de pós-graduação.


Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação. Textos apenas concordando ou discordando de comentários de outros participantes do fórum sem a devida justificativa ou complementação não acrescentam em nada ao debate da disciplina, sendo assim, devem ser evitados. Os textos devem sempre vir acompanhados das justificativas para a opinião do discente sobre o conteúdo discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além disso, podem ser utilizados citações de artigos, livros e outros recursos que fundamentem a opinião ou deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico principal do fórum, evitando debates que não tem relação com o tema selecionado pelo professor.

Habilidades e competênciasEspera-se que no final do curso os alunos possam:Compreender a necessidade de uma boa modelagem de dados para que o banco de dados possa ser o mais ágil e organizado possível.Aplicar a normalização é fundamental para este passo.Compreender os mecanismos de funcionamento nas operações fundamentais e essenciais do banco de dados, uma vez que sistemas voltados para ambiente Web são totalmente diferente em sua arquitetura dos sistemas cliente servidor.

ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES WEB

Unidade 1 – Banco de Dados na WebINTRODUÇÃOQuando o assunto é sistemas voltados para o ambiente internet/web, o quesito banco de dados toma uma importância de maior proporção, pois a segurança dos dados torna-se fundamental além de um bom desempenho, é lógico.Dividimos o nosso estudo em alguns capítulos que vão desde a modelagem de dados, passando pelo processo de normalização até chegarmos a uma arquitetura de banco de dados voltado para a web.MODELO ENTIDADE RELACIONAMENTOO modelo entidade relacionamento, que foi idealizado por Peter Chen, vem sendo utilizado desde a década de 70.

Este modelo prega a identificação e organização dos dados que se pretende armazenar, tudo isto obedecendo às regras do negócio em questão e que vão permitir a integração e entrelaçamento dos dados.O projeto de banco de dados envolve as etapas de construção do modelo conceitual de dados, do modelo lógico de dados e do modelo físico de dados.Estes modelos são projetados e desenhados com figuras geométricas pré-estabelecidas, onde esta representação recebe o nome de diagrama entidade relacionamento (DER).As figuras geométricas utilizadas como padrão são:- retângulo, representando as entidades;

- losango, representando os relacionamentos;

- elipses, representando os atributos;

- linhas, representando e unindo as figuras geométricas umas nas outras;

MODELO CONCEITUALNesta fase inicial do projeto de banco de dados, devemos representar o nosso cenário sistêmico o mais próximo da realidade do nosso usuário, sempre colocando o armazenamento dos dados de uma forma que possa haver a compreensão ‘do que se pretende guardar’ com ‘como será guardado’.Podemos citar um exemplo onde o nosso usuário deseja armazenar as informações e dados de um livro fiscal, ele apresenta o livro fiscal tradicional, e o analista de sistemas tem que visualizar esta necessidade e criar uma estrutura de armazenamento de forma lógica e que possa guardar de forma organizada e segura todos estes dados.

Figura 1. Livro fiscal e o modelo de dados ‘livro_fiscal’

No modelo conceitual não devemos ou precisamos nos preocupar com qual Sistema Gerenciador de Banco de Dados (SGBD) vai ser utilizado, pois esta necessidade será debatida nas próximas fases do projeto de banco de dados.O modelo conceitual nos permite em um único relacionamento a participação de três ou mais entidades, uma vez que o levantamento de requisitos do sistema pode apontar para uma regra de negócio que envolva ou apresente esta necessidade.As ferramentas CASE (Computer Aided Software Enginneering) que trabalham a fase de modelagem de dados, geralmente permitem a realização dos três modelos de banco de dados (conceitual, lógico e físico). Inclusive, fazem a transformação de um modelo para outro de forma automatizada e seguindo as regras do Modelo Relacional Normalizado.

Aprofundando conhecimentoPodemos citar como exemplo de ferramentas CASE que trabalham com banco de dados, o DBDesigner (empresa fabFORCE.netWWW.fabforce.net ), o Rational System Architect (empresa IBM WWW.ibm.com.br/software), o Designer 2000 (empresa OracleWWW.oracle.com.br), o Erwin Data Modeler (empresa CA WWW.ca.com).

No modelo conceitual nós tratamos apenas de entidades, relacionamentos, atributos e as cardinalidades do relacionamento. Não tratamos de chaves primárias ou estrangeiras, inicialmente são chamadas de ‘atributos identificadores’.

Os atributos são referenciados apenas como ‘caracteres’, ‘numéricos’, ‘alfanuméricos’ ou ‘datas’, ou seja, seus domínios não são totalmente especificados ainda. É possível já acrescentar a quantidade/tamanho dos atributos também, mas nada, além disso.MODELO LÓGICOO Modelo Lógico já é mais voltado especificamente ao pessoal de tecnologia da informação, pois o ‘tecniques’ ou ‘informatiques’ já fica mais evidente.Ao invés de utilizarmos entidades, agora já chamamos de tabelas, os atributos são chamados de campos ou colunas.

http://www.ca.com/

http://www.oracle.com.br/

http://www.fabforce.net/

Começamos a pensar na obrigatoriedade ou não do campo, nos formatos possíveis, nas representações que serão gravadas dentro do banco de dados.Algumas ferramentas CASE já aproveitam para determinar qual é o SGBD a ser utilizado e começam inclusive a trazer características e necessidades da parte física para esta etapa.No Modelo Lógico já não é mais possível representar um relacionamento ternário entre três ou mais entidades/tabelas, com isto, apenas relacionamentos binários são permitidos, levando a necessidade de normalizar o projeto de banco de dados antes.Para transformar o Modelo Conceitual em um Modelo Lógico, algumas ferramentas CASE já aplicam algumas regras pré-estabelecidas e resolvem alguns dos problemas de modelagem, porém, algumas delas não fazem de forma tão automática assim, sendo necessário a intervenção humana na sua resolução.Somente relacionamentos binários são permitidos no Modelo Lógico, pois uma das principais características do Modelo Entidade Relacionamento fica explicito neste modelo.O conceito de chave primária e chave estrangeira são estabelecidos, onde o principal ponto da ‘integridade referencial’ é concretizado.Este conceito diz que a chave primária de uma tabela é referenciada em outra tabela como uma chave estrangeira, estabelecendo assim um relacionamento. A quebra deste relacionamento compromete a integridade e a consistência dos dados das tabelas envolvidas.Do lado ‘chave primária’, sabemos que só pode haver uma ocorrência de um determinado conteúdo, mas do lado ‘chave estrangeira’, a nulidade, a presença única ou a presença de várias ocorrências vai depender da ‘regra de negócio’ estabelecida pelo relacionamento, mas o SGBD vai seguir fielmente esta regra que for implementada e vai garantir o cumprimento integral da mesma.Aqui podemos apresentar algumas das regras que são inerentes a uma chave primária ou uma chave estrangeira.- o conteúdo de uma chave primária uma vez estabelecida, não pode ser modificado, ou seja, sofrer um ‘update’.- uma ocorrência da tabela (registro) só pode ser removida se a mesma não tiver nenhum registro em outra tabela relacionada, ou seja, não possui referencia em outras tabelas.- se uma ocorrência da tabela (registro) tiver que ser removida, todos os registros da tabela referenciada deverá ser removido também (chamamos de infanticídio ou deleção em cascata) ou então a deleção original não poderá ser executada.- uma ocorrência da tabela (registro) referenciada pode ser removida sem a necessidade de nenhuma validação adicional (deletar um registro filho sem afetar o registro pai ou os demais registros irmãos).

MODELO FÍSICOAqui estamos tratando já dos comandos padrão SQL para a criação física do banco de dados, com as características e sintaxes apropriadas ao SGBD escolhido.Em linhas gerais, o projeto físico contém uma série de comandos CREATE e ALTER.Dependendo do SGBD adotado, ele pode ter uma sintaxe muito parecida com outro SGBD, mas sempre que for necessário utilizar um projeto físico de um SGBD específico em outro SGBD, uma revisão completa de sintaxe deve ser feita, senão você corre o risco do seu projeto físico não funcionar de acordo com o esperado.Normalmente como o Modelo Físico já esta ajustado sintaticamente para um SGBD, caso o mesmo projeto seja utilizado em outro SGBD, provavelmente alguns trechos e formatos dos comandos deverão ser ajustados. Isto faz com que um Modelo Físico seja específico de um determinado banco de dados, em muitas situações até mesmo a diferença de versão do mesmo SGBD faz com que o Modelo Físico seja ajustado.Uma prática comum em empresas que desenvolvem software é manter um projeto de banco de dados sempre no Modelo Lógico, que é independente de SGBD e na hora de montar o seu Modelo Físico, adequar o software para o SGBD desejado e assim a sintaxe gerada para o Modelo Físico será de acordo com o software desejado e na versão correta também.As ferramentas CASE permitem que no momento de transformar o seu Modelo Lógico em um Modelo Físico, seja possível escolher o SGBD desejado e até mesmo a versão do software, para que a sintaxe seja a mais próxima possível do que vai ser utilizado e assim evitar erros de sintaxe ou mesmo a intervenção humana no script de criação.

<http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados-parte-2/1678>.

00:00

00:00

VÍDEO AULA 01 – MODELAGEMMODELO RELACIONAL NORMALIZADOCONCEITO E NECESSIDADE DE NORMALIZAÇÃOO Modelo Entidade Relacionamento tenta se aproximar o máximo possível da representação do cenário sistêmico e por isso mesmo não está totalmente aderente às melhores formas de garantir a integridade e consistência dos dados.Por isso, uma série de situações pode levar o banco de dados a comprometer suas principais características de funcionamento e validação ou até mesmo comprometer o seu armazenamento de dados de forma organizada.A consistência dos dados é fundamental para a confiabilidade do banco de dados.Com isto, algumas regras foram desenvolvidas para refinar e melhorar a estrutura de armazenamento dos dados. Estas regras receberam o nome de Formas Normais e a sua aplicação e resultado final ficou conhecida como Modelo Relacional Normalizado.A execução ou o processo de aplicação das regras é referenciado como ‘Normalização do banco de dados’ ou ‘Normatização do banco de dados’, para entender um pouco mais do significado desta palavras, veja o seguinte link.

http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados-parte-2/1678

http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados-parte-2/1678

.O seu modelo de dados sem nenhuma revisão é conhecido como ‘Modelo Desnormalizado’, este é o seu ponto de partida.A sua aplicação é sequencial do Modelo Desnormalizado para a Primeira Forma Normal, depois da Primeira Forma Normal para a Segunda Forma Normal, depois para a Terceira Forma Normal e se for necessário, passar pela Boyce Codd Forma Normal e Quarta Forma Normal.A 1ªFN, a 2ªFN e a 3ªFN são obrigatórias e resolvem praticamente todas as situações de normalização. A BCNF e 4ªFN são necessárias apenas em situações especiais.Alguns especialistas de banco de dados já pregam a Quinta Forma Normal (5ªFN), porém são situações muito pontuais e especificas, nem sempre usual em sua ocorrência.PRIMEIRA FORMA NORMALPara transformarmos um modelo de dados da sua forma desnormalizada para a Primeira Forma Normal, devemos procurar por atributos repetidos dentro das entidades, ou seja, identificar os atributos que possuam o seu domínio repetido e que demonstrem assim a existência de várias ocorrências do mesmo atributo na entidade.Depois de identificar estes atributos, os mesmos devem ser removidos e separados em uma nova entidade.Nesta nova entidade, você não precisa colocar todas as repetições retiradas, apenas uma destas ocorrências é o suficiente, uma vez que é necessário estabelecer um relacionamento forte de 1-N, onde a chave primária da entidade forte vai ser uma chave estrangeira na entidade fraca e também fará parte da chave primária desta entidade fraca.

Desnormalizado Conceitual

http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados

Desnormalizado Lógico

1ª FN Conceitual

1ª FN Lógico

SEGUNDA FORMA NORMAL

Na Segunda Forma Normal devemos identificar e eliminar todas as dependências funcionais parciais, dos atributos não chave com partes da chave primária.Os atributos que apresentarem esta dependência deverão ser separados em uma nova entidade e um relacionamento forte deve ser estabelecido entre elas para que a chave primária composta continue assim.Uma observação importante pode ser afirmada com relação às entidades que possuam chave primária simples, estas entidades não podem conter dependências funcionais parciais da sua chave primária, portanto estas entidades já estão na Segunda Forma Normal automaticamente.

2ª FN Conceitual

2ª FN Lógico

TERCEIRA FORMA NORMALA Terceira Forma Normal analisa a dependência funcional dos atributos não chave com os outros atributos não chave, deixando a chave primária de fora desta vez.As dependências que forem identificadas deverão ser transferidas para uma nova entidade e o relacionamento que deverá ser estabelecido para manter esta nova entidade, é um relacionamento fraco.Outro ponto observado na Terceira Forma Normal é referente aos atributos calculados. Atributos que tenham o seu valor determinado por uma ação imposta em outras colunas não devem ser armazenados, pois podem ser calculados em tempo real sempre que foram necessárias a sua apresentação.O exemplo mais tradicional desta situação é o ‘valor total da nota fiscal’, pois é um atributo que depende do valor individual de cada item da nota fiscal.

Para o exemplo, vamos acrescentar o atributo ‘nom_atendente’ dentro da comanda e atributo ‘val_comanda’ na entidade Comanda e também o atributo ‘val_produto’ na entidade Produto.

Após aplicar a 3ª FN3ª FN Conceitual

3ª FN Lógico

BOYCE CODD FORMA NORMALA situação tratada pela BCFN foi descoberta pelos irmãos Boyce, como as Formas Normais já estavam todas definidas e difundidas, para não houvesse uma ‘renumeração’ ou ‘redistribuição’ das Formas Normais, uma vez que esta regra deveria ser executada entre a Terceira Forma Normal e a Quarta Forma Normal, convencionou-se chamar de Boyce Codd Forma Normal.A BCNF verifica uma situação de dependência funcional entre chaves primárias compostas, ou seja, quando uma parte de uma chave primária depende funcionalmente de outra parte da chave primária, causando uma situação onde não é possível identificar individualmente uma entidade dentro deste conjunto de entidades semelhantes.Isto significa que a chave primária composta precisa ser revisada, um novo atributo deverá fazer parte desta chave primária composta ou então uma parte desta chave primária composta deverá ser trocada ou substituída.Em linhas gerais, significa que na fase onde as chaves eram tradas como chaves candidatas, não houve uma escolha mais criteriosa ou então todas as possibilidades de combinação não foram testadas.Resumindo, a BCNF deve ser executada quando a chave primária composta não está executando a sua função primordial de identificação individual.Geralmente quando o analista cria um atributo ‘ID’ ou ‘COD’ e pensa num identificador ou código, onde ele mesmo vai decidir e estabelecer qual é o domínio deste identificador ou código, é porque ele não encontrou nenhum outro atributo na entidade que permita ou possibilite a função de chave primária, com isto ele puxa a responsabilidade de criar um atributo que vai conter um valor controlado e não repetido. Assim a Boyce Codd Forma Normal acaba sendo desnecessária.Ex. uma entidade Produto modelada para um pequeno comércio.

Veja que com os atributos ‘nome_produto’ e ‘descricao_produto’ escolhidos como chave primária (atributos identificadores no modelo conceitual) podemos ter o seguinte cenário:- nome_produto = tota-tola- descricao_produto = refrigerante gasoso sabor tola- tipo_embalagem_produto = garrafa vidro- peso_produto = 600 ml- data_validade_produto = 31/12/2012- valor_produto = 3,00e um segundo produto com:- nome_produto = tota-tola- descricao_produto = refrigerante gasoso sabor tola- tipo_embalagem_produto = lata alumínio- peso_produto = 350 ml- data_validade_produto = 31/12/2012- valor_produto = 2,50Veja que os produtos são iguais em nome e descrição, mas diferenciam-se no tipo de embalagem, no peso e no valor.Neste caso, fica evidente que os dois atributos escolhidos não são uma boa escolha.A solução seria acrescentar mais um atributo como identificador ou então, fazer o tradicional que é criar um novo atributo com a descrição de Identificador ou Código, trazendo a responsabilidade do seu domínio para o sistema.

QUARTA FORMA NORMALA 4FN trata de relacionamentos ternários (multivalorados) que podem ser modelados no plano conceitual.

Normalmente, no modelo conceitual podemos montar um relacionamento com mais de duas entidades, este tipo de relacionamento recebe o nome de relacionamento ternário ou n-ário.

Exemplo de relacionamento binário

Exemplo de relacionamento ternário com 3 entidades

Exemplo de relacionamento ternário com 4 entidadesNo Modelo Lógico não podemos implementar o relacionamento ternário, então temos que transformar todos os relacionamentos ternários em vários relacionamentos binários, você pode montar quantos relacionamentos binários forem necessários para que a sua regra de negócio seja mantida.

Exemplo de um relacionamento binário no modelo lógico

Exemplo do um relacionamento ternário transformado em vários binários

Exemplo de um relacionamento ternário transformado em vários bináriosEste exemplo acima demonstra uma situação onde o relacionamento ternário inicial foi desmembrado em 3 relacionamentos binários, uma situação que pode contemplar a todas as necessidades de regras de negócio.As cardinalidades neste caso não foram mantidas para efeito de demonstração, mas no seu dia a dia, deve-se prestar muita atenção para não montar um looping de relacionamento.

00:0000:00

VÍDEO AULA 02 - MRN

Pessoal, vamos participar do fórum colocando suas opiniões, dúvidas, ponto de vista e aproveitarmos o momento para troca de conhecimento.

QUESTÃO PARA REFLEXÃO UNIDADE INa unidade I da web aula, abordamos o modelo entidade relacionamento e depois o modelo relacional normalizado.

Com este conteúdo foi possível compreender por que um projeto de banco de dados não deve ser implementado diretamente sem que haja uma análise aprofundada aplicando-se as regras de normalização.Dentro deste sentido, os atributos calculados geralmente acabam gerando uma polêmica, pois o MRN pede para eliminá-los, mas em prol da performance, alguns analistas preferem mantê-los.Qual a sua opinião sobre este ponto? Participe do fórum.

CHEN, Peter. Modelagem de dados. São Paulo: Mc Graw Hill/Makron, 1990.HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzato, 1999.KROENKE, David M. Banco de dados. Rio de Janeiro: LTC, 1999.NISHIMURA, Roberto Yukio. Banco de dados I. São Paulo: Pearson, 2009._______.Banco de dados II. São Paulo: Person, 2009.SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados. São Paulo: Campus, 2012.

ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES WEB

Unidade 2 – Banco de Dados na WebPADRÃO SQLO padrão SQL (Structure Query Language – Linguagem de Consulta Estruturada ) nasceu dentro dos laboratórios de pesquisa da IBM na década de 70, mas foi na década de 80 que ganhou força quando o Instituto Nacional Americano de Padrões (ANSI) e a Organização Internacional de Padrões (ISO) estabeleceram uma versão final do que ficou conhecido como Padrão SQL (ANSI,86) ou SQL-86.Algumas revisões já foram realizadas acrescentando novos comandos e funções, assim nasceram o SQL-92, o SQL-99 e o SQL-2003.Sempre que o assunto SQL entra em cena, é enfatizada a semântica dos comandos que facilitam muito a compreensão do que se pretende fazer, deixando assim o comando com uma sintaxe muito intuitiva.Muitos SGBDs de mercado adotaram a palavra SQL na sua nomenclatura, com o intuito de reforçar a adoção do padrão SQL (ex. MS SQL-SERVER, MYSQL).Porém, nenhum deles adota 100% da sintaxe padrão, sempre colocam pequenas modificações na sua sintaxe para que caso o usuário queira trocar de SGBD, esta operação não possa ser feita sem nenhuma modificação ou adaptação.

Os comandos utilizados no padrão SQL podem ser classificados em linhas básicas como DML ou DDL.Comandos DML fazem a manipulação dos dados onde à escolha do melhor caminho pode ser feita pelo próprio usuário (DML procedural) ou pelo próprio SGBD (DML não procedural).Já os comandos DDL fazem a manipulação das estruturas de armazenamento e acesso, definindo, alterando, modificando ou eliminando estes objetos do banco de dados.

COMANDOS DMLOs comandos DML (Linguagem de Manipulação de Dados) permitem manipularmos os dados das tabelas do banco de dados, seja incluindo novos dados, atualizando dados que já estejam gravados no banco de dados, eliminando dados armazenados e principalmente consultando dados armazenados.Um comando DML procedural, o usuário deve especificar quais dados ele deseja localizar no banco de dados e também precisa especificar no mesmo comando, como fazer para chegar até estes dados. É conhecido entre os analistas e programadores como ‘passar o HINT no comando select’, é quando o analista indica qual índice de pesquisa ele deseja que seja utilizado, apenas lembrando que a responsabilidade de escolher um índice correto passa para o analista e tira do banco de dados a responsabilidade desta escolha.Já o comando DML não procedural, é geralmente o mais utilizado no nosso dia a dia, pois o usuário simplesmente especifica quais dados ele quer e a escolha do melhor caminho para este acesso é passado para o banco de dados. O banco de dados por sua vez faz acesso e utiliza os dados que estão armazenados no dicionário de dados, mais especificamente na parte dos dados estatísticos para realizar a analise da melhor estratégia de acesso.ESTRUTURA DE COMANDO SQLO SGBD pode interpretar os comandos SQL de duas formas, a primeira através de alguma ferramenta que faça o acesso intrusivo no banco de dados onde geralmente os comandos são interpretados e executados ou na segunda forma que é através de objetos no próprio banco de dados, por exemplo: procedures de banco, triggers, packages, funcionts.Um comando SQL quando submetido à execução, passa por algumas fases.

- análise sintática – é quando o comando é analisado em sua estrutura léxica e semântica, ou seja, é verificada cada parte do comando, se todos os itens necessários para que o comando fique completo estão presentes, se não está faltando nenhum símbolo ou que a gramática do comando esteja incompleta.Ainda na análise sintática, os campos, tabelas e outros objetos são verificados no dicionário de dados, confrontando e correlacionando os campos às tabelas, ou aos índices, seus tipos de dados e tamanhos.Esta fase é conhecida como PARSE.Nesta fase, o SGBD aproveita para verificar se um comando semelhante a este não foi executado recentemente e que esteja no buffer / cache do banco de dados, pois isto pode influenciar na escolha do caminho uma vez que o comando foi executado recentemente e a estratégia já foi escolhida.Esta indicação é passada para a fase de análise estratégica.É por isso que a adoção de uma padronização sintática de uso ajuda muito o SGBD. Combinar com os analistas, coisas do tipo:- Todos os comandos serão escritos em letras minúsculas, sejam comandos diretos interativos ou comandos dentro de programas de computador.- Estruturar os comandos como nos exemplos a seguir.

Apesar dos resultados serem os mesmos, será feitas duas análises distintas, com provavelmente a indicação da mesma estratégia de acesso, mas isso não é 100% garantido.A economia parece pequena, mas se a consulta for executada milhares de vezes ao dia, são muitas etapas de análise que podem ser economizadas.

- análise estratégica – é a fase onde o SGBD recebe o aval da análise sintática e de posse do resultado desta análise, vai consultar o dicionário de dados e as estatísticas do banco de dados para definir a sua estratégia e escolher qual é o melhor caminho para chegar às informações solicitadas pelo comando em execução.Para esta fase é importantíssimo que as informações estatísticas estejam devidamente atualizadas, pois caso contrário, com informações antigas ou erradas, é possível que o SGBD tome uma decisão errada na hora de montar o plano de acesso aos dados.- execução do comando – agora que o SGBD já definiu ‘como vai fazer’, o comando é executado, ou seja, as ordens dentro do comando são executadas de acordo com a sua recomendação.

Esta fase onde o comando SQL é estruturado é muito importante pois dois usuários diferentes podem pedir a mesma solicitação de dados para o SGBD e receber interpretações diferentes e consequentemente, ser executado por caminhos diferentes com performances diferentes também.COMANDO SELECT

O comando SELECT faz a leitura dos dados nas tabelas, procurando pela informação solicitada e depois apresentando os resultados ao usuário solicitante.O acesso pode ser feito em uma única tabela ou em várias tabelas ao mesmo tempo, quando utilizamos duas ou mais tabelas, é conhecido como ‘join de tabelas’.Um comando SELECT pode trazer como resposta uma linha de informação ou várias linhas de informação, bem como pode não trazer linha nenhuma, ou seja, uma resposta vazia (não encontrou nada que satisfizesse a consulta).Veja que se o comando SELECT esta sintaticamente correta, o mesmo será executado, mas a resposta vai depender diretamente dos dados que estiverem armazenados dentro do banco de dados.Por isso mesmo, um comando SELECT pode ter comportamento e resposta diferente se for executado em dois bancos de dados com a mesma estrutura de tabelas, mas com dados diferentes armazenados em cada um deles (é o famoso caso de banco de produção e banco de teste, onde o comando tem um resultado no desenvolvimento e outro na produção).Alguns cuidados devem ser tomados no uso do comando SELECT como o uso correto da cláusula WHERE, pois é a ‘peneira’ para que os dados sejam retornados de acordo com a sua necessidade.COMANDO INSERTO comando INSERT permite que seja gravada uma informação nova dentro de uma tabela.A inserção é feita em uma tabela de cada vez, ou seja, na mesma sintaxe não é possível (ainda) gravar dados em duas ou mais tabelas ao mesmo tempo.Em cada inserção, é gravado apenas um registro de cada vez. Existem sintaxes que permitem gravar dois ou mais registros num mesmo comando SQL, porém neste caso fica evidente que o comando está fora do padrão SQL ANSI. Pode até ser que em breve uma nova revisão do padrão SQL inclua esta nova sintaxe, mas no momento está fora.Quando é executado o comando INSERT, é verificada a validade dos dados em questão, como por exemplo, se o conteúdo do campo chave primária é único ou não, se existem atributos de preenchimento obrigatório, se existem valores de atributo tipo DATA inválidos ou não, se existem atributos com valores pré-determinados / definidos, se existem atributos que são chaves estrangeiras e a sua validade com a chave primária correspondente.Estas validações são conhecidas como regras de negócio ou ‘constraints’, como estas validações são executadas pelo banco de dados, os programas aplicativos não precisam programar estas regras em sua estrutura.Caso ocorra algum problema, uma mensagem de erro é emitida e o comando não é completado.COMANDO UPDATEO comando UPDATE possibilita substituir alguns dados previamente gravados nas tabelas, independentemente do motivo da atualização, este comando regrava uma nova informação sobrepondo a informação antiga.A atualização é feita em uma única tabela de cada vez, porém a quantidade de registros afetados depende diretamente da cláusula de seleção colocada na sintaxe do comando.

Aqui vale a mesma observação feita para o comando SELECT, o comando UPDATE pode afetar um ou vários registros e até mesmo nenhum registro, apresentando resultados diferentes em bancos de dados diferentes também.As regras de validação são equivalentes ao do comando INSERT, ou seja, validação de chave estrangeira, tipos de atributos, preenchimento obrigatório ou não, valores pré-determinados.Um comando UPDATE não permite a troca da chave primária, neste caso o usuário deverá apagar o registro por completo e depois criar um novo registro com o novo valor de chave primária.COMANDO DELETEO comando DELETE permite apagar registros completos de uma tabela e o critério de seleção é imprescindível para que não seja cometido algum erro.A cláusula WHERE é fundamental para selecionar e apagar somente os registros desejados, por isso mesmo, é recomendado que um comando SELECT com o mesmo argumento de seleção WHERE seja aplicado antes do comando DELETE e os resultados sejam verificados e validados, somente então, aplicar o comando DELETE.

00:0000:00

VÍDEO AULA 03 – PADRÃO SQL - CRUDPROPRIEDADES ACIDAs propriedades ACID de um SGBD são os pontos essenciais para que um software seja realmente considerado um SGBD ou um gerenciador de tabelas.A confiabilidade de um SGBD está diretamente ligada à garantia de que as propriedades ACID serão sempre executadas e em nenhum momento podem apresentar falhas.Transação é uma operação realizada no banco de dados que consiste em aplicação de comandos que modificam os dados no banco de dados (gravação de um dado novo, modificação de um dado existente ou eliminação de um dado existente).Toda transação tem um significado lógico e consistente para a veracidade dos dados armazenados.A transação é determinada pelo analista de sistemas dentro dos programas aplicativos ou do usuário de banco de dados que através de ferramentas apropriadas realiza um acesso interativo junto ao banco de dados.Toda transação é encerrada pelos comandos COMMIT ou ROLLBACK, que será abordado mais adiante.Atomicidade – uma transação de banco de dados é considerada indivisível, pode conter várias operações em uma mesma transação e ao término da mesma, todas as operações estarão garantidas, uma vez concretizadas, esta transação não pode ser dividida em partes.

Consistência – a transação tem que respeitar todas as regras de negócio aplicadas no banco com relação à consistência dos dados (campos tipo DATA, NUMERO, CARACTER, preenchimento obrigatório, valores mínimos ou negativos, valores pré-estipulados (sexo Masculino e Feminino), atributos que dependem do valor/conteúdo de outros atributos).Integridade – respeita todas as regras de negócio aplicadas no banco principalmente aquelas que dizem respeito a relacionamentos (integridade referencial).Durabilidade – não se perde com o tempo, ou seja, uma transação que foi efetivada deve ser durável para sempre (embora para sempre seja muito tempo, devemos pensar assim) até que outra transação integra e consistente venha modificar os dados desta transação antiga. Uma transação que não sofra modificações em seus dados não pode desaparecer do banco de dados com o passar dos anos, ou seja, o banco de dados não pode ‘esquecer’ ou ‘perder’ os dados simplesmente porque pertenciam a uma transação antiga.

00:0000:00

VÍDEO AULA 04 – PROPRIEDADES ACID

COMANDO COMMITUma transação de banco de dados pode conter diversas operações (Insert, Update ou Delete) e este conjunto de operações precisa receber uma confirmação da finalização da transação ou da desistência da transação.A confirmação é feita pelo comando COMMIT, que neste momento verifica a execução das propriedades ACID e em caso positivo, retorna para o usuário a confirmação OK da sua transação, em seguida já inicia uma nova transação.COMANDO ROLLBACKSe uma operação for executada errada e você decidir descartar o resultado desta operação (insert, update ou delete), é possível executar o comando ROLLBACK que desfaz o resultado desta operação, porém todas as operações envolvidas nesta transação também são desfeitas, ou seja, o banco de dados volta até o início da transação corrente.O comando ROLLBACK não permite desfazer apenas uma operação ou partes de uma operação, ele desfaz TODAS as operações da transação.COMANDOS DDLOs comandos DDL (Linguagem de Definição de Dados) permitem manipularmos as estruturas de armazenamento, ou seja as tabelas e os demais objetos do banco de dados.

Em linhas gerais, podemos definir a criação de uma tabela nova, executar alterações na estrutura de armazenamento das tabelas e até mesmo eliminar tabelas existentes no banco de dados.COMANDO CREATEO Comando CREATE é utilizado para a definição de novos objetos no banco de dados (tabelas, índices, triggers, procedures, functions, etc).Uma tabela nova é criada sempre vazia e já com todas as regras de integridade e consistência ativadas. Se alguma coluna ficou esquecida ou foi definida com características erradas, não é possível executar o comando Create para este mesmo objeto, você tem que partir para o comando de alteração de objetos.COMANDO ALTERO Comando ALTER é utilizado para modificar uma tabela já existente dentro do banco de dados, neste ponto é importante observar que existem situações onde mesmo à sintaxe permitindo a execução, devido aos dados já armazenados na tabela, a modificação não pode ser executada por ferir regras de integridade referencial ou consistência.Incluir uma nova coluna que a principio parece ser uma tarefa simples, depende muito do tipo de inclusão que está sendo realizada.Se incluir uma coluna nova sem propriedades de validação (not null, valores pré-definidos ‘S/N’, ‘M/F’), está é uma operação executada na hora e sem erros.Se incluir uma coluna nova com propriedades de validação (not null, valores pré-definidos ‘S/N’, ‘M/F’), temos dois cenários, se a tabela estiver vazia (sem nenhum registro) a alteração vai proceder normalmente, mas se a tabela estiver já populada (com registros), provavelmente vai dar errado.Como é possível incluir uma nova coluna com propriedade ‘not null’ se já existem registros na tabela, esses registros receberiam uma coluna inicialmente vazia e isto entra em contradição com a regra ‘not null’.O que pode ser feito?Incluir a nova coluna sem a regra ‘not null’, depois execute um comando Update populando esta coluna nova em todos os registros da tabela e depois execute novamente o comando Alter modificando a regra de validação de ‘null’ para ‘not null’.Se a alteração envolver aumentar o tamanho de um campo, independentemente deste campo ser numérico ou alfanumérico, esta é uma operação executada tranquilamente.Agora, se a alteração envolver diminuir o tamanho de um campo, tudo vai depender dos dados que estejam armazenados neste campo na tabela.Se a tabela estiver vazia, a alteração é executada na hora.Se a tabela já possuir registros dentro, o impacto da modificação é feito antes, analisando se a quantidade/tamanho da diminuição afeta algum registro já armazenado ou não, por exemplo, um campo nome com 50 caracteres que vai ser modificado para 40 caracteres, se em todos os registros armazenados os nomes tiverem menos de 40 caracteres no nome, a modificação é processada na hora, mas se existir um registro apenas cujo conteúdo do nome seja maior que 40 caracteres, já vai dar errado e o comando não será processado.

O que fazer então, tem que ser analisado se os dados podem ser truncados ou não, não é uma decisão que o analista de sistemas pode tomar sozinho, tem que ser conversado com os usuários antes de qualquer decisão.Uma modificação de tipo de dado então é mais complicada ainda.Modificar uma coluna numérica para alfanumérica pode ser fácil, porém é preciso lembrar que os números estão sempre alinhados pela direita e depois desta modificação estarão alinhados pela esquerda.Já modificar uma coluna alfanumérica para numérica, só vai dar certo se na coluna original, todos os dados sejam números e não podemos esquecer-nos do alinhamento à esquerda que passará a ser pela direita. Lembre-se que em um campo alfanumérico, o zero a esquerda pode ser significativo (telefone 04333750000).Quando modificamos o tipo do dado, se a tabela estiver vazia, o resultado é a hora, mas se a tabela estiver populada, os dados precisam ser analisados antes.Esta compreensão de cenário é muito importante porque é comum encontrarmos analistas de sistemas dizendo:‘no banco de testes deu certo, fiz todos os procedimentos e deu ok, mas quando fomos aplicar as mesmas modificações no banco de produção, deu tudo errado’.Onde está o erro? Banco de testes geralmente não tem a mesma ‘massa’ de dados do banco de produção.Por causa deste tipo de situação, em empresas cuja área de TI está bem estruturada, geralmente tem no mínimo 3 ambientes, um banco de dados de produção (o principal), um banco de dados de homologação (cópia da produção para testes, que periodicamente é igualado ao de produção, para manter o retrato mais fiel possível da produção) e um banco de dados de testes e desenvolvimento, onde são realizados todos os testes iniciais.

COMANDO DROPO comando DROP permite eliminar definitivamente uma tabela do banco de dados, ou seja, além de todos os dados, a estrutura de armazenamento também é eliminada.Caso a tabela em questão seja parte de uma regra de integridade referencial, ou seja, possui chave primária sendo doado para outra tabela, o comando não vai ser executada de forma natural, uma mensagem de erro é emitida.Você terá duas alternativas, a primeira é desativar a integridade referencial e depois eliminar a tabela. E a segunda é eliminar a tabela acrescentando na sua sintaxe a cláusula ‘CASCADE CONSTRAINTS’ que faz este papel de eliminar a integridade referencial para você.

COMANDOS PARA CONTROLE DE ACESSOSQuando os objetos do banco de dados (tabelas, índices, procedures, etc.) são acessados pelo próprio dono destes objetos, não é necessário nenhum controle de acesso, porém quando desejamos que outro usuário faça uso destes recursos, precisamos e podemos controlar estes acessos.Nestes casos chamamos de direito de acesso aos objetos do banco de dados que são trabalhados no sentido de conceder o acesso (GRANT) e revogar o direito de acesso (REVOKE).COMANDO GRANTO comando GRANT permite conceder o direito de acesso de um determinado objeto do banco de dados para outro usuário do banco de dados.Podemos controlar direitos de acessos como ‘SELECT, INSERT, UPDATE ou DELETE’.Assim, para o usuário X é possível conceder o direito SELECT e INSERT na tabela cliente.Desta forma, o usuário X (que não é dono da tabela cliente) poderá gravar novos clientes e consultar os clientes existentes, porém este usuário X não poderá modificar os dados de nenhum cliente ou mesmo eliminar clientes cadastrados.COMANDO REVOKEO comando REVOKE permite revogar ou eliminar um determinado direito de acesso que foi concedido para um usuário sobre um determinado objeto.

A revogação poderá ser total (ALL) ou parcial, especifico de um determinado tipo de acesso.COMANDO ROLEQuando a quantidade de usuários nos sistemas aumenta muito, organizar e controlar a concessão ou revogação de acessos aos objetos do banco de dados pode ficar complicado ou gerando um trabalho enorme.Imagine um sistema aplicativo com aproximadamente 1.000 usuários, ao incluirmos uma nova tabela no sistema e ter que executar a liberação de acesso, serão 1.000 comandos no mínimo. Isto sem falar que dentro destes 1.000 usuários poderemos ter diversos perfis de acesso (alguns só select, outros select e delete, outros select e insert, outros tudo).Para facilitar um pouco este tipo de controle, podemos agrupar os usuários pode perfis de acesso ou ‘papéis de acesso’ dentro do sistema, que chamamos de ROLE.Neste caso, os comandos GRANT e REVOKE seriam dados os ROLES e os usuários incluídos dentro dos ROLES.Se um usuário estiver dentro de mais de um ROLE, ele vai acumular os direitos, ou seja, vira uma somatória.

QUESTÕES PARA REFLEXÃOPara entendermos um melhor vamos apresentar um cenário com duas tabelas, uma integridade referencial entre elas e dados que populem ambas as tabelas.

00:0000:00

VÍDEO AULA 05 – DIRETIVAS DE ACESSO

O modelo conceitual apresenta a tabela Marca com os atributos id_marca e nm_marca, que receberão dados das principais montadoras de veículo do Brasil.A segunda tabela é o Modelo, com os atributos nm_modelo, tp_modelo e tp_combustivel, que receberão dados dos principais veículos das montadoras brasileiras.O relacionamento é de 1-N, onde uma Marca possui vários Modelos e cada Modelo é de uma única Marca.Uma Marca cadastrada pode não ter nenhum Modelo ainda, mas todo Modelo deve obrigatoriamente estar associado a uma Marca.Justificando assim as cardinalidades mínimas e máximas de cada entidade.Marca (1,1) – possui – (0,N) Modelo

Fonte: Nishimura (2012).O modelo lógico já apresenta a integridade referencial estabelecida a nível lógico, com a chave primária da tabela Marca como uma chave estrangeira e primária na tabela Modelo compondo junto com o atributo nm_modelo, uma chave primária composta (relacionamento forte).

Fonte: Nishimura (2012).O modelo físico apresenta os comandos para a criação física destas tabelas e do relacionamento.

Fonte: Nishimura (2012).Tabela Marca

Fonte: Nishimura (2012).

Fonte: Nishimura (2012).O que pode acontecer com os seguintes comandos?1 ) INSERT INTO MARCA VALUES (7,’HYUNDAI’) ;2 ) UPDATE MARCA SET ID_MARCA = 11 WHERE NM_MARCA = ‘FIAT’ ;3 ) SELECT * FROM MARCA WHERE NM_MARCA = ‘KIA’ ;4 ) DELETE MARCA WHERE ID_MARCA = 2 ;5 ) DELETE MARCA WHERE NM_MARCA = ‘TOYOTA’ ;6 ) INSERT INTO MODELO VALUES (11, ‘HB20’, ‘HATCH’, ‘F’);

7 ) DELETE MODELO WHERE NM_MODELO = ‘FOX’ ;8 ) DELETE MODELO WHERE NM_MODELO = ‘307’ ;9 ) INSERT INTO MODELO VALUES (2, ‘PUNTO’, ‘HATCH’, ‘F’) ;10) UPDATE MODELO SET ID_MARCA = 1 WHERE NM_MODELO = ‘PUNTO’ ;RESPOSTAS1 ) Este comando apresentará erro pois o ID_MARCA com valor igual a 7 já existe dentro da tabela, receberá mensagem de chave primária duplicada.2 ) Este comando apresentará erro pois a troca de valores de campos chave primária não são permitidos, seria necessário deletar o valor antigo e depois incluir o valor novo.3 ) Sintaticamente este comando está correto e a resposta será ‘nenhum valor encontrado’ pois a marca KIA ainda não está cadastrada na tabela MARCA.4 ) Apesar deste comando estar sintaticamente correto, ele não poderá ser executado pois o ID_MARCA = 2 tem registros referenciados na tabela MODELO, que não podem ficar órfãos, é necessário remover os modelos primeiro.5 ) Apesar deste comando estar sintaticamente correto, ele não poderá ser executado pois o campo NM_MARCA apesar de não ser a chave primária da tabela MARCA, com o conteúdo ‘TOYOTA’ possui registros na tabela MODELO que são referenciados pela chave primária de forma automática (conhecido como integridade referencial).6 ) Este comando está sintaticamente correto, porém faz o uso de um valor para ID_MARCA = 11, e este valor não existe na tabela MARCA, por isso viola a integridade referencial por fazer referencia a um valor inexistente.7 ) Este comando está sintaticamente correto e a resposta será ‘nenhum registro deletado’, pois na tabela MODELO não temos o valor ‘FOX’ em nenhuma das ocorrências da tabela.8 ) Este comando está sintaticamente correto e a resposta será ‘1 registro deletado’.9 ) Este comando está sintaticamente correto e será executado ‘OK’, para o banco de dados, ele não sabe que ‘PUNTO’ não é da ‘VOLKSWAGEM’ mas a partir deste momento esta é uma informação verdadeira para o banco de dados.10) Este comando está sintaticamente correto porém não pode ser executado pois não é permitido alterar / atualizar valores em campos que sejam parte da chave primária, como é o caso do ID_MARCA na tabela MODELO (é chave primária e chave estrangeira ao mesmo tempo).Estas foram apenas algumas dicas para demonstrar que o mundo do banco de dados é bem organizado e a utilização do padrão SQL facilita muito o dia a dia.A prática é o melhor caminho para o seu aperfeiçoamento e nunca se esqueça de que ‘o mesmo comando pode ser comportamento e resultados diferentes em bancos de dados diferentes’.ENCERRAMENTOChegamos ao final da nossa disciplina, espero que tenham gostado do nosso conteúdo e compreendido que um banco de dados para web precisa de um cuidado especial, principalmente porque o seu funcionamento é um pouco diferente do modelo tradicional.

Questão para reflexão Unidade IINa unidade II da web aula, o padrão SQL com as operações CRUD e propriedades ACID é que foram os pontos de atenção.Como a padronização de comandos entre softwares concorrentes pode ser considerado algo vantajoso? Participe do fórum.

Usuário feliz Analista feliz

Obrigado

CHEN, Peter. Modelagem de dados. São Paulo: Mc Graw Hill/Makron, 1990.HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzato, 1999.NISHIMURA, Roberto Yukio. Banco de dados I. São Paulo: Pearson, 2009._______.Banco de dados II. São Paulo: Person, 2009.SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados. São Paulo: Campus, 2012.

SUGESTÕES DE LEITURAKROENKE, David M. Banco de dados. Rio de Janeiro: LTC, 1999.


O estudo sobre Interação Humano-Computador (IHC) tem como direcionamento facilitar a utilização de sistemas computacionais e geralmente seu foco está relacionado com a satisfação do usuário a partir das funcionalidades das aplicações. Essa satisfação pode ser definida através da qualidade de uma interação entre o ser humano e o computador. Para saber se uma interação possui boa qualidade, existem direcionamentos e técnicas de avaliação de IHC que serão apresentadas nesta disciplina.

Objetivos:

Trabalhar com princípios para concepção de interfaces com foco em usabilidade e técnicas de avaliação de IHC.

Conteúdo Programático:- Conceitos de Usabilidade- Critérios Ergonômicos de Usabilidade- Conceitos e definições de métodos e técnicas de avaliação de IHC.


Textos da própria web-aula e de outros sites que possam contribuir para a discussão;

Vídeos que podem esclarecer ou aprofundar determinados conteúdos;




Avaliação Prevista:Cada web aula conterá uma avaliação virtual composta de 5 questões (sendo assim, temos 2 web-aulas com 5 questões cada). Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação.


Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação. Textos apenas concordando ou discordando de comentários de outros participantes do fórum sem a devida justificativa ou complementação não acrescentam em nada ao debate da disciplina, sendo assim, devem ser evitados. Os textos devem sempre vir acompanhados das justificativas para a opinião do discente sobre o conteúdo discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além

disso, podem ser utilizados citações de artigos, livros e outros recursos que fundamentem a opinião ou deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico principal do fórum, evitando debates que não tem relação com o tema selecionado pelo professor.

Habilidades e competências

Espera-se que no final do curso os alunos possam:a) Desenvolver habilidades de análise em IHC (Interação Humano-Computador)b) Estimular a utilização dos conceitos de boas práticas de IHC (Interação Humano-Computador) para desenvolvimento de interfaces com boa qualidade de uso;c) Propiciar ao profissional de informática, o entendimento de diversos tipos de métodos e técnicas de avaliação de IHC (Interação Humano-Computador) para apoio no desenvolvimento de aplicações;


Olá!Sou o professor Everson, sou mestre em Ciência da Computação e vou trabalhar com você sobre conceitos que envolvem o campo de IHC (Interação Humano-Computador).Os aspectos abordados nos conteúdos serão em torno de métodos e técnicas de avaliação de IHC.Vamos, participe efetivamente!

RESUMOO estudo sobre Interação Humano-Computador (IHC) na computação vem sendo realizado há vários anos, visando facilitar a utilização de sistemas computacionais. Devido ao número crescente dos sistemas computacionais interativos, esses estudos foram-se intensificando.

Nesse contexto, a partir das funcionalidades das aplicações, o foco geralmente está direcionado à satisfação do usuário. Essa satisfação pode ser definida através da qualidade de uma interação entre o ser humano e o computador.

Para saber se uma interação possui boa qualidade, existem as técnicas de avaliação de IHC. Nesse sentido esta unidade descreve os direcionamentos e técnicas de avaliação de IHC.

WEB AULA 1

Unidade 1 – Interações Humano-Computador

INTRODUÇÃOAo iniciar o nosso estudo, vamos ver algumas definições de alguns autores sobre Interação Humano-Computador (IHC).

A partir desse conceito, surgiram novas interpretações a respeito dos aspectos que englobam interfaces. Segundo Moran (1981), “a interface de usuário deve ser entendida como sendo uma parte do sistema computacional com a qual uma pessoa entra em contato física, perceptiva e conceitualmente”.

Diante disso, Prates e Barbosa (2003, p. 246) complementam que a dimensão física inclui os elementos de interface que o usuário pode manipular, enquanto a dimensão perceptiva engloba aqueles que o usuário pode perceber.A dimensão conceitual resulta de processos de interpretação e raciocínio do usuário, desencadeados pela sua interação com o sistema, com base em suas características físicas e cognitivas, seus objetivos e seu ambiente de trabalho.

Dessa forma, ao criar uma interface com boa qualidade de interação, devem ser analisados além da proposta de software e hardware, os aspectos que envolvem a ação e interpretação do ser humano.

Nesse sentido, vamos analisar uma representação gráfica de um modelo básico de interação humano-computador (Figura 1):

Vamos à nossa Vídeo Aula 01

O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download clicando aqui ou ative o mesmo.

No contexto do processo de interação humano-computador, segundo Preece et al (1994), o objetivo de IHC é produzir sistemas utilizáveis e seguros, como também sistemas funcionais.

Para Preece et al (1994 apud Interacting with Computers, 1989, p. 3), essas metas podem ser resumidas em desenvolver ou melhorar segurança, utilidade, efetividade, eficiência, e usabilidade de sistemas no meio computacional.

Nesse caso, para alcançar as metas estabelecidas, é necessário que o processo de interação humano-computador passe por um processo de avaliação, a fim de identificar possíveis problemas, bem como servir de retroalimentação para o desenvolvimento.

Veja o vídeo...

http://www.uxdesign.blog.br/usabilidade/usabilidade-por-luli-radfahrer/

Então, conseguiu perceber o direcionamento inicial para a construção de uma interface com boa qualidade de interação?

O grande foco é pensar sempre que o usuário deve ter uma interface amigável e para isso é necessário ter objetos que indiquem seu caminho, como exemplo, uma estrada bem sinalizada. Outro ponto é manter o usuário sempre informado do status da página, onde ele está e o que está acontecendo... Atualmente, existem muitos sites e softwares para web com várias abordagens e com diferentes objetivos. Isso pode dificultar a elaboração de uma interface com boa qualidade de interação. Por isso, devemos sempre vincular dois itens básicos para a construção de uma interface, sendo aqualidade de uso com seu objetivo.

Um importante início para a criação de uma página web é respeitar muito seu principal objetivo.Um grande exemplo de sucesso é a página da Google, sendo uma página limpa direcionada para a pesquisa com vários subitens, mas disponibilizados de forma discreta, não causando poluição da página.www.google.com.brAcesse a página e navegue com tranquilidade, é isso, o objetivo de uma boa interface.A grande responsável por deixar a página do Google limpa foi a Marissa Mayer (na época vice-presidente da Google).Sua iniciativa a levou para uma carreira de sucesso e atualmente, foi convidada para assumir a presidência da Yahoo...Vejam a reportagem:

São Paulo - A presidente-executiva do Yahoo, Marissa Mayer, apresentou nesta terça-feira a nova versão do Yahoo Mail, popular serviço que ficará mais rápido e com um visual mais "clean" e homogêneo para diferentes tipos de dispositivos.

Essa é a primeira reformulação de um produto do Yahoo durante a gestão da ex-executiva do Google, reconhecida no Vale do Silício pelos práticos produtos de Internet que criou.

O Yahoo é um dos sites mais populares do mundo e recebe quase 700 milhões de visitas por mês, mas a receita caiu diante da concorrência com o Google e o Facebook, além de transformações no mercado publicitário online, que pressionaram as tarifas dos anúncios, essenciais para o Yahoo.

Marissa assumiu o cargo em julho, e desde então as ações da companhia acumulam ganho de 25 por cento e estão no maior nível desde setembro de 2008, quando o co-fundador Jerry Yang ainda era o presidente-executivo.

Fonte: http://info.abril.com.br/noticias/internet/marissa-mayer-apresenta-nova-versao-de-e-mail-do-yahoo-11122012-26.shl

Para uma descontração... Mas também, lembrando que o usuário também deve fazer a sua parte!

http://www.videosdehumor.com.br/teste-de-usabilidade-google/

Páginas Poluídas...Por outro lado temos algumas páginas que considero poluídas e causam um cansaço expressivo, como exemplo, encontramos algumas páginas de jornais.Até entendo que o objetivo dessas páginas é de notícias e para atrair o usuário para sua leitura é necessário mais informações do que a da Google, mas acho que é um campo que merece um estudo maior sobre qualidade de uso.Faça um teste, deixe uma tela de jornal aberta quando você não estiver utilizando o computador e fique por perto a analisando, você vai perceber que causará certo desconforto...

Estive pesquisando para montar esta aula e acessei algumas dessas páginas, como exemplo a Folha de São Paulo, apresenta um excesso de informações e

animações o tempo todo, como disse, acho que está dentro do seu objetivo, mas poderia ser melhor.

Uma fonte de pesquisa no Brasil importante para o campo de IHC é o Labiutil - Laboratório de Utilizabilidade da UFSC.

Navegue e aproveite para estudar!http://www.labiutil.inf.ufsc.br/

Qualidade de Uso...

Então, como alinhar os parâmetros de qualidade de uso com os objetivos e interesses de cada software?

Para esse alinhamento é necessário entender melhor sobre os conceitos que direcionam para uma interface com boa qualidade.Iniciando vamos conhecer indicações de qualidade segundo a norma ISO 9241-11 de 1998, que foi criada pela International Standard Organization e consideradas como requisitos ergonômicos para trabalho de escritórios com computadores.

Vamos ver as definições dos termos que envolvem a norma ISO 9241-11:Usabilidade

É a medida na qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com eficácia, eficiência esatisfação em um contexto específico de uso.Nesse contexto, a usabilidade deve ser entendida como um caminho que possibilita ao usuário executar sua tarefa de forma ágil e intuitiva e ainda, sem erros ou dificuldades provocadas ou direcionadas pela própria aplicação.

Acesse o link e faça a leitura do artigo...http://www.labiutil.inf.ufsc.br/hiperdocumento/unidade1_2.html

Eficácia

Está ligada à acurácia e completude com as quais os usuários alcançam objetivos específicos.

Acurácia: o quanto o usuário consegue chegar próximo ao seu objetivo.Eficiência

Relaciona-se com o nível de eficácia alcançada no consumo de recursos relevantes, como esforço mental ou físico, tempo, custos materiais ou financeiros.

No contexto em estudo consiste em alcançar o resultado com o menor recurso possível.Satisfação

Tem a ver com o conforto e com atitudes positivas em relação ao uso de um produto, podendo ser medida pela avaliação subjetiva em escalas de desconforto experimentado, gosto pelo produto, satisfação com o uso do produto ou aceitação da carga de trabalho, quando da realização de diferentes tarefas, ou a extensão dos objetivos de usabilidade que foram alcançados.Contexto de Uso

Refere-se a usuários, tarefas, equipamentos (hardware, software e materiais) e ao ambiente físico e social no qual um produto é usado.Sistema de Trabalho

Envolve o sistema, composto de usuários, equipamento, tarefas e o ambiente físico e social, com o propósito de alcançar objetivos específicos.

Sua diferença entre o contexto de uso é porque a análise deve ser direcionada ao alcance do objetivo proposto.

A partir desses termos, a ISO traz uma estrutura de usabilidade, ilustrado na seguinte figura:



Na especificação de usabilidade devem descrever os objetivos pretendidos e os componentes do contexto de uso como usuários, tarefas, equipamento e ambientes, detalhando-se os aspectos que influenciam a usabilidade e, descrevem-se, também os valores reais ou desejados de eficácia, eficiência e satisfação para o objetivo do contexto.De acordo com a ISO 9241-11, no campo de usabilidade, é necessário ter as medidas de eficácia, eficiência e satisfação, de acordo com o contexto de uso e das propostas.O nível de detalhes de cada medida depende dos objetivos das partes envolvidas na medição, devendo ser considerada a importância relativa de cada medida para os objetivos.Essas medidas podem ser especificadas para objetivos globais ou para objetivos menores.Um exemplo de objetivos globais é ilustrado na Tabela Exemplo de Medidas de Usabilidade.

De acordo com a ISO 9241-11, as medidas de usabilidade dependem dos requisitos do produto e das necessidades da organização.Os objetivos de usabilidade podem ser: primários, menores, ou secundários, em que, determinar objetivos menores pode permitir uma avaliação antecipada no processo de desenvolvimento.Em relação aos critérios, estes podem reduzir-se ao menor nível aceitável, ou para o nível esperado de usabilidade, e seus valores para um grupo de usuários podem ser uma média, para todos indivíduos ou para uma porcentagem de usuários, tomando-se cuidado para que seja dado o peso apropriado para cada item de medida.

Acesse o link para aprofundar nos detalhes da Norma ISO 9241-11:

TESTES FOCADOS NA USABILIDADE, COMUNICABILIDADE E APLICABILIDADE

Para testar a usabilidade, são envolvidas as seguintes questões: facilidade de aprendizado e uso, eficiência de uso e produtividade, satisfação, flexibilidade, utilidade e segurança.

Dessa forma, objetiva-se quantificar o desempenho do usuário. Para a preparação do teste, devem ser definidos os limites mínimos aceitáveis, os máximos possíveis e, também, o valor almejado para a medida do projeto (PRATES E BARBOSA, 2003).Cybis (2003), define que se deve propor a elaboração de um plano de testes de usabilidade, cuja composição será uma seqüência estruturada de avaliação, com base nos objetivos a serem atingidos, como se relata a seguir:a) Constatar, observar e registrar, problemas efetivos de usabilidade durante a interação;

b) Calcular métricas objetivas para eficácia, eficiência e produtividade do usuário na interação com o sistema;

c) Diagnosticar as características do projeto que provavelmente atrapalhem a

https://repositorio.ufsc.br/bitstream/handle/123456789/80905/147075.pdf?sequence=1

interação por estarem em desconformidade com padrões implícitos e explícitos de usabilidade;

d) Prever dificuldades de aprendizado na operação do sistema;

e) Prever os tempos de execução de tarefas informatizadas;

f) Conhecer a opinião do usuário em relação ao sistema;

g) Sugerir as ações de re-projeto mais evidentes em face dos problemas de interação efetivos ou diagnosticados.

COMUNICABILIDADEA Comunicabilidade baseia-se na capacidade de os usuários entenderem o design da mesma maneira como é entendido pelos projetistas, possibilitando-lhes interagir com o sistema e transmitir, de maneira eficaz, as intenções projetadas.Segundo de Souza et al. (2001), a comunicabilidade de um sistema é a propriedade de transmitir ao usuário, de forma eficaz e eficiente, as intenções e princípios de interação que guiaram o seu design.Da mesma forma, o objetivo da comunicabilidade é permitir que o usuário, através da sua interação com a aplicação, seja capaz de compreender as premissas, intenções e decisões tomadas pelo projetista durante o processo de design.Quanto maior o conhecimento que o usuário, tem da lógica do designer que há na aplicação, maiores são suas chances de conseguir fazer uso criativo, eficiente e produtivo da aplicação.

PRATES E BARBOSA 2003, p.249 apud DE SOUZA et al, 1999; PRATES ET AL, 2000b

O objetivo da comunicabilidade é revelar qualitativamente as falhas de comunicação potenciais, que podem ocorrer durante a interação.Segundo Prates e Barbosa (2003), a análise dos dados é dividida em 3 passos:

Estas expressões são relacionadas com o usuário, como caracterizadas a seguir:

Onde está? O usuário sabe o que deseja executar, mas não o encontra de imediato;

E agora? O usuário não sabe o que significa e procura descobrir qual é o seu próximo passo;

O que é isto? O usuário não sabe o que significa um elemento na interface;

Epa! O usuário realizou uma ação indesejada e percebe imediatamente;

Onde estou? O usuário efetua operações que são apropriadas para outros contextos, e não para o atual;

Assim não dá! O usuário efetuou uma sequência longa de operações, antes de perceber que estava seguindo um caminho improdutivo;

Por que não funciona? A operação efetuada não produz o resultado esperado, mas o usuário não entende;

Ué, o que houve? O usuário não entende a resposta dada pelo sistema para a sua ação;

Para mim está bom... O usuário acha equivocadamente que concluiu uma tarefa com sucesso;

Desisto. O usuário não consegue fazer a tarefa e desiste;

Vai de outro jeito. O usuário não consegue realizar a tarefa como o projetista gostaria, e resolve seguir outro caminho;

Não, obrigado. O usuário já conhece a solução preferencial do designer, mas opta por uma outra forma de interação;

Socorro! O usuário não consegue realizar sua tarefa.

Como exemplo veja-se a seguinte classificação genérica de problemas relacionados à interpretação:

Execução: o usuário não consegue atingir o objetivo;

Navegação: o usuário se perde durante a interação;

Atribuição de significado: o usuário não é capaz de atribuir um significado relevante a signos da interface;

Percepção: o usuário não consegue perceber alguma resposta ou estado do sistema;

Incompreensão de affordance: o usuário não entende uma solução oferecida pelo designer e executa de uma forma mais complicada;

Recusa de affordance: o usuário entende a solução principal oferecida, mas escolhe outra.

Assim, este passo acrescenta à avaliação os problemas identificados, podendo fazer considerações sobre possíveis premissas de design e conhecimentos táticos, a partir da representação do contexto da aplicação. Continuando nosso estudo!Abaixo é apresentada uma tabela de associação entre expressões e classes de problemas:

Associação entre expressões e classes de problemas

Expressão de Comunicabilidade

Problemas de Interação

Execução

Navegação

Atribuição de significado

Percepção

Incompreensão de affordance

Onde está? X

E agora? X X X

O que é isto? X

Epa! X X

Onde estou? X X X

Assim não dá. X X X

Por que não funciona? X X

Ué, o que houve? X X

Para mim está bom. X X

Não, dá. X

Vai de outro jeito XNão, obrigado.

Socorro! X X X

A tabela acima resume o direcionamento para as observações que devem ser analisadas em uma aplicação, principalmente quando se trata de um software para web.Nesse caso, o usuário por estar longe e não tem um fácil acesso ao suporte para tirar dúvidas ou a uma capacitação.Muitas vezes, criar um software parece estar ligado a simplesmente a codificação, “ah isso é fácil”, “aquilo é mais difícil”, mas geralmente é deixado de lado a interação com o usuário.

Cuidado!

Essa interação pode definir o sucesso de sua aplicação...Assim, um projeto de interface de concepção mais próxima do processo cognitivo do usuário, pode ter maior eficiência na comunicabilidade.

APLICABILIDADE

A qualidade dos sistemas que podem ser usados com sucesso em uma ampla variedade de contextos, incluindo até mesmo aqueles em que o objetivo do usuário não é o objetivo original concebido pelos seus designers, depende da sua utilidade na resolução de problemas variados. Assim, Fischer (1998) define a aplicabilidade.Dentro desse conceito, para Prates e Barbosa (2003), a aplicabilidade permite determinar:a) Quanto o sistema é útil para o contexto para o qual foi projetado;

b) Em que outros contextos o sistema pode ser útil.Segundo Fischer (1998), a idéia é aumentar a participação do usuário nas decisões dos sistemas, para que ele tenha um sistema mais aberto, e seja mais participativo, com maior poder de decisão.Nesse caso, uma boa aplicabilidade está relacionada com aplicações de um sistema que sejam mais condizentes com a realidade de um usuário.Diversos pesquisadores afirmam que é necessário desenvolver sistemas que ampliem as capacidades dos usuários, em vez de tentar substituí-los, possibilitando

que eles ajam de forma mais inteligente e eficiente (PRATES e BARBOSA 2003 apud ADLER & WINOGRAD, 1992).



A baixa qualidade de uso de sistemas pode trazer diversos problemas, destacados por Prates e Barbosa na seguinte figura:

O contexto estudado demonstra que a partir das funcionalidades das aplicações, o foco geralmente está direcionado à satisfação do usuário.Essa satisfação pode ser definida através da qualidade de uma interação entre o ser humano e a aplicação, envolvendo partes físicas, emocionais e o contexto onde acontece a atividade.E para saber se uma interação possui boa qualidade, foram realizadas observâncias em torno da qualidade de uso. Mas, para apoiar na construção de boas interfaces podemos contar ainda com as técnicas de avaliação de IHC, que serão apresentadas na nossa próxima aula.

Então... Conseguiu visualizar o caminho para uma boa qualidade de uso de interação?

Continue estudando... Acesse o link e navegue:

http://www.labiutil.inf.ufsc.br/hiperdocumento/conteudo.html

Aproveite para um descanso e vamos para a próxima aula...

Participe do fórum de discussão! Alguns livros da biblioteca digital da Pearson para sua consulta:

Projeto interface homem-computador (MORAIS, Everson Matias de; SOLER, Luciano)

Interação Humano-Computador (David Benyon)

Como Criar Sites Persuasivos (Chak, Andrew)

[Airasian et al, 1977] Airasian, P. W. et al; Avaliação educacional: planejamento, análise de dados, determinação de custos. Petrópolis: Vozes, 1977.[Babbie, 1999] Babbie, E.; Métodos de Pesquisas de Survey. Belo Horizonte: Editora da UFMG, 1999.[Bastien e Scapin, 1993] Bastien, C.; Scapin, D.; Human factors criteria, principles, and recommandations for HCI: methodological and standardisation issues. Internal Repport - INRIA, 1993.[Bastien e Scapin, 1997] Bastien, C.; Scapin, D.; Ergonomic criteria for evaluating the ergonomic quality of interactive system. Behaviour and Information Technology 16 (4/5): 220-231, 1997.[Benyon , 1993] Benyon, D.; Adaptive Systems: A Solution to Usability Problems. Computing Department, Open University, Milton Keynes, MK7 6AA UK, 1993.[Cook e Campbell, 1979] Cook, T. D.; Campbell, D.T.; Quasi-experimentation: design and analysis issues for field settings. Chicago: Rand Mc Nally, 1979.[Cybis, 2003] Cybis, W. A.; Engenharia de Usabilidade: uma abordagem ergonômica, Florianópolis: Universidade Federal de Santa Catarina, 2003.[Cybis et al, 1998] Cybis, W. A. et al; Uma Abordagem Ergonômica para o Desenvolvimento de Sistemas Interativos, Florianópolis: Universidade Federal de Santa Catarina, 1998.

[de Souza et al, 2001] de Souza, C. S. et al; Projeto de Interfaces de Usuário – Perspectivas Cognitivas e Semióticas. Rio de Janeiro, 2001.[Erthal, 2003] Erthal, T. C.; Manual de Psicometria. Rio de Janeiro: Jorge Zahar Ed., 2003.[Fernandes et al, 1996] Fernandes, F. et al; Dicionário Brasileiro Globo. 43 ed. São Paulo: Globo, 1996.[Ferreira, 2004] Ferreira, A. B. H.; Novo Dicionário Aurélio da Língua Portuguesa. 3 ed. Curitiba: Positivo, 2004.[Fischer, 1998] Fischer, G.; "Beyond 'Couch Potatoes': From Consumers to Designers", Proceedings of the 3rd Asia Pacific Computer Human Interaction Conference, IEEE Computer Society, 1998.[Hoelzel, 2004] Hoelzel, C. G. M.; Design Ergonômico de Interfaces Gráficas Humano-Computador: Um Modelo de Processo,Florianópolis: Universidade Federal de Santa Catarina, 2004.[ISO, 2007] ISO 9241-11:1998; Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs), Part 11, Guidance on Usability. Disponível em: < http://www.inf.ufsc.br/~cybis/pg2003/iso9241-11F2.pdf >; acesso em: Abr. 2007[Kaplan, 1975] Kaplan, A.; A conduta na pesquisa: metodologia para as ciências do comportamento. 2. ed. São Paulo: EPU, 1975.[LabIUtil, 2006] Laboratório de Utilizabilidade, ErgoList, Universidade Federal de Santa Catarina, < http://www.labiutil.inf.ufsc.br/ergolist/ >; acesso em: jan. 2006.[Moran, 1981] Moran, T.; The Command Language Grammars: a representation for the user interface of interactive computer systems. International Journal of Machine Studies, 1981.[Nevo, 1986] Nevo, D.; The conceptualization of educational evaluation: An analytical review of the literature. House, Ernest R. (editor).New directions in educational evaluation. Philadelphia, USA: The Falmer Press, 1986.[Nielsen, 2007] Nielsen, J.; Severity Ratings for Usability Problems. Disponível em: < http://www.useit.com/papers/heuristic/ severityrating.html >; acesso em: 5 jan. 2007.[Nielsen, 2006] Nielsen, J.; Ten Usability Heuristics. Disponível em: < http://www.useit.com/papers/heuristic/heuristic_list.html >; acesso em: 10 dez. 2006.[Nielsen e Mack, 1994] Nielsen, J. & Mack, R.; Usability inspection methods. EUA: John Wiley & Sons, 1994.[Oliver, 2001] Oliver, H..; Contribution à l’évaluation des logiciels multimédias pédagogiques, PhD Thesis, University of Technology of Compiegne, France, 2001.[Pfleeger, 2004] Pfleeger, S. L.; Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.[Prates e Barbosa, 2003] Prates, R.O.; Barbosa, S.D.J.; Avaliação de Interfaces de Usuário – Conceitos e Métodos. Anais do XXIII Congresso Nacional da Sociedade Brasileira de Computação. XXII Jornadas de Atualização em Informática (JAI). SBC’2003. Agosto de 2003.

[Preece et al, 1994] Preece, J. et al; Human-Computer Interaction. Addison Wesley Longman Limited, England, 1994.[Raupp e Reichle, 2003] Raupp, M.; Reichle, A.; Avaliação: ferramenta para melhores projetos. EDUNISC, Santa Cruz do Sul, 2003.[Rocha e Baranauskas, 2000] Rocha, Heloisa V. da; Baranauskas, Maria C. C.; Design e avaliação de interfaces humano-computador. IME-SP, São Paulo, 2000.[Scriven, 1996] SCRIVEN, M.; Types of evaluation and types of evaluators. Evaluation Pratice, v. 1, n.13, 1996, p.151-161.[Sykes, 1990] Sykes, V.; Validity and Reliability in Qualitative Marketing Research : a Review of Literature. Journal of the Market Research Society, Vol. 32, nº 3, July, 1990.[Unicef, 1991] A UNICEF guide for monitoring and evaluation: making a difference? Evaluation Office, 1991.[Yin, 1989] Yin, R. K.; Case Study Research - Design and Methods. Newbury Park. Sage Publications, 1989.


WEB AULA 1Unidade 2 – Interação Humano-Computador

RESUMOA partir do estudo realizado na Unidade 1 sobre o contexto qualidade de uso, identificaremos nesta unidade questões relacionadas às técnicas de avaliação da interação de um usuário com sua aplicação.Para isso vamos identificar aspectos que envolvem as técnicas de avaliação de IHC descritas por diferentes autores.

Para saber se uma interação possui boa qualidade, existem as técnicas de avaliação de IHC. Nesse sentido esta unidade descreve os direcionamentos e técnicas de avaliação de IHC.

Veja no exemplo do vídeo de Portugal, a importância da usabilidade...

http://www.dailymotion.com/video/xek2hn_design-vs-usabilidade-caso-pratico_school

AVALIAÇÃO DE IHC...

Conforme já explanado, o campo de IHC está relacionado à qualidade de um sistema de computador, ou seja, à qualidade de uso de um software.

Para medir essa qualidade, e identificar possíveis problemas de interação, existem várias técnicas e métodos de diferentes aspectos.

Essas técnicas e métodos estão relacionados ao objetivo do contexto a ser avaliado e permitem avaliar a qualidade de interação entre o usuário e a aplicação.

Problemas de Interface!Como identificá-los?Um caminho... São as técnicas de avaliação de IHC...

Agora, vamos conhecer aspectos sobre as técnicas e métodos mais utilizados pelos principais autores da área...

Técnicas Prospectivas: utiliza-se uma metodologia baseada na aplicação de questionários e entrevistas com o usuário para avaliar sua satisfação em relação ao sistema e a sua operação.

Essas técnicas podem ser empregadas para auxiliar nas avaliações analíticas.Técnicas Diagnósticas: baseiam-se em verificações e inspeções realizadas por especialistas e nas quais se dispensa a participação direta de usuários.

Como exemplo, temos as avaliações heurísticas e as inspeções ergonômicas via checklists.Técnicas Definitivas: referem-se basicamente aos ensaios de interação e às sessões com sistemas espiões e contam com a participação direta de usuários.

Como exemplo, temos as técnicas de ensaios de interação e sistemas de monitoramento.


O Plugin Silverlight está desabilitado ou não foi instalado em seu browser, faça o download clicandoaqui ou ative o mesmo.

MÉTODOS DE AVALIAÇÃO ANALÍTICOS

Seus objetivos, segundo Prates e Barbosa (2003 apud Mack & Nielsen, 1994):- Identificar, classificar e contar o número de problemas de usabilidade encontrados durante a inspeção...

- Após identificar os problemas, a equipe de projeto deve reprojetar a interface para corrigir o maior número possível de problemas. Os problemas a serem corrigidos são priorizados de acordo com a gravidade do problema e o custo associado à correção.As avaliações analíticas dispensam a participação direta de usuários nas avaliações e inspeções, que se baseiam em verificações e inspeções de versões intermediárias

ou acabadas de softwares interativos, feitos pelos projetistas ou por especialistas em usabilidade.

Avaliação Heurística

Representam um julgamento de valor sobre as qualidades ergonômicas das interfaces e são realizadas por especialistas em ergonomia, que diagnosticam problemas que o usuário poderá ter em uma interação (CYBIS et al, 1998).

Heurísticas, segundo Nielsen (2006):De visibilidade do status do sistema: o sistema precisa manter o usuário informado sobre o que está acontecendo, fornecendo-lhe um feedback dentro de um tempo razoável;

De compatibilidade do sistema com o mundo real: O sistema deve falar a linguagem do usuário, com palavras, frases e conceitos familiares a ele, em vez de usar termos técnicos. Deve seguir convenções do mundo real, dando-lhe uma informação numa ordem natural e lógica;

De controle e liberdade do usuário: os usuários escolhem, freqüentemente e por engano, funções do sistema e precisam ter saídas de emergência claramente marcadas, para abandonar a operação sem ter que percorrer um extenso diálogo, possibilitando funções undo eredo;

De consistência e padrões: os usuários não precisam saber que diferentes palavras, situações ou ações significam a mesma coisa. Devem seguir convenções de plataforma computacional;

De prevenção de erro: é melhor projetar um design cuidadoso, no qual se previne o erro antes dele acontecer, do que, uma boa mensagem de erro;

De reconhecimento em vez de lembrança: minimize o uso da memória do usuário, disponibilizando objetos, ações e opções visíveis. O usuário, na passagem de uma operação para outra não precisa lembrar-se da informação anterior. Instruções para uso do sistema devem estar visíveis e facilmente recuperáveis, sempre que oportuna;

De flexibilidade e eficiência de uso: aceleradores não vistos por usuários novatos podem acelerar freqüentemente a interação de usuários especialistas, de modo que o sistema possa suprir necessidades de usuários sem experiência e experientes. Permitir a usuários experientes costurar ações, freqüentemente;

Do design estético e minimalista: diálogos não devem conter informação irrelevante ou utilizada raramente. Toda unidade extra de informação, em um diálogo, compete com as unidades pertinentes de informação, e diminui a

visibilidade relativa;

Para ajudar os usuários a reconhecer, diagnosticar erros e recuperar-se deles: mensagens de erro devem ser expressas em linguagem clara (sem código) indicando precisamente o problema e sugerindo uma solução;

Ajuda e documentação: embora seja melhor um sistema que possa ser usado sem documentação, seria bom disponibilizar ajuda e documentação. Essas informações devem ser fáceis de encontrar, focalizadas na tarefa do usuário, com uma lista de passos concretos, e não muito extensas.

Para auxiliar as heurísticas, ainda é necessário verificar sobre a severidade de um problema de usabilidade que consiste na combinação de três fatores (NIELSEN, 2007):

• Frequência com que o problema acontece: se é comum ou raro?

• Impacto do problema: será fácil ou difícil de solução caso aconteça?

• Persistência do problema: o problema não é superado, ou, ele causa aborrecimento constante?Para medir a severidade de um problema, Nielsen (2007) sugere a seguinte escala:

0 = eu não concordo que este seja um problema de usabilidade.

1 = problema cosmético de usabilidade: não é necessário consertar o problema, a menos que haja tempo disponível no projeto.

2 = problema de usabilidade secundário (sem importância): o conserto deste problema não deve ser prioritário.

3 = problema de usabilidade principal (importante): o conserto deste problema é de bastante prioridade.

4 = problema catastrófico de usabilidade: é imperativo consertar este problema antes que o produto seja liberado.

Inspeções Ergonômicas via Checklists

São vistorias com base em listas de itens de verificação, para diagnosticar problemas de interface.Essas listas são usadas pelos avaliadores como roteiro de princípios básicos, desejáveis em uma interface, para identificar problemas, reduzir a subjetividade e custos.Como em uma lista já estão presentes conhecimentos ergonômicos, não se faz necessária à aplicação destes questionários por especialistas em usabilidade e ergonomia.

Presteza: verifique se o sistema informa e conduz o usuário durante a interação;

Agrupamento por localização: verifique se a distribuição espacial dos itens traduz as relações entre as informações;

Agrupamento por formato: verifique os formatos dos itens como meio de transmitir associações e diferenças;

Feedback: avalie a qualidade do feedback imediato às ações do usuário;

Legibilidade: verifique a legibilidade das informações apresentadas nas telas do sistema;

Concisão: verifique o tamanho dos códigos e termos apresentados e introduzidos no sistema;

Ações mínimas: verifique a extensão dos diálogos estabelecidos para a realização dos objetivos do usuário;

Densidade informacional: avalie a densidade informacional das telas apresentadas pelo sistema;

Ações explícitas: verifique se é o usuário quem comanda explicitamente as ações do sistema;

Controle do usuário: avalie as possibilidades do usuário controlar o encadeamento e a realização das ações;

Flexibilidade: verifique se o sistema permite personalizar as apresentações e os diálogos;

Experiência do usuário: avalie se usuários com diferentes níveis de experiência têm iguais possibilidades de obter sucesso em seus objetivos;

Proteção contra erros: verifique se o sistema oferece as oportunidades para o usuário prevenir eventuais erros;

Mensagens de erro: avalie a qualidade das mensagens de erro enviadas aos usuários em dificuldades;

Correção de erros: verifique as facilidades oferecidas para que o usuário possa corrigir os erros cometidos;

Consistência: avalie se é mantida uma coerência no projeto de códigos, telas e diálogos com o usuário;

Significados: avalie se os códigos e denominações são claros e significativos para os usuários do sistema;

Compatibilidade: verifique a compatibilidade do sistema com as expectativas e necessidades do usuário em sua tarefa.

Percurso Cognitivo

Tem o objetivo de identificar problemas de usabilidade, para avaliar a facilidade de aprendizado do sistema através da exploração do usuário, direcionando as tarefas apenas quando requeridas em seu trabalho.

Esse método examina principalmente (PRATES E BARBOSA, 2003):• A correspondência entre a conceitualização de uma tarefa dos usuários e a dos designers;• Escolha adequada ou não-adequada de termos ou do vocabulário utilizado;• Feedback adequado ou não, para os resultados de uma ação.

De acordo com Prates e Barbosa (2003), nessa avaliação é necessária, uma fase de preparação para a definição de:• Hipóteses sobre os usuários e sobre o conhecimento que eles têm sobre a tarefa e a interface;• Cenários de tarefas, construídos a partir de uma seleção de tarefas importantes e freqüentes;• Sequência correta de ações para completar cada tarefa, definida pelo projetista;• Proposta de design em papel ou protótipo ilustrando cada passo e indicando o estado da interface antes e depois de cada passo.

Para o procedimento de uma execução dessa avaliação são relacionados os seguintes passos (PRATES E BARBOSA, 2003):a) O projetista apresenta uma proposta de design;b) Os avaliadores constroem histórias sobre a interação de um usuário com a interface, com base nos cenários de tarefas selecionados;c) Os avaliadores simulam a execução da tarefa, efetuando uma série de perguntas sobre cada passo;d) Os avaliadores anotam pontos-chave, sobre os quais o usuário:• Precisa saber antes de realizar a tarefa;• Deve aprender ao realizar a tarefa.

São necessárias perguntas básicas, feitas pelos avaliadores, em cada passo das tarefas as quais orientam para identificar problemas que poderiam ocorrer no processo de interação (PRATES E BARBOSA, 2003):a) O usuário tentará atingir a meta correta?• Dada a decomposição de tarefa em subtarefas, o usuário saberá por onde começar e qual é o próximo passo?• O que o usuário vai tentar fazer a cada momento?

b) O usuário perceberá que a ação correta está disponível?• Onde está o elemento de interface correspondente ao próximo passo?• Que ações a interface torna disponíveis?

c) O usuário associará o elemento de interface correto à meta a ser atingida?• O elemento de interface revela seu propósito e comportamento?• O usuário consegue identificar os elementos de interface?

d) Se a ação correta é tomada, o usuário perceberá que progrediu em direção à solução da tarefa?• Como a interface apresenta o resultado de cada ação?• O resultado apresentado tem correspondência com o objetivo do usuário?De acordo com as descrições das etapas do percurso cognitivo, seu conceito baseia-se em um processo em que os usuários aprendem por tentativas e sem treinamento, sendo de fácil uso e de baixo custo.

MÉTODOS DE AVALIAÇÃO EMPÍRICOS

As avaliações empíricas são métodos baseados em experiências que se relacionam basicamente aos ensaios de interação e a monitoramentos (sistemas espiões). Geralmente essa técnica envolve a participação de usuários na coleta de dados, dados que são diagnosticados por especialistas, a fim de identificar problemas de usabilidade e comunicabilidade. As próximas seções relatam as principais avaliações empíricas.

Os ensaios de interação consistem em uma simulação de uso do sistema, envolvendo os usuários, que tentam fazer suas tarefas típicas, com uma versão do sistema pretendido (CYBIS, 2003).Na visão de Cybis (2003), para se ter uma noção da complexidade de cada teste, é necessário fazer uma análise das seguintes características dos ensaios de interação:a) O constrangimento é inerente aos testes e, portanto, algumas medidas devem ser seguidas:

Esclarecer o usuário sobre o teste, enfatizando a finalidade do ensaio e da sua participação;

Não pressionar os usuários a participar dos ensaios;

Não expor os usuários a comentários de colegas;

Caso o participante se sinta cansado ou constrangido diante de uma determinada situação, é preferível parar a realização do ensaio de uma forma tranqüila;

Os ensaios devem ser planejados cuidadosamente quanto à divulgação dos resultados, evitando-se invadir a privacidade dos participantes, realizando-se de preferência, uma coleta anônima.

b) Para uma melhor informação faz-se necessário que o usuário verbalize durante ou após a interação com o software, onde se identifica:

Verbalização simultânea: é realizada durante o ensaio de interação, no qual o analista deve controlar a verbalização de acordo com o que o usuário está pensando, tentando fazer ou, lendo ou de acordo com a maneira como o trabalho está sendo apresentado;

Verbalização consecutiva: é feita uma entrevista com o usuário no final do ensaio de interação e, se necessário, pode-se repassar a gravação do vídeo que registrou o teste.

c) O local do teste pode ser no ambiente usual da tarefa, ou em um laboratório:

Teste no local: é mais trabalhoso, mas pode trazer informações mais ricas por estar no seu ambiente com as variantes do dia-a-dia, como, por exemplo, parar para atender um telefonema, suportar pressão de superiores, entre outras;

Teste em laboratório: deve ser equipado com recursos e aparelhos sofisticados, que permitiam observar a interação humano-computador de forma contínua, possibilitando ao analista maior controle da situação. Para softwares na fase de concepção, este tipo pode ser mais viável, pois o analista pode testar uma função, fazer correções e testar o sistema.

d) Registro e coleta de dados: é recomendado utilizar câmeras de vídeo para o registro de tudo, sem filmar o rosto do usuário, realizando o ensaio da forma mais conveniente para o usuário e em local e horário que lhe seja mais favorável. Para a montagem de um ensaio de interação contam-se várias etapas, desde a análise preliminar até a realização dos ensaios.

Neste contexto Cybis (2003) descreve as etapas como seguem:a) Na etapa de análise preliminar os especialistas tomam conhecimento da composição do software, realizando duas fases:

Reconhecimento de software: faz-se uma entrevista com a equipe que desenvolveu o software, abrangendo questões como a população-alvo do software, o tipo de tarefa que o software visa atender, as funções principais do produto, quantas pessoas foram envolvidas no desenvolvimento e se houver ergonomistas, o tempo de desenvolvimento, o ambiente de programação do sistema, as versões, a situação na área comercial e também sobre o suporte;

Pré-diagnóstico: pode ser obtido através de uma técnica de avaliação do tipo heurística ou checklists para inspeção ergonômica, de que resulta um conjunto de hipóteses sobre problemas de usabilidade que serão testados nos ensaios de interação.

b) Nesta fase são definidos os scripts, os cenários e a amostra de usuários, a saber:

Reconhecimento do perfil do usuário: os projetistas selecionam as pessoas (público-alvo), que poderão vir a participar dos ensaios;

Coleta de informações sobre o usuário e sua tarefa: o analista deve elaborar questionários destinados a buscar os dados de uma amostra de usuários. Estes questionários devem conter os dados a respeito dos recursos disponíveis, do contexto da tarefa, do nível dos usuários, da utilização do sistema;

Definição dos scripts de tarefas para os ensaios: um script nasce a partir da combinação dos parâmetros levantados, como os objetivos principais do software, as hipóteses dos ergonomistas, as amostras de tarefa dos usuários, a funcionalidade do sistema considerada mais e menos importante pelo usuário e, também, as operações mais frequentes do usuário.

c) Enfim, a realização dos ensaios deve durar no máximo 1 hora, com a participação do usuário, de 1 ou 2 ergonomistas observadores e de 1 assistente técnico responsável pelo funcionamento dos equipamentos. Os ensaios são controlados pelos ergonomistas que devem planejar como proceder nos casos de interrupções, retomadas e encerramento precoce do teste e, também, fazer anotações em tempo real sobre o desempenho do usuário, erros e incidentes. Na sequência complementa-se a caracterização desta etapa:

Obtenção da amostra dos usuários: é necessário selecionar alguém da amostra de usuários que realiza efetivamente as tarefas dosscripts, e que seja experiente na tarefa, alguém que realmente exerça suas atividades com

o auxílio do software, separando novatos de experientes.

Ajustes nos scripts e cenários: com cada participante deve ser realizada uma nova entrevista para buscar informações visando os ajustes nos scripts e cenários.

Planejamento dos ensaios: envolve a tomada de decisão e a adoção de providências relativas ao local dos ensaios, ao equipamento para registro dos acontecimentos, à escolha das técnicas de verbalização e à definição das estratégias de intervenção, em caso de impasse. Para lidar com as situações, sugere-se deixar o usuário tentar resolver sozinho qualquer tarefa, nunca ser grosseiro, propor ao usuário a realização de uma tarefa alternativa na persistência do impasse, e, caso os usuários se encontrem constrangidos ou nervosos, os ensaios devem ser interrompidos.

Análise e interpretação dos dados obtidos: a equipe de analistas deve rever todas as gravações buscando dados relevantes que comprovem ou não as hipóteses estabelecidas. Os resultados são relatados e entregues aos projetistas do sistema, com a descrição dos incidentes havidos durante a interação, relacionando-os com um aspecto do software e, também, definindo a prioridade dos problemas.

Conclui-se que a utilização da técnica de ensaios de interação, por utilizar a participação direta do usuário, se mostra capaz de identificar problemas específicos referentes à realização das tarefas que por outras técnicas não se conseguem identificar.

Esta técnica pode utilizar uma série de outras técnicas, como entrevistas, questionários, checklists, sistemas espiões que, em conjunto, caminham para um diagnóstico final que busca a satisfação do usuário.

São softwares “espiões” que permanecem na máquina do usuário simultâneos ao aplicativo em teste, os quais capturam e registram aspectos das interações do usuário com seu aplicativo em sua própria realidade de trabalho. (Cybis, 2003).Esta técnica não causa constrangimento ao usuário e ao mesmo tempo captura as interferências causadas por sua realidade de trabalho.Na parte negativa, constata-se que não há como incentivar ou registrar as verbalizações dos usuários que apresentam limitações de ordem técnica, relacionadas principalmente à portabilidade das ferramentas de espionagem.Assim, um sistema de monitoramento pode auxiliar outras técnicas de avaliações, contribuindo para um melhor resultado de uma avaliação.

É um conjunto de qualidades ergonômicas definidos por Bastien e Scapin (1993), e são formados por oito divisões que representam as características mínimas que um sistema interativo deve ter para apresentar um nível razoável de usabilidade.

Suas divisões (Bastien e Scapin , 1997):ConduçãoA condução refere-se aos meios disponíveis para aconselhar, orientar, informar e conduzir o usuário na interação com o computador, por exemplo: mensagens, alarmes, rótulos, etc. São necessários quatro critérios:a) Presteza: relaciona-se com as informações que permitem ao usuário identificar o estado ou contexto no qual se encontra, bem como as ferramentas de ajuda e o modo de acesso, incluindo-se os mecanismos ou meios que permitem ao usuário conhecer as alternativas, no que se refere a ações. Esse critério engloba os meios utilizados para levar o usuário a realizar determinadas ações, como, por exemplo, entrada de dados, na qual, sua finalidade é facilitar a navegação do aplicativo e diminuir a ocorrência de erros;b) Agrupamento/distinção de itens: diz respeito à organização visual dos itens de informação, relacionados uns com os outros, mostrando se esses itens pertencem ou não a uma classe, ou se indicam as diferenças entre as classes. Considera-se a topologia e algumas características gráficas que podem indicar as relações entre os itens, dependendo, da compreensão do usuário, entre outras coisas, da ordenação, do posicionamento, e da distinção dos objetos de uma interface. Esse critério está subdividido em outros 2 critérios elementares:

Agrupamento/distinção por localização: tem relação com o posicionamento relativo dos itens, indicando as diferenças entre as classes, se os itens pertencem ou não a uma determinada classe, e o posicionamento relativo dos itens de uma classe;

Agrupamento/distinção por formato: está relacionado com as características gráficas como, formato e cor e indicam se os itens pertencem ou não a uma classe as distinções entre classes diferentes e as distinções entre itens de uma classe.

c) Feedback imediato: a qualidade e rapidez do feedback são fatores importantes para a satisfação e confiança do usuário. Esse critério diz respeito às respostas do sistema às ações do usuário. Essas entradas podem ir do simples pressionar de uma tecla até uma lista de comandos. As respostas do computador devem ser fornecidas, de forma rápida, com um tempo de resposta condizente e consistente;d) Legibilidade: no que tange às características cognitivas e perceptivas dos usuários, a legibilidade diz respeito aos aspectos lexicais das informações apresentadas na tela, que possam dificultar ou facilitar a leitura desta

informação. Citam-se como exemplo: brilho do caractere, contraste entre letra e fundo, tamanho da fonte, espaçamento entre palavras, espaçamento entre linhas, espaçamento de parágrafos, comprimento da linha, entre outros. Carga de TrabalhoA carga de trabalho diz respeito a todos elementos da interface que têm um papel importante na redução da carga cognitiva e perceptiva do usuário e no aumento da eficiência do diálogo, e comporta:a) Brevidade: corresponde ao objetivo de limitar a carga de trabalho de leitura e entradas e o número de passos, com base na carga de trabalho perceptiva e cognitiva, para as entradas e saídas ou para os conjuntos de entradas. Esse critério supõe duas qualidades:

Concisão: diz respeito à carga perceptiva e cognitiva de saídas e entradas individuais, e por definição não se refere às mensagens de erro e feedback;

Ações mínimas: procura-se limitar o número de passos pelos quais o usuário deve passar para a realização de uma tarefa, tentando diminuir a carga de trabalho e a probabilidade de ocorrência de erros.

b) Densidade informacional: essa qualidade relaciona-se com a carga de trabalho do usuário, de um ponto de vista perceptivo e cognitivo, com relação ao conjunto total de itens de informação apresentados aos usuários, e não ao item individual, objetivando minimizar a carga de memorização. Controle ExplícitoO controle explícito refere-se tanto ao processamento das ações do usuário pelo sistema, quanto ao controle que os usuários têm do processamento de suas ações pelo sistema, e subdivide-se em dois critérios:a) Ações explícitas do usuário: referem-se às relações entre o que se processa pelo computador e as ações do usuário, devendo, o computador processar somente aquelas ações solicitadas pelo usuário e somente quando solicitado a fazê-lo. Dessa forma, o usuário aprende e entende melhor o funcionamento da aplicação, ficando menos sujeito a erros;

b) Controle do usuário: os usários devem estar sempre no controle do sistema, ou seja, eles podem interromper, cancelar, suspender e continuar uma determinada ação. E cada ação possível do usuário deve ser antecipada, e disponibilizadas opções apropriadas. Assim, o computador se torna mais previsível. AdaptabilidadeA adaptabilidade de um sistema diz respeito a sua capacidade de reagir conforme o contexto e conforme as necessidades e preferências do usuário. Dois subcritérios constam na adaptabilidade:

a) Flexibilidade: corresponde aos meios colocados à disposição do usuário que permitem personalizar a interface levando-se em conta as exigências da tarefa, de suas estratégias ou seus hábitos de trabalho com vistas a possibilitar ao usuário várias maneiras para alcançar seu objetivo;b) Consideração da experiência do usuário: a interface deve ser concebida para lidar com as variações dos níveis de experiência, de novatos a experientes. Através dos meios implementados, as opções possíveis do sistema devem ser mostradas de maneiras diferentes, de acordo com o tipo de usuário.Gestão de ErrosA gestão de erros compreende todos os mecanismos que permitem evitar ou reduzir a ocorrência de erros e, quando eles ocorrem, favorecer sua correção.Os erros são aqui considerados como entradas de dados incorretos, entradas com formatos inadequados, entradas de comandos com sintaxes incorretas etc. Três subcritérios participam da manutenção dos erros:a) Proteção contra os erros: refere-se aos mecanismos empregados para detectar e prevenir os erros de entradas de dados ou comandos, ou possíveis ações de consequências desastrosas e/ou não sanáveis;b) Qualidade das mensagens de erros: fundamenta-se na pertinência, legibilidade e exatidão da informação dada ao usuário sobre a natureza do erro cometido e sobre as ações que se devem executar para corrigi-lo. Este critério favorece o aprendizado do sistema indicando ao usuário a razão ou a natureza do erro cometido, o que ele fez de errado, o que ele deveria ter feito e o que ele deve fazer;c) Correção dos erros: diz respeito aos meios colocados à disposição do usuário com o objetivo de permitir a correção de seus erros para tornar mais ágil essa correção. ConsistênciaO critério da consistência, também chamado de homogeneidade ou coerência, refere-se à forma pela qual as escolhas, na concepção da interface, são conservadas idênticas em contextos idênticos, e diferentes em contextos diferentes.Essas escolhas podem ser códigos, denominações, formatos, procedimentos etc. Significado dos Códigos e DenominaçõesO significado dos códigos e denominações diz respeito à adequação entre o objeto ou a informação apresentada ou pedida e sua referência.Códigos e denominações significativas possuem uma forte relação semântica com seu referente.Termos pouco expressivos para o usuário podem ocasionar problemas de condução podendo ele ser levado a fazer uma opção errada.

Compatibilidade

A compatibilidade refere-se ao acordo que possa existir entre as características do usuário, como: memória, percepção, hábitos, competências, idade, expectativas etc.As tarefas por um lado, e por outro a organização das saídas, das entradas e do diálogo de uma dada aplicação. Diz respeito também ao grau de similaridade entre diferentes ambientes e aplicações.



Então, visualizaram o caminho para a construção de uma interface amigável, a partir dos critérios de avaliação?

Participem do fórum!

QUANTO À ESCOLHA DAS TÉCNICAS!

Nas seções anteriores expressaram-se questões essenciais sobre as técnicas de avaliações de IHC, mas não se pode esquecer que o sucesso de uma avaliação depende, e muito, da escolha correta da técnica utilizada no contexto a ser avaliado.Para a determinação de uma técnica de avaliação, faz-se necessário o entendimento do objetivo particular de um ambiente a ser avaliado, considerando-se os recursos disponíveis e as expectativas dos resultados da avaliação.Em Cybis (2003), são relatadas algumas características importantes para a escolha de uma avaliação:a) Efetividade: refere-se à quantidade de problemas sérios identificados - técnicas indicadas: avaliação heurística e ensaios de interação;b) Abrangência: refere-se à quantidade de problemas reais de todos os tipos identificados – técnicas indicadas: inspeções por checklist e avaliação heurística;c) Eficiência: é a razão da quantidade de problemas sérios identificados em, face da quantidade de problemas reais identificados de todos os tipos – técnica indicada: ensaios de interação;

d) Produtividade: refere-se à razão entre a quantidade de problemas reais de todos os tipos identificados e a quantidade de recursos financeiros necessários;e) Sistematização: para esta qualidade concorrem dois fatores igualmente importantes: repetitividade e reproduzibilidade. Arepetitividade relaciona-se à medida pela qual os resultados produzidos pela técnica se repetem, quando o mesmo avaliador examina o mesmo software algum tempo depois da primeira avaliação. A reproduzibilidade está relacionada com a medida pela qual dois avaliadores diferentes, examinando um mesmo software, produzem os mesmos resultados – técnica indicada: inspeções por checklist;f) Facilidade de aplicação: refere-se à qualidade da técnica que não exige formação ou competências específicas para a realização da tarefa - técnica indicada: inspeções por checklist;g) Poder de persuasão: refere-se a qualidade da técnica de produzir resultados capazes de convencer os projetistas da gravidade dos problemas de usabilidade identificados – técnicas indicadas: ensaios de interação e avaliações heurísticas;h) Poder de desobstrução: refere-se à qualidade da técnica produzir indicações de melhorias na usabilidade dos sistemas.

Para aprofundar seu conhecimento... Conheça o que diferentes autores destacam em relação ao campo de IHC...

http://www.lits.dei.uminho.pt/tu.pdf

http://irlabr.wordpress.com/apostila-de-ihc/parte-1-ihc-na-pratica/6-usabilidade-e-suas-metas/

Parabéns, você chegou ao fim de mais uma etapa do nosso estudo!Nosso estudo continua no fórum de discussão...

WEBAULA 1Unidade 1 – Introdução ao Design de Interfaces

O QUE É INTERFACE?A wikipedia (goo.gl/Y66zU) diz que interface é todo e qualquer dispositivo que

ofereça interação entre dois sistemas diferentes. Ainda está complicado, né? Vamos exemplificar: Um painel de um carro, é uma interface.O controle remoto é uma interface.A tela do seu celular touchscreen é uma interface. E um site também é uma interface.

O QUE DEFINE UM BOM DESIGN?Existem vários critérios para o desenvolvimento de design. Um dos mais básicos diz que a forma deve seguir a função. Esse conceito vem sendo utilizado e discutido desde a Bauhaus (1919 a 1933), e prega que se um objeto tem uma determinada função, sua forma deve favorecer o seu uso.Compliquei de novo?Imagine uma cafeteira italiana, bico de um lado e alça do outro. Agora imagine se os dois fossem do mesmo lado. Essa forma iria atrapalhar muito a sua função, e você, provavelmente, se queimaria tentando usá-la.Dessa forma, entendemos que cada elemento de um layout deve ter uma função específica, para que não ocorram confusões na utilização da interface.Mas o melhor de tudo é ver quem entende do assunto falando...

Aqui, você pode acompanhar Alexandre Wollner (pioneiro do design do Brasil) falando sobre o que é design.http://youtu.be/4RHf2jV3RPk

http://youtu.be/4RHf2jV3RPk

http://youtu.be/4RHf2jV3RPk

http://goo.gl/Y66zU

Nesse link, você verá o Luli Radfahrer falando um pouco sobre design.Vale muito a pena cada segundo!http://vimeo.com/56205628

E O DESIGN DE INTERFACES?

Primeiro devemos saber que ele é focado no usuário e não no sistema.Seu objetivo é tornar a tarefa a ser realizada pelo usuário o mais simples e eficiente possível.O design de interfaces deve equilibrar a funcionalidade e elementos visuais de modo a facilitar a tarefa do usuário sem chamar a atenção para si.Eu acredito que o design não precisa necessariamente chamar a atenção.Ele é apenas um meio, um condutor para a mensagem. Esta sim deve ser clara e perfeitamente compreensível. Vendo desta forma:

Você encontra mais sobre design de interfaces:

http://pt.wikipedia.org/wiki/Design_de_interface_de_usuário

http://www.uxdesign.blog.br/design-de-interfaces/

Sendo assim, o designer de interfaces deve sempre conhecer o perfil do usuário que utilizará o seu projeto.

http://www.uxdesign.blog.br/design-de-interfaces/

http://pt.wikipedia.org/wiki/Design_de_interface_de_usu%C3%A1rio

http://vimeo.com/56205628

Design de Interfaces – 1

APRESENTAÇÃO DO PROFESSOR:Sou designer gráfico (UNOPAR, 2007), Especialista em Gestão do Design (UEL, 2009), sócio proprietário na Vallent Design (www.vallent.com.br) e docente no curso de Desenho Industrial (Programação Visual e Projeto de Produto) e Design de Interiores da UNOPAR, tendo ministrado as disciplinas: Ergonomia Visual; Interface e Usabilidade; Tipografia; Empreendedorismo e Negócios; Composição gráfica; Estudo e representação da Cor; Tópicos Especiais em Design I; Estágio supervisionado; Gestão do Design aplicada a Projetos. Tenho 12 anos de experiência no desenvolvimento e gerenciamento de projetos de design, utilizo meus conhecimentos para auxiliar as empresas a atingirem suas metas estratégicas e financeiras implementando o design e a inovação em suas ações. RESUMO DA UNIDADE:O objetivo desta unidade é apresentar noções básicas referentes à design de interfaces. Desta forma, trataremos de assuntos relacionados com o tema, como Interfaces, Cores, Tipografia, Gestalt, Composição Visual e Ergonomia.Ao final deste módulo se terá conhecimento de técnicas e conceitos visuais capazes de ajudar no desenvolvimento gráfico de interfaces.PESQUISAS COM USUÁRIOS

http://www.vallent.com.br/

Sempre que vamos desenvolver um projeto de design, precisamos saber que vai utilizá-lo. Para isso servem as pesquisas.É sempre importante saber sobre a cultura, o nível de escolaridade, os interesses e as aptidões dos usuários. E o melhor jeito é realizando testes.Por exemplo: quando uma empresa vai lançar um novo software, ela primeiro libera uma versão beta para alguns usuários selecionados (beta testers) que darão um feedback para que ela melhore o software antes de lançar a sua versão final.Este processo pode se repedir diversas vezes, até que o resultado esteja satisfatório, e o trabalho pode durar meses.O usuário deve ter a perfeita noção do que está fazendo, pois em muitos casos, um erro pode acarretar em problemas graves e grande prejuízos.

VÍDEO AULA 1


Você encontra um pouco mais sobre design centrado no usuário em:

http://goo.gl/0eJY4

FATORES ERGONÔMICOS BÁSICOSJoão Gomes Filho (2003a) nos ensina que essas pesquisas devem levar alguns itens em consideração.REQUISITOS DO PROJETO:Tarefa: O que o usuário terá que realizar para fazer o sistema funcionar, por exemplo: “mover o mouse e digitar comandos em um teclado”; ou “puxar ou empurrar alavancas em sequencias predeterminadas”; ou ainda “movimentar-se em frente a um receptor” que interprete seus movimentos e os transforme em resultados gráficos.Segurança: Utilização segura e confiável dos objetos em relação à sua função. Sua importância varia de projeto para projeto, chegando a ser insignificante em alguns casos.

http://goo.gl/0eJY4

http://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx

Conforto: É na verdade uma condição, mas também pode ser vista como a sensação de comodidade, bem-estar e segurança. Esse fator está muito ligado ao de segurança, mas também, e principalmente, a fatores pessoais, como condições físicas, psicológicas, experiência de vida e condições gerais do usuário.

Estereótipo popular: Práticas de uso consagradas e comuns, como a direção da leitura ocidental, ou girar um botão de volume no sentido horário para aumentar o som. Esse fator também influencia diretamente o conforto e a confiança nos resultados das ações realizadas pelo usuário. Este fator é bastante subjetivo, pois pode variar de acordo com o grupo social do indivíduo. Por exemplo: No Japão a leitura é da direita para a esquerda, e na Inglaterra, o motorista fica do lado direito do veículo.Para que lado você giraria essa torneira?

Envoltórios de alcance físico: É o volume espacial de objetos que devem estar ao alcance do usuário para o manejo do sistema. Por exemplo, para manusear um computador, ele utilizará um mouse, um teclado, um monitor... Todos esses objetos devem estar organizados de modo que o usuário não precise realizar movimentos que gastem uma energia desnecessária, ou gere fadiga. Em interfaces, isso é fundamental, pois a disposição dos elementos determinará a movimentação do usuário sempre que utilizá-la.

Postura: Posição do corpo do usuário no momento da utilização. Uma postura incorreta pode gerar fadiga, lesões e problemas de articulação. Se houver algo possível para melhorar a postura do usuário, devemos sempre considerar!

Aplicação de força: Depende do manejo e do controle dos objetos.

AÇÕES DE MANEJO:

Manuseio operacional: É o ato de utilização do objeto. O ato de pegar, empurrar, puxar, torcer, esfregar e etc. Para manter, ou fazer cessar o funcionamento de algo. Normalmente relacionado à pega, empunhadura...Não está muito relacionado ao design de interfaces digitais, mas deve-se levar em consideração a utilização dos periféricos dos computadores (mouse, teclado e trackpad, em laptops) e de dispositivos móveis, como smartphones e tablets.

Manutenção: Para objetos físicos, é necessário pensar na facilidade de desmontagem e acesso às peças internas do objeto. Já para interfaces digitais, podemos considerar a plataforma de desenvolvimento, o código-fonte e a facilidade de reparos nesses códigos, ou na modularidade dos layouts.

Arranjo espacial: Melhor distribuição dos elementos dentro do espaço disponível, de modo a facilitar a atividade do utilizador.Um bom arranjo espacial pode facilitar o trabalho do usuário, diminuindo o seu cansaço e aumentando a sua produtividade.Imagem retirada de wix.com. Layout de website modular que é utilizado como base para desenvolvimento de sites personalizados

AÇÕES DE PERCEPÇÃO:VISUAL: A visão é o sentido mais usado na interação com interfaces digitais. Sendo assim, precisamos tomar muito cuidado com dois fatores:

Acuidade: É a capacidade de perceber os detalhes. Pode ser bastante subjetiva, pois depende de fatores referentes ao usuário, mas também existem cuidados que podemos tomar durante o desenvolvimento de projetos: As cores podem influenciar esta capacidade, a iluminação também, assim como o contraste entre figuras e fundos, e nos textos utilizados no layout.

Legibilidade: Está ligada a como reconhecemos informações que recebemos através de comparação com o que já temos na memória. Resumindo, quanto mais comum e bem organizada estiver a imagem utilizada, mais legível ela será. E quanto mais incomum e desorganizada (tamanho, cor, contraste...) ela estive, menos legível será!

AUDITIVO: Os sinais auditivos reforçam (ou até substituem) alguns sinais visuais. Por exemplo, o som se uma mensagem que chegou, ou foi enviada com êxito. O cumprimento de uma tarefa com sucesso, ou um alerta para uma correção.

Por favor, não coloque áudio em tudo o que acontece na interface, a não ser que seja absolutamente necessário (para cegos, por exemplo), pois esta pode acabar ficando muito chata para o usuário!

TÁTIL: É o contato direto com o tato, que é o sentido que percebe contato, pressão, calor e dor. Você pode pensar nisso se a sua interface utiliza uma tela sensível ao toque, ou à pressão. Em dispositivos móveis, um sistema que consuma muita energia, fará o seu processador aquecer, e isso será percebido pelo usuário.

CINESTÉSICO: Cinestesia é o sentido de percepção dos movimentos musculares ao longo do corpo. Utilizamos esse sentido para executar tarefas sem um controle visual, como, por exemplo, tocar um piano olhando a partitura, digitar sem olhar o teclado, ou dirigir sem ter que olhar os pedais do carro para frear ou acelerar.Se a sua interface precisar da utilização de pedais, ou de algo que necessite o movimento de partes diferentes do corpo, esta é uma preocupação que se deve tomar.

Mais sobre ERGONOMIA:http://pt.wikipedia.org/wiki/Ergonomiahttp://www.abergo.org.br/http://abcdesign.com.br/por-assunto/artigos/design-e-ergonomia/

CÓDIGOS VISUAISCromático: Com disse João Gomes Filho (2003b) “A cor é a parte simples mais emotiva do processo visual”. Seu uso é de extrema importância para reforçar a mensagem que se deseja transmitir.Agora a coisa começa a ficar importante!Aqui vão dicas que serão fundamentais para qualquer composição que você venha a fazer no futuro:

COMBINE AS CORES: As cores não são escolhidas aleatoriamente para compor um layout, normalmente elas seguem um padrão.Podem ser compostas, análogas, complementares, tríade e de muitas outras formas. O importante, é que isso seja feito corretamente.

http://abcdesign.com.br/por-assunto/artigos/design-e-ergonomia/

http://abcdesign.com.br/por-assunto/artigos/design-e-ergonomia/

http://www.abergo.org.br/

http://pt.wikipedia.org/wiki/Ergonomia

Para sua sorte, a Adobe já pensou nisso e colocou GRÁTIS na internet, o KULER https://kuler.adobe.com/

Lá você escolhe o tipo de combinação que deseja fazer, realiza os ajustes que achar necessários e ele te dá uma palheta com 5 cores diferentes, mas harmônicas entre si para que você possa utilizar em seu trabalho.

O VERMELHO CHEGA PRIMEIRO: As corres que enxergamos são ondas com frequências diferentes para cada uma. E a amplitude de onda da cor vermelha é a maior de todas, por isso ela chega primeiro aos nossos olhos.Veja: uma imagem com o fundo vermelho e a figura azul causa estranheza aos olhos, pois percebemos que o azul está acima do vermelho, mas este chega antes aos seus olhos. CORES QUENTES E FRIAS

As cores quentes, amarelo, laranja e vermelho, têm amplitude de onda maior do que as cores frias, azuis e verdes.Por isso sempre chegam primeiro aos nossos olhos.Sabendo disso, utilizamos as cores quentes para elementos visuais que precisam de destaque, como um aviso, ou algo do tipo.Já as cores frias, são melhores para fundos e informações secundárias. COR LUZ e COR PIGMENTO

Existem dois tipos de cores: Cor luz (emitida) e cor pigmento (refletida)Nos monitores, o as cores que vemos é a luz emitida, e nos objetos ao nosso redor, as cores são luz refletida. Isso significa, que se um objeto é verde, ele reflete o espectro verde da luz que recebe, absorvendo os outros.Já em um monitor, a luz é emitida e forma as cores de acordo com a combinação de outras. Se somarmos todas as cores em forma de luz, o resultado será a cor branca (lembre-se! Quanto mais luz, mais claro!).

https://kuler.adobe.com/

Se misturarmos as tintas, a tendência é chegar ao preto (quanto mais pigmento, mais escuro).

Vídeo bem didático sobre cores.

http://youtu.be/Zeo5ZXlUtTg

SIGNIFICADO DAS CORESAs cores possuem muitos significados, e muitas vezes nos fazem tomar decisões. Por isso, podemos utilizá-las de acordo com as sensações que pretendemos transmitir!Veja que interessante:

PRATA: Luar, alquimia, poderes espirituais, mistério. Intelecto harmonia e autoconhecimento (espelhos). Depende de textura para diferenciar-se do cinza.

DOURADO: Tradicional cor do dinheiro e uma das cores do Sol. Segurança e abundância. Faz as pessoas se sentirem relaxadas.

VERMELHO: Paixão, perigo, raiva, amor, sexo, poder. Sentimentos fortes.

VERDE: Natureza, sorte, renovação, novos começos (mudas, plantas), oxigênio, dinheiro, prosperidade, cura, emprego, fertilidade, sucesso, saúde, harmonia.

AZUL: Calma, frialdade, serenidade (A Virgem Maria), Introspecção, sabedoria, solidão, espaço, verdade, beleza, cálculo, frigidez.

TURQUESA: Misticismo, exaltação, generosidade, riquezas e expansividade. Está para o Prata assim como púrpura para o dourado.

http://youtu.be/Zeo5ZXlUtTg

MARROM: Dominado pelo vermelho, mas complementa o azul e o verde. Terra, madeira, solidez, estabilidade, calor.

VÍDEO AULA 2


CÓDIGO VISUAL TIPOGRÁFICO

Quando falamos em tipografia, penso que poderíamos ter uma web aula só sobre isso, pois o tema é extenso. Vou colocar algumas das dicas mais importantes para vocês:Quando Gutemberg começou a comercializar os tipos móveis (por volta do ano de 1500), as letras eram feitas de metal, de forma a se encaixarem umas nas outras formando as palavras. Este sistema foi utilizado por muitos anos (até o século XIX).Com o advento dos computadores, fez-se necessário o desenvolvimento de tipos digitais. Estes tipos foram desenvolvidos para uso em tela, e seu desenho é modular para facilitar a exposição nos pixels.Para textos impressos mais longos, o ideal é utilizar fontes com serifa, como Garamond, ou Times.A serifa ajuda na fluidez da leitura de textos longos, e diminui o cansaço na vista humana.Para o desenvolvimento de interfaces digitais, dê preferencia a fontes desenvolvidas para tela, normalmente sem serifas e com desenho mais moderno. Com isso a leitura será mais fácil e os usuários entenderão mais rapidamente o que precisam fazer.Alguns exemplos de fontes boas para tela:


Baixar fontes grátis:

http://www.dafont.com/

http://fontfabric.com/

http://www.searchfreefonts.com/

http://www.actionfonts.com/

http://www.google.com/webfonts

Não utilize textos em caixa alta (maiúsculas) para textos corridos. Este formato é indicado apenas para títulos e destaques específicos.Procure utilizar apenas uma família tipográfica em cada projeto. Isso trará mais unidade visual e melhorará a imagem geral de sua apresentação.

http://fontstruct.com/Para finalizar esta parte, vale a pena dar uma conferida no FONTSTRUCT.Um software online para criação de fontes.

http://www.google.com/webfonts

http://www.actionfonts.com/

http://www.searchfreefonts.com/

http://fontfabric.com/

http://www.dafont.com/

http://fontstruct.com/

É necessário um pouco de conhecimento em tipografia, mas com ele você pode desenvolver a sua própria fonte digital!Código Visual MorfológicoOs códigos visuais morfológicos dizem respeito à organização visual geral do layout. Vamos estudar melhor sobre isso mais adiante, quando falarmos de Gestalt. ERGONOMIA DE INTERFACES

Assim como o design, a Ergonomia de Interfaces é uma ciência multidisciplinar, ou seja, se vale do conhecimento e dos métodos de diversas áreas para realizar as suas tarefas.Seu principal objetivo é a adaptação das condições de trabalho das interfaces às características físicas e psicológicas do homem, deixando as interfaces cada vez mais amigáveis às necessidades das pessoas, para que haja uma interação eficiente, com segurança, conforto e eficácia.Ela verifica se o software atende às necessidades operacionais e funcionais para saber se o mesmo é adequado à tarefa a que se propõe.Para isso, precisamos primeiro entender a diferença entre os termos Utilidade e Usabilidade.

VÍDEO: O ESTUDO DA ERGONOMIA

http://youtu.be/w0ybfmCmnXw

“Se facilidade de uso fosse o único requisito, estaríamos todos usando triciclos.” Douglas Engelbart, inventor do mouse

http://youtu.be/w0ybfmCmnXw

Nesta afirmação Engelbart nos mostra que usabilidade é a facilidade de uso, e utilidade é para que o objeto se destina.Então, podemos entender que quanto mais fácil de usar uma interface, melhor. Porém, um usuário mais experiente já não precisará mais de todos os “apoios” e esta interface pode acabar se tornando chata para ele.Neste caso, o melhor a se fazer é pensar em como otimizar o processo para estes usuários mais experientes.Existem técnicas específicas de avaliação de interfaces, que vocês verão no próximo modulo do curso, com o Professor Everson. Por enquanto ficaremos apenas com a concepção visual, OK? FALANDO MAIS ESPECIFICAMENTE SOBRE COGNIÇÃOCognição é a aquisição de conhecimento através da percepção. Envolve atenção, memoria, raciocínio, juízo, imaginação, pensamento e linguagem.Mas não adianta tentar falar sobre cognição sem falar de Gestalt.

O termo vem da palavra alemã Gestaltung, que significa o ato de configurar o que é exposto ao olhar.Esta teoria estuda a forma como se dá a percepção visual humana, que é exatamente o que nos interessa quando vamos desenvolver uma interface interativa.Segundo a Gestalt, nós percebemos primeiro o todo, depois as partes de um objeto observado.Explicando mais claramente, quando olhamos para algum objeto complexo (um carro, por exemplo) primeiro percebemos o todo (É um carro!), depois as partes. Aí identificamos a marca, o modelo, o tamanho, quantas portas, a cor, as rodas, os faróis e assim por diante, até o menor detalhe, dependendo do tempo e da atenção que vamos dispensar a este objeto.Este é o ponto em que o designer de interfaces deve ter certeza do que se está fazendo, pois poderá direcionar a atenção do seu usuário (observador) para onde

desejar, sem precisar usar artifícios simplórios, como simplesmente aumentar o tamanho de uma letra ou de uma figura.A Gestalt também é conhecida como psicologia da forma, e, para fins didáticos, foi dividida em algumas categorias, mas é importante lembrar que várias categorias da Gestalt podem estar presentes em cada objeto.Vejamos a seguir algumas das principais categorias da Gestalt.TEORIA GERAL DA GESTALT - Afirma que percebemos as coisas dentro de um conjunto de relações (o todo). Isso pode até alterar a nossa percepção da realidade, com fenômenos de ilusão de ótica, por exemplo. (Os mágicos sabem disso como ninguém!)

UNIDADE - Um, ou mais de um elemento que constitui um objeto. Podem ser agrupamentos de elementos que são percebidos em conjunto ou parte de um todo maior. São percebidos através das relações entre os elementos que fazem parte de sua constituição.

SEGREGAÇÃO - É a percepção de formação de unidades por contrastes no campo visual ou na configuração o objeto. Estes contrastes podem ser de Cores, Brilhos, Matizes, formas, movimento e etc.

UNIFICAÇÃO – Diferente de unidade, a unificação é fundamentada nos conceitos de Harmonia, Ordem e Equilíbrio Visual. A coerência entre os elementos e sua linguagem, além de outros fatores como proximidade e semelhança, geralmente ajudam a promover e reforçar a unificação da figura.

FECHAMENTO – Através de nossa memoria visual, as imagens tendem a seguir uma linha que se espera, o caminho natural, formando as figuras que desejamos observar. Mesmo que a linha não exista fisicamente, ela existirá na nossa mente na hora de formar a imagem.

CONTINUAÇÃO – É a organização das imagens, de modo a acompanharem um movimento pré-estabelecido, formando um “caminho visual” pelo qual é agradável deixar correr os olhos.

PROXIMIDADE – Elementos próximos entre si tendem a ser percebidos juntos, e desse modo, acabam formando unidades.

SEMELHANÇA – Assim como a proximidade, a semelhança também tende a formar unidades. Dois pares de objetos iguais formam duas unidades.

PREGNÂNCIA DA FORMA – Quanto melhor for a organização visual de uma forma, e mais rápida e fácil for a sua leitura e entendimento, maior será o índice de pregnância.

VÍDEO AULA 3


GOMES FILHO, João. Ergonomia do Objeto: sistema técnico de Leitura ergonômica. São Paulo: Escrituras, 2003a.GOMES FILHO, João. Gestalt do Objeto: Sistema de Leitura Visual da Forma. São Paulo: Escrituras, 2003b. BIBLIOGRAFIA CONSULTADABONSIEPE, Gui. Design: do material ao digital. Tradução de Cláudio Dutra. Florianópolis: FIESC/IEL, 1997.CYBIS, Walter. BETIOL, Adriana Holtz; FAUST, Richard. Ergonomia e usabilidade: conhecimentos, métodos e aplicações. 2. ed. São Paulo: Novatec, 2010.


FRASER, Tom; BANKS, Adam. O guia completo da cor. Tradução de Renata Bottini. São Paulo: Senac, 2007.JOHNSON, Steven. Cultura da Interface: como o computador transforma nossa maneira de criar e comunicar. Tradução de Maria Luísa X. de A. Borges. Rio de Janeiro; Jorge Zahar, 2001.NIEMEYER, Lucy. Tipografia: uma apresentação. 3. ed. Rio de Janeiro: 2AB, 2003.

Design de Interfaces - 2

WEBAULA 1Unidade 2 – Design de Interfaces

INTRODUÇÃO

Quando o projeto de software tem o perfil de seus usuários definidos e limitados, é possível aplicar a ergonomia com foco nas necessidades específicas desse público alvo. Por exemplo em um software para clínicas odontológicas, os conceitos de ergonomia podem ser aplicados diretamente ao segmento clínico, criando interfaces e diálogos específicos.E quando for necessário criar projetos de software onde os usuários finais possuem os mais diversos perfis?Como por exemplo software para caixa eletrônico de banco.Como aplicar os conceitos de ergonomia em projetos de softwares desse nível?Apesar do esforço empreendido por muitos pesquisadores, é difícil encontrar um direcionamento global que atenda diretamente todas as expectativas ou objetivos de um designer ao construir uma interface.Por isso, além do conhecimento das técnicas de interação, é necessário um conhecimento aprofundado do campo de atuação do software que será criado, como também, de seu público alvo. TEORIA DAS FORMAS

Cada vez mais elementos gráficos e visuais fazem parte dos softwares, com o objetivo de aumentar suas vendas e a produtividade de quem o utiliza.Todo o trabalho está relacionado ao equilíbrio das formas, a sua harmonia, a transparência e a segurança que os objetivos transmitem ao usuário.O computador e sua interface representam uma ferramenta cognitiva, uma extensão da memória, uma prótese cognitiva que permite tratar melhor a informação. É importante que se conheça como os processos cognitivos humanos se desenvolvem para a concepção de próteses cognitivas compatíveis com eles (CYBIS, 2003, p. 3).Tomando como exemplo, as telas de inicialização das diversas versões do Windows, que tiveram várias evoluções na riqueza das formas, cores e equilíbrio.

Um dos papéis do projetista de software é criar projetos no sentido de satisfazer as necessidades dos seus usuários em relação harmonia visual.Segundo Bonsiepe (1997, p. 59), a interface tem a função de “permitir ao usuário obter uma visão panorâmica do conteúdo, navegar na massa de dados sem perder a orientação, e por fim, mover-se no espaço informacional de acordo com seus interesses”.A teoria das formas é um assunto que deve ser considerado e explorado amplamente pelos projetistas em seus projetos, pois seu objetivo é sempre aumentar a usabilidade e a aplicabilidade do software para seu usuário.FORMAForma, é tudo aquilo que compõe um objeto e que se torna um símbolo representativo.

Figura 9 – Forma

FORMAS SIMÉTRICAS E ASSIMÉTRICASFormas simétricas são formas equilibradas, ou seja, se fizermos um corte ao meio da forma, as partes são como um espelho, uma parte refletindo exatamente a outra parte.Formas assimétricas são formas que não possuem um centro definido no espaço, e são formas mais próximas da realidade.

Figura 10 – Forma simétrica Figura 11 – Forma assimétrica

SINAIS E SÍMBOLOSUma imagem pode dizer mais do que mil palavras e por isso os sinais e símbolos são utilizados desde as formas mais primitivas de comunicação.Ao utilizar sinais e símbolos no desenvolvimento de software, procure observar se o que está sendo utilizado transmite a mensagem com clareza ao usuário, por exemplo:

Sem dúvida a imagem da tesoura indica melhor o sentido a função recortar do que a outra imagem.

PERCEPÇÃOPercepção, são as nossas sensações, experiências e conceitos sobre algo, e como utilizamos tudo isso de forma integrada para lidarmos com o mundo.Perceber não é a assimilação de um componente figural, mas sim a assimilação da figura e o contexto com seus diversos componentes. Koffka (1975, p. 186), abordando a questão da significação explora o assunto da parte e do todo, dando uma visão mais clara desta teoria quando afirma que:[...] o problema da significação está intimamente vinculado ao problema da relação entre o todo e suas partes. Já foi dito: o todo é mais do que a soma de suas partes. Seria mais correto dizer que o todo é alguma outra coisa que a soma de suas partes, porque somar é um procedimento vazio de significado, enquanto que a relação todo-parte é significativa.

Figura 13 – Taça ou rosto humano?

Penna (1966) relata a importância do trabalho do psicólogo Edgard Rubin. Rubin diz respeito aos critérios dos componentes e caracterização do campo da percepção. Pode-se resumir os critérios em oito itens:a) A figura tem forma, mas o fundo não;b) O contorno que define o limite entre a figura e o fundo faz parte da figura;

c) O fundo cria a impressão de estar sendo continuado por detrás da figura, não se interrompendo ou perdendo sua unidade. Tal propriedade vai revelar-se de considerável importância para a atividade exploratória;d) A figura é visualizada sempre mais próxima da visão do perceptor.e) As propriedades dos componentes figurais não são permanentes ou imutáveis.

f)Elas sobrevivem até o momento em que por um processo de reversão, novas unidades figurais surgem.g) Apreciadas em função do elemento cor e utilizadas as distinções que neste domínio foram introduzidas por D. Katz, podemos caracterizar a figura em termos de cor de superfície, exibindo-se o fundo com um colorido transparente ou cor filme.h) A figura possui um efeito de destaque, sendo o elemento mais estável e bem visto.

Para saber mais sobre percepção acesse:http://pt.wikipedia.org/wiki/Percepçãohttp://geisasantos.com/tag/percepcao-humana/http://www.infoescola.com/psicologia/cognicao-percepcao-e-apercepcao/

BOA FORMAÉ a forma ideal, que contém todos os elementos para uma boa apresentação, como: simetria, estabilidade, equilíbrio e simplicidade.“A figura abaixo ilustra a noção de boa forma. Normalmente percebemos o segmento da reta A maior do que o segmento da reta B, mas isso é uma ilusão de ótica, pois são idênticos” (BOCK; FURTADO; TEIXEIRA, 1996, p. 80).

Figura 15 – Setas que confundem a visão

http://www.infoescola.com/psicologia/cognicao-percepcao-e-apercepcao/

http://www.infoescola.com/psicologia/cognicao-percepcao-e-apercepcao/

http://geisasantos.com/tag/percepcao-humana/

http://pt.wikipedia.org/wiki/Percep%C3%A7%C3%A3o

Fonte: Adaptado de BOCK; FURTADO; TEIXEIRA (1996) INSIGHT“É a passagem súbita de um estado de desconhecimento ou de incompreensão para um estado de conhecimento e resolução face a um problema” (GICK; LOCKHART, 1995, p. 197).Na prática seria como se uma criança de que ainda não sabe ler e falar, mas ao ouvir o som de um “plim...plim” sabe que irá começar o seu desenho preferido.Ou ainda ao ver elementos visuais de uma marca de refrigerante, saber de qual marca se trata.

Figura 16 – refrigerante

Langley e Jones (1988) têm a perspectiva face ao insight com base no modelo de memória de ativação por propagação. Neste modelo, a memória é tomada como uma imensa rede de conceitos e de ligações entre eles, sendo ativada a rede a partir de uma informação exterior. Por exemplo, a palavra “verde” vai ativar um conceito próximo como “semáforo”, e este ativará conceitos próximos como “siga em frente” e assim sucessivamente. ALGUNS PRINCÍPIOS DA TEORIA DAS FORMASa) Normalmente consideramos formas como figuras em primeiro plano, áreas circundadas e áreas escuras;b) É comum considerarmos fundo como formas em segundo plano;c) As formas geométricas são mais importantes, visualmente, que as espontâneas porque são compactas;

d) Não conseguimos visualizar todas as formas olhando para conjunto de imagens, quando visualizamos uma forma, os outros objetos e formas automaticamente se tornam parte do fundo.e) Formas isoladas tem um destaque maior;f) Formas verticais são mais grosseiras que as horizontais.

Quando um usuário pensa “Não gosto deste software”, mas não sabe explicar o motivo, na realidade ele sabe, de forma inconsciente, o que há de errado! Seu cérebro capta que existe divergências entre os objetos da interface, que alguns fora do lugar, suas formas e cores não estão em harmonia, trazendo desconforto para sua visão e percepção.Estudar a teoria das formas pode oferecer aos designers de software a chance de desenvolver melhores layouts e permitir que seu usuário se sinta confortável e utilizá-lo.

VÍDEO AULA 4


DIRETRIZES PARA CONSTRUÇÃO DE INTERFACES

As diretrizes para desenvolvimento de interfaces levam em consideração detalhes como o equilíbrio na distribuição dos


elementos em tela, cores, menus, ícones e letras apropriadas, entre outras. Tudo isso, torna-se importante na interação com o usuário, pois estamos pensando em alguém que usará as nossas telas muitas horas por dia.Então, é essencial possuirmos bom senso na escolha dos elementos que estarão nas telas, também procurando seguir padrões entre essas. Para criar dessa maneira, uma forma de comunicação direta com o usuário, convidando-o para navegar entre as facetas do sistema.Projetar interfaces por modelos conceituais resultam em melhor condução dos caminhos que os usuários utilizarão nos sistemas. Aplicação de diretrizes torna o software tão amigável quanto possível. CONCEITOS DO DESIGN DE INTERAÇÃO

LINK: Para saber mais sobre maus projetos de interface com o usuário e seus resultados, acesse o site: http://www.baddesigns.com/

Agora vamos fundamentar alguns conceitos sobre desenvolvimento de interfaces. Estes servirão de base para as aplicações e testes das diretrizes. Podemos destacar alguns, como:a) Interface: “é uma superfície de contato que reflete as propriedades físicas das partes que interagem, as funções a serem executadas e o balanço entre poder e controle” (LAUREL, 1993 apud ROCHA; BARANAUSKAS, 2000, p. 8).b) Interface Amigável: São elementos que estão dispostos na interface deixando-a mais agradável do ponto de vista estético;c) Interação: É como as pessoas utilizam o computador;d) Usabilidade:[...] é a qualidade que caracteriza o uso dos programas e aplicações. Segundo a ISO 9241 usabilidade é a capacidade que um sistema interativo oferece a seu usuário, em determinado contexto da operação, para a realização de tarefas de maneira eficaz, eficiente e agradável (CYBIS; BETIOL; FAUST, 2007, p. 2).e) Design de interação: “significa criar experiências que melhorem e estendam a maneira como as pessoas trabalham, se comunicam e interagem” (PREECE; ROGERS; SHARP, 2005, p. 35).f) Modelo mental (MM): “representação dinâmica sobre qualquer sistema ou objeto, que evolui naturalmente na mente de um sujeito” (NORMAN, 1985, p. 94 apud ROCHA; BARANAUSKAS, 2000, p. 91-92).

http://www.baddesigns.com/

g) Modelo Conceitual: “tem haver com a análise das dificuldades no aprendizado de programação, e propõe modelos mentais para auxiliar no contexto das representações computacionais” (ROCHA; BARANAUSKAS, 2000, p. 97).h) Ergonomia: visa eficácia e eficiência, bem-estar e saúde do usuário, através da adaptação do trabalho ao homem.i) Guidelines: recomendações para assegurar que produtos sejam utilizáveis (PREECE; ROGERS; SHARP, 2005).j) Heurística: refere-se a como determinar o que os usuários devem ver e fazer quando realizam tarefas utilizando um produto interativo.k) Semiótica:[...] explica a relação entre o objeto, seu representante e o processo de interpretação, no plano dos signos que encontramos ao nosso redor. Na perspectiva semiótica o papel do computador é basicamente o de um medium – uma substância na qual signos podem ser manifestados para uso em comunicação (ANDERSEN, 1997, p. 333).

l) Cognição: é o que acontece em nossas mentes quando realizamos nossas atividades diárias, envolvendo processos cognitivos, tais como: pensar, lembrar, aprender, fantasiar, tomar decisões, ver, ler, escrever e falar (PREECE; ROGERS; SHARP, 2005).m) Percepção: atividades diárias envolvendo processos, tais como pensar, lembrar, aprender, fantasiar, ver, ler, escrever e falar(PREECE; ROGERS; SHARP, 2005).

n) Feedback: É a forma de retornar ao usuário informações sobre ação que foram tomadas.o) Metáfora de Interface: este conceito provê às pessoas um esquema de funcionamento da interface, prevendo desentendimentos. “Funcionam como modelos naturais, permitindo usar conhecimento familiar de objetos concretos e experiências para dar estrutura a conceitos mais abstratos” (CARROLL et al., 1988

apud ROCHA; BARANAUSKAS, 2000, p. 12).Segundo Rocha e Baranauskas (2000), interface e interação são conceitos que não podem ser estabelecidos ou analisados independentemente, pois isso seria uma perspectiva simplista desta realidade do desenvolvimento.

VÍDEO AULA 5


HEURÍSTICAS PARA O DESIGN

Durante a atividade de design, de um projeto IHC, algumas heurísticas devem ser levadas em consideração. Segundo Nielsen e Mack (1994), heurísticas são regras gerais que objetivam descrever propriedades comuns de interfaces usáveis.a) Visibilidade do status do sistema: O sistema sempre mantém o usuário informando sobre o que está acontecendo.b) Compatibilidade do sistema com o mundo real: O sistema interage com o usuário com linguagens que ele possa compreender.c) Controle do usuário e liberdade: Permite ao usuário ter a liberdade de avançar ou retroceder em etapas do sistema.

d) Consistência e padrões: Padroniza palavras e funções para que tenham o mesmo sentido em qualquer momento do sistema.e) Prevenção de erros: Procura antecipar-se a errosf) Reconhecimento em vez de memorização: Procura auxiliar o usuário para que ele tenha as instruções para uso do sistema sempre que necessário.


g) Flexibilidade e eficiência de uso: Permite usuário com mais experiência a acessarem atalhos para que suas tarefas sejam realizadas com mais rapidez.h) Estética e design minimalista: Na comunicação com o usuário os diálogos precisam conter informações objetivas e restritas ao que se deseja transmitir.i) Ajudar os usuários a reconhecer, diagnosticar e recuperar-se de erros: Erros precisam ser demonstrados aos usuários de forma objetiva e que indique uma ou mais soluções.

j) Help e documentação: Ajuda pontual a cada etapa o sistema, facilita ao usuário quando houver a necessidade de procurar uma documentação sobre a tarefa que se deseja executar.

GUIDELINES PARA O DESIGN

Ainda, durante a atividade de design, de um projeto IHC, algumas guidelines são essenciais para bons projetos de interação. A maneira como projetamos a interface deve conter guidelines(recomendações), que visam diminuir conflitos entre usuários envolvidos na aplicação (PREECE; ROGERS; SHARP, 2005). Segundo Shneiderman (1998) existem oito regras de ouro, a saber:a) Esforce-se pela consistência: Posicione menus sempre no mesmo canto e do mesmo lado da tela. Para cada ação que possa resultar em perda de dados, peça confirmação da ação, e ofereça aos usuários a oportunidade de mudar de idéia.

b) Possibilite que usuários frequentes utilizem atalhos: Por exemplo, em processadores de texto, os usuários podem se movimentar pelas funções utilizando menus, teclas de atalho ou botões de funções.

c) Ofereça feedback informativo: Deixe claro o que o erro significa, considerando os diferentes tipos de usuários e seus significados.d) Projete diálogos para encerrar as ações: Deixe claro quando uma ação foi realizada com sucesso.

e) Ofereça prevenção contra erros e manuseio fácil dos mesmos: Erros são inevitáveis, e o sistema deve perdoar os cometidos e possibilitar que o usuário volte atrás.

f) Permita uma reversão fácil das ações: Ofereça uma tecla desfazer (undo) sempre que possível.g) Forneça suporte para um local interno de controle: Os usuários se sentem mais confortáveis se percebem que estão no controle da interação, ao invés da máquina.

h) Reduza a carga de memória de curto prazo: Sempre ofereça aos usuários opções, em vez de exigir que se lembrem das informações quando mudarem de uma tela para outra. Como por exemplo, lembrando o que está em seu carrinho de compras, enquanto procura outros itens para comprar no site.Um recurso para essas informações é a utilização de Guidelines, que são orientações que o sistema disponibiliza durante a sua execução. Com o uso deGuidelines a interação de uma aplicação pode ser bem mais amigável.Após projetar uma interface é importante submetê-la ao processo de avaliação, que está detalhado com o professor Everson no próximo módulo.. Pois, estas certificam que o software é utilizável, e também, se está de acordo com o que os usuários desejam.

DIRETRIZES DE CONSTRUÇÃO DE INTERFACES PARA WEBSegundo Nielsen e Loranger (2007) as interações fundamentais da web não mudam com o passar do tempo. As pessoas continuam clicando em links para navegar pelas páginas, e sua capacidade cognitiva na mudou.A Web tinha menos de 10 milhões de sites em 2000. E, em 2007, a Web tinha 80 milhões de sites. Hoje a situação é esta: as pessoas simplesmente pressupõem que a Web tem o que elas querem (NIELSEN; LORANGER, 2007).

Quando o usuário clica mais de três vezes para encontrar uma informação em qualquer site ele sente-se desmotivado a continuar navegando. E, geralmente não permanecerá mais que 10 segundos navegando em outras partes do mesmo site.

Atualmente, a maioria dos projetos para a web leva em consideração, a observação e a experiência do usuário no uso de interfaces. E a usabilidade beneficia o projeto, pois apóia a divulgação dos negócios.

LINKS:

Para saber mais sobre usabilidade com o usuário e seus resultados, acesse o site:http://www.useit.com/

USUÁRIOS

Segundo Chak (2004), o site pode ser projetado para quatro tipos de usuários. Eles representam necessidades de quem navega, e principalmente de quem toma as decisões. São estes: Navegadores, Avaliadores, Realizadores de Transações e Clientes.Os navegadores procuram por informações para atender suas necessidades, especialmente aquelas que forneçam um contexto para a tomada de decisão.Os avaliadores procuram por informações detalhadas sobre produtos e serviços oferecidos pelo site em questão. Podendo selecionar produtos ou serviços, este tipo de usuário realiza as avaliações dessas funcionalidades.Já, os realizadores de transações tomam as decisões de compra pelo site. Podendo oferecer segurança durante o processo, este tipo de usuário realiza as transações.Agora, os clientes são aqueles que já compraram e o interesse neste momento é criar a fidelização destes, a fim de proporcionar outras compras.

http://www.useit.com/%20

DIRETRIZES PARA INTERFACES WEBNeste momento, precisamos considerar que para o uso de interfaces web o tempo é sempre diferente em relação ao uso de interfaces desktop. Os usuários têm menos tolerância com as interfaces, pois desejam que a velocidade de carregamento das páginas seja alta, e também com menos atrasos.

LINKS:

Para saber mais sobre técnicas e aplicações de usabilidade, acesse o site:http://www.labiutil.inf.ufsc.br/

Mas, em compensação o usuário sente-se mais no controle da interação, se nas páginas visitadas houver indicativos de links visitados ou não, ou ainda o caminho de migalhas. Como também, permitir que o usuário possa voltar para a home page, a partir de qualquer lugar que esteja navegando. Esses e outros padrões de interação são descritos a seguir, juntamente com alguns exemplos de suas aplicações.DIRETRIZES GERAIS DE PROJETOS WEBSegundo Chak (2004), para criar sites persuasivos existem sete princípios, que foram identificados por meio de observações empíricas, e servem como diretrizes no design e teste de projetos Web.O primeiro princípio diz “A sua concorrência inclui os sites do seu concorrente, a web e o mundo off-line”. Isso significa que é preciso considerar seus concorrentes, principalmente nos aspectos relativos à facilidade de localização e compra de produtos. O autor ainda alerta que o mundo off-line é menos conveniente para os clientes, então se seu site oferece bons conteúdos e boas funcionalidades você poderá conquistar esta vantagem em relação a eles.

“Nem tudo pode ser vendido na Internet” diz respeito ao segundo princípio. Entende-se que a entrega de produtos via web, aumenta o valor total pago pelos clientes. E este fator pode ser decisivo, no momento da compra. Principalmente para aqueles clientes que tem urgência na aquisição dos produtos, e não desejam pagar mais caro por isso.Já o terceiro princípio diz: “Você deve conquistar o direito de fazer transações com o usuário”. Este princípio preza pela consciência do projetista, de não exigir

http://www.labiutil.inf.ufsc.br/

“aproximação”, na forma de solicitar informações pessoais, quando é desnecessário. Nem sempre os usuários estão dispostos ao preenchimento de cadastros, simplesmente porque não é do interesse deles. E, na maioria das vezes é do interesse apenas do projetista.O quarto princípio descreve assim: “Você sabe tudo sobre o seu site, mas os seus usuários não sabem nada”. Neste a complexidade do desenvolvimento de sistema web é considerada. Pois, às vezes, as restrições como as de banco de dados é imposta e os usuários nem sabem o que significa isso.“Faça previsão dos erros e das variações com bastante antecedência”. Este princípio identifica a preocupação com as situações não previstas durante o projeto do site. Especialmente, as situações longe das idealizadas.O princípio “Ou você faz o trabalho ou eles fazem” significa oferecer mecanismos no site para que o usuário possa tomar decisões com mias segurança e realizando as transações desejadas.O último princípio listado pelo autor diz: “Ajude seus usuários a fazer o que você deseja que eles façam”. E, significa que quanto mais guiar os passos dos usuários mais satisfação em atendê-los você terá, pois estes se tornaram clientes e realizadores de transações.Assim, pode-se concluir que após conhecer algumas diretrizes para design web, é possível aplicá-las em projetos reais. Sabe-se também que durante o processo de desenvolvimento de sites é importante que o produto de trabalho seja avaliado. E, se esses forem avaliados por usuários reais os resultados dos testes servem, muitas vezes, como redesign do próprio site.

Para observarmos um pouco mais as possibilidades do design para web, separei alguns sites interessantes. Alguns deles são sobre o assunto e alguns com estéticas diferenciadas para que vocês possam se divertir e aprender mais sobre o tema. Vejam:

http://www.dontclick.it/

http://www.w3c.br/Home/WebHome

https://www.youtube.com/watch?v=rrn1P-U8kMY

http://www.usabilidoido.com.br/

http://chocoladesign.com/o-que-faz-um-ux-designer

http://arquiteturadeinformacao.com/tag/ux-design/

http://www.similarsitesearch.com/pt/semelhante/arquiteturadeinformacao.com

ANDERSEN, Peter Bøgh. A theory of computer semiotic: semiotic approaches to construction and assessment of computer systems. Cambridge: Cambridge University Press, 1997.

http://www.similarsitesearch.com/pt/semelhante/arquiteturadeinformacao.com

http://arquiteturadeinformacao.com/tag/ux-design/

http://chocoladesign.com/o-que-faz-um-ux-designer

http://www.usabilidoido.com.br/

https://www.youtube.com/watch?v=rrn1P-U8kMY

http://www.w3c.br/Home/WebHome

http://www.dontclick.it/

ASSOCIAÇÃO BRASILEIRA DE ERGONOMIA. O que é ergonomia? Disponível em: < http://www.abergo.org.br >. Acesso em: 18 abr. 2010.ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Requisitos ergonômicos para trabalho de escritórios com computadores: parte 11: orientações sobre usabilidade. Rio de Janeiro, 2002. Disponível em: < http://www.inf.ufsc.br/~cybis/pg2003/iso9241-11F2.pdf >. Acesso em: 20 mar. 2009.BASTIEN, J. M. Christian; SCAPIN, Dominique L. Human factors criteria, principles, and recommandations for HCI: methodological and standardisation issues. Rocquencourt: INRIA, 1993.BENYON, Daniel. Adaptive systems: a solution to usability problems. User Modeling and User-Adapted Interaction, Milton Keynes, v. 3, n. 1, p. 65-87, Mar. 1993.BOCK, Ana Mercês Bahia; FURTADO, Odair; TEIXEIRA, Maria de Lourdes Trassi. Psicologias: uma introdução ao estudo de psicologia. São Paulo: Saraiva, 1996.BONSIEPE, Gui. Design: do material ao digital. Florianópolis: FIESC/IEL, 1997.CHAK, Andrew. Como criar sites persuasivos: clique aqui. São Paulo: Pearson, 2004.CYBIS, Walter de Abreu. Engenharia de usabilidade: uma abordagem ergonômica. Florianópolis: Labiutil, 2003.CYBIS, Walter; BETIOL, Adriana Holtz; FAUST, Richard. Ergonomia e usabilidade: conhecimentos, métodos e aplicações. São Paulo: Novatec, 2007.CYBIS, Walter de Abreu et al. Uma abordagem ergonômica para o desenvolvimento de sistemas interativos. In: WORKSHOP BRASILEIRO DE FATORES HUMANOS EM SISTEMAS COMPUTACIONAIS, 1., 1998, Maringá. Anais… Maringá, 1998. Disponível em: < http://www.unicamp.br/~ihc99/Ihc99/AtasIHC99/AtasIHC98/Cybis.pdf >. Acesso em: 15 mar. 2010.FARINA, Modesto. Psicodonâmica das cores em comunicação. São Paulo: Edgard Blücher, 1987.FERNANDES, Francisco; LUFT, Celso Pedro; GUIMARÃES, F. Marques. Dicionário brasileiro Globo. 43. ed. São Paulo: Globo, 1996.FISCHER, Gehard. Beyond “couch potatoes”: from consumers to designers. In: ASIA PACIFIC COMPUTER HUMAN INTERACTION CONFERENCE, 3., 1998, Hayama-machi. Proceedings… [s.l.]: IEEE Computer Society, 1998.GICK, Mary L.; LOCKHART, Robert S; Cognitive and affective components of insight. In: STERNBERG, Robert J.; DAVIDSON, Janet E. (Ed.). The nature of insight. Cambridge: MIT Press, 1995. p. 197-228.GOMES FILHO, João. Ergonomia do objeto: sistema técnico da leitura ergonômica. São Paulo: Escrituras, 2003.GOMES FILHO, João. Gestalt do objeto: sistema de leitura visual da forma. São Paulo: Escrituras, 2000.HIX, Deborah; HARTSON, H. Rex. Developing user interfaces: ensuring usability through product and process. Hoboken: John Wiley & Sons, 1993.

HOELZEL, Carlos Gustavo Martins. Design ergonômico de interfaces gráficas humano-computador: um modelo de processo. 2004. Tese (Doutorado em Engenharia da Produção) - Universidade Federal de Santa Catarina, Florianópolis, 2004.KOFFKA, Kurt. Princípios da psicologia da Gestalt. São Paulo: Cultrix, 1975.LABORATÓRIO DE UTILIZABILIDADE DA INFORMÁTICA. Menu de checklist. Disponível em: < http://www.labiutil.inf.ufsc.br/ergolist/ >. Acesso em: 12 mar. 2010.LANGLEY, Pat; JONES, Randolph. A computational model of scientific insight. In: STERNBERG, Robert J. The nature of creativity: contemporary psychological perspectives. Cambridge: Cambridge University Press, 1988. p. 177-201.LAUREL, Brenda. The art of human-computer interface design. Reading: Addison-Wesley Professional, 1990.LEITE, Jair Cavalcanti; SOUZA, Clarisse Sieckenius de. Uma linguagem de especificação para a engenharia semiótica de interfaces de usuário. Disponível em < http://www.unicamp.br/~ihc99/Ihc99/AtasIHC99/art23.pdf >. Acesso em: 26 mar. 2010.MONTMOLLIN, M. Introducción a la ergonomía: los sistemas hombres-maquinas. Madri: Aguillar, 1971.MORAIS, Éverson Matias de. Um estudo sobre a validade e fidedignidade de métodos de avaliação de interfaces. 2007. 114 f. Dissertação (Mestrado em Ciência da Computação) – Universidade Estadual de Maringá, Maringá, 2007. Disponível em: < http://www.din.uem.br/arquivos/pos-graduacao/mestrado-em-ciencia-da-computacao/dissertacoes >. Acesso em: 15 mar. 2010.MORAN, Thomas P. The command language grammars: a representation for the user interface of interactive computer systems. International Journal of Man-Machine Studies, London, v. 15, n. 1, p. 3-50, July 1981.NEVO, David. The conceptualization of educational evaluation: An analytical review of the literature.Review of Education Research, Washington, v. 53, n. 1, p. 117-128, Spring 1983.NIELSEN, Jakob. Ten usability heuristics. Disponível em: < http://www.useit.com/papers/heuristic/heuristic_list.html >. Acesso em: 10 dez. 2009.NIELSEN, Jakob; LORANGER, Hoa. Usabilidade na web: projetando websites com qualidade. São Paulo: Campus. 2007.NIELSEN, Jakob; MACK, Robert L. Usability inspection methods. Hoboken: John Wiley & Sons, 1994.PENNA, Antonio Gomes. Percepção e aprendizagem. Rio de Janeiro: Fundo de Cultura, 1986.PRATES, Raquel Oliveira; BARBOSA, Simone Diniz Junqueira. Avaliação de interfaces de usuário: conceitos e métodos. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 23., 2003, Campinas. Anais... Campinas: SBC, 2003. Disponível em: < http://www.dimap.ufrn.br/~jair/piu/artigos/avaliacao.pdf >. Acesso em: 1 abr. 2010.PREECE, Jennifer et al. Human-computer interaction: concepts and design. Essex: Addison-Wesley Longman, 1994.

PREECE, Jennifer; ROGERS, Yvonne; SHARP, Helen. Design de interação: além da interação homem-computador. Porto Alegre: Bookman, 2005.PRESSMAN, Roger. Engenharia de software. Rio de Janeiro: Campus, 2007.RAUPP, Magdala; REICHLE, Adriana. Avaliação: ferramenta para melhores projetos. Santa Cruz do Sul: EDUNISC, 2003.ROCHA, Heloisa Vieira da; BARANAUSKAS, Maria Cecília C. Design e avaliação de interfaces humano-computador. São Paulo: IME-USP, 2000.SANTOS, Venétia, ZAMBERLAN, Maria Cristina. Projeto ergonômico de salas de controle. São Paulo: Fundación Mapfre, 1992.SCAPIN, Dominique L.; BASTIEN, J. M. Christian. Ergonomic criteria for evaluating the ergonomic quality of interactive system. Behaviour and Information Technology, London, v. 16, n. 4/5, p. 220-231, July 1997.SCRIVEN, Michael. Types of evaluation and types of evaluator. Evaluation Practice, Saint Louis, v. 17, n. 2, p. 151-161, Summer 1996.SHNEIDERMAN, Ben. Designing the user interface: strategies for effective human-computer interaction. 3. ed. Essex: Addison-Weslley, 1998.SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Prentice Hall, 2007.SOUZA, Clarisse Sieckenius de et al. Projeto de interfaces de usuário: perspectivas cognitivas e semióticas. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 19., 1999, Rio de Janeiro. Anais... Rio de Janeiro: SBC, 1999. Disponível em: < http://www.dimap.ufrn.br/~jair/piu/JAI_Apostila.pdf >. Acesso em: 15 mar. 2010.SOUZA, Maria Carolina S; BUNHAM, Teresinha Fróes. Metáforas e EAD: em busca de menores distâncias. In: JAMBEIRO, Othon; SILVA, Helena Pereira da (Org.). Socializando informações, reduzindo distâncias. Salvador: EDUFBA, 2003. p. 87-125.TEORIA das cores. Disponível em: < http://www.tecelagemanual.com.br/Teoria%20das%20Cores.ppt >. Acesso em: 13 abr. 2010.WISNER, Alain. Por dentro do trabalho: ergonomia: método e técnica. São Paulo: FDT, 1987. SUGESTÕES DE LEITURACYBIS, Walter de Abreu. A identificação dos objetos de interfaces home,-computador em seus atributos ergonômicos. 1994. Tese (Doutorado em Engenharia da Produção) - Universidade Federal de Santa Catarina, Florianópolis, 1994.ERTHAL, Tereza Cristina. Manual de psicometria. Rio de Janeiro: Jorge Zahar, 2003.JOHNSON, Steven. Cultura da interface: como o computador transforma nossa maneira de criar e comunicar. Rio de Janeiro: Zahar, 2001.MINICUCCI, Agostinho. Psicologia aplicada à administração. São Paulo: Atlas, 1992.

NIELSEN, Jakob. Severity ratings for usability problems. Disponível em: < http://www.useit.com/papers/heuristic/severityrating.html >. Acesso em: 5 jan. 2010.PERES, Cláudio Cezar. Ações de fiscalizações preventivas de LER/DORT na área do comércio. Boletim da Saúde, Porto Alegre, v. 19, n. 1, p. 39-50, jan./jun. 2005. Disponível em: < http://www.mp.to.gov.br/portal/sites/default/files/Ações%20Coletivas%20para%20Prevenção%20de%20LER-DORT.pdf >. Acesso em: 11 abr. 2010.PERES, Cláudio Cezar et al. A multiprofissionalidade e interinstitucinalidade necessárias em uma ação ergômica complexa. In: CONGRESSO BRASILEIRO DE ERGONOMIA, 10., 2000, Rio de Janeiro.Anais... Rio de Janeiro: ABERGO, 2000. Disponível em: < http://www.ergonet.com.br/download/amultiprofissionalidade-claudio_c_peres.pdf >. Acesso em: 15 mar. 2010.