Arquivar por categoria Engenharia de Software

Novo Trabalho – SWEBOK (Capítulo 8)

Hoje adicionei um novo trabalho do SWEBOK, capítulo 8 que fala sobre Gerência de engenharia de software.

, ,

Nenhum comentário.

Redes PERT/CPM (Tempo de projeto)

Estimar o tempo de projetos é extremamente difícil porque se trata de muitas tarefas nas quais pode-se ter tarefas concorrentes, identificar estas concorrências e estimar o tempo de uma tarefa é muito complicado e incerto.

Após a estimativa dos tempos e identificação da concorrências das tarefas existe técnicas de cálculo do tempo total de duração. Uma destas técnicas é a representação das atividades em uma rede PERT (Program Evaluation and Review Technique) e o cálculo do caminho crítico através da técnica CPM (Critical Path Method).

Estas redes utilizam as teorias de grafos para representação da rede PERT como um grafo orientado e vértices (nós) com pesos determinando respectivamente a atividade e a duração desta.

Este video demonstra como fazer uma rede PERT, principalmente identificar o caminho crítico e entender as informações que podem ser extraídas dos cálculos.

, , , , , ,

Nenhum comentário.

Modelo para documentação de requisitos simplificado

No artigo anterior, mostrei um modelo para descrição de requisitos, mas na prática existem alguns problemas quanto a leitura deste tipo de documentação:

  1. Normalmente a cada 3 (três) requisitos descritos naquele modelo de documentação oculpa 1 (uma) página;
  2. O cliente não possui ou não dedica tempo para ler documentos grandes; e
  3. Documentações naquele modelo se tornam grandes.

Por este motivo, uma prática recomendável é fazer um modelo simplificado daquele documento, o que cria então 2 (dois)  documentos de requisitos, sendo este totalmente derivado daquele documento.

Para cada tabela do modelo anterior é criada uma tabela neste documento, mas apenas com a linha “Nome do Requisito”. Veja o exemplo abaixo:

Nome do requisito

Desta forma, teria outro documento apenas com os nomes dos requisitos. Particularmente colocaria uma linha a mais para identificar o requisito que é a linha “Identificação do Requisito”. Desta forma o documento ficaria assim:

Identificação do Requisito
Nome do requisito

Deste modo, o cliente poderá visualizar este documento simplificado e caso se enteresse abre o documento de requisitos detalhado procurando pelo “Identificador do Requisito”.

, ,

Nenhum comentário.

Modelo para documentação de requisitos

Um grande problema depois de enteder o que o cliente necessita é saber documentar o conhecimento explicito adquirido. Lembrando que existem dois tipos de conhecimentos: tácito e explicito.

Documentações podem ser feitas em textos abertos sem formatações ou utilizando um modelo para documentação. Ambos os modos atendem o objetivo, entretanto utilizar um modelo possibilita o rastreamento e uma melhor organização.

Existem vários modelos para documentação de requisitos, inclusive modelos específicos para trabalhos específicos. Veja o modelo que utilizo:

Identificação do Requisito Valor numérico sequencial
Nome do Requisito Descrição resumida de um requisito
Fonte Responsável pelo Requisito Nome do interessado que fez o analista ver o requisito
Data Data da conversa com o interessado, ex: 21/04/2009 13:00
Local e/ou Reunião Onde foi realizada a conversa, ex: empresa XYZ
Obrigatoriedade ( ) Imprescindível ( ) Desejável
Classificação quanto à prioridade ( ) Alta ( ) Baixa
Classificação quanto ao risco ( ) Alto ( ) Baixo
Especificação do Requisito Descrição um pouco mais aprofundada do requisito, acredito que muitas pessoas dividem esta descrição em duas colunas: ações do usuário e do sistema, mas particularmente não gosto muito
Dicionário de Dados Dicionário de dados, lembra análise estruturada (Separei esta por minha conta, pois muitas pessoas descreviam na coluna acima)
Responsável pelo Requisito Analista responsável pelo levantamento ou realização do requisito

Mesmo com os modelos é necessário saber descrever requisitos. Então, não se considere um analista somente pelo fato de saber fazer uma tabela.

, ,

1 Comentário

Novos trabalhos

Esta semana foi bem produtiva, veja a lista de novos trabalhos:

  1. Apresentação do SWEBOK – Capítulo 1;
  2. Apresentação do SWEBOK – Capítulo 2;
  3. Apresentação do SWEBOK – Capítulo 3; e
  4. Apresentação do artigo The Mythical Man-Month, escrito por Fred.Brooks.

Os próximos artigos irei publicar detalhes sobre cada item das apresentações, facilitando assim o entendimento.

, ,

1 Comentário

Exemplo Simples de Design by Contracts

Como havia comentado anteriormente, Design by Contracts serve para estabelecer um contrato entre o cliente (quem chama uma rotina) e o fornecedor (quem executa uma rotina), abaixo segue um exemplo bem simples da implementação do padrão, na linguagem Nice.

/**
 * Classe para calculos de exemplo da folha
 */
class Folha {
/**
 * Calcular salario
 */
 public float calcularFerias(float salario)
  requires //Requerimentos
   salario > 0 : "Salario deve possuir um valor"
  ensures //Garantias
   result >= salario : "Resultado nao e maior do que o salario"
 {
  //Retorna o valor unitario mais 1/3 do salario
  return 4F/3 * salario;
 }
}

/**
 * Funcao principal
 */
void main(String[] args){
 //Cria uma variavel chamada folha do tipo folha
 let folha = new Folha();
 //Cria uma variavel com o retorno do salario
 let salarioFerias = folha.calcularFerias(1800);
 //Exibe o resultado do calculo
 println("Salario de ferias " salarioFerias);
}

Assim, neste exemplo é garantido o parâmetro salário da função calcularFerias, como sendo um número maior que zero e é garantido que o retorno seja um número maior que o salário.

A quebra do contrato resulta em uma excessão para o sistema, assim garante as pré-condições (requires) e as pós-condições (ensures).

,

Nenhum comentário.

SWEBOK – Requisitos de Sistema e de Software

Finalmente a última etapa sobre os fundamentos dos requisitos, fecha as definições contidas no SWEBOK, entretanto serão mencionados casos práticos sobre o assunto, nos próximos artigos.

“Uma combinação de elementos para realizar um objetivo definido. Estes incluem: hardware, software, firmware, pessoas, informação, técnicas, facilidades, serviços e outros elementos de suporte”

[International Council on System Engineering]

Requisitos de sistemas são todos os requisitos do sistema como um todo.

Requisitos de software são derivações dos requisitos do sistema.

Esta definição é um pouco abstrata, mas cada parte será detalhada nos próximos artigos.

,

Nenhum comentário.

SWEBOK – Requisitos Quantificáveis

São requisitos que devem ser declarados sem abiguidade, e se possível de forma quantitativa

Exemplos:

  1. O software deve aumentar o rendimento dos operadores em 20%; e
  2. O software deve ter probabilidade de falha em um tempo de no máximo 3 minutos.

Requisitos de reabilitação obrigam determinadas arquiteturas.

Exemplos de como NÃO FAZER:

  1. O software deve ser honesto; e
  2. O software deve ser amigável ao usuário.

Finalmente, o próximo artigo será o final para encerrar a definição de requisitos segundo o SWEBOK, o tema será Requisitos -> De sistema e de software.

, , ,

Nenhum comentário.