Leia um pouco sobre a Arquitetura de Software!

Arquitetura de Software

Introdução

Arquitetura de Software é um conjunto de decisões significativas sobre a organização de um sistema de software, a seleção de elementos estruturais e suas interfaces juntamente com o comportamento especificado nas colaborações entre estes elementos, a composição destes elementos em subsistemas progressivamente maiores e o estilo arquitetural que guia esta organização (IBM).

Arquitetura é a organização fundamental de um sistema materializado em seus componentes, na relação entre eles e com o ambiente e nos princípios que guiam seu projeto e evolução (IEEE)

A arquitetura de software define quais serão os elementos que constituirão o software (módulos) seus relacionamentos e pelos princípios (padrão) que conduzem seu design e evolução.

Ela está preocupada em compreender como deve ser organizado os elementos do sistema e suas estruturas. No processo de desenvolvimento de software, o projeto de arquitetura é um dos principais estágios que liga o projeto à engenharia de requisitos, pois é nesta fase que são identificados os principais componentes, estruturas e seus relacionamentos. O resultado do projeto de arquitetura é um modelo que descreve como deve ser organizado os elementos (componentes ou módulos) do sistema e de que forma estes elementos irão se comunicar (protocolos de comunicação).

O projeto de arquitetura de sistema é muito importante, pois afeta diretamente o desempenho, a robustez do software, a capacidade de distribuição e na sua manutenção. Cada componente individua representa um requisito funcional do sistema, já os requisitos não funcionais dependem da arquitetura do sistema ou seja a forma como estes componentes estão organizados e da comunicação entre eles.

Bass et al. (2003) discute três vantagens de projetar e documentar a arquitetura de software.

•          Comunicação de stakeholders. A arquitetura é uma apresentação de alto nível do sistema e pode ser usada como um foco de discussão por uma série de diferentes stakeholders.
•          Análise de Sistemas. Tornar explícita a arquitetura de sistema, em um estágio inicial do desenvolvimento, requer alguma análise. As decisões de projeto de arquitetura tem um efeito profundo sobre a possibilidade de o sistema atender ou não aos requisitos críticos, como desempenho, confiabilidade e manutenibilidade.
•          Reuso em larga escala. Um modelo de arquitetura de sistemas é uma descrição compacta e gerenciável de como um sistema é organizado e como os componentes interoperam. A arquitetura do sistema geralmente é a mesma com requisitos semelhantes e, por isso, pode apoiar o reuso  de software em grande escala.

Não há dúvida de que o mundo está se tornando cada vez mais dependentes de software. Software é um elemento essencial no mundo corporativo e por que não dizer nas nossas vidas em particular. Mesmo as organizações tradicionais, como organizações financeiras, varejo e setor público, não sobreviveriam sem a presença forte de um software. Hoje em dia, a aplicação de softwares em seus negócios.

Para que estas organizações sobrevivam, o software de que eles dependem devem fornecer a capacidade exigida, ter qualidade suficiente, estar disponível quando prometido, e ser entregue a um preço aceitável.

Todas essas características são influenciadas pela arquitetura do software.

Entenda um pouco sobre a Orientação a Objetos!

Orientação a Objetos

            A programação orientada a objetos é uma técnica de programação baseada em modelos ou objetos do mundo real. Isto que dizer que dentro do programa (executável) deve ter um objeto representando os objetos do mundo real de acordo com a área a qual foi projetado o sistema.

            Por exemplo, se o sistema foi projetado para atender um consultório médico, onde este sistema deve gerenciar a agenda de consultas dos médicos da clinica, então eu preciso criar dentro deste sistema objetos que representem os médicos, os pacientes, os funcionários etc.

            Para isso precisamos entender melhor o que significa estes “objetos”. Se pensarmos em um grupo de pessoas unidas a um bem comum (uma sociedade, por exemplo) vamos verificar claro que este grupo é formado por varias pessoas onde cada uma assume uma função dentro do grupo para atingir o tal bem comum. Cada pessoa do grupo é especialista em alguma coisa que pode ajudar o grupo a andar ao encontro do objetivo traçado. Cada elemento deste grupo executa a sua tarefa e ao mesmo tempo se comunicando com outros elementos do grupo. Ao se comunicar uns com os outros, ele estabelece um relacionamento entre si que vai auxiliar na conclusão de suas tarefas. Esta comunicação serve para simplesmente avisar que a sua tarefa foi concluída ou para pedir auxilio na conclusão da tarefa, pois a casos em que algumas atividades das tarefas delegadas ao elemento não são de total domínio dele, sendo assim ele precisa da ajuda de um elemento mais especializado naquele momento.

Da mesma forma, é um programa orientado a objetos. Onde o grupo é o programa (executável), os elementos do grupo são os objetos do programa.

Cada objeto dentro do programa é como um elemento do grupo (sociedade) que possui funções especifica dentro do programa. Cada objeto desempenha uma função dentro do programa para que o programa atinja o seu objetivo. Estes objetos também se relacionam entre si da mesma forma que os elementos de um grupo também se relacionam.

Dentro do paradigma orientado a objeto, existem algumas regras para que o cenário exemplificado acima possa ser implementado como um projeto orientado a objetos. Para que um objeto possa ser criado dentro de um POO (Programa Orientado a Objeto), é preciso descrevê-lo de uma forma que fique bem detalhado como será este objeto, suas características e como ele vai se comportar dentro do POO ou seja, o que exatamente ele vai fazer dentro do sistema. Para isso existe o conceito de Classe. A classe é a maneira adotada na POO para descrever os objetos, é dentro de uma classe que definimos tudo o que o objeto pode fazer quais os dados ele vai poder manipular e com quem ele pode se relacionar.

Por exemplo, vamos imaginar uma receita de bolo. Para fazer um bolo, é preciso conhecer a receita do mesmo, pois lá estão definidos os ingredientes que vamos usar e o modo de preparar. Quando usamos esta receita, estamos nos baseando nela para criar um bolo. Desta forma fica claro que vamos comer o bolo e não a receita, então usamos uma descrição de como se deve fazer um bolo, e o resultado é o bolo assado. O bolo só existe por que tem uma receita dizendo como deve ser um bolo e alguém foi lá e o criou com base nesta descrição.

            Para projetarmos sistemas orientado a objetos precisamos conhecer e aprender a usar ferramentas de modelagem que utilizem uma linguagem padrão para descrevermos os objetos do projeto. Ésta linguagem é a UML.

Introdução: Principio básicos da engenharia de software!

Principio básicos da engenharia de software

Ciclo de Vida de Desenvolvimento de Software

Para começarmos a falar sobre projeto orientado a objeto, vamos relembrar alguns conceitos da engenharia de software.

No mundo real, é importante abordar projetos de desenvolvimento de software de uma forma estruturada e sistemática para garantir que a solução atende plenamente as necessidades do usuário final. Vamos fazer um breve estudo sobre o ciclo de desenvolvimento de software.

Mesmo os projetos de software mais simples podem ser divididos em várias fases. A quantidade e os nomes dessas fases podem ser diferentes de um autor para outro, mas a maioria das descrições do ciclo de vida de desenvolvimento de software compartilham os mesmos elementos comuns:

1. Determinar os requisitos do software desejado (Fase de analise).
2. Produzir um projeto que atenda aos requisitos (Fase de projeto).
3. Construir (programar) o software projetado (Fase de construção).
4. Verifique se o software atende aos requisitos (Fase de testes).
5. Manter o software ao longo de sua vida (Fase de manutenção).

Muitos desenvolvedores de software, especialmente os novatos, saltam imediatamente para a fase 3 sem dedicar tempo suficiente para as duas primeiras e últimas fases. 

O modelo de ciclo de vida clássico no campo de Sistemas de Informação é o modelo cascata. Esta abordagem é normalmente usada em grandes projetos envolvendo muitos desenvolvedores. O projeto progride através de cada fase em uma sequência precisa. Os membros da equipe de desenvolvimento pode realizar uma revisão no final de cada fase para determinar se o projeto deve continuar para a próxima fase. O modelo cascata distingue-se como um processo dirigido a documento. Os documentos são as saídas de uma fase, e as entradas para a próxima fase, é um registro de que o trabalho numa fase foi devidamente concluída.

Uma das desvantagens do modelo cascata é que ele é muito inflexível. Como resultado, uma abordagem mais recente substituiu o modelo em cascata pelo modelo de Prototipagem Rápida. Este modelo tem as mesmas fases básicas, mas coloca uma ênfase na criação de um protótipo. Isto torna possível identificar deficiências no projeto antes de um grande esforço ter sido dispendido no projeto. O protótipo na verdade não faz nada de útil; ele da ao cliente uma visualização mais útil do produto final baseado nos requisitos. Para software que tem uma interface gráfica do usuário, uma boa quantidade de código de programação do aplicativo depende da configuração dos controles de interface. Neste modelo, o desenvolvedor terá a certeza de obter o modelo aprovado pelo cliente antes de escrever muito código.

Embora haja uma série de outros modelos de ciclo de vida lá fora, o modelo de Prototipagem Rápida é, provavelmente, o mais adequado para pequenas e médias projetos. 

Requisitos fase de estudo

A primeira parte da fase de requisitos se discute com o cliente sobre o produto e o que se espera do mesmo. Neste ponto, é importante identificar eventuais problemas que possam aparecer no caminho do pprojeto. Estas restrições podem incluir prazos de entrega do produto final, as limitações técnicas (por exemplo, se o cliente tem o hardware / software necessário para utilizar o produto), e as restrições orçamentais (O cliente pode pagar para o desenvolvimento do produto?) .

Fase de Projeto

Na fase de projeto, o desenvolvedor produz um modelo que atenda aos requisitos enunciados na descrição do produto. Esta é a fase em que o desenvolvedor cria um protótipo, que pode começar como um esboço simples de uma interface de usuário. O objetivo da fase de projeto é a de criar um esqueleto do produto final, com o objetivo de apresentar ao cliente para obter feedback. 

Ao projetar um protótipo, uma série de fatores devem ser considerados:

• Como dados de entrada exigidos seja a partir de um banco de dados, através de um formulário web ou através de caixas de entrada.
• Como as entradas devem ser processadas para se chegar ao resultado desejado.
• Qual é o formato da saída, um relatório, exportação para um arquivo etc.

Durante o processo de design, o desenvolvedor deve resistir à tentação de escrever muito código. A única codificação que deve ser feito nesta fase é que o que é necessário para dar ao cliente uma ideia de como o produto final irá operar. Por exemplo, os botões podem ser codificados para abrir formulários ou para exibir caixas de mensagens que descrevem o que os botões vão fazer quando a aplicação estiver concluída, o código pode ser adicionado para preencher caixas de listagem, etc.

MODELAGEM DE PROCESSOS DE NEGÓCIOS

  MODELAGEM DE PROCESSOS DE NEGÓCIOS  

Noções sobre Processos de Negócio

Segundo Harrington [2], um processo de negócio é um conjunto de atividades lógicas, relacionadas e sequenciais que, a partir de uma entrada de um fornecedor, agrega-lhe valor e produz uma saída para um cliente.

Dentro da área de processos, quando falamos em Gestão de Processos de Negócios, utilizamos o termo BPM (Business Process Management), que trata-se de um modelo para apoiar as organizações a criarem e aperfeiçoarem seus processos de negócio em tempo real, baseados em tecnologia, com foco na melhoria contínua de processos e consequentemente na satisfação dos clientes, quanto a melhor qualidade dos produtos, agilidade de entrega de produtos e serviços baseado nas necessidades do mercado.

Segundo CBOK [6], BPM é uma abordagem disciplinar para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio, automatizados ou não, para alcançar resultados consistentes e alinhados com os objetivos estratégicos da organização.

Para KROENKE [1], Processos de Negócio, é uma rede de atividades, funções, recursos, repositórios e fluxos de dados que interagem para executar uma função de negócios, onde:

• Atividades: São grupos de tarefas correlatadas que recebem dados e informações, e processam esses fatores para produzir resultados.
• Decisões: Uma questão que pode ser respondida como “Sim” ou “Não”.
• Funções: Conjuntos de Procedimentos.
• Recursos: Físicos, envolve a infraestrutura necessária para a realização de uma determinada função. Humanos, são pessoas necessárias a desempenhar determinada função.
• Repositórios: é o local de armazenamento dos registros das empresas.
• Fluxo de Dados: É a movimentação de dados de uma atividade para outra.

Com o uso do BPM as empresas tem conseguido entender sua estrutura organizacional a partir da visão de seus processos relacionados e trabalhando de forma integrada deixando de lado a antiga visão departamental. E para as organizações se manterem competitivas no mercado, é necessário constante revisões destes processos e a divulgação do mesmo. Vejamos na figura 2 abaixo um processo de negócio modelado BPMN (Notação de Gestão de Processos de Negócio), utilizando a ferramenta Bizagi e na figura 3 utilizando a ferramenta Astah.

 

          Figura 3 – Modelagem de Processos para Compra de Produto (Bizagi)

O diagrama abaixo da figura 3, foi criado usando a UML (linguagem de modelagem unificada), que abordaremos no próximo semestre.  Para saber mais sobre UML, Clique aqui.

Figura 4 – Modelagem de Processo para Compra de Produto (Astah)

Para saber mais sobre Modelagem de Processo com as práticas BPM,acesse aqui: http://blog.iprocess.com.br/tag/modelagem-de-processos/ 

Links importantes: http://www.efagundes.com/tecnologias/Gestao_de_processos_de_negocios.htm http://www.efagundes.com/tecnologias/Gestao_de_processos_de_negocios.htm#sthash.UGLkRacf.dpuf http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-basics.html

Projetos de Interface Usabilidade

     Segundo ISO (2007), 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 dependem 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 2.

Tabela 2. Exemplo de Medidas de Usabilidade

Medidas de Usabilidade
Objetivos de Usabilidade	Medidas de Eficácia	Medidas de Eficiência	Medidas de satisfação
Usabilidade global	Porcentagem de objetivos alcançados; Porcentagem de usuários que completam a tarefa com sucesso; Média da acurácia de tarefas completadas.	Tempo para completar uma tarefa; Tarefas completadas por unidade de tempo; Custo monetário de realização da tarefa.	Escala de satisfação; Freqüência de uso; Freqüência de reclamações

Fonte: ISO (2007)

Usabilidade e a interação Homem-Computador: Este link nos complementa um pouco mais a usabilidae:

 http://www.agner.com.br/download/pucrio/01BrenoGentil.pdf

 Porém, podem ser necessárias algumas medidas adicionais para propriedades particulares do produto que contribuam para a usabilidade, conforme a Tabela 3:

Tabela 3. Exemplo de Medidas para Propriedades Desejáveis do Produto.

Medidas para Propriedades Desejáveis do Produto
Objetivos de Usabilidade	Medidas de Eficácia	Medidas de Eficiência	Medidas de satisfação
Adequados às necessidades de usuários treinados	Número de tarefas importantes realizadas; Porcentagem de funções relevantes usadas	Eficiência relativa comparada com um usuário experiente	Escala para satisfação com características importantes
Adequados às necessidades para usar facilmente	Porcentagem de tarefas completadas com sucesso na primeira tentativa	Tempo gasto na primeira tentativa1) ; Eficiência relativa na primeira tentativa	Taxa de uso voluntário
Adequados às necessidades para uso não-freqüente ou intermitente	Porcentagem de tarefas completadas com sucesso depois de um período específico sem uso	Tempo gasto reaprendendo funções 1) ; Número de erros persistentes	Freqüência de reuso
Redução de necessidade de suporte	Número de referências para documentação; Número de chamadas ao suporte; Número de acessos para obter ajuda	Tempo produtivo1) ; Tempo para aprender por critério 1)	Escala para satisfação com recursos de apoio
Facilidade de Aprender	Número de funções aprendidas; Porcentagem de usuários que conseguem aprender por critério	Tempo para aprender por critério 1) ; Tempo para reaprender por critério 1) ;	Escala para facilidade de aprendizado
Tolerância a erros	Porcentagem de erros corrigidos ou apresentados pelo sistema; Número tolerado de erros do usuário	Tempo gasto na correção de erros	Escala para verificar erros
Legibilidade	Porcentagem de palavras lidas corretamente em uma distância normal de visualização	Tempo para ler corretamente um número especificado de caracteres	Escala para desconforto visual
1) Convém que nesses exemplos os recursos sejam medidos em relação a um nível especificado de eficácia.

Fonte: ISO (2007)

 De acordo com ISO (2007), 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. Emrelaçã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.

Diretrizes WEB e Desktop

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. E, 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.

Elementos da Interação

Os elementos da interação evoluíram conforme houve o crescimento da tecnologia envolvendo computadores e seus dispositivos interativos. Segundo Pressman (2007), nos primórdios da era do computador o único modo realístico de IHC era a interface de comando e consulta. A comunicação era puramente textual e impulsionada mediante comandos, e respostas a consultas geradas pelo sistema.Esta evolução dos elementos da interação foi inevitável, principalmente quando pensamos que esta depende do usuário. Sendo centrada no usuário a interação tende a ser mais direta e menos restrita, inserindo elementos visuais mais fáceis e amigáveis. A seguir veremos alguns exemplos desses elementos da interação, a maioria deles esta baseada nas diretrizes de Cybis, Betiol e Faust (2007).

Projetos de Interface

Projetos de Interface

Vamos conhecer algumas dicas para construir interfaces homem-computador em sistema desktop e web. As diretrizes para estes sistemas 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 aproximadamente oito horas por dia. Segundo 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).

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.

 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).

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 ummedium – 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.

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. E, 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.

Péssimo atendimento na #NET

Falávamos da #oi mais a #net não fica para trás.

um caminhão torou os fios da net no começo da rua, então depois de dois dias liguei para a #net para informar que a internet não esta funcionando nem na minha casa e nem na casa dos vizinhos, então a telefonista falou que ia verificar, depois de 10 minutos ela diz que a internet esta funcionando e que tenho que ligar para outra empresa para fazer a reclamação que o cabo esta rompido. eu falei então diga qual o nome da outra empresa que tenho que ligar para resolver o problema de conexão de cabo ele informou que espera-se um momento no telefone que ela ira verificar o nome da empresa. então ja faz meia hora que estou pendurado com o telefone no ouvido gastando meus créditos da oi ligando para a net.  que absurdo.  ao menos a oi falava que iria ajeitar e a net tem que ligar para outra empresa. só pegando a gravação da ordem de serviço 907140987411848  que já faz meia hora esperando mim passar o telefone de outra empresa que corrige os cabos danificados.  faz mim rir.

na hora de cobra olha o que ela manda.


Péssimo atendimento na #NET

Projeto de interface Avançado!

Projeto de interface Avançado

Aqui iniciamos os elementos essenciais para planejamento web e desktop.

Desktop

Painéis de controle

Janelas

Apresentam graficamente os comandos, as ferramentas e os dados de determinada aplicação.

 

 Caixa de Diálogo

Apóiam a operação de funções específicas e bem delimitadas, provendo troca de informações. É uma janela secundária que apresenta ou recebe informações adicionais do usuário

 Formulários

É uma caixa de diálogo destinada especificamente à entrada e consulta de dados, com opções de comandos específicas para o registro e a manutenção desses dados.

 Caixa de Mensagem

É uma caixa de diálogo que apresenta informações sobre uma situação ou condição particular.

 Seleção

Menus

Proporcionam aos usuários escolhas que podem ser de comandos, ou de opções relacionadas a um comando (PREECE; ROGERS; SHARP, 2005). SegundoPressman (2007), o menu simples proporciona ao usuário um contexto global, e é menos propenso a erros do que o formato de linha de comando, mas seu uso pode ser tedioso. Use quando o número de escolhas é limitado ou para facilitar o aprendizado de usuários inexperientes para o aplicativo. Assim, poderá fornecer navegação facilitando a orientação dentro do sistema. Existem tipos de menus, a saber: suspensos (drop-down), instantâneos (pop-up), ou de diálogo simples.

Barra de Menu

Ela é apresentada abaixo do título da interface e contém as chamadas para outras intercaces.

 Barra de Ferramentas

A barra de ferramentas é um painel não modal (o usuário continua seu trabalho sobre uma outra janela ou caixa de diálogo, sem fornecer uma resposta imediata a caixa não modal), que contém conjuntos de controles projetados para fornecer o acesso rápido a comandos específicos. Combina a idéia de um conjunto de ferramentas com uma barra (PREECE; ROGERS; SHARP, 2005). Use para comandos globais e que são usados com freqüência. 

Caixa de Combinação (Combo Box)

É um objeto que permite a entrada de dados através de uma forma de interação que combina seleção e edição.

 Barra de Rolagem

A barra de rolagem combina o conceito de rolo com uma barra, em um gráfico de barras (PREECE; ROGERS; SHARP, 2005).

 Lista de Seleção

É uma lista que apresenta valores para entrada de dados e que permitem ao usuário selecionar um ou mais opções desejadas. Ela pode ser classificada como textual, gráfica e mista

Procure incluir barra de rolagem. Elas podem ser usadas para calendários quando a densidade na tela é baixa, ou para paleta de cores quando quiser apresentar um conjunto de dados do tipo gráfico (para seleção de cores).

 Caixa de Agrupamento

Contém um grupo de informações relacionadas. É utilizado por razões semânticas ou ergonômicas de apresentação.

Controle – Botões de Rádio (Radio Button)

São grupos de botões que permitem ao usuário escolher entre uma ou outra opção.

 Controle – Caixa de Atribuição (Check Box)

Permite o usuário escolher uma ou mais opções dentro de um grupo.

 Controle - Botão de Comando (Command Button)

É um botão que contém uma ação a ser executada, normalmente um OK ou, CANCELA, em sua maioria tem formato retangular com um texto objetivo sobre a ação a ser executada.

 DIRETRIZES PARA INTERFACES WEB

Neste 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. 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.

 Entenda um pouco mais sobre a condução na criação de sites:

http://www.sobresites.com/usabilidade/cursos.htm

 Links

Para saber mais sobre diretrizes para a confecção de páginas Web Acessíveis, acesse o site: http://www.w3.org/ [W3C The World Wide Web Consortium].

 Padrões de IHC definidos por Welie

Sobre Navegação

 Menu sem cabeçalho

Problema: usuário precisa acessar seções principais do site.

Solução: Combinar menus na vertical usando diferentes pistas visuais ou invés de cabeçalhos.

 Caminho de Migalhas

Problema: usuário precisa conhecer onde ele esta na estrutura hierárquica e voltar a navegar no mais alto nível desta hierarquia.

Solução: Mostrar o caminho hierárquico do nível mais alto até a página atual e tornar cada caminho um link.

 Diretórios de Navegação

 Problema: o usuário precisa escolher um item de fora do conjunto de itens.

Solução: resumir nível 1 e nível 2.

 Duplo Guia de Navegação

 Problema: os usuários necessitam navegar em uma estrutura hierárquica.

Solução: use uma guia tabular para mostrar os dois níveis mais altos da hierarquia.

 Menu Fly-Out

 Problema: usuários precisam ter acesso direto a sub navegação, mas a quantidade de espaço na tela de navegação é limitada.

Solução: Combinar navegação horizontal com um sub menu que aparece (flies-out) quando o usuário para sobre um item do menu principal.

 Link para a Home Page

Problema: usuários precisam voltar para um ponto de início familiar.

Solução: usar um elemento fixo, tal como a logo do site, como um link para a página inicial.

Navegação Principal

Problema: usuários precisam conhecer onde eles podem encontrar o que estão procurando.

Solução: Colocar um menu sempre visível, em uma posição fixa na tela.

 Navegação por Mapa

Problema: usuários precisam encontrar uma localização da sua escolha em um mapa.

Solução: Mostre um mapa com os pontos de interesse e fornece links de navegação para todos os cantos.

 Meta de Navegação

Problema: usuários querem conhecer com quem eles estão lidando.

Solução: reserve uma área em todas as páginas para comunicação e elementos de navegação secundários.

 Minesweeping

Problema: usuários precisam similar a interação com elementos de navegação.

Solução: mostre nos elementos gráficos que ao posicionar o mouse em cima revela seu significado.

 Menu Repetido

Problema: usuários precisam acessar o menu principal.

Solução: repita o menu principal no final da página [rodapé].

 Caixa de Atalho

Problema: usuários desejam acessar funcionalidades especificas em um caminho direto.

Solução: permita que os usuários selecionem importante localização em uma combobox.

 Link para o topo da página (to-the-top)

Problema: usuários precisam voltar para o início da página.

Solução: forneça um link para o topo da página.

 Árvore de Navegação

Problema: usuários precisam encontrar um item na navegação principal.

Solução: seções (em pilha) são abertas verticalmente, ao mesmo tempo em que o usuário digita o conteúdo.

 Interações Básicas

Botão de Ação

Problema: usuários precisam tomar alguma importante ação, que é relevante no contexto da página que ele está visualizando.

Solução: Use um botão de apertar (push-button), com a ação tendo um verbo significativo como parte do rótulo (label).

 Paginação

Problema: usuários precisam navegar entre uma grande lista de itens de interesse.

Solução: representar o resultado da busca por agrupamento em páginas, com um número fixado de itens e permitir que o usuário escolha facilmente qualquer dos itens listados.

 Botão Pulldown

Problema: usuário precisa selecionar um item fora do conjunto de itens.

Solução: mostre os itens por suas representações visuais, em uma lista circular. Tal que um dos itens pode ser selecionado na hora.

 Slideshow

Problema: usuários querem ver uma série de imagens ou fotos.

Solução: mostre cada imagem por alguns segundos e forneça controle para navegar manualmente tanto para trás como pra frente, assim como no caso de parar a apresentação.

 Passo a Passo

Problemas: usuário precisa ver em ordenação linear o conjunto de itens.

Solução: permitir aos usuários ir para a tarefa anterior ou próxima, também por meio de links. 

Wizard

Problema: usuário precisa alcançar uma única meta, mas várias decisões precisam ser tomadas antes da meta ter sido alcançada completamente. Esta pode não ser conhecida pelo usuário.

Solução: usuário realiza a tarefa um passo de cada vez. Mostrando cada passo ainda existente, e quais têm sido completados.

 Busca

Busca Avançada

Problema: usuários precisam encontrar um item especifico em uma grande coleção de itens.

Solução: ofereça uma busca especial e avançada função de busca, com termos estendidos, correspondentes e com opções de saída.

Qstões freqüentemente perguntadas (FAQ – Frequently Asked Questions)

Problema: usuários têm questões relativas ao site, ou aos seus tópicos.

Solução: crie uma página com as questões freqüentemente perguntadas (FAQ) e fornece pequenas respostas.

 Caixa de busca

Problema: usuários precisam encontrar um item ou uma informação especifica.

Solução: ofereça a busca.

 Área de busca

Problema: usuários precisam encontrar uma página.

Solução: use uma área dedicada com diferentes tipos de funcionalidade de busca. 

Resultados de busca

Problema: usuários precisam entender a lista de resultados.

Solução: forneça pequenos resultados com pequenas descrições.

 Tipos de busca

Problema: usuários precisam conhecer o mecanismo de busca.

Solução: ofereça ajuda em palavras-chave e em opções correspondentes.

 Índice do site

Problema: usuários precisam encontrar uma página especifica.

Solução: mostre todas as páginas em índice em ordem alfabética ou por tópicos.

 Mapa do site

Problema: usuários precisam encontrar uma página específica.

Solução: mostre o mapa do site.

 Mapa do site no rodapé

Problema: usuários precisam encontrar uma página específica.

Solução: mostre um conjunto de links categorizados no rodapé de cada página.

Tags

Problemas: usuários precisam conhecer quais tags são freqüentemente usadas e sua popularidade.

Solução: liste as tags mais comuns ordenadas alfabeticamente e indique as mais populares com fontes de tamanho maior.

Lidando com dados

Construtor de listas

Problema: usuário precisa construir e gerenciar uma lista de itens.

Solução: mostre a lista completa e ofereça funcionalidade de edição.

 Visão geral em Detalhes

Problema: usuário deseja verificar objetos que são parte de um conjunto.

Solução: mostre uma visão geral de todos os objetos e mostre os detalhes do objeto selecionado em uma nova página.