Arquivar por categoria Engenharia de Software
Novo Trabalho – SWEBOK (Capítulo 8)
Postado por Ronneesley como Comunicados, Engenharia de Software em 5 de junho de 2009
Hoje adicionei um novo trabalho do SWEBOK, capítulo 8 que fala sobre Gerência de engenharia de software.
Redes PERT/CPM (Tempo de projeto)
Postado por Ronneesley como Estimativas, PERT/CPM em 8 de maio de 2009
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.
Modelo para documentação de requisitos simplificado
Postado por Ronneesley como Documentação em 21 de abril de 2009
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:
- Normalmente a cada 3 (três) requisitos descritos naquele modelo de documentação oculpa 1 (uma) página;
- O cliente não possui ou não dedica tempo para ler documentos grandes; e
- 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”.
Modelo para documentação de requisitos
Postado por Ronneesley como Documentação em 21 de abril de 2009
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.
Novos trabalhos
Postado por Ronneesley como Comunicados, Engenharia de Software em 13 de abril de 2009
Esta semana foi bem produtiva, veja a lista de novos trabalhos:
- Apresentação do SWEBOK – Capítulo 1;
- Apresentação do SWEBOK – Capítulo 2;
- Apresentação do SWEBOK – Capítulo 3; e
- 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.
Exemplo Simples de Design by Contracts
Postado por Ronneesley como Linguagem Nice, Padrões de Projeto em 25 de março de 2009
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).
SWEBOK – Requisitos de Sistema e de Software
Postado por Ronneesley como Fundamentos em 24 de março de 2009
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.
SWEBOK – Requisitos Quantificáveis
Postado por Ronneesley como Fundamentos em 24 de março de 2009
São requisitos que devem ser declarados sem abiguidade, e se possível de forma quantitativa
Exemplos:
- O software deve aumentar o rendimento dos operadores em 20%; e
- 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:
- O software deve ser honesto; e
- 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.