Várias formas de especificação de um requisito de software

Existem diversas formas de se especificar um requisito funcional. Neste post apresento algumas.

Requisito a ser especificado: Efetuar Matricula

a) Linguagem natural

O Aluno se dirige a Secretaria Acadêmica munido dos documentos pessoais e solicita a sua matricula em um determinado curso. A Secretaria Acadêmica confere os documentos do Aluno, conforme estabelecido em seu protocolo. A Secretaria Acadêmica efetua a matricula do Aluno no curso solicitado. A Secretaria Acadêmica encaminha o Aluno para a Tesouraria. O Aluno realiza o pagamento da matricula. A Tesouraria emite o recibo de pagamento para o Aluno. O Aluno retorna a Secretaria Acadêmica e apresenta o recibo. A Secretaria Acadêmica confirma a matricula do Aluno e emite o comprovante de matricula.

b) Caso de Uso

Especificação do Caso de Uso

UseCase: Efetuar Matricula
Sumário: Possibilitar que o aluno, assim que aprovado no processo de seleção (ENEM ou vestibular tradicional) realize sua matricula.
Atores:  Aluno, Secretaria Acadêmica, Tesouraria
Pré-Condições: Aluno aprovado no processo de seleção.
Fluxo Normal: 
1 - Aluno entrega documentação na Secretaria Acadêmica.
2 - Secretaria Acadêmica confere documentação.
3 - Aluno preenche formulário de matricula.
4 - Secretaria Acadêmica solicita que Aluno realize o pagamento da taxa de matricula.
5 - Aluno acessa a Tesouraria para pagamento da taxa de matricula.
6 - Tesouraria entrega recibo para Aluno.
7 - Aluno retorna a Secretaria Acadêmica para efetivar matricula.
8 - Secretaria Acadêmica efetiva a matricula.
9 - Secretaria Acadêmica entrega comprovante de matricula para o aluno.
Fluxo Alternativo: 
2.a - Documentação do aluno incompleta.
2.r - Secretaria Acadêmica solicita ao Aluno que apresente a documentação completa para efetuar matricula.
3.a - Aluno não realiza o pagamento.
3.r - Secretaria Acadêmica não efetiva matricula do aluno.

c) Diagrama de Sequência

d) Diagrama de Fluxo de Dados

e) Mapa Conceitual

f) Mapa Mental

É possível estabelecer qual é a melhor forma de especificação?

José Augusto Fabri – fabri@utfpr.edu.br

Vídeo aula (4-5) sobre pontos por função – Mapeando a Complexidade das Entrada de Dados

Disponibilizo as duas últimas vídeo-aulas do curso de pontos por função. As demais podem ser acessadas por meio destes post:

Antes de acessar os vídeos é importante ler este texto.

.

.

.

Fabri – fabri@utfpr.edu.br

Vídeo aula (3) sobre pontos por função – Mapeando a Complexidade das Entrada de Dados

Pessoal no dia 27 de março, publiquei uma vídeo-aula sobre a teoria de Pontos por Função para mapear os arquivos de interface externa. Neste vídeo apresento o mapeamento da complexidade da entrada de dados.

Para entender o conteúdo desta aula, é interessante acessar os link:

É possível comprar 1000 pontos por função.

Vídeo-aula sobre a contagem dos arquivos lógicos interno.

Vídeo-aula sobre a contagem dos arquivos de interface externa.

Abraços

Fabri – fabri@utfpr.edu.br

Ferramenta on-line para construção de interface

Pessoal, após publicar este post, fui amplamente questionado sobre as ferramentas para prototipagem de interface. Acredito que uma alternativa seja esta (indicação de Ricardo Satin).

Fabri.

Vídeo aula (2) sobre pontos por função – Arquivo de Interface Externa

Pessoal, após a publicação do último post, recebi vários e-mails solicitando que as vídeos aulas sobre pontos por função fossem disponibilizadas. Vou acatar as solicitações, lembrando que tenho várias limitações perante as câmeras.

Para entender o conteúdo desta aula, é interessante acessar os link:

É possível comprar 1000 pontos por função.

Vídeo aula sobre a contagem dos arquivos lógicos interno.

J. A. Fabri – fabri@utfpr.edu.br

Vídeo aula sobre pontos por função

Pessoal, nesta semana tive a oportunidade (claro, dentro de minhas limitações) de gravar algumas aulas sobre pontos por função. Aproveito a oportunidade para disponibilizar a primeira delas para toda a comunidade. Iniciamos nosso curso mapeando a complexidade dos arquivos lógicos internos.

Antes de executar o vídeo, sugiro que todos leiam este texto.

José Augusto Fabri – fabri@utfpr.edu.br

XP na íntegra

Pessoal, compartilho com vocês o XP na íntegra.

Abraços

fabri – fabri@utfpr.edu.br

Scrum na íntegra

Pessoal, compartilho com vocês o Scrum na íntegra.

Abraços

fabri – fabri@utfpr.edu.br

Utilizando o diagrama de espinha de peixe para a definição do escopo de um projeto de software.

O Diagrama de Ishikawa, também denominado Diagrama de Causa e Efeito ou Diagrama Espinha-de-peixe caracteriza-se como uma ferramenta utilizada pela Teoria Geral da Administração para a gestão e Controle de Qualidade de diversos processos. O diagrama foi proposto pelo engenheiro Kaoru Ishikawa em 1943.

A sua composição estrutural mapeia as causas de um determinado problema. Toda e qualquer causa pode ser classificada em seis tipos diferentes: Método, Matéria prima, Mão-de-obra, Máquinas, Medida e Meio ambiente (o diagrama também é conhecimento como Diagrama 6Ms).

Exemplo: A causa (ou motivo) que leva a ocorrência de um determinado problema pode estar relacionado a composição da Matéria prima, ou o atraso no processamento das informações de uma determinada Máquina, ou ainda, na falta de capacidade da Mão de obra.

Perceba que a composição estrutural do diagrama é composta por (vide figura em anexo):

• Cabeçalho: Título, data, autor.
• Efeito: Título do projeto (ou problema a ser resolvido). O título é escrito no lado direito, envolvido pela cabeça do peixe.
• Eixo central: Uma flecha horizontal apontando para o projeto.
• Categoria: Principais grupos de fatores que se relacionam com o projeto.
• Causa: Todo e qualquer projeto é fracionado em sub-projetos (ou sub-causa), perceba que é necessário executar sub-projetos (ou sub-causas) para atingir o sucesso no projeto como um todo.
• Sub-causa: Causa que pode contribuir com uma causa maior.

As figuras mapeadas no início deste post apresentam a estrutura genérica e a aplicabilidade de um diagrama em um projeto de software.

Perceba que na cabeça da espinha você encontra a idéia do projeto: Desenvolvimento de uma ferramenta de planejamento e controle de produção de software (PCP-SW). A primeira superior espinha mapeia as pessoas envolvidas no projeto; a segunda as atividades de processo sistêmico; a terceira os equipamentos necessários para que o projeto possas ser implantado com sucesso. As espinhas da parte inferior mapeiam as fontes dos requisitos, o ambiente no qual o projeto será implantado e forma de gestão que será aplicada.

Benefícios do diagrama:

• Possibilita o mapeamento do escopo do projeto;
• Registra as causas potenciais que podem ser revistas e atualizadas;
• Possibilita aglutinação, via brainstorm, dos stakeholders durante o desenvolvimento do diagrama.

 José Augusto Fabri – fabri@utfpr.edu.br

O roteamento (ou distribuição) da produção em um projeto de software

Produzir software cada vez mais rápido com um custo reduzido e com maior qualidade caracteriza-se como fator determinante dentro de um mercado altamente competitivo. Existem vários modelos de processo, de qualidade e de gestão que provêm práticas consolidadas focadas em questões de produtividade. Porém, a maioria destes não foca questões relacionadas à produção distribuída. Questões relacionadas ao roteamento da produção são muitas vezes tangenciadas (ou desprezadas) pelos referidos modelos. Dentro deste contexto questiona-se:

Quais os atributos que devem ser considerados no momento que se deseja distribuir (ou rotear) a produção de um produto caracterizado como software?

A produção distribuída de software é concretizada por meio de um grupo de empresas (ou desenvolvedores) que trabalham em conjunto durante o desenvolvimento de um projeto. Durante o roteamento da produção alguns atributos devem ser considerados:

• Qualidade: A organização responsável por parte da produção deve possuir características sólidas de qualidade. O nível de satisfação no atendimento dos requisitos, a capacidade de integração do produto são questões que devem ser mapeadas no momento de rotear.
• Tempo de produtividade: Não basta possuir um padrão de qualidade sólido, as organizações que recebem parte da produção devem atender a demanda rapidamente. Lembre-se que em mercado altamente competitivo a qualidade deve vir aliada a velocidade na entrega.
• Custo: Possuir políticas sólidas e eficazes para determinar o custo de produção é um fator que deve ser considerado na matriz (entidade que detém a responsabilidade pela execução do projeto) e nas filiais (entidades subcontradas para produzir parte do software).
• Segurança e sigilo de informações: Um ambiente seguro que acondicione todo o modelo de negócio e atributos do projeto deve ser uma constante na matriz e nas filiais.
• Cultura: Matriz e filiais devem alinhar nas questões ligadas a cultura organizacional – empresas de culturas diferentes não conceberão a integridade no projeto.
• Comunicação: O protocolo de comunicação entre matriz e filiais deve ser claro, conciso e consistente. Ambas devem respeitar o protocolo delineado para que a comunicação ocorra com o mínimo ruído.
• Sincronização: Matriz e filial devem buscar um sincronismo de produção. É importante que ambas tenham subsídios para equalizar questões de processo e de projeto.
• Processo: O processo de produção deve ser delineado e institucionalizado na matriz e nas filiais.

Lembre-se, o roteamento da produção pode maximizar produtividade desde que os atributos sejam mapeados na matriz e nas filiais. Caso contrário, aconselho a desenvolver o produto sem qualquer nível de distribuição.

 Abraços

Fabri – fabri@utfpr.edu.br