Tecla Windows: veja do que ela é capaz

Descrição: teclawindows

Tecla Windows. Ela nunca foi tão útil quanto nessa
nova versão do sistema operacional. Nas versões
anteriores, algumas combinações já eram possíveis,
mas agora, ela ganhou outras funções que facilitam
o manuseio e fazem com que o usuário ganhe tempo.
Quer ver?

Experimente a combinação Windows + seta para a
direita. A janela que estava em primeiro plano
vai, automaticamente, para a metade direita da
tela. Selecione outra janela e, dessa vez, aperte
Windows + seta para a esquerda. Veja só. A tela
ficou dividida ao meio, com cada janela para um
lado. Isso é ideal para quem gosta de utilizar
duas aplicações ao mesmo tempo. A combinação
Windows + seta pra cima maximiza a janela, e
Windows + seta pra baixo minimiza o que estava em
primeiro plano.

Se o botão Windows for apertado junto com a tecla
de espaço, todas as janelas somem da tela e a área
de trabalho é mostrada. Isso é muito útil caso
você queira ver algo que esteja no desktop, sem
precisar minimizar uma por uma. O mesmo efeito
pode ser conseguido ao repousar o mouse aqui, no
cantinho direito. Agora, experimente clicar em
alguma janela e chacoalhar o mouse. Olha só. Tudo
é minimizado, menos o programa selecionado. Legal,
né? Isso também pode ser feito via teclado,
apertando simultaneamente os botões Windows e
Home.

Agora, com o Windows 7, cada item na barra de
tarefas é associado a um número. O mais perto do
botão iniciar é o 1. O item logo em seguida é o 2,
e assim sucessivamente. Se você apertar a tecla
Windows + algum número, aquele programa vai para o
primeiro plano. Já a combinação Windows + Shift +
algum número vai executar uma nova janela daquela
aplicação. Windows + T e você percorre pelos itens
da barra de tarefas. E se você tem problemas com
letras pequenininhas, experimente Windows e a
tecla +. O zoom digital aproxima a região onde o
mouse estiver repousado. Para voltar ao zoom
original, é só apertar Windows e a tecla -.

Veja logo abaixo uma lista com outras dicas de
como utilizar a tecla Windows:

Win+Home: Deixa aberta apenas a janela ativa
Win+Space: Todas as janelas ficam transparentes, e
o usuário consegue enxergar o desktop
Win+Seta para cima: Maximiza a janela atual
Shift+Win+Seta para cima: Maximiza a janela atual
na posição vertical
Win+Seta para baixo: Minimiza a janela / volta ao
tamanho original se maximizada
Win+seta esquerda / direita: leva a janela para
cada metade da tela
Shift+Win+seta direita / esquerda: Leva a janela
para o monitor da direita ou da esquerda (em caso
de monitor duplo)
Arrastar a janela para o topo: maximiza
Arrastar a janela para a esquerda ou direita: faz
com que ela ocupe metade direita / esquerda da
tela
Chacoalhar a janela com o mouse: minimiza tudo,
menos a janela selecionada
No Windows 7, se você usar a tecla Windows com
algum número, é possível interagir com as
aplicações da taskbar. Por ex: Win + 4 vai abrir o
4. programa, contado da esquerda para a direita.
Windows + Alt + 4 mostra o jumplist do mesmo
aplicativo.
Shift+Win+número (1-9): Abre uma nova janela
daquele aplicativo
Ctrl+Win+número (1-9): Alterna entre as janelas já
abertas daquele aplicativo
Alt+Win+número (1-9): Abre a jumplist daquele
aplicativo
Win+T: Passeia pelos ítens da taskbar
Win+B: mostra os aplicativos da direita da taskbar
Ctrl+Shift+N: Cria uma nova pasta no Windows
Explorer
Alt+Up: Sobe um nível de pastas no Windows
Explorer
Win+(+/-): Zoom in/out
Win+G: Alterna entre os gadgets da sua tela

Read Users' Comments (0)

Estudo de Caso

Estudo de Caso
 Introdução
            A técnica de modelagem de estudo de caso é usada para descrever o que um sistema novo deveria fazer ou qual a função de um sistema já existente. O modelo de estudo de caso é construído através de um processo interativo de discussão entre os desenvolvedores do sistema, e os clientes (e/ou) usuários em busca de uma solução pela qual todos estejam satisfeitos.
            O estudo de caso foi criado por Ivar Jacobson, em 1994, baseado em suas experiências em desenvolvimento do sistema AXE na Ericsson, mais especificamente o OOSE e método Objectory (Veja Histórico). O estudo de casos têm recebido bastante atenção pela comunidade de orientação a objetos, e têm, da mesma forma,  afetado os métodos usados na orientação a objetos.
            Os componentes primários do modelo de estudo de caso  são: os casos, os atores, e os sistemas moldados. O limites do sistema são definidos pela funcionalidade proposta ao sistema. A funcionalidade é representada por um número de estudo de casos, e cada estudo de caso especifica uma funcionalidade completa.quando a funcionalidade está completa, o estudo de caso deve manobrar a função inteira, desde o início, feito por um ator externo, até que ele tenha alcançado a funcionalidade desejada no início. Um estudo de caso deve sempre retornar um valor para o ator, de acordo com o que este ator definiu para o sistema.
            O ator é qualquer entidade externa ao sistema que tenha interação com o sistema. Normalmente, é uma pessoa, um usuário do sistema, mas pode ser, também, outro sistema, ou algum tipo de artifício de um hardware na necessidade de interagir com o sistema.
            Na modelagem de estudo de caso, o sistema é visto como uma "caixa preta" que supre o estudo de caso. Como o sistema faz isso, como os estudo de caso são implementados, ou como eles trabalham internamente, não é o mais importante. Na verdade, quando uma modelagem de estudo de caso é feita no início do projeto, os desenvolvedores não tem idéia de como os casos de uso são implementados.
            Tópicos:    
            Objetivos
            Diagramas de estudo de caso
            Sistemas
            Atores
           Estudo de Caso
                               
   
Objetivos
            Portanto, o importante é saber quais são os propósitos iniciais para o estudo de caso:
  •         Decidir e descrever as funcionalidades exigidas pelo sistema, resultado de um acordo entre o cliente (e/ou usuários finais) e os desenvolvedores de software que estão trabalhando no projeto;
  •         Dar uma visão clara e consistente do que o sistema deve fazer, para tanto o caso de uso é utilizado durante todo o processo para comunicar todos os desenvolvedores os objetivos principais exigidos pelo sistema, e para suprir as bases de uma modelagem gráfica futura do sistema, de acordo com esses objetivos;
  •        Garantir uma base para que testes de verificação do sistema sejam feitos. Certificar que os objetivo iniciais ainda sejam o foco principal do desenvolvimento do sistema.
  •        Providenciar uma habilidade para traçar a funcionalidade requeridas dentro das classes e das operações do sistema. Simplificar mudanças, extensões para o sistema (manutenção), e então, traçar o estudo de caso alterado na interface gráfica e na implementação.
            Todo este trabalho de criação de modelos de estudo de casos envolve a especificação do sistema, conhecimento dos atores e dos usos de casos, descrevendo os usos de caso, e definido o relacionamento entre os casos, e por fim, a validação do modelo.
            O modelo de estudo de casos consiste de diagramas mostrando os atores, os casos e os relacionamentos. Esses diagramas dão uma visão geral do modelo. Mas as principais descrições são tipicamente textuais. Modelos visuais não podem suprir toda a informação necessária para um modelo de estudo de caso, dessa forma, ambos, diagramas e textos são usados.
            O cliente, e o usuário devem estar interessados porque o estudo de caso especifica a funcionalidade do sistema e descreve como o sistema poderá ser usado. É de grande utilidade quando o consumidor participa ativamente do processo de criação de estudo de caso, porque o modelo acaba por se adaptar em detalhes aos desejos, e necessidades do usuário. 
            O modelo de estudo de caso representa a visão do caso de uso do sistema. Esta visão é muito importante, pois influencia todas as outras visões do sistema. Tanto a arquitetura lógica quanto a física são afetadas pelo estudo de caso, pois as funções especificadas no estudo de caso são implementadas nessas arquiteturas.
            A modelagem de estudo de caso não apenas captura as necessidades de um novo sistema, mas também é usada para a geração de novos sistemas a serem desenvolvidos. Quando uma nova geração (versão) do sistema é desenvolvida, uma nova funcionalidade é acrescentada para a extensão do modelo do caso de uso basta adicionar novos atores ou casos, ou modificando as especificações de casos já existentes. No entando, deve se tomar cuidado quando se modifica um caso de uso para uma extensão para que a funcionalidade inicial não seja prejudicada.


Diagramas de estudo de casos
             Um modelo de estudo de caso é descrito em UMl como um diagrama de caso de uso, e este modelo pode ser dividido em vários diagramas de estudo de casos. Um diagrama desses deve conter elementos do modelo para o sistema, os atores, e os estudo de casos, e mostrar diferentes relacionamentos como generalização, associação e dependência entre os elementos.
            A descrição real de diagrama de estudo de caso normalmente contem m texto completo. Em UML, a descrição é tratada como um documentação própria dos elementos de estudo de caso. Essa descrição contém informações vitais para a definição nas necessidades reais da funcionalidade. Como uma alternativa para descrever o estudo de caso em forma de texto, pode-se desenhar o diagrama. Contudo, é importante lembrar que o estudo de caso deve ser facilmente compreendido pelo usuário final, e uma estrutura mais formal como um diagrama ativo, pode intimidar as pessoas a interpretá-lo.
        Veja a Figura



Sistemas
        Como parte da modelagem do estudo de caso, os limites do sistema desenvolvido são definidos. (É importante que se tenha em mente que um sistema não é necessariamente um sistema de software, pode ser uma máquina, ou um negócio). Definir os limites e a todas as responsabilidades do sistema não é sempre fácil, pois não é sempre óbvio quais questões são melhores automatizadas por um sistema que pode ser executado manualmente, ou  por outros sistemas.
        Um sistema em um diagrama de caso de uso é descrito em uma caixa, o nome deve aparecer acima, ou dentro da caixa.


Atores
        Um ator é alguém ou algo que interage com o sistema, é quem o que usa o sistema. Por "interagir com o sistema" queremos dizer que o ator manda e recebe mensagens para e do sistema, ou seja, troca informações. Em suma, atores executam os casos de uso.
        Um ator é um tipo (uma classe), e não uma instância. Ele representa um papel, não um usuário individual do sistema. Essa troca de mensagens com o sistema é bastante similar à programação orientação a objetos, apesar de não serem tão formalmente especificados em um caso de uso. Um caso de uso é sempre inicializado por uma mensagem enviada por um ator, o que chamamos de estímulo. Quando um caso de uso é executado, espera-se que ele envie mensagens para um ou mais atores.
        Atores também podem ser definidos como ativos ou passivos. Um ator ativo é aquele inicializa o estudo de caso, enquanto que o passivo nunca inicia um estudo de caso, mas apenas participa de outros usos de caso. Quando se identifica um ator, está se estabelecendo uma entidade interessada em usar e interagir com o sistema.
       Um ator deve possuir a mesma associação com um ou mais casos de uso. Apesar do ator não ter inicializado o caso de uso, o ator irá em algum momento se comunicar com um. O ator recebe um nome que reflita seu papel no sistema.
        Atores em UML
        Tendo em mente que em UML existem classes com tipos <>, e que o nome da classe é o nome do ator (como dito acima, refletindo seu papel), uma classe ator, como outra qualquer, possui atributos e métodos, bem como documentação própria descrevendo o ator. Uma classe ator possui padrão de  representação que é o "homem palitinho", como o nome do ator abaixo da figura.
           Veja a Figura

       Relacionamento entre Atores
       Como atores são classes, eles tem os mesmos relacionamentos de uma classe normal. No diagrama de caso de uso, apenas relacionamentos de generalização são usados para descrever o comportamento normal entre atores. (Veja Gereneralização)
            Veja a Figura




Estudo de Caso
            Introdução
       Um caso de uso representa uma funcionalidade completa, como percebida pelo ator. Um caso de uso em UML é definido como um série de ações em seqüência que um sistema executa que produzem um resultado de valor notável para o ator. As ações podem envolver comunicação com vários atores (usuários ou sistemas), bem como performar cálculos e trabalhos internos no sistema.
        As características de um estudo de caso são:
  •        Um estudo de caso é sempre iniciado por um ator: é sempre executado em parte por um ator. O ator deve direta ou indiretamente ordenar que o sistema utilize um estudo de caso.
  •        Um estudo de caso devolve um valor ao ator: Um estudo de caso deve enviar algum tipo de valor tangível ao usuário.
  •        Um estudo de caso é completo: um estudo de caso deve possuir uma descrição completa. Um erro comum seria dividir o caso em casos menores que acabam não completando um ao outro. Um caso de uso não está completo até que se acabe o processamento do valor, mesmo que várias comunicações (como o uso de diálogos) sejam necessários ao longo do processo.
        estudo de casos está ligados aos atores através de associações, que são as vezes chamadas de associações de comunicações. As associações mostram qual ator está se comunicando, incluindo o ator que iniciou a execução de caso de uso. A associação é normalmente de um-pra-um, e sem direção. Isso significa que uma instância de ator se comunica com outra instância de estudo de caso, e que isso ocorre nas duas direções. Um estudo de caso recebe o nome de que caso performa.
        Um caso de uso é uma classe, não uma instância. Ele descreve a funcionalidade como um todo, incluindo possibilidades alternativas, erros e exceções que podem ocorrer durante o processo do estudo de caso. Um instanciamento do estudo de caso é chamado de scenario (em português cenário), e ele representa o uso real do sistema (uma execução específica através do sistema)
           Veja a Figura

    
        Estudo de Casos em UML
       Um estudo de caso é representado em UML como ema elipse contendo o seu nome dentro ou abaixo dela. Um caso de uso é geralmente alocado dentro dos limites do sistema, e pode estar ligado a um ator com uma associação ou  uma associação de comunicação que mostra como usar o caso e como o ator interage com ele.
            Veja Figura

        
        Relacionamentos entre Casos de Usos
         Existem 3 tipos de relacionamentos entre casos.
  •         Relacionamento por extensão:  é um tipo de herança, onde um caso de use é uma extensão de outro através da adição de ações do caso geral. O usa da extensão pode incluir o comportamento da classe que está sendo herdada, dependendo das condições de extensão;
  •         Uso de Relacionamento: é outro relacionamento de generalização onde um caso de uso, porém outro estudo de caso indicando que como parte especializada do caso de uso, o comportamento do caso de uso geral (classe mãe), também será incluído;
  •         Agrupamento: quando um número de casos de uso apresentam funcionalidades semelhantes, ou de alguma forma relacionadas, eles podem ser colocados juntos num pacote UML. Um grupo de pacotes relaciona um modelo de elementos, e pode ser expandido ou quebrado, permitindo ao desenvolvedor visualizar um pacote de cada vez. O pacote não possui nenhum outro significado semântico.

        Descrevendo estudo de casos
        Como já foi mencionado  várias vezes, a descrição do estudo de casos é normalmente fetita através de uma descrição textual. Esta é uma forma simples e consistente de especificação de como os atores e os usos de casos (sistemas) interagem. Isso contrasta com o comportamento externo do sistema. A terminologia da linguagem usada na descrição é a mesma da usada por consumidores/usuários do sistema:
        O texto de descrição inclui:
  •             Objetivos para o caso de uso: Quais são os objetivos finais do caso de uso?! O que se quer alcançar?! O estudo de caso é orientado a objetivos, e os os objetivos de cada caso de uso devem aparecer.
  •             Como o estudo de caso é inicilaizado: Que ator inicializa a execução do estudo de caso. E em quais situações.
  •             A fluência das mensagens entre os atores e os casos de uso. Que mensagens ou acontecimentos, o ator do caso de uso troca: atualizada, ou não, e ajuda em outras decisões.
  •             A fluência alternativa no caso de uso: um caso de uso pode ter execuções alternativas dependendo das condições ou exceções. É importante mencionar isso, mas é preciso também ser cauteloso para não descrever em muitos detalhes, já que eles devem escondem a fluência principal da ação no caso geral.
  •             Como um caso de uso termina com um valor para um ator: descrever quando um caso de uso é considerado terminado e que tipo de valor ele retorna ao ator.
         Lembrar-se que a descrição identifica o que é feito de relevante pelo ator externo, e não como as coisas são feitas dentro do sistema. O texto precisa ser claro e consistente para que o consumidor possa entender e validá-lo. Evitar sentenças complicadas que dificultem a interpretação.
         Um caso de uso pode também ser descrito através de um diagrama mostrando a seqüência de atividades, suas ordens e as decisões opcionais que são feitas para indicar que atividade será executada em seguida. 
        Como complemento para o caso de uso descrito, que contém uma completa e geral descrição, um número real de cenários são usados para ilustrar o que acontece, com ambos, os atores e os casos em suas respectivas instâncias definidas. É importante não esquecer que o scenario é apenas um complemento e não um substituto para a descrição do caso.
        Depois que os casos de uso são descritos, uma atividade específica revela se os relacionamentos previamente estabelecidos descritos estão identificados. Os desenvolvedores não tem conhecimento completo para identificar os relacionamentos cabíveis, até que todas as classes estejam descritas, além de ser arriscado o fazer sem essas informações.

Read Users' Comments (0)

Saiba como agir após uma entrevista de emprego

Enviar uma nota de agradecimento, mostrando que entendeu a vaga e a empresa e que está pronto para assumir o desafio, pode fazer diferença.
Em um mercado competitivo, no qual as melhores vagas são muito disputadas, candidatos a emprego devem lançar mão de todos os recursos para causar boa impressão. Nesse contexto, uma das coisas que pode fazer bastante diferença é o envio de uma pequena nota de agradecimento, capaz de demonstrar cordialidade e reafirmar o interesse pela vaga.Esse pequeno gesto, no entanto, não é muito comum, principalmente entre os jovens postulantes às vagas de tecnologia.
De acordo com a gerente geral do grupo de recrutamento Winter, Wyman &Company, Tracy Cashman, esse é um erro que pode fazer a diferença: se o recrutador estiver dividido entre dois candidatos, o recebimento de um agradecimento sincero e bem escrito pesará a favor de quem o enviou. Como esse tipo de ação não é tão comum, pode se tornar uma vantagem competitiva para quem adotar a prática. “Mostra cortesia, interesse pela posição e iniciativa”, afirma Cashman.
Mas, para que a ação seja realmente bem sucedida, Cashman afirma que é necessário seguir algumas regras básicas.
1 – Envie o agradecimento prontamente – Logo após o a entrevista, rascunhe a nota de agradecimento enquanto a conversa ainda está fresca na cabeça e envie no máximo em 24 horas. A nota pode e deve ser enviada por e-mail, que é mais imediato, mas deve seguir regras formais de escrita, como se fosse uma carta em papel.
2 – Seja específico e sucinto – Se a nota de agradecimento passar de três parágrafos, é melhor reduzir. Cashman diz que uma nota muito longa pode não ser lida inteiramente e, de quebra, somar pontos negativos na avaliação de sua habilidade de comunicação.
Mesmo com pouco espaço, é necessário abordar os pontos-chave da conversa, indicando que você teve atenção ao recrutador e ouviu o que ele tem a dizer.
3 – Siga uma estrutura - Cashman recomenda um modelo para uma nota de agradecimento funcional e eficiente. No primeiro parágrafo, expresse sua gratidão pela oportunidade  de saber um pouco mais das estratégias da companhia, desafios e necessidade por equipe.
No segundo, reitere porque você é um bom candidato à vaga, ressaltando que tem as habilidades desejadas e que está pronto a atender aos desafios e oportunidades que lhe foram apresentados. Mostre também que está confiante que a sua experiência trará benefícios para a organização. A meta é mostrar que o candidato entende quais são as necessidades para a posição e que seria a escolha ideal dentro desses requisitos.
No terceiro parágrafo, reforce seu interesse pela posição e pela companhia e coloque-se à disposição para novas conversas.
4 – Não erre na gramática e na ortografia – Assim como no currículo, erros na carta de agradecimento podem causar péssima impressão e provocar efeito contrário ao desejado. Revise quantas vezes for necessário.
5 – Evite o tom de desespero – Outra coisa que pode minar as chances de obter a vaga é escrever expressões que denotem desespero por um emprego.
6 – Não esqueça informações de contato – Com a excitação da entrevista, não é difícil esquecer de pedir as informações de contato do recrutador para que seja possível mandar a nota de agradecimento. Peça o cartão de visita da pessoa que realizou a entrevista ao final da conversa.

Read Users' Comments (0)

10 segredos para solucionar problemas de TI

Atitudes são tão importantes quanto conhecimentos técnicos na hora de resolver indisponibilidades de sistemas e outras questões tecnológicas.

Não importa quão profundo sejam os conhecimentos técnicos de uma equipe. Sem metodologia adequada, a solução de problemas torna-se um processo muito mais complicado.

O CIO da Escola de Medicina da Harvard e de um dos maiores grupos de assistência médica dos EUA, John Halamka, baseou-se em sua experiência para elaborar uma lista com os 10 principais segredos para resolver problemas com rapidez e experiência.

1 – Uma vez que algum problema foi identificado, verifique seu real alcance – O software de monitoramento pode até dizer que tudo está bem, mas é bom não se conformar. O ideal é conversar com os usuários, testar a aplicação ou a infraestrutura sozinho e ter certeza sobre a origem de qualquer reclamação.

2 – Quando o alcance do problema é muito grande e a raiz ainda é desconhecida, acione um plano de emergência – É muito melhor mobilizar toda a equipe para um falso alarme ocasional do que intervir tarde demais e quando o problema alcançar proporções muito grandes com uma resposta lenta do departamento de TI.

3 – O processo de solução de um problema deve ser visível, atualizado constantemente para todos e participativo – Muitas vezes os profissionais técnicos ficam tão focados em suas tarefas diárias que perdem a noção do tempo, não se atualizam mutuamente e deixam de conversar com outras áreas. A companhia deve ter uma abordagem multidisciplinar, com relatórios de progressos pré-determinados para prevenir, isolar o problema e buscar soluções com maiores chances de acerto.

4 – Mesmo com a rotina de atualizações e relatórios, a equipe deve ficar livre para trabalhar – Alguns líderes de TI gostam de retornos constantes de sua equipe e isso não é necessariamente ruim. Mas se a equipe gastar 90% do seu tempo reportando o status do trabalho, fica muito mais difícil solucionar problemas em prazo razoável.

5 – A explicação mais simples geralmente é a correta – Halamka relata que, em um incidente recente em sua corporação, todas as evidências apontaram para o mal-funcionamento em um componente do firewall. Mas todos as ferramentas de testes e diagnósticos indicavam que o firewall funcionava perfeitamente. Alguns levantaram a hipótese de que a empresa sofria um tipo muito específico de ataque de negação de serviços. Outros aventaram a possibilidade de uma falha em componentes das redes Windows dos servidores. Surgiu ainda a possibilidade de um ataque incomum por vírus. A explicação mais simples, do firewall, foi comprovada correta após sua remoção da infraestrutura da rede. E, segundo Halamka, a regra da explicação mais simples ser a resposta, até mesmo para problemas mais complexos, é verdadeira na maioria das vezes.

6 – Os prazos devem ser definidos de maneira responsável – O que mais irrita os usuários não é exatamente a demora, mas a definição de prazos imprecisos e os consequentes pedidos de “só mais uma hora para resolver o problema”. Se uma indisponibilidade de sistema ocorrer por conta de uma mudança planejada de infraestrutura, a questão é ainda mais séria: o melhor a fazer é definir um prazo preciso e respeitá-lo.

7 – Comunique-se com os usuários o máximo possível – A maioria dos stakeholders da empresa estão dispostos a tolerar indisponibilidade se você explicar exatamente as ações que estão sendo tomadas para restaurar o serviço. Os principais executivos de TI são os maiores alvos dessa dica, pois devem mostrar compromisso, presença e liderança.

8 – Orgulho não deve atrapalhar a solução – É difícil assumir erros e desafiador reconhecer o que não se sabe. Mas em vez de gastar tempo procurando culpados por problemas, o foco deve ser em examinar a raiz da indisponibilidade e depois definir processos para prevenir a repetição dos problemas.

9 – Não cante vitória antes do tempo – É tentador presumir que os problemas foram resolvidos e dizer a todos os usuários sobre a suposta vitória. Mas o melhor é esperar 24 horas seguidas de serviços ininterruptos antes de declarar o problema resolvido.

10 – Líderes de TI devem focar na sua trajetória, não em sua posição cotidiana – Indisponibilidades podem causar diversas emoções, como ansiedade, medo de perder o emprego ou a reputação e tristeza pelo impacto causado nos usuários. Nessas horas, a melhor coisa é ter em mente que o tempo é capaz de curar qualquer coisa e que incidentes eventuais serão esquecidos. Com o passar da trajetória profissional, a comunidade de usuários tende a observar mais a consistência e o processo contínuo de melhoria de qualidade do que episódios isolados.

De uma forma geral, problemas são dolorosos, mas capazes de unir pessoas. Nos piores momentos é que se constrói relações de confiança, criação de novos canais de comunicação e melhoria de processos.

Read Users' Comments (0)

html5

Alguns detalhes ainda serão decididos, mas muitos recursos - e os browsers que os usam - estão aí.

Muito tem sido divulgado sobre a HTML5 e sobre as especificações da nova versão da linguagem padrão da web. Agora chega a boa notícia: você pode começar a usar a HTML5 já, a partir de agora. E não é pouca coisa que você pode fazer.

Há algumas informações que você precisa definir antes de sair alucinadamente escrevendo aquela página ultralegal.

Para quem você escreve?
Se a maioria da audiência do site para o qual você escreve ainda usa o IE6, pode ir tirando o bloco de notas da área de trabalho. Mas, caso quem acessa o site use predominantemente produtos da linha iPad e iPhone, é chegada a sua hora de mandar ver na HTML5. Páginas de audiência mista – como a maioria delas é – devem seguir linhas de aproximação menos radicais à nova linguagem.

Já, agora, Now!
Apesar de as especificações da HTML5 ainda estarem no forno, em desenvolvimento por comitês na busca por padrões, boa parte do suporte à versão 5 da HyperText Markup Language já é nativa em navegadores como Safari, Chrome, Firefox e Opera. 

Assim que for lançada, a versão 9 do IE deverá apresentar suporte robusto ao HTML5. Uma excelente fonte de informações sobre como e quando usar os recursos da HTML5 podem ser encontrados emhttp://caniuse.com. O endereço fornece detalhes minuciosos sobre o uso e o suporte de vários browsers.

Browser Securitiy Deep Dive
No endereço http://html5test.com, programadores interessados podem verificar como anda a integração entre os navegadores mais usados e a HTML5. Para ver que tipo de suporte é oferecido, o internauta deve acessar esse site usando sempre o browser que pretende colocar à prova. Para cada navegador o site emite um score, uma nota. Em 12/6, os scores eram:

Materia completa:

http://idgnow.uol.com.br/internet/2010/07/12/html5-por-que-voce-pode-usa-la-ja/
--

Cleiton vogel

33-8815-6055
33-3523-4141

Read Users' Comments (0)

Dez fatores essenciais ao sucesso dos projetos

FONTE>>>Computerworld

Alguns dos fatores mencionados são óbvios, outros nem tanto. Acompanhe os principais itens discutidos:

1. Defina sucesso

Os profissionais só vão atingir o sucesso se souberem exatamente o que é esperado deles. O gerente de projetos globais da empresa Integra LIfeSciences, Steve Hawthorne, diz que é indispensável saber quais os objetivos de um projeto.

“É comum para nós, profissionais de TI, definirmos sucesso como a junção de metas, necessidade e orçamento atendidos”, diz. O executivo ainda afirma que, sim, esses são pontos importantes em um projeto. Mas vale lembrar que compreender a influência desses quesitos para a empresa é igualmente importante. Em outras palavras: saiba o quê, mas tente saber também por quê.

2. Popularidade não é tudo

Consultora de TI e líder de projetos, Bronnie Brooks, diz que, por várias vezes já teve de tomar decisões que a fizeram pouco popular entre os clientes, a gerência ou, mesmo, a equipe. Tudo isso para manter um projeto andando e atingir os resultados esperados. Em uma ocasião, por exemplo, teve de informar ao cliente que determinado recurso – esperado para o software encomendado – não poderia ser integrado ainda. O usuário teria de esperar pacientemente até o lançamento da versão seguinte.

Tomar decisões difíceis sobre onde alocar recursos no meio do andamento de projetos é, no mínimo, difícil. Gerentes de projetos também querem ser queridos, ao passo em que respondem pelo sucesso das empreitadas. Mesmo assim, não podem recuar ante a decisões críticas.



“Às vezes, a melhor decisão não é a mais popular”, diz Brooks, que emenda “mas é o que vai garantir que a projeto ande equilibrando a relação entre o esperado e o possível”.



3. Capacitar o usuário final e acompanhar o start-up

Uma questão óbvia ao sucesso do projeto é treinar os usuários para utilização das soluções. Em muitos casos, porém, a implementação de sistemas falha, não em função de entrega fora do prazo ou por estourar o orçamento, mas porque as pessoas não foram adequadamente treinadas.

“Quando a questão é aprimorar o uso do software, não existe “demais”. Certamente a maioria das soluções novas dão errado, por conta de usuários mal treinados”, afirma um gerente de TI, durante o encontro de CIOs realizado na Espanha.

4. Estabelecer atribuições e competências – de maneira clara e objetiva

Não é raro que pessoas envolvidas em um projeto, como gerentes, equipe de TI, comitês e patrocinadores não entendam exatamente quais são as atribuições individuais. Isso se dá em função da falta de esclarecimento prévio. A afirmação é do auditor de TI pertencente ao The Wood Group, Chet Ung.

Se, por exemplo, o comitê de gestão de um determinado projeto não souber qual a função dentro do projeto, jamais saberá o que é esperado dele. As pessoas têm o poder de mudar o rumo do projeto, e, nem sempre sabem disso. A conseqüência é uma contribuição deficiente, causada pela falta de informação.

“Atribuições e competências precisam ser claramente definidos e documentados. É a única maneira de evitar a confusão e de alcançar o nível de contribuição esperado de cada membro do projeto”, esclarece Ung.

5. Fluxo de trabalho transparente

“Fluxos claros de trabalho não deixam espaço para as pessoas duvidarem qual o espaço em que estão exatamente alocadas dentro da dinâmica do processo; o que vem antes e para onde vai aquilo no que estão envolvidas no momento”, diz a presidente da empresa norte-americana ProjectExperts, Stacy Goff.

Clareza no fluxo dos processos é um componente essencial quando o objetivo é gerar economia e incrementar qualitativamente todo o projeto. “Nada se compara à segurança de saber que o trabalho está sendo feito por pessoas capacitadas, e que haverá poucas correções a serem feitas naquilo que chega na escrivaninha ou na caixa de entrada. Quando sabe-se que o próximo a receber aquilo no que estamos trabalhando é alguém dedicado e com olhos perfeccionistas, costumamos nos esmerar em nossa tarefas”, diz Goff.

6. Gerenciar alterações no escopo de projetos

É comum que usuários finais de sistemas em desenvolvimento queiram implementar mudanças e alterar algumas nuances nas soluções. Mal sabem que alterações, mesmo que pareçam mínimas, podem ocasionar em modificações brutais no esquema do projeto, influenciando tanto em custo quanto em prazo para a entrega.

Acontece que, nem sempre, o gerente de projetos consegue entender a profundidade da alteração que três botõezinhos a mais na interface do sistema ocasiona no trabalho. “Essa falta de noção é especialmente acentuada nos casos de consultorias externas”, afirma o fundador da empresa de consultoria e de gerência de projetos Spivey & Co., Chris Spivey. Na tentativa de agradar a gregos e a troianos, a gerência de projetos, muitas vezes, aceita a inlcusão dos três botões no sistema. Quando são informados pelo departamento de design técnico que essa implementação vai custar ao projeto alguns preciosos meses de trabalho extra, a casa, literalmente, cai.

É essencial dispor de um processo para gerir mudanças em projetos que estejam em andamento. Nesse gerenciamento devem ser integrados os recursos de aprovação e veto às mudanças, avaliação do prazo exigido pelas alterações e definição de custos dos incidentes. De posse de rotinas dessa natureza, um gerente de projetos pode definir a profundidade do impacto de algumas mudanças caso a caso.

Também oferece ao cliente a oportunidade de reavaliar a necessidade da implementação dos três botões na interface.

Menos surpresa, mais eficiência.

7. Gerenciamento de risco

“A gestão de riscos é, sem a menor sombra de dúvidas, parte essencial de qualquer projeto, independentemente do tamanho”, afirma Goff, da ProjectExperts. De acordo com o profissional, o gerenciamento deve estar integrado em todas as etapas, de concepção a início até o dia do lançamento.

O que torna o gerenciamento de riscos vantajoso é o fato de oferecer ao gestor do projeto uma perspectiva do que pode dar errado. Também vale para deixar a equipe de desenvolvimento, o cliente e os demais envolvidos, esclarecidos acerca dos detalhes e do ritmo a ser adotado para a execução dos trabalhos.

8. Documentação apropriada

Sem a documentação, as equipes podem não entender de maneira adequada quais funcionalidades e requerimentos técnicos estão atrelados aos recursos planejados para a configuração da solução em desenvolvimento. A ausência da documentação detalhada também implica em um desperdicio de tempo e de recursos na tentativa de acomodar as expectativas do cliente.

É um riso enorme para a equipe, dar andamento em projetos sem embasamento documentado e as metas esclarecidas.

A habilidade de evitar confusão é, para Ung, um dos fatores que justificam a implementação de documentos referentes à execução dos projetos.

9. Controle de qualidade eficiente

Esforços para aferir a qualidade são aplicáveis nas instâncias de integração, de funcionalidade e em ensaios de stress. Não recebem a atenção devida, pelo fato da gerência de projetos não estar familiarizada com esse recurso, nem com suas diferentes vertentes. Em outros casos, à análise de qualidade é dedicado menos tempo do que o necessário em função do ganho de tempo. A despeito do motivo, o resultado é sempre o mesmo: um software ou um hardware defeituosos – mais trabalho – menos satisfação.

“Ter um acompanhamento de qualidade eficiente é essencial”, diz Ung. “É a única maneira de garantir a entrega de uma solução de acordo com o encomendado”, afirma.

O CTO da Richard Ivey School of Business, Peter Scheyen, recomenda execução de análises de qualidade em todas etapas, e o envio de versões de teste para os clientes. “Obter deles (usuários finais) um feedback sobre o programa é algo muito precioso, é uma das maneiras mais eficientes de reduzir o eventual risco do projeto não estar saindo de acordo com o esperado na outra ponta”, finaliza o profissional da escola londrina.

10. Governança

Segundo Ung, a governança será responsável pela definição dos moldes dentro dos quais um projeto ou um programa devem ser gerenciados. “Ela também define a “linguagem” usada no desenvolvimento das soluções”, adiciona Ung. “Com uma boa governança, o trabalho flui de maneira mais harmoniosa, mais eficiente”, diz.

Ausente, a governança dá ao projeto um ar de inconsistente, pouco confiável. A equipe de desenvolvimento, por exemplo, poderá trabalhar de acordo com um molde, enquanto os analistas de negócios trabalham com outras referências, levando o projeto inteiro de encontro ao fracasso.

Read Users' Comments (0)

Ativando o xp

Como validar o Windows XP Profissional – Deixar o Windows Original
Siga o tutorial abaixo e valide seu Windows, deixe ele como um original.

1. Vá em Iniciar > Executar

2. Digite regedit e clique em OK.

3. Já dentro do regedit, navegue até a chave: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\Cu rrentVersion\WPAEvents

4. No painel à direita, clique duas vezes em OOBETimer

5. Na janela que foi aberta, apague qualquer valor e clique em OK. Feche o regedit

6. Vá novamente em Iniciar > Executar e dessa vez digite:
%systemroot%\system32\oobe\msoobe.exe /a

7. Na janela que foi aberta, escolha a opção Sim, desejo telefonar…

8. Na próxima etapa, clique no botão Alterar chave de produto.

9. Na etapa seguinte, digite a CD-Key:

THMPV-77D6F-94376-8HGKG-VRDRQ
ou
Q6TD9-9FMQ3-FRVF4-VPF7Y-38JV3

e clique no botão Atualizar

10. Após clicar no botão Atualizar, o assistente para ativação voltará para a janela anterior, então, clique em Lembrar mais tarde e reinicie o Windows.

11. Reiniciado o Windows vá novamente em Iniciar > Executar e digite:
%systemroot%\system32\oobe\msoobe.exe /a

12. Aparecerá a seguinte mensagem:
O windows já está ativado.

Read Users' Comments (0)

Zarafa

Zarafa é uma solução de groupware que fornece a conectividade de um servidor baseado em Linux com o cliente Outlook, usando o padrão MAPI. Por ser uma solução licenciada em AGPL, utiliza como base uma arquitetura open source, como o Apache, Mysql e PHP.
Usa como MTA serviços reconhecido no mercado pela sua estabilidade de confiabilidade. O Postfix, Sendmail e o Qmail fazem parte dos serviços de MTA's homologados pela solução.

Possui ferramentas que tornam a migração do MS-Exchange fácil e confiável. A integração com o Active Directory e LDAP é completa e 100% funcional. Segurança, confiabilidade, mobilidade e o melhor custo benefício fazem do Zarafa a solução número 1 em e-mail e calendário open source.

Zarafa é uma palavra árabe que significa girafa. E, como uma girafa, a Zarafa tem uma visão do mercado para outras aplicações de colaboração em uma direção amigável e aberta.

Principais recursos

Uso amigável do Webaccess com a tecnologia AJAX Zarafa - Disponibiliza todas as funcionalidades de um webaccess com um "look & feel" Outlook. Inclui acesso aos e-mails, multi-calendários, contatos, tarefas, pastas compartilhadas e pastas públicas. A implementação do AJAX com o drag & drop proporciona uma facilidade a mais. Existe suporte em várias línguas, inclusive o português do Brasil;
Suporte a todas as versões do Outlook - A arquitetura do Zarafa é completamente baseada no padrão MAPI, havendo uma integração estável com o Outlook. Todas as versões do Outlook desde 2000 até a última de 2007 são completamente suportadas. Outros clientes podem conectar ao Zarafa via POP3, IMAP e iCalendar;
Backup - Utilizando o Zarafa Brick Level Backup é possível realizar backup de caixas de e-mails individualmente;
Restore - Utilizando a ferramenta Zarafa Restore, é facil recuperar apenas um item, uma pasta ou mesmo uma caixa de e-mail completa. O Brick Level Backup pode ser usado também para as pastas públicas;
Single Sing On - Ao realizar o login no seu domínio via autenticação Single Sing On ntlm, todas as credenciais configuradas do usuários serão usadas no seu cliente Outlook;
Mobilidade - Zarafa suporta uma vasta gama de celulares e PDA's que possuem o suporte ao Activesync. Através do projeto open source Z-Push, é possível sincronizar e-mails, contatos, calendários e tarefas em tempo real. Nas versões Professional e Enterprise existe nativamente o suporte ao serviço BES (BlackBerry Enterprise Server); com isso, o sincronismo entre as funcionalidades do seu BlackBerry e o servidor Zarafa é realizado em tempo real.

Read Users' Comments (1)comentários

ECM-GED

ECM (Enterprise Content Management) é a sigla introduzida pela AIIM em 2000 pela qual o GED (Gerenciamento Eletrônico de Documentos) é conhecido mundialmente.
GED é como o Gerenciamento Eletrônico de Documentos ficou conhecido no Brasil, e engloba o conjunto de tecnologias voltadas para a gestão de documentos eletrônicos. Deve-se entender por documento eletrônico qualquer tipo de documento (planilhas, cartas, plantas) já em formato eletrônico e, claro, imagens.
O ECM-GED cobre toda a operação referente ao ciclo de vida de um dado, documento ou informação, desde sua captação até a sua preservação, porém, relacionando essas etapas aos processos de negócios do front (CRM - gestão de relacionamento com o cliente, comércio eletrônico etc.) ao back-office (ERP, bancos de dados legados, processamento de pedidos etc.).

O universo ECM-GED é muito abrangente e engloba outros conceitos e tecnologias tais como:
Document Imaging (OCR-ICR, Indexação, Tratamento de Imagens, Digitalização)
Document Management
ERM-COLD
EDM
Full Text Retrieve
Armazenamento
Image Enable
O ciclo ECM-GED

Atualmente ECM-GED organiza a visão da informação dentro das empresas segundo o seguinte ciclo:

Captação

Indexação: criação de metadados, palavras-chave ou texto completo, a partir de documentos digitalizados, de modo que o documento possa ser encontrado posteriormente. Conheça o Converge Production Scan, Converge Personal Scan

Categorização / Taxonomia

Taxonomia: automatiza a classificação do conteúdo (imagens de documentos, e-mail, documentos em texto, etc), segundo as necessidades individuais de uma empresa. Conheça o Converge Production Scan, Pré-index e Pós-Index

Reconhecimento: tecnologias que tornam possível que informações em papel sejam transformadas em dados eletrônicos sem entrada manual de dados, como OCR (Reconhecimento Ótico de Caracteres), ICR (Reconhecimento Inteligente de Caracteres) e Reconhecimento de Códigos de Barras. Convertem grandes quantidades de formulários ou dados não-estruturados em informação utilizável em um sistema de gerenciamento de conteúdo. Conheça o Converge Production Scan, Converge AutoTask

Document Imaging

O Software capta a imagem do documento em papel ou captura documentos já em formato eletrônico.

Os sistemas de Document Imaging (DI) substituem o método tradicional de arquivamento em pastas onde, através de índices, se recupera a imagem do documento digitalizado.

Processamento de Formulários

Os formulários da empresa são inseridos no sistema. Atualmente, a maioria dos formulários são estruturados, a localização dos elementos dos formulários é conhecida. A capacidade de processar formulários não-estruturados, aqueles sem um template de formulário predefinido, está melhorando. Converge AutoTask

Digitalização

O papel geralmente entra em uma empresa por meio de um scanner, ou, algumas vezes, de um equipamento multifuncional. Em operações de digitalização centralizadas, grandes volumes de papel são colocados no sistema por profissionais especializados. Em operações distribuídas, pequenos volumes de documentos são capturados com escaners de baixo volume ou equipamentos multifuncionais mais próximo de seu ponto de criação. Conheça o Converge Production Scan, Converge Personal Scan, Converge AutoTask

Conteúdo e Documentos

O conteúdo não-estruturado entra na infra-estrutura de TI de uma empresa a partir de uma variedade de fontes. Independente da maneira pela qual um fragmento de conteúdo entra, ele tem um ciclo de vida. Acompanhe um documento ao longo de seu ciclo de vida como visto pelo uso da tecnologia de ECM.
Dados eletrônicos Não-estruturados - e-mail, mensagem instantânea, documento de texto, planilha, etc.
Formulários eletrônicos
Documentos e formulários em papel.
Gerenciamento
Gerenciamento de Conteúdo na WEB (WCM)
A tecnologia de Gerenciamento de conteúdo da WEB se volta para os processos de criação de conteúdo, revisão, aprovação e publicação de conteúdo baseado na web. As principais funcionalidades incluem ferramentas de criação e autoria ou integrações, desenvolvimento e gerenciamento de template para apresentação e informação, gerenciamento de reutilização de conteúdo e recursos de publicação dinâmica.

Gestão de Ativos Digitais (DAM)

Similar em funcionalidade ao Document Management, a gestão de ativos digitais é focada no armazenamento, rastreamento e uso de documentos em rich media (vídeo, logotipos, fotografias, etc.). As bases da tecnologia estão nas indústrias da mídia e do entretenimento, atualmente em crescimento, especialmente em departamentos de marketing. Os ativos digitais geralmente têm um alto valor de propriedade intelectual.

Gerenciamento de e-mail

Remover e-mails do servidor e os salvar em um repositório não é suficiente enquanto padrão para comunicações empresariais. Os e-mails devem ser classificados, armazenados e apagados em consonância com padrões empresariais, como qualquer outro documento ou registro.

Gestão Documental (Records Management)

Conteúdo ou valores empresariais de longo prazo são considerados registros e gerenciados de acordo com uma tabela de temporalidade que determina por quanto tempo um registro será mantido com base em regulamentações externas ou práticas de negócio internas. Qualquer fragmento de conteúdo pode ser definido como um registro.

Document Management

A tecnologia de Document Management ajuda as empresas a gerenciar melhor a criação, revisão, aprovação e destruição de documentos eletrônicos. Proporciona funcionalidades essenciais como serviços de biblioteca, definição de perfil de documento, busca, check-in, check-out, controle de versão, histórico de revisão e segurança de documentos.

Colaboração

Tecnologias de colaboração permitem aos usuários individuais, tais como empregados ou parceiros comerciais, criar e manter facilmente equipes de projeto, independentemente de sua localização geográfica. Essas tecnologias facilitam a criação colaborativa de conteúdo, baseada no trabalho em equipe, e a tomada de decisões.

Gerenciamento de Processos (BPM) / Workflow

Soluções de BPM - Business Process Management caracterizam-se por ambientes de trabalho que podem ser utilizados para desenvolver, implantar, monitorar e otimizar múltiplos tipos de aplicações de automação de processo, inclusive processos que envolvem sistemas como pessoas. Considere quais processos são candidatos à automação e se requerem algum grau de processamento específico ou intervenção manual.

Soluções de Workflow, atualmente, estão associadas aos processos manuais de gerenciamento de documentos. Executa aprovações e prioriza a ordem de apresentação de documentos. No caso de exceções, também transfere as decisões para a próxima pessoa na hierarquia. Essas decisões são baseadas em regras predefinidas, desenvolvidas pelos proprietários do sistema.

Segurança

Restringe o acesso ao conteúdo, tanto durante sua criação e gerenciamento, como quando de sua disponibilização.
Gestão de direitos digitais - impede a distribuição ilegal de direitos ao conteúdo gerenciado, restringindo o acesso ao conteúdo ao nível de frases, bem como atribuindo ou restringindo permissões para acesso ao conteúdo e seu envio.
Assinatura Digital - Garante a identidade do remetente do documento e a autenticidade da mensagem.
PKI (Infra-estrutura de chaves públicas) - Utiliza um par de chaves pública e privada mantido por uma autoridade certificada, ou certificadora digital, para fazer negócios na Internet Pública.


Armazenamento

O Conteúdo precisa morar em algum lugar. As tecnologias de armazenamento (discos óticos, magnéticos, fitas, microfilme, RAID, papel) proporcionam opções para armazenamento de conteúdo on-line para acesso rápido ou quase imediato, ou off-line para conteúdo que não necessite de acesso freqüente.
Repositórios (Estruturado e não-estruturado) - É a essência de muitos sistemas de ECM, onde residem os dados e grande parte dos investimentos de uma empresa em ECM. Um repositório pode ser um sistema sofisticado de centenas de milhares de dólares, ou tão simples quanto um sistema de pastas de arquivos em uma pequena empresa. A chave é ter informações que possam ser encontradas uma vez que tenham sido inseridas no sistema.
Preservação
Arquivamento de Longo Prazo - O conteúdo que precisa ser preservado durante décadas deve ser salvo em mídia como papel e imagem baseada em microfilme, com longevidade compatível.
Migração - A medida que a mídia de armazenamento envelhece, o conteúdo precisa ser transferido para uma nova mídia para que possa continuar a ser acessado.
Back up / Recuperação - Salvar o conteúdo em vários formatos e/ou locais ajuda a garantir a viabilidade do negócio em caso de desastre.
Integração de Conteúdo (Content Integration) - Torna possível que fontes de conteúdo muito diferentes pareçam e atuem com um único repositório.
Disponibilização
Busca e Recuperação - Um dos maiores benefícios de um sistema de ECM eficaz é a capacidade de recuperar o que foi inserido nele. Possuindo serviços eficientes de indexação, taxonomia e repositório, será muito fácil localizar a informação em seu sistema.
Associação (Syndication) - Distribuição de conteúdo para reutilização e integração em outro conteúdo.
Localização (Localization) - Reformulação de conteúdo com base nas necessidades e costumes culturais dos diferentes mercados globais.
Personalização - Recorrendo à taxonomia e se baseando nas preferências já estabelecidas pelo usuário, vários tipos e objetos de conteúdo podem ser disponibilizados por meio das preferências definidas pelo próprio usuário.
Publicação - O conteúdo chega onde e para quem é necessário por meio de inúmeras ferramentas. O conteúdo pode ser disponibilizados impresso, por e-mail, em websites, portais, mensagens de texto.
Papel
Eletrônica - Portais, Intranet, Extranet, e-Mail e fax.

Read Users' Comments (0)