quarta-feira, 22 de maio de 2013

Perfil Profissional - VII



Refinamento de Requisitos

Obtemos aqui o detalhamento necessário para entendermos os objetivos do projeto, compreendendo todos os requisitos funcionais e não funcionais do projeto.

Os requisitos devem atender os seguintes critérios:
  • Viabilidade – de implementação, respeitando as restrições da solução.
  • Completeza – possuir todas as informações necessárias para o seu desenvolvimento.
  • Executável – Contêm todas as regras e passos que possibilitam a sua execução.
  • Verificável – o que foi implementado corresponde ao que foi especificado.
  • Rastreabilidade – conseguimos identificar a origem e o responsável pelo requisito.


Produto de Entrada

As solicitações dos Stakeholders

Modelo II - Documento de Visão (arquivo anexo)
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo III - Glossário do Projeto (arquivo anexo)
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo VIII - Lista de Requisitos Funcionais
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo VIII - Lista de Requisitos Não Funcionais
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo IV – Plano de Gerenciamento de Requisitos
Cenários Operacionais e Matriz de Rastreabilidade

Modelo XII - Documento de Arquitetura
O arquivo contém o modelo do documento e instruções de preenchimento.

Produtos de saída

Especificações de requisitos funcionais.
Geramos a partir dos artefatos lista de requisitos funcionais, solicitações do cliente, documento de visão e glossário do projeto, retratando todos os requisitos funcionais do sistema.

Especificações de requisitos não funcionais.
Descrever os requisitos de usabilidade, confiabilidade, desempenho, Suportabilidade, restrições de projeto, requisitos de implementação, requisitos de interface, requisitos físicos.

Especificações de cenários operacionais.
O cenário operacional é a representação de um fluxo de operação completo para os usuários finais, segundo as suas necessidades. Com base no documento de requisitos funcionais e no documento de visão, especificamos os cenários operacionais. Os cenários operacionais são criados de acordo com as funcionalidades do sistema, ou seja, para cada funcionalidade do sistema identificado deve ser gerado um cenário operacional.

Criação de Protótipo.

Atas da reunião.

Modelo VI - Glossário do Projeto

Atividades

Especificar requisitos funcionais.

Especificar requisitos não funcionais.

Especificar cenários operacionais.

Criar protótipo da solução.

Consolidar requisito.
Nesta fase revisamos os documentos de visão, especificação de requisitos funcionais e não funcionais, protótipos, especificações de cenários operacionais, matrizes de rastreabilidade e atributos de requisitos.

Grande Abraço,
Gilberto Ribeiro.

Requisitos - VIII

Elementos Básicos

Os elementos básicos de formação do processo apresentado são os utilizados pelo RUP, para descrever seus aspectos estáticos, como:
  • Papéis
  • Artefatos
  • Atividades
  • Fluxo de atividades

Os três fluxos de atividades de engenharia de requisitos são:
  • Definir o Escopo do Sistema
  • Refinar Requisitos de software
  • Gerenciar Mudanças

Papéis

O comportamento é descrito por meio das atividades associadas àquele papel e as responsabilidades são definidas com relação aos artefatos criados, modificados ou controlados por ele.
  • Equipe: toda a equipe de desenvolvimento.
    • Analista de Sistemas – o principal responsável pela engenharia de requisitos:
      • Elicitação
      • Análise
      • Especificação
      • Validação
    • Gerência de requisitos.
    • Gerente de Projetos – responsável pelo bom andamento do projeto, monitoração de riscos, alocação de recursos e demais atividades de planejamento.
    • Cliente: representa um stakeholders do sistema, pertencente à organização cliente e que possui autorização para atuar como fornecedor de requisitos ao projeto.
    • Comitê de Controle de Mudanças: é formado por representantes de todos os stakeholders.
      • Uma configuração típica seria – o gerente de projeto, o gerente do projeto na organização cliente, um analista e um líder técnico.
      • Em projeto pequenos, pode ser formado apenas pelo gerente de projeto.
    • Qualquer Papel: qualquer membro da equipe de desenvolvimento ou stakeholders da organização cliente.
Artefatos

Os artefatos produzidos durante a execução das atividades do projeto são:
  • Documentos de Entrada: quaisquer documentos relacionados ao projeto que foram produzidos antes da fase de Iniciação. Exemplo típicos de documentos de entrada são RFPs (Request for Proposals) enviados por um cliente, a Proposta Comercial feita pelo departamento de vendas e aceita pelo cliente e a Proposta Técnica, que sugere uma visão inicial das características e módulos do sistema.

  • Atributos de Requisitos: são dados recolhidos ao longo do processo de análise de requisitos, desde a especificação até a aprovação da especificação final ou de posteriores mudanças.
    • Há vário tipos de atributos de requisitos: identificadores e informações cadastrais, especificações e detalhamento, status e índices como importância para o negócio, relevância para arquitetura, estimativa de tamanho (ou complexidade).
    • Um atributo especial é a prioridade do requisito, definida com base nos índices de outros atributos, e cuja definição depende de negociações com o cliente que envolvem atividades de gerência de projeto.

  • Matrizes de Rastreabilidade: documentam as relações de dependência entre requisitos. A rastreabilidade documentada é vertical (obrigatória) e horizontal (opcional).
    • É possível documentar as matrizes de rastreabilidade explicitamente, através de tabelas, planilhas ou ferramentas de gerência de requisitos, ou implicitamente, através dos demais artefatos do projeto.
    • Um exemplo de documentação implícita é a matriz que relaciona requisitos aos recursos de projeto como tempo e pessoas.
    • Os cronogramas do projeto possuem atividades agrupadas em blocos com os mesmos nomes dos requisitos, o que resulta em uma relação implícita com os requisitos armazenados no repositório.

  • Glossário: registro do vocabulário comum do projeto, na linguagem do cliente. É criado no início do projeto e evolui ao longo do desenvolvimento do sistema, servindo como referência para todos os envolvidos.

  • Documento de visão: nesse documento é definida a visão que os envolvidos têm do produto a ser entregue, em termos das principais necessidades e características.
    • Também registra a motivação para o desenvolvimento do sistema, através da breve descrição do principal problema de negócio a ser resolvido pelo sistema, além de descrever os limites do produto e as restrições impostas à solução.
    • Por conter um descrição em alto nível dos requisitos centrais pretendidos, incluindo restrições de design, serve como base contratual para requisitos técnicos mais detalhados.

  • Especificação de Requisitos de Software (ERS): captura todos os requisitos de software do sistema e consiste em um pacote contendo especificações funcionais e não funcionais aplicáveis.
    • As especificações funcionais possuem dois níveis de detalhamento: uma visão geral da funcionalidade é descrita nesse documento e o detalhamentos minucioso de cada requisitos é anotado em um documento chamado Especificação Funcional de Requisitos.

  • Especificação Funcional de Requisitos: os requisitos mais genéricos, alguns requisitos não funcionais e os requisitos que não podem ser bem representados nas especificações funcionais também são registrados na ERS, na seção de Especificação Suplementares.
    • Esse documento descreve minuciosamente a interação que ocorre entre os atores (usuários ou sistemas externos) e o sistema durante a execução deste(s) requisitos(s).
    • O principal objetivo é especificar o funcionamento de um porção do sistema de forma clara o suficiente para que o cliente possa validar o que será desenvolvido e a equipe de desenvolvimento compreenda o que deve entregar.

  • Modelo de Domínio: modelo de objetos inicial do sistema ou outra representação das entidades essenciais do sistema.

  • Protótipo de Interface: descrição de uma ou mais interface com o usuário.
    • Pode ser criada em vários formatos, tais como protótipos funcionais do sistema, protótipos estáticos, exemplos de tela, desenhos à mão livre capturados em meios eletrônicos e etc.

  • Solicitação de Mudanças: utilizada sempre que uma mudança no projeto é requisitada.
    • Esse artefato pode ser criado por qualquer membro da equipe de desenvolvimento ou da equipe do cliente, e deve ser aprovado pelo Comitê de Controle de Mudanças.

  • A Solicitação do Mudança é utilizada para documentar a necessidade de mudança (defeito, melhoria ou novos requisitos), informações sobre impacto e consequências de sua adoção e status de mudança, além das justificativas para as decisões tomadas sobre a implementação da mudança.

  • Repositório do Projeto: contém todos os artefatos utilizados no processo de desenvolvimento do software.
    • Pode ser um conjunto de arquivos, um banco de dados ou qualquer outra base controlada, por exemplo, por uma ferramenta de gerência de requisitos.

  • Aprovações: comunicação oficiais enviadas pelo cliente, atestando aceitação de algum artefato produzido.
    • Geralmente são e-mails com a aprovação de Especificações Funcionais de Requisitos.

Grande Abraço,
Gilberto Ribeiro.

SCRUM - Implantação VII

O Framework Ágil 

O Scrum não é um processo ou uma técnica para construir produtos. O framework nos diz o que fazer, mas não como fazer, usando uma sequência lógica de gestão de processos começando com o desenvolvimento da Visão do Produto, onde questionamos: o que vamos fazer e qual o objetivo do sistema? 

As respostas às perguntas anteriores nos levam ao segundo passo do framework que é a elaboração do Backlog do Produto, onde listamos todos os requisitos priorizados pelo Dono do Produto[1], ou Product Owner em inglês. 

O terceiro passo seria o Planejamento da Sprint que propõe a revisão do Backlog do Produto, acordando com o Dono do Produto a definição do objetivo da Sprint, culminando na formação e estimativa do Backlog da Sprint. 

O Backlog da Sprint é composto pelos requisitos selecionados para formação da Sprint, com suas tarefas estimadas pelo time. 

O quarto passo proposto pelo framework são as reuniões diárias, onde a equipe responde a três perguntas que ajudam a inspecionar o processo. O gráfico burndown ajuda no acompanhamento da evolução da Sprint, registrando a sua evolução e desvios. 

O próximo passo proposto no modelo seria a Revisão da Sprint, onde teremos a demo do software e o feedback do dono do produto atestando a qualidade ou não do sistema em desenvolvimento.  

Na Retrospectiva da Sprint verificamos o que deu certo durante a Sprint e o que precisamos melhorar. Nesta fase registramos todas as lições apreendidas durante o ciclo de vida do desenvolvimento da Sprint. O Produto gerado no final de cada Sprint é um incremento do software pronto e potencialmente usável.

No framework você pode empregar vários processos ou técnicas de Engenharia de Software. O Scrum deixa clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las. Permite tratar e resolver problemas complexos e adaptativos, entregando produtos com o mais alto valor possível para o negócio do cliente.

[1] Dono do produto: durante o desenvolvimento do estudo de caso vamos usar esta denominação em português para o cliente.

Grande Abraço,
Gilberto Ribeiro

Engenharia de Software - VII

Confiabilidade segundo a Norma ISO 9126

“Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas”. (NBR ISO/IEC 9126)

A Norma define como confiabilidade ao desempenho do sistema em produção.

Maturidade

“Capacidade do produto de software de evitar falhas decorrentes de defeitos no software”. (NBR ISO/IEC 9126)

A Norma define como maturidade o nível de erros, defeitos e falhas identificados no ciclo de vida de desenvolvimento. Os erros estão ligados a usabilidade do sistema, pois são gerados pelas ações do usuário na operação do sistema. Os defeitos do sistema estão ligados ao não entendimento do domínio do negócio, a má qualidade da informação ou mesmo a sua omissão. As falhas segundo o padrão IEEE ocorrem quando um programa não se comporta conforme o esperado ou apresenta resultados diferentes do planejado. (1983) A observância destes fatores contribuem para a qualidade e maturidade do sistema.

Tolerância a falhas


“Capacidade do produto de software de manter um nível de desempenho especificado em casos de defeito no software ou de violação de sua interface especificada”. (NBR ISO/IEC 9126)

A Norma define como tolerância a falhas de nível de desempenho especificado em casos de defeitos no software ou da violação da sua interface.  O Scrum contribui para a tolerância a falhas do sistema a cada iteração na dinâmica da arquitetura emergente do sistema, de acordo com as especificações, com base no domínio do negócio.

Recuperabilidade

“Capacidade do produto de software de restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha”. (NBR ISO/IEC 9126)

A Norma define como recuperabilidade o reestabelecimento do desempenho e a garantia da integridade dos dados gerados na utilização do sistema.

Conformidade relacionada à confiabilidade

Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações relacionadas à confiabilidade. (NBR ISO/IEC 9126)

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - VII


Identificando ALI e AIE

  1. Identifique todos os dados ou informações de controle, logicamente relacionados, reconhecidos pelo usuário no escopo da contagem.
    • Descarte entidades ou atributos não requeridos pelo usuário.
  2. Para cada entidade independente identificada
    • Dados de código?
      • Sim. Descarte mesmo se requerido pelo usuário.
  3. Conceito completo?
    • Sim. Proceda para classificação.
    • Não. Para cada entidade dependente relacionada.
      • Agrupe com os dados da entidade independente.
Classificando ALI e AIE
  1. Mantida pela aplicação medida?
    • Sim. ALI.
  2. Não. Referenciada pela aplicação medida?
    • Não. Reavalie a Identificação
  3. Sim. ALI em uma ou mais aplicação?
    • Sim. AIE.
Definição de Arquivo Lógico Interno – ALI
  • Um grupo de dados ou informações de controle.
  • Identificável pelo usuário.
  • Logicamente relacionado.
  • Mantido na fronteira da aplicação.

Definição de Arquivo de Interface Externa – AIE
  • Um grupo de dados ou informações de controle.
  • Identificável pelo usuário.
  • Logicamente relacionado.
  • Referenciado (lido) pela aplicação.

Principal diferença entre ALI e AIE
  • ALI - Mantido na fronteira da aplicação.
  • AIE - Referenciado (lido) pela aplicação. (ALI em outra aplicação)

Exemplos de Arquivos Lógicos
  • Tabelas que armazenam dados mantidos pela aplicação (ALI) ou referenciados por ela e mantidos por outra aplicação (AIE)
  • Arquivos de parâmetro de negócio mantido pela aplicação (ALI)
  • Arquivos mantidos não só pela aplicação, mas também por outra aplicação.
Determinação de Complexidade

Os ALIs e AIEs devem ser classificados de acordo com a sua complexidade funcional, com base em:
  • Número de Tipos de Dados (TD)
  • Número de Tipos de Registros (TR)


Complexidade do ALI/AIE
TR | TD
> 20
20 a 50
> 50
1
Baixa
Baixa
Média
2 a 5
Baixa
Média
Alta
> 5
Média
Alta
Alta

Grande Abraço,
Gilberto Ribeiro.