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 matricual.

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 apresenta a documentação completa para efetuar matricula.
3.a - Aluno não realiza o pagamento.
3.r - Secretaria academica 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

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

A importância do log de projeto

Em um projeto, o log tem como objetivo registrar os eventos relevantes durante a atividade execução. Esse registro possui uma grande importância, pois é a partir dele você consegue estabelecer um controle efetivo das atividades executadas. O registro também serve como artefato de entrada para ajustes na EAP e no Cronograma.

Em meus projetos, utilizo mapas mentais (veja modelo – figura ao lado) para gerar os logs - (perceba que cada projeto possui um mapa-log). No mapa registro :

• Data-hora da do evento;
• Evento;
• Envolvidos;
• Ocorrências;
• Decisões tomadas.

Por fim, é importante salientar que o log facilitará a construção do relatório final de projeto e proporcionará a criação de banco de lições aprendidas.

Fabri – fabri@utfpr.edu.br

O product owner pode utilizar um mapa mental para especificar uma funcionalidade dentro do Scrum?

Sim, o product owner pode utilizar um mapa mental para especificar uma funcionalidade dentro do Scrum.

O product owner (proprietário do projeto) é o responsável por definir quais são as funcionalidades que compõem um software. O mapa mental, por ser considerado uma ferramenta de organização de idéias, pode perfeitamente ser utilizado durante esta definição.

É importante salientar que algumas equipes padronizam que a especificação tenha o seguinte formato:

Como o … quero que … para que …

Exemplo:

Como o relatório de clientes em débito quero que o relatório de contas a vencer seja limitado por duas datas – início e término, para que eu possa estabelecer metas de pagamento durante o semestre.

Perceba que a especificação é baseada em outra já existente, porém ela ainda não é completa – como a maioria das especificações. Como desenvolvedor questiono: quais os campos que devem fazer parte do relatório?

Este fato leva o scrum team a discutir sobre a funcionalidades a serem implementadas durante a sprint planning meeting, as informações geradas durante esta discussão devem ser armazenadas e, se necessário, recuperadas. É neste PONTO que entra os MAPAS MENTAIS.

Por que não especificar a funcionalidade diretamente no mapa, tomando como base o padrão proposto anteriormente (vide figura no início do post)?

Perceba que o mapa possui 4 nós de grau 1: Mapeamento da funcionalidade perante a sprint, os envolvidos na discussão, a descrição efetuada pelo product owner e as informações geradas durante a especificação.

Por fim é importante salientar que mapa apresentado é uma sugestão para ser utilizado pelo scrum team, customizações podem (e devem) ser elaboradas de acordo com as características do projeto e da própria equipe.

Até a próxima

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

Proposta de um modelo de rastreabilidade de requisitos permeado por mapas mentais.

Pessoal.

O artigo anexo a este texto, apresenta a proposta de um modelo de rastreabilidade de requisitos de software baseado em mapas mentais. O artigo será publicado na 7ª Conferência Ibérica de Sistemas e Tecnologias de Informação (junho) – Madri Espanha.

Artigo.

Abraços.

Survey: Aplicação de mapas conceituais na especificação de funcionalidades em um projeto de software

Caros interlocutores do blog.

Estou orientando um trabalho de conclusão de curso que verifica a aplicabilidade dos mapas conceituais na especificação de funcionalidades em um projeto de software.

Os mapas conceituais são amplamente utilizados para representar conhecimento.

Você pode colaborar com o desenvolvimento deste trabalho respondendo a pesquisa abaixo. Para isto você deve analisar o mapa conceitual (click na figura para visualizá-la) e o diagrama de entidade e relacionamento (click na figura para visualizá-la). Efetuada a análise click no link survey e responda as questões. O tempo de resposta varia entre 1 e 2 minutos.

Click survey para participar de nossa pesquisa.

O outro lado das métricas de um software

Esta semana me deparei com uma questão extremamente interessante e complexa. Existe um modelo (ou métrica) que estime o valor agregado que um software irá trazer após a sua implantação?

O valor agregado caracteriza-se pelo aumento do capital intelectual, financeiro e de gestão em uma organização do setor produtivo dado a incorporação de uma entidade (pessoa, grupo de pessoas, software, ferramenta ou processo).

A implantação de um software (desde que seja bem conduzida) pode trazer um aumento substancial dos capitais elencados no parágrafo anterior, a organização analisa seu modelo negócio, reorganiza processos, realoca pessoas e reflete sobre questões relacionadas à persistência do conhecimento.

Introduzir métricas dentro deste contexto não é uma tarefa fácil, demanda conhecimentos que transcendem a esfera puramente técnica relacionada à definição, desenvolvimento e implantação de um software. É necessário conhecer profundamente o ambiente sistêmico no qual o software irá funcionar. Conceitos ligados a planejamento de produção devem fazer parte do escopo do profissional que irá promover a aplicação destas métricas.

Antes de conceber um modelo, tentarei compartilhar um caso (real) sobre o retorno temporal e financeiro na execução de um determinado processo negócio, dada a análise correta e reorganização de processos.

O exemplo

Caracterização do problema:  Zaca (nome fictício) é uma cidade do interior do Brasil. Como toda cidade ela deveria oferecer creche a suas crianças em período integral. Porém este fato não ocorre (não vamos entrar no mérito social da questão). Em virtude do não oferecimento das vagas em tempo integral, os pais matriculam seus filhos na creche A pela manhã e na creche B no período da tarde. Com isto a criança ocupa duas vagas, uma na creche A e outra na creche B, promovendo uma menor democratização no número de vagas. A secretaria municipal da educação (SME) percebeu a “necessidade” de construir um software que una o processo de matrícula nas creches em uma rede de dados. A caracterização sistêmica elaborada a partir da descrição problema pode ser visualizada por meio do diagrama de seqüência representado no lado esquerdo.

Solução do problema (emitida por um consultoria após analisar o ambiente sistêmico – vide diagrama a direita): Não é necessário implementar software sobre uma rede de dados que una o processo de matrícula. É necessário apenas reestruturar os processos de negócio. Como? Seguindo os passos abaixo:

a)      Entre as 16h e 18h as 6 creches devem comunicar via telefone a SME a disponibilidade de vagas dada alguma desistência.

b)      A SME deve disponibilizar uma pessoa para captar e controlar estas vagas.

c)       Os pais não irão realizar a matricula na creche e sim na SME (visto que a cidade é de pequeno porte).

De posse do exemplo questiono: Qual foi o valor da organização sistêmica (reestruturação do processo) efetuada?

Para tentar responder esta questão utilizei a seguinte premissa:

se valor > preço então benefício > custo

O valor (não financeiro e sim no sentido do retorno gerado para a organização) da análise efetuada é extremamente alto se comparado ao preço do software e da infra concebida na caracterização do problema. Este fato nos remete a um aumento substância do benefício coletivo, a prefeitura de Zaca pode aplicar toda a verba que seria destinada a construção do software para resolver o problema central – construir mais creches para atender as crianças em tempo integral.

Esboço do modelo de métricas pós-implantação

O esboço do modelo de métricas pós-implantação leva em consideração aumento da:

• Capacidade de gestão da organização: O software implantado proporciona uma maior governança dentro do ambiente organizacional? É possível prever o tempo/esforço/custo de um projeto com maior grau de certeza? Antes da implantação do software quantas previsões de tempo/custo/esforço se concretizavam? Este número aumentou após a implantação? O que isto implica em termos de satisfação do cliente? Qual a colaboração do software junto aos padrões de qualidade da organização?
• Capacidade financeira da organização: A implantação do software provê uma diminuição de tempo e esforço para a execução de uma determinada tarefa? Se sim, qual é o valor quantitativo desta diminuição?
• Capacidade intelectual da organização: O desenvolvimento e a implantação do software promoveram o aumento da visão organizacional dos colaboradores? É possível quantificar este aumento? O software possui subsídios para armazenar conhecimentos explícitos sobre o processo de negócio? Se sim, este conhecimento é de fácil recuperação?

Analise o ambiente organizacional após a implantação do software e tente responder estas questões. As respostas iram refletir o valor agregado que um software traz após a sua implantação.

Fabri – Universidade Tecnológica Federal do Paraná (fabri@utfpr.edu.br).

Adaptando as necessidades de Maslow na relação entre consumidor e empresa

pirâmide de maslow

Pessoal, neste texto adapto as 5 necessidades de Maslow na relação entre um consumidor e uma empresa. Vale a pena confeir.

Abraham Maslow defende que existe um conjunto com cinco necessidades que um ser humano necessita sanear.  Fisiológicas: fome, sono, sede e abrigo. Segurança: física e econômicas, por exemplo: conseguir um emprego estável. Sociais: pertencer a um determinado grupo de pessoas ou ser associado de um determinado clube. Estima: reconhecimento de nossas capacidades pessoais e o reconhecimento dos semelhantes em face à capacidade laboral que desempenhamos. Auto-realização: O ser humano sente a necessidade de progredir rumo à realização plena de seu potencial. Neste caso existe a necessidade que o seu trabalho esteja à altura de seus talentos e habilidades.

A adaptação:

1 – Relação fisiológica: Empresa e consumidor não possuem um forte comprometimento, o consumidor mantém a relação pura e simplesmente por falta de opção. A inexistência de empresas concorrentes alicerça a relação fisiológica. Se sua relação com o consumidor encontra-se neste patamar, mexa-se, pois em breve a concorrência aparecerá e seu relacionamento apodrecerá.

2 – Relação de segurança. A relação entre empresa e consumidor ultrapassou o âmbito fisiológico, a concorrência é pequena e o produto ou serviços prestados pela sua empresa ainda possuem credibilidade junto ao mercado. Neste relacionamento o tempo ainda joga a seu favor. Sua empresa se posiciona, erroneamente, em uma zona de conforto, se esforce para atingir o próximo nível – SAIA DA ZONA DE CONFORTO.

3 – Relação de sociabilidade: Neste tipo de relação o consumidor não identifica mais o produto e sim a marca, é o que acontece com o Bombril, você conhece alguém que compra esponja de aço? Neste caso a sua marca é bastante sólida junto ao consumidor, a relação é duradora e a socialização do produto foi massificada junto ao mercado. Porém ninguém se auto-realiza utilizando a esponja de aço.

4 – Relação de reconhecimento: Esta relação é baseada na inovação que sua empresa proporciona aos consumidores, lembrando ainda que sua marca ultrapassou a relação de sociabilidade. Neste âmbito podemos aplicar a seguinte equação: Reconhecimento = sociabilidade + inovação. É como ter um iPhone da Samsung.

5 – Relação de auto-realização: Os produtos ou serviços proporcionam o crescimento profissional e potencializam os consumidores. Aspectos ligados a inovação, sociabilidade foram ultrapassados a um bom tempo. A empresa quebra paradigmas de consumo, a invenção e a criatividade movem os pilares desta relação.

Em que nível sua empresa se encontra?

Fabri – fabri@utfpr.edu.br

Como descrever um caso de uso

Pessoal, várias pessoas me questionam se existe uma fórmula para descrever um caso de uso.

Como sempre digo, está formula não existe. O grau de especificação de um caso de uso depende da natureza dos requisitos, para requisitos mais complexos, a especificação terá que ser o mais completa possível. Para requisitos que não possuem grande complexidade, uma breve descrição basta.

Eu, particularmente, utilizo especificação proposta neste link.

Lembrando que para requisitos menos complexo, preencho somente os campos: Atores, finalidade e descrição.

J. A. Fabri - Universidade Tecnológica Federal do Paraná –  Campus Cornélio Procópio

fabri@utfpr.edu.br

A institucionalização de um processo de software e a persistência do conhecimento nas empresas – parte 2

A representação e a persistência do conhecimento são problemas críticos na maioria das organizações que trabalha com a produção de software. Materializar as informações relacionadas à como fazer algo (processo) não é trivial, garantir que as informações armazenadas na base irão oferecer subsídios para que o produto seja construído com qualidade é um tema de constante discussão na área de gestão do conhecimento.

O fato explicitado no parágrafo anterior é provado em palestras, consultorias e treinamentos efetuados pelo autor deste post – veja os indícios deste fato em A institucionalização do processo e a persistência do conhecimento nas empresas de software.

Na semana passada realizei, junto aos alunos do 6º período do curso de Tecnologia em Análise e Desenvolvimento de Sistemas do Campus Cornélio Procópio da UTFPR, a mesma experiência apresentada no link destacado no parágrafo anterior.

O resultado apresentado neste post foi muito parecido ao encontrado no primeiro.

Os alunos tentaram exaustivamente materializar o conhecimento sobre o processo de construção do avião (vide as fotos).

Um dos alunos que participou da experiência – aquele que fica distante do resto da turma (vide  A institucionalização do processo e a persistência do conhecimento nas empresas de software) – lembrando que desta vez dois alunos participaram, não conseguiu construir o avião (veja a foto destacada abaixo).

O que mais me chamou a atenção na turma foi a pré-disposição da Izebelle e do Aiton (alunos) em construir um vídeo que retrata como construir o avião.

Após tentar construir o avião com as informações materializadas no quadro (e não conseguir) o aluno teve acesso ao vídeo e o avião foi construído sem problema algum.

Conclusão: a forma de representação do conhecimento é de extrema importância para o processo de produção de uma empresa de software. O conhecimento a ser representado deve possuir portabilidade, acessibilidade, simplicidade e, principalmente, transmitir de maneira clara, concisa e consistente o que deve ser feito.

Neste caso o vídeo foi muito mais eficaz que o texto. Interessante: Os próprios alunos descobriram esta prerrogativa por si só.

Abraços

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