quarta-feira, maio 31, 2006

Seu e-mail foi premiado!

Olha que cara de pau! Esse foi o e-mai lque recebi. Vamos brincar de jogo dos 7 (ou mais) erros:

PROMOÇÃO , 2 EM 1 !!!
VOCE GANHA UMA CAIXA POSTAL VIRTUAL GRATIS E AINDA CONCORRE A 1 DVD POR SEMANA.

VOCE LIGA PARA 21-7818-7859 , TECLE A OPÇÃO 4 ,SERVIÇOS DE ENCONTROS
CASO VOCE NÃO TENHA UMA CAIXA POSTAL VIRTUAL NOSSA , DEVERÁ SE CADASTRAR ,
É GRATIS , APÓS ISSO MANDE O NUMERO DE SUA CAIXA POSTAL PARA
O E-MAIL hcralmeida52@terra.com.br, E COMCORRA A UM DVD POR SEMANA, LIGUE JÁ !!!

FONE- 21-7818-7859 E TECLE 4 E BOA SORTE !!!
vÁLIDO PARA TODO BRASIL

  • Não coloquei aqui, mas o e-mail (From) é do Hotmail.
  • Premiado por quem?
  • Caixa Postal Virtual?
  • Ligar para um celular do Rio de Janeiro.
  • Se não tiver caixa postal com eles, devo me cadastrar (grátis) e mandar o número para um e-mail nada com nada do Terra.
  • Falta concordância e na última linha o "v" está em minúsculo.
  • Sem formatação, caixa alta o e-mail inteiro (dificulta a leitura), ...
Bom... será que alguém telefona? Acho que sim.... Estou pensando em ligar só para ver qual é... Não, é melhor não... hoje em dia não se sabe nada, né?
Não caia nessas, ok?

Abraço!

segunda-feira, maio 29, 2006

Requisitos - Aula 1

Galera,

Eu entrei no grupo de requisitos do meu setor e, por causa da certificação, temos que bolar aulas e resumos para o resto do pessoal, assim como os membros dos grupos de projeto, qualidade, condiguração e etc. Segue abaixo o resumo da aula 1 de requisitos. Espero que aproveitem, pois está bem compacto, com exemplos e não cansa a leitura.
O resumo dessa aula foi feito pelo meu colega e xará Daniel, baseando-se em apresentações usadas nos mini-treinamentos.


Resumo Requisitos – Aula 1


Norma

A norma estabelece a base, define as regras do que deve ser feito para realizar ou avaliar as atividades.
Ela está relacionada com o compromisso assumido pela organização para se atingir as metas para a certificação envolvendo o estabelecimento de políticas e patrocínio da alta gerência.
A norma diz o que deve ser feito e não como ser feito, sendo assim a Norma não é um processo.
Existe uma norma para cada área chave de processo e, no geral, está dividida em finalidade, âmbito de aplicação, conceituação e determinação. A norma pode ser encontrada no site do XXX (processo) (item Normas e Padrões) ou no sistema de normas.

XXX (processo)

O XXX é o processo de desenvolvimento que possui a seqüência de ações (atividades e subatividades) que devemos realizar. O XXX segue o que foi determinado na Norma, dando ação às suas determinações.

Requisitos

Os requisitos expressão as características e restrições do produto de software do ponto de vista da satisfação do usuário. Geralmente independe da tecnologia aplicada na implementação da solução.
Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessárias que o software deve possuir para que o usuário possa resolver um problema, atingir um objetivo, atender as necessidades, restrições da organização ou dos outros componentes do sistema.

Classificação dos Requisitos

Os requisitos são classificados como requisitos funcionais e não funcionais.

Os requisitos funcionais descrevem a funcionalidade que se espera que o sistema realize, como ele se comportará com as entradas particulares e em situações especificas.

Ex: Para um sistema de biblioteca
  • Permitir a consulta na base por parte do usuário;
  • Realizar a reserva de uma obra emprestada;
  • Efetuar o empréstimo de obras para clientes cadastrados;
  • Efetuar cadastro de novos usuários;

Os requisitos não funcionais são as qualidades gerais do sistema ou parte dele, não descrevendo uma funcionalidade do sistema, mas é de grande importância, pois possui informações de como o sistema foi feito, como será o seu funcionamento, etc.
São requisitos não funcionais: requisito de desempenho, requisito de espaço, requisito de confiabilidade, requisito de portabilidade, requisitos de padrões utilizados no desenvolvimento, entre outros.
Ex: Para o sistema de biblioteca
  • O sistema deverá responder uma solicitação em até 20 segundos;
  • A base de dados deverá ser protegida de acessos não autorizados;
  • O sistema deverá rodar sobre o sistema operacional Windows;
  • O processo de desenvolvimento adotado será o XXX (processo);
  • O sistema estará disponível de segunda a sábado, das 08:00 às 22:00 horas;
  • O backup da base será feito diariamente às 02:00 horas;

Engenharia de Requisitos

Elicitar

A elicitação é a fase da descoberta dos requisitos para um sistema através da conversa com o cliente, usuários finais e demais partes interessadas do sistema.
Pode-se elicitar os requisitos utilizando-se questionários, entrevistas, documentações, brainstorming, prototipação, além de outras técnicas para descobrir os requisitos.
Por exemplo: Em conversa com o cliente, utilizando as leis vigentes e/ou outros métodos coleta as informações importantes do que o sistema deverá fazer, o que o usuário do sistema espera encontrar quando for usar o sistema.
Para ficar mais prático, o nosso cliente quer bloquear um usuário que infligiu as regras da biblioteca, o usuário espera encontrar no sistema a possibilidade de digitar o motivo do bloqueio e para ter certeza de que seja a pessoa certa, o sistema deverá trazer informações relevantes como nome, CPF, endereço.
Em uma conversa com o cliente essas informações são levantadas e anotadas informalmente para posterior análise.

Analisar

A análise têm como objetivo identificar possíveis problemas na declaração informal. Utiliza-se a lista de verificação para realizar a análise. Esse é o primeiro momento de se verificar se o que foi elecitado está consistente, foi entendido, podendo assim continuar o ciclo.
Utilizando o exemplo da elicitação, o analista de requisitos revê as anotações informais feitas na elicitação e utilizando-se da sua experiência ou com auxilio de outras pessoas experientes busca por falhas no encadeamento das idéias levantados, oportunidades de melhoria, buscando o entendimento mais claro possível do que o cliente quer.
Quando há imperfeições volta-se para a fase de elicitação para buscar novas informações corrigindo assim ambigüidades ou falhas ou adicionando informações importantes ao entendimento do problema/solução.
Depois disso feito chega-se a hora de documentar todo o levantamento feito de maneira formal.

Documentar

Depois da análise dos requisitos, deve ser feita a documentação que têm como objetivo registrar de forma entendivel por todos os envolvidos, uma vez que servirá de contrato entre usuários e desenvolvedores e as informações nele contidas serão utilizadas nas demais fases do projeto.
No exemplo, o analista de requisitos com as informações analisadas em mãos documenta essas informações escrevendo os passos necessários para a resolução, as regras que o sistema deverá comprir para atender, as informações de desempenho, de horário que o sistema deverá atender, casos para teste, entre outras informações.

Negociação e Priorização

É realizada a negociação com os usuários a fim de priorizar os requisitos e estimular marcos de entregas.
Para a priorização é importante que os riscos e complexidades sejam vistos a fim de não haver problemas com as previsões.
Utilizando o exemplo, o cliente quer um módulo para consultar e o outro de bloquear. Nesse momento pode-se negociar com o cliente para a fim de montar o que entregar primeiro, o que é mais emergêncial, a fim de priorizar os esforços de criação.

Revisar

A revisão é de suma importância para avaliarmos se o que está sendo elaborado está consistente com as necessidades do usuário.
A revisão é feita com a equipe e com o GQS, depois disso, os requisitos são mandados ao cliente que faz a verificação que fica registrada no termo de aceite.
Estando os requisitos revisados e aprovados pelo cliente, o processo de desenvolvimento pode continuar.
No exemplo, tudo está documentado, mas é necessário ter certeza de que o que está escrito é o que realmente o cliente deseja que o sistema faça. Para se ter mais certeza, os documentos são revisados pela equipe e também pelo cliente que dessa forma pode ver se o que está descrito é o que ele necessita. Dessa forma diminui-se as chances de criação de um sistema que não atenda ao que o cliente pediu.
Mesmo com o cliente aceitando não é garantido que os requisitos ficarão da forma que foram aprovados, eles podem mudar a qualquer momento e sendo assim, é necessária uma gestão nos requisitos.

Gestão de Requisitos

A gestão de requisitos deve ocorrer em todo o ciclo de requisitos e enquanto o projeto estiver ativo, pois os requisitos podem mudar durante o desenvolvimento o que vai necessitar análises de impacto para visualizar o que a alteração muda no que foi especificado.
Além disso, a gestão também é feita para o acompanhamento da situação do projeto, através da analise dos requisitos pode-se avaliar como está o projeto (quanto já foi realizado, por exemplo).

Necessidade e Funcionalidade

A necessidade é o que o usuário quer que o sistema faça, são os problemas que o usuário têm e que o sistema irá ajudar a resolver.
A funcionalidade é o como que isso será feito, é a solução, características do sistema que farão com que a necessidade seja satisfeita.
Ex: Para o sistema de biblioteca
  • Necessidade:
    • Reservar um livro para um aluno.
  • - Funcionalidade:
    • Pesquisar existência de obra no acervo;
    • Realizar a reserva de obra;
    • Informar conclusão da reserva;

Ator

O ator é algo externo ao sistema podendo ser uma pessoa, um sistema e até mesmo um equipamento (impressora, por exemplo) que interage com o sistema fornecendo entradas ou recebendo saídas dele.

Caso de Uso

É um documento narrativo que descreve a seqüência de eventos de um ator que usa um sistema para complementar um processo (por Ivan Jacobson). Ou seja, é a descrição da seqüência de ações que devem ocorrer para que o ator tenha a sua necessidade satisfeita.
Por exemplo: Para um caso de uso Realizar Saque, teríamos a descrição da seqüência de ações para realizar essa atividade: colocar cartão; digitar senha; validar senha; informar valor desejado; verificar existência de saldo na conta; verificar existência de valor no caixa; subtrair valor da conta; liberar valor para o cliente.

Inclusão

A inclusão é um caso de uso que é sempre chamado por outro caso de uso. Ele não depende de uma condição para essa chamada.
A inclusão é muito utilizada quando temos uma ação que é comum a muitas partes do sistema.
Por exemplo o Login que é utilizado por muitas partes do sistema da mesma forma, além disso, é uma chamada incondicional, pois o login é necessário para que as operações sejam executadas.

Extensão

A extensão, diferentemente da inclusão, depende de uma condição para chamar um outro caso de uso, com isso o caso de uso nem sempre é chamado.
Por exemplo uma parte de um sistema responsável em informar um fornecedor que o estoque está baixo. Vamos nomear esse caso de uso como sendo INFORMAR FORNECEDOR e imaginar que o estoque mínimo é de 10 unidades.
Quando uma compra ocorrer e a quantidade em estoque for de 9 produtos, o caso de uso INFORMAR FORNECEDOR é chamado.

Generalização

A generalização ocorre quando temos um caso de uso que faz uma parte comum e é complementado por outros casos de uso. O caso de uso base possui diferentes especializações que são tratadas por outros casos de uso.
Por exemplo um caso de uso responsável por pagar uma fatura, podemos pagar a fatura usando o cartão de crédito, dinheiro ou cheque.
Vamos nomear esses casos de uso como: PAGAR FATURA, PAGAR COM CARTÃO, PAGAR COM DINHEIRO e PAGAR COM CHEQUE.
O PAGAR FATURA é genérico e é complementado pelo PAGAR COM CARTÃO, PAGAR COM DINHEIRO e PAGAR COM CHEQUE.
Além de generalização de caso de uso também podemos ter generalização de atores. Vamos considerar dois atores o GERENTE e o FUNCIONÁRIO.
O GERENTE também é um funcionário, mas ele possui permissões diferentes de acesso ao sistema, sendo assim ele complementa as operações do FUNCIONÁRIO.

A generalização de caso de uso é o tipo mais complicado de se usar e se explicar. Eu particularmente, nunca utilizei nem vi um uso prático para isso, que em situações parecidas utilizei inclusão. Digo isso porque acho que todo mundo fica confuso ao tentar mentalizar um cenário com este tipo de CDU. A generalização, ou especialização, é mais comum com atores.

quinta-feira, maio 18, 2006

Denúncia de Spam

Galera,

Achei uma matéria classe A em português sobre denúncia de Spam. O site é da consultoria G2CTech e explica direitinho como reportar um spam.

Alguns links para serviços que o artigo se refere:

Abraço!

sexta-feira, maio 05, 2006

Presente de aniversário

É galera... hoje é meu aniversário... faço 22 anos.... tô ficando velho... e logo de cara abro o e-mail e vejo um daqueles spams: Não cliquem no link, caso vocês recebam. É bonitinho, com logo e fotos da Petrobrás, no cabeçalho diz que vem de contato@petrobras.gov.br, mas é um blefe... o link para o edital vai para um executável que provavelmente vai zoar sua máquina... que presentão... pelo menos hoje poderia não receber essas coisas.... Segue o texto:
A Petrobrás, maior empresa estatal do país, está com
inscrições abertas para o concurso que visa ao
preenchimento de 1.178 vagas para os níveis médio,
médio técnico e superior.
Os interessados em participar podem fazer as inscrições
até o dia 25/05. A taxa é de R$28,00 para cargos de
níveis médio/técnico e de R$42,00 para os cargos de
nível superior.
Os salários iniciais chegam a R$3.605, de acordo com
o cargo pretendido.
Aproveite! Boa remuneração, benefícios e a estabilidade profissional que você precisa para planejar seu futuro.
Clique aqui para maiores informações e retire o Edital (lnk para um executável em um domínio esquisito... em espanhol)
Só estou postando isso para que caso alguém que não está acostumado com essas coisas, ou não é familiarizado com os problemas do mundo da informática fique esperto... Muitos e-mails de cartões, Serasa, banco, e concurso também podem ser estas pragas... que instalam outras pragas na sua máquina.

Abraço. E obrigado pela tentativa do presente!