Tecnicas de Levantamento de Informações

1. Entrevista
• É a interação com o Cliente/Usuário. Consiste na seguinte lógica de organização que possibilita em ótimos resultados:

• Preparação da entrevista: É importante estudar o material disponível, estabelecer um principal objetivo da entrevista e preparar uma lista de questões.
• Condução da entrevista: Falar menos que o entrevistado e se possível levar um escriba (responsável por registrar os pontos importantes da entrevista).
• Finalização da entrevista: Reservar alguns minutos pra resumir e consolidar os principais pontos discutidos/citados, informar quais serão os próximos passos e que será enviado uma ata (explicar que, após aprovado será publicada).
2. Pesquisa a Manuais e Registros
• Internos
• Manuais
• Relatórios
• Formulários
• Bases de Conhecimento
• Externos
• Publicações especializadas do negócio
• Estatísticas governamentais
• Relatórios de pesquisa e tendências
• Vendedores, Clientes
• Internet, Bases de Conhecimento

3. Questionário
• É usado geralmente para coletar informações de um grupo, departamento ou até mesmo individualmente. São informações solicitas por escrito, quando se tem dificuldade pra reunir os stakeholders por exemplo.
• Um bom questionário deve ser bem estruturado e deve ser de fácil entendimento, com perguntas claras e objetivas, por isso exige um bom tempo para criá-lo.
• Preferencialmente, antes de envia-lo é ideal que faça um teste com algumas pessoas, a fim de obter opiniões e qualidade do mesmo.
4. Observação

• Utilização do método "In Loco"
• Esse processo consiste em acompanhar de perto todos os passos e processos da tarefa em questão. 
• As principais dúvidas a serem esclarecidas são:
• Qual o escopo/objetivo do trabalho
• Qual o resultado final, o que se espera como resultado final?
• Quem executa cada passo do trabalho?
• Com quais recursos?
• Como se faz?
• Quando se inicia este trabalho e quais são as entradas
• Quem solicita?
• 
  
5. Role Playing
• Analistas
• É ideal aprender todo o trabalho e processo (fim a fim) do usuário
• Vantagens
• Levanta informações ainda não mapeadas nas demais tecnicas e obtem maior domínio do problema.
• Conhece os problemas que geralmente os usuários enfrentam.
6. Brainstorming
   
   
   
• Grupo de no máximo 10 pessoas (aconselhável) reunidas, trocando informações e idéias com a finalidade de resolver algum problema/propor novas soluções. Quanto maior o número de ideias, melhor vai ser o resultado.
• O objetivo precisa ser bem definido
• Modificar as ideias ou combina-las pode ter bons resultados.
• Debates ou críticas não podem ser permitas, a finalidade é escutar a todos, independente da opinião.
7. Storyboard
• São dados gráficos, que tem a finalidade de ajudar a mostrar/ilustrar o processos e ou passos do trabalho, de forma sequencial. Normalmente mostra quais são os atores, quando se inicia cada passo e são quais os objetivos.
8. Workshop
• Conduzido por um facilitador (geralmente de 1 a 5 dias), tem a finalidade de se chegar num consenso sobre escopo, riscos e caracteristicas (Casos de Uso, Requisitos, Regras de Negócio, etc).
• Obs: As decisões são escritas e aprovadas na hora. As mesmas são enviadas a todos os participantes.
9. JAD (Joint Application Design)
   
   
   
• Consiste numa dinamica de grupo, que tem como objetivo definir os objetivos e requisitos de um projeto/sistema.
• Recursos visuais são muito usados e tem como finalidade estimular os sentidos, criar interesses, esclarecer alguns pontos confusos e otimizar o tempo da dinamica. Consegue definir objetivos com mais eficaz, evitando retrocessos.
• Toda documentação é gerada durante as sessões, assim é possível que os usuários entendam o porque das decisões feitas podendo discutir o conteúdo criado.
• Cerca de 20 a 60% de melhora na produtividade para especificação de requisitos, se comparado com outros métodos tradicionais.
10. Protótipos
• É a demonstração de um modelo ou comportamento de um projeto/solução, muito útil e recomendado para:
• Obter feedback do cliente
• Validar alguns requisitos
• Demonstrar entendimento do escopo
• Obter aprovação da solução
• OBS: É importante deixar claro para o cliente que se trata de um protótipo (um esboço desenhado numa folha de papel é muito utilizado por alguns analistas), e não do sistema em si. O intuito é dar um esboço e validar os pontos citados anteriormente. 

Termo de Abertura de Projeto (TAP) - Project Charter (PC)

O termo de abertura do projeto (TAP) ou Project Charter (PC) em inglês, é o documento que autoriza formalmente o projeto. Ele concede ao gerente/gestor a autoridade para utilizar os recursos da organização na execução das atividades do projeto.

O termo de abertura do projeto deve abordar, ou referenciar, as seguintes questões:

• requisitos que satisfazem as necessidades do cliente;
• objetivos do projeto (que devem ser SMART);
• propósito ou justificação do projeto;
• stakeholders do projeto e os seus papéis e responsabilidades;
• expectativas dos stakeholders;
• identificação do gestor do projeto. e nível de autoridade do gerente;
• cronograma macro dos marcos do projeto;
• premissas, ou pressupostos, organizacionais (fatores considerados verdadeiros, reais ou certos);
• restrições organizacionais (fatores que limitam as opções da equipe);
• investimento (orçamento preliminar);
• constrangimentos e riscos;
• descrição do sub-produto(s) identificados;
• milestones identificadas.

Permite assim responder a questões como:

• O que deve ser feito para atingir o objectivo do projeto?
• Como deve ser feito?
• Quem o vai fazer?
• Quando deve ser feito?

Introdução ao Gerenciamento de Projetos

A partir deste momento estaremos detalhando e apresentado assuntos inerentes à projetos, onde o ponto objetivo é expandir o conhecimento sobre o assunto, no qual o mesmo não é aplicado apenas na área de TI e que na prática a aplicabilidade de projetos é difundida para diversas áreas e até em nossas vidas.

Gestão de projetos ou gerência de projetos ou gerenciamento de projetos ou administração de projetos é a área da administração aplicada de conhecimentos, habilidades e técnicas na elaboração de atividades relacionadas para atingir um conjunto de objetivos pré-definidos, num certo prazo, com um certo custo e qualidade, através da mobilização de recursos técnicos e humanos.

O que é um Projeto?

Um Projeto é normalmente definido como um empreendimento colaborativo ou como um esforço temporário empreendido para criar um produto, serviço ou um resultado exclusivo. Um projeto frequentemente envolve um pesquisa ou desenho, que é cuidadosamente planejado e organizado para alcançar um objetivo particular.

Ciclo de Vida de um Projeto

O Ciclo de vida de um projeto é a estimativa de duração de um projeto indeterminado, que possui início, meio e fim. O Ciclo de Vida do projeto serve para detalhar as fases do projeto de forma que o mesmo apresente uma organização e coerência em sua estrutura. Cada fase do projeto é marcada pela entrega (entrega = deliverables "em inglês") de um ou mais produtos/serviços, como estudos de viabilidade ou protótipos funcionais.O início de cada fase define o trabalho a ser realizado por todos os envolvidos em sua execução. O final de cada fase é marcado por uma revisão do produto/serviço e do projeto até o momento em que o mesmo se encontra. Quando há "overlapping" entre as fases, denominamos essa prática de "fast tracking", nesse caso, começa-se a trabalhar nas próximas fases do projeto antes do fim da fase corrente (entrega e revisão dos produtos). Os custos de um projeto são geralmente crescentes à medida que a fase avança. Os riscos são geralmente decrescentes à medida que a fase avança. A habilidade das partes envolvidas alterarem os produtos de cada fase é decrescente à medida que a fase avança. As fases de um projetos são descritas como: 

Iniciação, Planejamento, Execução, Monitoramento ou Controle, Finalização. 

Conforme a imagem abaixo:

Componentes de um Projeto

• Equipe
• Gerente
• Cliente
• Fornecedores
• Stakeholders/Shareholders (qualquer pessoa ou organização que tenha interesse, ou seja afetado pelo projeto, partes envolvidas no projeto).

Antipatterns na manipulação de exceções e logs

Ninguém constrói um software acreditando que ele irá falhar, mas, pelo menos, deveríamos prepará-lo caso isso ocorra.

Se o Titanic não foi construído para afundar, então para que se preocupar com avisos de emergência e botes salva-vidas, por exemplo. Mas se acontecer algum problema em seu casco a ponto de entrar mais água do que ele pode suportar, ele irá parar no fundo do oceano, queira você ou não. Então coloque alarmes no barco e botes salva-vidas para todos.

E com o seu software não é diferente. Se uma package no banco ficar inválida, ou se o disco do servidor encher porque alguém esqueceu de monitorar, a sua aplicação irá parar, queira você ou não. E não é o famoso "Erro no sistema. Contacte o administrador" que irá salvar você. Emita um aviso preciso, ou o sistema ficará por horas parado até encontrar qual é o problema.

A maior catástrofe marítima de todos os tempos. Todo software pode apresentar problemas e esteja preparado quando isso acontecer para não ser mais um Titanic. 

Pode parecer boba a comparação, mas, infelizmente, não são apenas os estagiários, ou programadores juniors que não dão atenção a isso. É comum encontrar aplicações onde o Projeto & Design não detalham como será o tratamento de exceção e, tampouco qual será a política para escrita dos logs. Com isso cada programador trata a sua maneira. 

E independente de existir orientações dos arquitetos sobre tratamentos de exceção e logs, existem erros comuns nestes tratamentos, os Antipatterns na manipulação de exceção e logs. 

Mas antes de falarmos sobre o que não se deve fazer, vamos comentar sobre o que se espera de um bom código, as boas práticas:  

• Mecanismos de Logs Java
• Exceções Java

Erros comuns encontrados em códigos Java, os Antipatterns:

• Logar e Relançar
• Captura e Ignora
• Propagação Deficiente

O que é o Code Review?

A revisão de código, inspeção estática de código, ou Code Review, é a verificação do código-fonte de um sistema de forma sistemática, mesmo que o sistema ainda esteja em desenvolvimento. O objetivo desta atividade é encontrar e arrumar erros antecipando ao máximo a fase inicial do ciclo de vida da aplicação, enquanto aumenta a qualidade do software e amadurece a habilidade do desenvolvedor.

A revisão pode ocorrer de algumas maneiras como:

• Programação em Par - onde dois programadores utilizam a mesma estação de trabalho. Enquanto um programa, o outro passa algumas sugestões sobre como resolver o problema, enquanto verifica a qualidade como a solução está sendo implementada. O código já é construído sob a revisão de um par.
• Análises Informais - quando a equipe troca código entre os desenvolvedores para realizar análises informais no código de outro desenvolvedor, ou a análise é feita por um profissional mais experiente dentro da equipe (como um arquiteto de sistemas). Neste caso, quaisquer inconformidades são informadas diretamente ao autor do código-fonte, sem nenhuma documentação formal.
• Análises Formais - onde existe uma atividade formal dentro do processo de desenvolvimento. A revisão do código-fonte é realizada por outro desenvolvedor dentro da equipe, ou por um profissional mais experiente (como a Análise Informal). De forma resumida, a diferença é que esta análise precisa acontecer dentro do processo e precisa ser documentada.
• Ferramentas de Code Review - ferramentas procuram de maneira automática erros comumente encontrados no código-fonte

Existe um consenso comum equivocado, onde a aprovação do usuário é suficiente para garantir a qualidade do projeto. A figura abaixo tenta ilustrar que isso não é bem verdade. Ainda mais que o usuário irá executar o fluxo básico de alguns casos de uso e não fará um teste exaustivo no sistema. Sem contar que itens como manutenibilidade e confiabilidade não são facilmente identificados com testes funcionais. 

Esta imagem exemplifica o porquê é errado achar que a validação do usuário é suficiente para garantir a qualidade do código-fonte

O que é Antipatterns?

Antipadrões de projeto de software, ou simplesmente antipatterns, é o termo utilizado para erros ou práticas comuns durante o processo de desenvolvimento de software. Este erro pode ocorrer durante diversas fases: análise, projeto, codificação, gerência, etc.

A inspiração deste conceito, surgiu em 1995 por Andrew Koenig no livro Gang of Four Design Pattern. Esse livro define alguns padrões para resolver problemas comuns para o desenvolvimento de software, atribuindo nomes para cada um destes padrões.

Três anos depois, surgiu o conceito de antipattern com o livro AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. De maneira análoga, esse livro atribuiu nomes para padrões comumente encontrados nos códigos-fontes, entretanto que não são considerados como Boas Práticas.

Neste blog irei publicar diferentes tipos de Antipatterns, focando nos que mais impactam o desenvolvimento. 

Bem Vindos ao Blog EasyALM!

Iremos abordar assuntos relevantes de Projetos, Processos, Testes, Requisitos, Negócios, Programação, Ferramentas e muito mais.

Acessem nosso blog diariamente para tirar suas dúvidas, partilhar de conhecimento e acompanhar nossas resenhas e casos de estudo sobre os assuntos citados acima.

Fiquem à vontade para acrescentarem idéias e dicas nos comentários para que possamos aplicar em nosso Blog!

Bons estudos e um grande abraço da EQUIPE ALMEASY!!!!!!!!

Como elaborar um documento de Especificação de Requisitos

A seguir, um exemplo de como elaborar um documento de especificação de requisitos.

1. Cabeçalho
1. Usar o cabeçalho padrão adotado pela empresa
2. Capa
1. Indicamos que trata-se de um documento de requisitos, na linha abaixo citamos o nome do sistema e em outra linha a versão. Exemplo:

Documento de Requisitos do Sistema
EasyALM

Versão 4.0

3. Histórico de Alterações
1. Montamos uma pequena tabela onde é solicitado Data, Versão, Descrição e Autor.
4. Conteúdo
1. Criar um índice
5. Introdução
1. Iniciamos com uma breve descrição sobre o escopo do documento
2. Visão geral do documento

                                          i.    Separando por seções, definimos como estão organizadas as informações. Exemplo:

1.     Seção 2 – Descrição geral do sistema

2.     Seção 3 – Requisitos Funcionais (RF)

3.     Seção 4 – Requisitos Não Funcionais (RNF)

4.     Seção 5 – Requisitos Negativos

5.     Seção 6 – Referências

3. Convenções, termos e abreviações

                                          i.    Identificações dos requisitos

1.     Define-se termos e/ou nomenclaturas para os requisitos

                                         ii.    Prioridades dos requisitos

1.     Exemplo: Essencial, Importante e Desejável.

6. Descrição Geral do Sistema
7. Requisitos Funcionais
8. Requisitos Não Funcionais
9. Requisitos Negativos
10. Referencias

Clique aqui para baixar um modelo exemplo

O que é um Caso de Uso?

Um Caso de Uso é uma das principais técnicas para capturar requisitos (para novos sistemas ou manutenção). Cada caso de uso provê um ou mais cenários que indicam como o sistema deve interagir com o usuário final ou outro sistema para atingir um objetivo de negócio específico.

Casos de uso tipicamente evitam o jargão técnico, preferindo ao invés disto a linguagem do usuário final. Casos de usos são ferramentas enganosamente simples para descrever o comportamento de um software. Um caso de uso deve conter uma descrição textual de todos os passos que o usuário futuramente poderá vir a utilizar no software através de sua interface. 

Casos de uso não descrevem nenhum comportamento interno do software, nem fazem explanações de como o software será implementado, basicamente mostra os passos que o usuário deve seguir para usar o software. Recomenda-se que criar casos de uso para todas as formas de interação que o usuário terá com o software.

Exemplo simples dos casos de uso "Sacar Dinheiro" e "Imprimir Extrato" representados em diagrama UML:

Abaixo, um exemplo do caso de uso "Sacar Dinheiro" representado de forma escrita (o nível de detalhamento é opcional, o importante é clareza que os passos são descritos):

Caso de Uso: Sacar Dinheiro

Ator: Cliente

Escopo: Caixa Eletrônico

Pré-condição: Cliente autenticado para utilizar sua conta bancária

1. Cliente escolhe a opção "Saque"
2. Cliente informa o valor que deseja sacar
3. Cliente confirma informações de saque
4. Cliente retira o dinheiro do caixa e finaliza a operação.

-------------------------------------------------------------------------------------------------------

Outro exemplo simples de caso de uso representado por UML:

Mais informações sobre casos de uso:

• Casos de Uso com Fluxo Alternativo
• Casos de Uso com Fluxo de Exceção
• Documento de Especificação de Casos de Uso