Casos de Uso - Embora seja uma técnica muito utilizada, ainda é mal compreendida – Parte 1

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Estou apresentando o primeiro de uma série de cinco posts que estou escrevendo sobre o assunto Modelagem de Casos de Uso. Cada post irá abordar diferentes aspectos dessa técnica (Bittner, 2003; pag.9) tão utilizada, no mundo inteiro, na elicitação de requisitos de software.

O que me motivou escrever sobre esse assunto foi o fato de perceber uma grande carência de conhecimentos dos fundamentos teóricos que devem referenciar o trabalho dos Analistas de Negócio, Analistas de Requisitos, Analistas de Sistemas, Arquitetos de Software e principalmente dos Gerentes e Líderes de Projeto.

Em cada projeto que me envolvo como consultor, mentor ou coach, noto que os profissionais envolvidos na gestão de requisitos desconhecem os pilares que fundamentam a elicitação de requisitos de software. Heroicamente, eles usam conhecimentos obtidos com colegas que também aprenderam como outros colegas e assim por diante. Admiro a coragem desses profissionais, pois como bons brasileiros são versáteis e “se viram” fazendo o projeto andar. O problema é que o uso equivocado de técnicas pode causar graves danos na qualidade final do produto.

Cada vez mais me convenço de que Casos de Uso é uma excelente técnica que deve ser usada para a elicitação de requisitos de software. Infelizmente ela tem sido bastante mal interpretada pelos membros das equipes de projetos de desenvolvimento de software.

Aproveito a oportunidade para salientar que, com o advento do Use Case 2.0 apresentado recentemente por Ivar Jacobson (Jacobson, 2011), o pai dos casos de uso, poderemos seguramente continuar a usar casos de uso em projetos ágeis, pois, se descritos apropriadamente, se convertem em excelentes contextos para a elicitação de Estórias do Usuário, tão utilizadas em metodologias ágeis como o SCRUM e XP.  

Percebo que muitos gerentes de projetos, ou qualquer profissional associado ao planejamento de projetos de software têm usado casos de uso como um repositório para toda e qualquer especificação endereçada à equipe de construção de aplicações. Com isso obtemos casos de uso extremamente longos, aninhando vários outros artefatos de diferentes níveis de abstrações elevando desnecessariamente a complexidade, dificultado a comunicação e confundindo usuários e desenvolvedores.

Com isso perde-se muito tempo para produzir e validar todos esses artefatos e depois, um outro tempão para compreender o que foi escrito. Frequentemente esses artefatos apresentam problemas de completeza, ambigüidade, falta de clareza, levando o desenvolvedor a retornar aos analistas de negócio ou usuário para completar ou entender os requisitos descritos. Tudo isso leva a um desperdício de tempo onerando o projeto.

Casos de uso é um artefato de nível de abstração conceitual. Não é de implementação. Por isso não deveríamos associá-los a telas. Telas ou protótipos de telas devem estar associados a caso de uso, mas não o contrário. Telas implementam casos de uso e possuem uma forte rastreabilidade entre eles, mas isso não quer dizer que uma tela ou protótipo de tela deva compor a descrição de um caso de uso.

A descrição de casos de uso deve ser feita de forma altamente abstrata, sem nenhuma inferência em soluções de implementação. Dessa forma poderemos deixar os casos de uso independentes e totalmente livres do impacto das freqüentes alterações das interfaces gráficas do usuário. Imagine, cada alteração que tiver na tela, ter que alterar também o caso de uso. Isso é um absurdo, pois irá onerar desnecessariamente o projeto.

Caso de uso é algo bem mais simples do que parece. Para melhor explicar vou contar uma história que resume como e porque surgiu os casos de uso. Em 1979 Tom DeMarco escreveu o livro "Structured Analysis and System Specification" (Claudiomir, 1999) onde ele apresentou os princípios básicos da Análise Estruturada. Paralelamente Gane e Sarson se juntaram às idéias de Tom DeMarco e publicaram o famosíssimo livro “Análise Estrutura de Sistemas”, ainda hoje vendido nas principais livrarias do mundo inteiro. A principal ferramenta apresentada era o Diagrama de Fluxo de Dados (DFD), ainda muito utilizada, principalmente em projetos para alta plataforma.

Isso trouxe uma enorme evolução e padronização na forma de conceber um sistema de software. A intenção original era trazer o usuário para a equipe de projeto no papel de co-autor na concepção da aplicação. Infelizmente isso não ocorreu como se esperava, porque o DFD é uma técnica composta de muitos elementos e regras, tais como Entidades Externas, Funções, Fluxos de Dados, Depósito de Dados, um conjunto de Diagramas mostrando a Decomposição Funcional partindo do nível zero (frequentemente chamado de Diagrama de Contexto) até chegar nas primitivas funcionais que corresponderiam a programas ou módulos de programas a serem codificados em uma determinada linguagem, naquela época, o nosso velho e eficaz COBOL.

O problema é que o Usuário não estava preparado para tudo isso. O que ele queria (e continua querendo) é somente uma coisa: software funcionando para resolver o problema dele. Como eles eram, e continuam sendo, leigos em Engenharia de Software, isso tudo era muito complexo para eles. Por isso a intenção de ter o Usuário como co-autor ficou frustrada.

Contudo, a necessidade de envolver os usuários em projetos de software continuou aumentando, porque as necessidades dos negócios elevavam constantemente a complexidade das soluções de software. Foi então, que no início da década 90, Ivar Jacobson, um dos três amigos que criaram a UML, desenvolveu uma técnica chamada de Casos de Uso. Seu objetivo era voltar a conquistar o Usuário. Por isso ele criou uma forma de diagrama extremamente simples que qualquer pessoa pudesse entender e usar. Era tão simples que mais parecia um desenho feito por uma criança de quatro anos.

O diagrama de Casos de Uso possui somente três elementos: Ator (representado por um bonequinho), Caso de Uso (representado por uma elipse) e uma Associação entre eles (representada por um tracinho). Veja bem, aquele tracinho não é um fluxo de dados. É somente uma associação, ou seja, um Ator está associado a um Caso de Uso. Nada mais do que isso. Tem mais outra coisa extremamente importante: não tem decomposição funcional. Fica tudo em um único diagrama. Em sistemas muito grandes, com muitos casos de uso, você até pode quebrar um diagrama de casos de uso em outros pequenos diagramas, mas isso é só uma sub-divisão seguindo algum critério para não deixar o diagrama muito grande. Isso NÃO É decomposição funcional. Todos os casos de uso de todos os diagramas possuem absolutamente o mesmo nível de abstração.

Então, logo de cara, vamos aprender uma coisa. Um caso de uso não corresponde a uma função de um DFD. Por favor, se você quer aprender modelagem de Casos de Uso, esqueça DFD. São paradigmas totalmente diferentes. DFD é uma técnica usada no paradigma de Análise Estruturada. Caso de Uso é outra coisa. É uma técnica pertencente ao paradigma Orientado a Objetos.

Vou confessar uma coisa para vocês. No fim da década de 90, quando iniciei meus estudos e pesquisas sobre UML, devido ao fato de já ter usado muito DFD, senti dificuldades para usar o conceito de Casos de Uso porque, inconscientemente buscava fazer uma paridade de um para outro, ou seja, com funções de DFD. Até que um amigo me disse: “enquanto não tirar o “chapéu” da análise estruturada, você não irá conseguir aplicar corretamente os conceitos de casos de uso”. Fiz isso e deu certo. Foi aí que vi que deveria guardar o DFD numa “gaveta”. Veja bem, não é jogar fora. É guardar numa “gaveta” em algum lugar no seu cérebro. Isso quer dizer que você não irá usá-la em projetos OO. Mas toda a experiência (“a manha”) já obtida no relacionamento com Usuário é extremamente bem vinda.

Hoje, como professor, percebo isso muito explicitamente em sala de aula. Alunos que iniciaram suas carreiras usando o paradigma OO entendem e aplicam com muito mais facilidade do que experientes Analistas de Sistema Seniores, com vinte ou mais anos de experiência no paradigma Análise Estruturada. Realmente, os analistas seniores conseguem entender muito bem o conceito de casos de uso, mas sentem dificuldades na hora de aplicar a técnica. Neste caso, além do treinamento formal em sala de aula, se faz necessária a aplicação de um processo de mentoring para ajudar, de forma personalizada, o aluno a aplicar corretamente a técnica.

No próximo post irei comentar sobre os fundamentos teóricos que envolvem a Modelagem de Casos de Uso.

BIBLIOGRAFIA

- Bittner, K; et. al.; Use Case Modeling; Addison-Wesley; 2003.

- Jacobson, I., Spence, I., Bitnner, K.; Use Case 2.0 – The Guide to Succeeding with Use Cases; Ivan Jacobson International, Dez/2011.

- Selner, Claudiomir; Análise de Requisitos para sistemas de informações, utilizando as ferramentas da qualidade e processos de software; Dissertação submetida à Universidade Federal de Santa Catarina para obtenção do grau de Mestre em Engenharia; Florianópolis, Agosto/ 1999; obtido na internet em 20/01/2012;  http://www.eps.ufsc.br/disserta99/selner/cap3.html; 

Treinamento em Análise de Requisitos com BPM, Estórias do Usuário e Casos de Uso

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.


Este curso aborda três técnicas que ajudam na elicitação de requisitos: Modelagem de Processos de Negócio (BPM), Estórias do Usuário e Casos de Uso. A Modelagem de Processos de Negócio ajuda na identificação de funcionalidades; Estórias de Usuário nos leva a uma descrição sucinta e precisa oferecendo agilidade ao processo de desenvolvimento; Casos de Uso é um método que pode, opcionalmente, ser aplicado para descrever as interações entre o usuário e o sistema. O curso apresenta cenários de gestão de requisitos que definem quando cada uma dessas técnicas deve ser utilizada.

O objetivo deste curso é formar Analistas de Requisitos. Não se trata de um curso de informação, ou seja, ensinando o que é um Analista de Requisitos, o que faz, quando faz, porque faz, etc. Este curso vai bem além disso. Formamos um profissional com a competência necessária e suficiente para elicitar requisitos de sistemas de informação, ou seja, achar (identificar), classificar, organizar e especificar requisitos.

O curso foi totalmente idealizado para duas categorias de público:

• Profissionais especializados em desenvolvimento de sistemas que desejam aprimorar as técnicas de Análise de Requisitos, aproximando-se da Análise de Negócio da empresa.
• Administradores, Contadores, Economistas, Engenheiros e Usuários de sistema de informação, leigos em Informática que pretendem conhecer as técnicas de Análise de Requisitos para melhorar suas performances nos projetos que participam, ou que pretendem ingressar na área de Informática através da Análise de Requisitos.

Será apresentada uma visão operacional do trabalho cotidiano de um Analista de Requisitos, com dicas de como elicitar requisitos a partir das Necessidades dos Stakeholders de nível estratégico, tático e operacional. Apresentará formas de descrever requisitos usando a técnica de Estórias do Usuário, muito usada nas metodologias ágeis tais como SCRUM e XP. A partir dessas Estórias será ensinado como desenvolver o Modelo de Casos de Uso e fazer a especificação detalhada de cada Caso de Uso e Requisitos Não-Funcionais.

Programa do curso

• Conceitos introdutórios sobre Requisitos de Software.
• A importância da Modelagem Visual na busca pela eliminação da ambigüidade.
• Conceitos sobre a Abstração X Decomposição como forma de definir a granularidade dos requisitos.
• Elementos da Visão Geral de um Sistema.
• Tipo de Stakeholders: Estratégico, Tático e Operacional.
• Analista de Negócio X Analista de Requisitos.
• Postura profissional de um Analista de Negócio/Requisitos.
• Modelagem de Processos de Negócio (Diagrama de Atividades da UML) como forma de identificação de Requisitos Funcionais.
• Estórias do Usuário como técnica de elicitação de Requisitos Funcionais.
• Casos de Uso como forma de elicitação de Requisitos Funcionais.
• Estórias do Usuário X Casos de Uso.
• Modelagem de Casos de Uso.
• Especificação de Casos de Uso.
• Requisitos Não-Funcionais.
• ISO-9129 como forma de identificação de Requisitos Não-Funcionais.
• Requisitos de Usabilidade.
• Especificações Suplementares.

Data de Início
04/02/2012


Carga horária
24 horas (3 sábados de 8 horas).

Local
Veris – IBTA
Av. Paulista, 302, (em frente a estação do metrô Brigadeiro).
São Paulo - SP.

Faça sua Inscrição
Fone (11) 9631-1247
E-mail: evandro@wm2info.com.br

Bibliografia sobre Engenharia de Software

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Neste post estou incluindo novos itens na nossa Bibliografia sobre Engenharia de Software. São livros, artigos dissertações de mestrado e doutorado sobre Requisitos, UML, Processos de Software, etc. Meu objetivo é apresentar o maior número possível de referências bibliográficas para ajudar aos profissionais em seus estudos como autodidata, bem como aos alunos de graduação e pós-graduação (lato sensu e stricto sensu).

Posteriormente, em post futuros, irei comentar o conteúdo de cada uma dessas referências para facilitar a tão difícil tarefa de pesquisa bibliográfica necessária para a elaboração TCC (Trabalho de Conclusão de Cursos), dissertação de mestrado e doutorado.

Convido aos leitores deste blog a colaborarem conosco enviando-nos suas referências bibliográficas. O nome do colaborador irá constar junto às referências cedidas.

Segue abaixo a primeira versão das referências bibliográficas:

Bibliografia sobre processos de software (metodologias).
• KRUCHTEN, Philippe; Introdução ao RUP Rational Unified Process; Editora Ciência Moderna.
• JACOBSON, I.; BOOCH, G.; RUNBAUGH, J.; The Unified Software Development Process; Addison Wesley.

Bibliografia sobre UML (Unified Modeling Language).
• Fowler, M.; UML Essencial – Um breve guia para a linguagem padrão de modelagem de objetos; Bookman; 2000.
• Booch, G.; Rumbaugh J.; Jacobson I.; UML Guia do Usuário; Ed. Campus; 2006.
• OMG; Unified Modeling Language: Superstructure; Versão 2.1; ptc/2006-04-02.
• Larman, Craig; Utilizando UML e Padrões; 2ª Edição; Bookman, 2002.
• Pender, Tom; UML a Bíblia; Editora Campus; 2004.
• Borges, C.C.P.; Sistema de Controle de Eventos Utilizando Metodologia ICONIX; Dissertação de Mestrado; UFJP; 2005.

Bibliografia sobre Gestão de Requisitos.
• Bittner, K; Spence, I; Use Case Modeling; Addison Wesley;
• Cockburn, Alistair; Escrevendo Casos de Uso Eficazes; Bookman; 2007.
• LEFFINGWELL, D; WIDRIG, D.; Managing Software Requirements – A Unified Process; Addison Wesley 2000.
• Rosenberg, D; Scott, K.; Applying Use Case Driven Object Modeling with UML – An annotated e-Commerce Example; Addison Wesley 2001.
• Rosenberg, D; Scott, K.; Use Case Driven Object Modeling with UML – A practical Approuch; Addison Wesley 2003.
• Schneider, G.; Winters, J. P.; Application Use Cases Second Edition – A practical Guide. Addison Wesley 2003.

Bibliografia sobre Análise-Design Orientado a Objetos
• Booch, G.; Maksimchuk, R.; Engle. M.; Young. B.; Conallen. J.; Houston. K.; Object-Oriented Analysis and Design with Applications; 3ª Edition; Addison Wesley 2007.
• Fowler, M.; Analysis Patterns: Reusable Object Models, MA.; Addison-Wesley; 1996.
• Jones, M.P; Fundamentos do Desenho Orientado a Objetos com UML; Makron Books; 2001.

Bibliografia sobre Engenharia de Software.
• SWEBOK – Software Engineering Body of Knowledge; Versão 2004; IEEE.
• OMG – Object Management Group; UML Superstructure Specification, v2.1; ptc/2006-04-02; April/2006.

Requisitos de software existem por si só.

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Um dos principais medos que temos quando vamos entregar um sistema que estamos desenvolvendo, é ouvir a seguinte frase: “o sistema parece interessante, bem feito, mas...”. O grande problema está no “mas...”.

O que significa este “mas...”? Significa que alguma coisa está faltando, como por exemplo, uma funcionalidade fundamental, alguma informação necessária ou alguma característica de qualidade esperada. A questão é, porque esta funcionalidade, informação ou característica não foram entregues? Certamente é porque não foram lembradas na ocasião em que a equipe estava elicitando os requisitos. De quem é a culpa? Certamente não é do Usuário que foi interrogado. Com certeza é do Analista de Negócio. Então, o que faltou? Faltou o uso das técnicas e abordagens apropriadas para achar os requisitos.

Os requisitos existem nas mentes dos stakeholders. Cada stakeholder visualiza parte do problema do negócio cuja solução é refletida na forma de Necessidades, que precisam ser identificadas nas três esferas (ou camadas) administrativas da empresa: Estratégica, Tática e Operacional. Particularmente, gosto muito do verbo “achar”. Nosso papel é “achar” as Necessidades em toda a amplitude do negócio, ou seja, nas três esferas administrativas.

Muitas vezes, nos restringimos a identificar Necessidades somente na camada Operacional, porque envolve um público mais fácil de ser acessado, mas em algumas empresas, até esta camada é de difícil acesso. O fato é que a esfera Operacional abriga os usuários do sistema, ou seja, aqueles que interagem diretamente com o sistema. Se o analista de negócio analisar o problema somente do ponto de vista da camada Operacional, certamente irá identificar somente as Necessidades Operacionais do negócio.

Dessa forma, quando for entregar o sistema, os stakeholders Estratégicos e Táticos irão reclamar porque suas Necessidades não foram atendidas. Por isso irão dizer a tão temida expressão “sim, mas...”. Portanto, podemos concluir que as Necessidades existem, independentemente de achá-las ou não. O processo que nos leva a “achar” a totalidade das Necessidades requer o envolvimento das camadas Estratégica, Tática e Operacional.

O conjunto dessas Necessidades é usado como insumo no processo que leva à completa identificação dos requisitos de software. Em outras palavras, podemos afirmar que os requisitos de software são derivados a partir das Necessidades dos stakeholders. Se as Necessidades não forem completamente identificadas, isso implica que um determinado grupo de requisitos, conseqüentemente, não será identificado. Ora, se as Necessidades existem independentemente de achá-las, ou não, conseqüentemente os requisitos também existem, independentemente de achá-los, ou não.

É fácil achá-los? Claro que não. Mas este é o papel do Analista de Negócio. Em minhas aulas e palestras, gosto muito de usar a seguinte analogia. Elicitar requisitos é como achar agulha em um palheiro. As agulhas foram postas lá. Elas existem. Compete a nós achá-las.

Se não as encontrarmos, certamente iremos ouvir dos usuários: “Sim, o sistema parece interessante, mas...”. 

A Gestão de Requisitos como uma ferramenta de apoio à área comercial.

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Em empresas fornecedoras de serviços de TI, uma das atribuições do Analista de Negócio e Analista de Requisitos é dar suporte à área comercial. Esses profissionais colaboram fazendo o levantamento das necessidades do negócio do cliente e, a partir dessas necessidades, elicitam requisitos dos usuários, regras de negócio e um conjunto de requisitos de software e elaboram um artefato popularmente conhecido como Documento de Visão.

A partir deste documento, é elaborada a Proposta Técnica a qual descreve o escopo do projeto através de seções que abordam as necessidades do negócio, os requisitos funcionais, requisitos não-funcionais, regras de negócio, casos de uso, especificações suplementares, premissas, restrições e requisitos inversos.

Tenho percebido que os Analistas de Negócio (ou Analistas de Requisitos) frequentemente confundem o que significa cada uma desses objetos de Gestão de Requisitos e, por isso, sentem dificuldades em descrevê-las, cometendo erros que levam à elaboração de uma proposta imprecisa, ambígua e com o escopo aberto, permitindo que o cliente, em ocasiões futuras, solicite novos requisitos alegando que a proposta permite tal mudança.

Na tentativa de colaborar com os Analistas de Negócio e com as equipes comerciais, vou comentar sobre cada um desses objetos de Gestão de Requisitos. Tomo como pressuposto que se esses objetos estiverem corretamente descritos, teremos um Documento de Visão e, como conseqüência, uma proposta consistente e com o escopo bem delimitado.  

Necessidades do negócio

Descreve o que é esperado pelos stakeholders de nível executivo da empresa. A correta elicitação dessas necessidades é fundamental para a eficácia do projeto. Para tal será necessário que reflitam as causas-raiz dos problemas do negócio. A análise dos problemas e a identificação das respectivas causas-raiz constituem numa excelente técnica que leva à correta elicitação das necessidades do negócio. Ela irá determinar o alvo a ser alcançado pelo sistema a ser desenvolvido. Será a partir das necessidades que os requisitos do sistema serão elicitados.

Requisito Funcional.

Como o próprio nome afirma, trata-se de uma funcionalidade, ou seja, é uma AÇÃO que será executada pelo sistema que, antes da automação do processo, era executada manualmente. O termo funcional deve remeter à idéia de uma função que o sistema irá executar. Por isso a descrição deverá ter uma conotação VERBAL. Exemplos: Calcular o saldo da conta corrente. Debitar saque na conta corrente. Calcular faturamento mensal. Note que cada sentença inicia com um verbo, caracterizando uma ação a ser executada pelo sistema.

Requisito Não-Funcional.

É uma descrição da CARACTERÍSTICA do sistema como um todo, ou de algum elemento seu, tais como, uma interface gráfica, relatório, arquivo, etc. Pode também descrever aspectos genéricos do sistema, tais como, segurança, manutenibilidade, desempenho (performance), interoperabilidade, confiabilidade, portabilidade, etc. A ISO-9126 descreve em detalhes todas essas características não-funcionais de uma aplicação de software.  Um requisito não-funcional QUALIFICA um aspecto do sistema. Por isso sua descrição deve ter uma conotação QUALITATIVA. Exemplo: Todos os campos obrigatórios de uma tela deverão estar marcados com um asterisco. O cadastro de clientes deverá ter um crescimento mensal de 10%. O tempo de resposta para transações na ATM não deverá ultrapassar a 3 (três) segundos. Note que não há nenhuma ação na descrição destas sentenças. Elas descrevem características que devem ser implementadas no sistema.

Regras de Negócio.

Nem é uma ação a ser executada pelo sistema, nem é uma descrição qualitativa do sistema. Trata-se de uma RESTRIÇÃO IMPOSTA PELO NEGÓCIO. Ela afeta o comportamento do negócio e, como conseqüência, afeta o comportamento do sistema que o automatiza. Não tem nada a ver com requisito de software. Uma regra de negócio existe independente do processo de negócio ser ou não automatizado por software. Por isso sua descrição deverá ter uma conotação RESTRITIVA. Exemplo: Cliente inadimplente não pode fazer compras a prazo. Um item de estoque só poderá ser reposto quando seu saldo atingir o nível mínimo.

Casos de Uso.

É uma descrição do diálogo entre o ator (papel executado por um usuário, sistema ou um dispositivo de hardware) e o sistema (foco do projeto), o qual produz um resultado de valor do ponto de vista do ator. É uma excelente técnica de captura de requisitos funcionais e não-funcionais. Por isso podemos dizer que os casos de uso realizam os requisitos funcionais e requisitos não-funcionais (também conhecidos como requisitos especiais). Alguns requisitos não-funcionais que não possuem relação com nenhum caso de uso, são popularmente chamados de Especificações Suplementares. 

Premissa.

É um PRESSUPOSTO que deverá ser levado em consideração pela EQUIPE DO PROJETO. Descreve ações a serem (ou não serem) executadas pela equipe do projeto. Sua descrição deve referenciar aspectos que devem ser levadas em consideração durante a execução do projeto. Exemplos: Os desenhos das telas serão feitos pelo Web-Design por ocasião do Modelo de Análise. A equipe de implementação deverá ter experiência em UML 2.1. Os requisitos deverão ser validados pelos usuários antes da elaboração do Modelo de Design da aplicação.

Restrições.

São fatos que restringem o projeto ou a solução. É diferente de uma Regra de Negócio. Enquanto uma Regra de Negócio restringe o comportamento do sistema, uma Restrição restringe decisões a serem tomadas pela gestão ou pela equipe operacional do projeto. Restrições do projeto estão associadas ao orçamento, prazo, disponibilidade de recursos, etc. Restrições da solução estão associadas à arquitetura, design, tecnologia e infra-estrutura. Exemplo: Toda documentação deverá ser feita em UML 2.1. O modelo de processo utilizado deverá ser o SCRUM.

Requisitos inversos.

São requisitos do sistema que não serão contemplados pelo projeto em foco. Reconhece-se a existência do requisito, mas deixa-se claro que o presente projeto não irá abordá-lo. É uma declaração explícita de que o projeto não entregará aquele requisito. Isso é muito útil para não causar expectativas por parte do cliente/usuários. Ajuda a delimitar o escopo do projeto.

Conclusão.

Esses elementos acima descritos constituem o foco da Gestão de Requisitos. Não é necessário que a equipe comercial tenha experiência em Gestão de Requisitos. Minha sugestão é que toda empresa que presta serviços de Engenharia de Software, deve ter uma célula de trabalho especializada em Gestão de Requisitos, onde uma das suas funções é dar suporte à área comercial. Este suporte consiste na elaboração do Documento de Visão, o qual deverá conter todos esses itens tão essenciais para a elaboração de uma Proposta Técnica, a qual será usada como ponto de partida para o correto planejamento do projeto. Sem esses itens corretamente descritos e negociados, existirá um forte risco do sistema “iniciar torto”.

Qual a diferença entre Equipe e Time?

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Dentro do domínio da gestão de projetos, é muito comum a utilização dos termos “time” e “equipe”. Alguns, quando querem demonstrar que suas equipes são altamente coesas e costumam atingir os objetivos do projeto, escolhem o termo “time”. Será que o termo “equipe” significa um conjunto de profissionais incompetentes que não costumam atingir seus objetivos? Claro que não! Qual será a diferença entre os termos “time” e “equipe”?

O Wikcionário (http://pt.wiktionary.org) descreve “time” como um grupo de pessoas envolvidas em atividades semelhantes e descreve “equipe” como um conjunto de pessoas encarregadas de qualquer tarefa em comum. A diferença parece existir, mas não ficou clara.

A Wikipédia (http://pt.wikipedia.org), na ocasião em que consultei, descreve “equipe” como um grupo de pessoas com habilidades complementares que trabalham juntas com o fim de atingir um propósito comum. Faz ainda uma associação a uma agremiação esportiva, tal como um time de futebol.

A minha interpretação é que o termo “time” leva a entender que é um tipo especial de equipe, porque reúne pessoas com habilidades complementares. Por exemplo, um time de futebol é formado por onze jogadores onde cada um desempenha um papel diferente de tal forma que um complementa o papel do outro.

Com isso, chego à conclusão que o termo “equipe” tem um conceito mais genérico, ou seja, reúne pessoas que trabalham para atingir um determinado objetivo. Um time de futebol, neste sentido, pode ser considerado uma equipe, porque todos têm o mesmo objetivo, o qual é ganhar o jogo. Em contrapartida, podemos também ter uma equipe onde cada membro faz exatamente a mesma coisa, ou seja, possuem o mesmo papel.

No contexto da Engenharia de Software, o termo “time” poderia ser aplicado para uma equipe onde cada membro possui um papel diferente (complementar), tais como gerente do projeto, arquiteto de software, analista de negócio, projetista, programador (popularmente chamado de desenvolvedor), testador, etc. Como se vê, temos um grupo de pessoas com papeis diferentes e complementares. Creio que podemos chamar esse grupo de “time”.

Entretanto, se tivermos um grupo de programadores fazendo exatamente a mesma coisa, ou seja, programando, entendo que temos aí, uma equipe de programadores. É possível que alguém possa argumentar que não, ou seja, temos um time de programadores porque cada um está fazendo um programa (método de uma classe, stored procedure, etc.) diferente. Insisto ainda dizer que se trata de uma equipe, porque cada programador com seu respectivo programa em desenvolvimento, corresponde à uma instância de um mesmo papel.

Este é um excelente tema para uma discussão acadêmica. Para que serve? Talvez para nada... mas poderá servir como um exercício mental para desenvolvermos nossa capacidade de descrever corretamente elementos abstratos que nos cerca no nosso dia-a-dia, muito útil para Analistas de Negócio e Analistas de Requisitos.

Convido a todos a fazerem seus comentários sobre este tema. Quem sabe poderemos chegar a uma descrição consistente. Se chagarmos, poderemos colaborar com o Wikcionário e com a Wikipédia.

Bibliografia sobre BPM, Requisitos, UML, OOAD, Metodologias, etc

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Este é o primeiro post que estou disponibilizando sobre o tema “Bibliografia”. Meu objetivo é apresentar o maior número possível de referências bibliográficas para ajudar aos profissionais em seus estudos como autodidata, bem como aos alunos de graduação e pós-graduação (lato e stricto sensu).

Posteriormente, em post futuros, irei comentar o conteúdo de cada uma dessas referências para facilitar a tão difícil tarefa de pesquisa bibliográfica necessária para a elaboração TCC (Trabalho de Conclusão de Cursos), dissertação de mestrado e doutorado.

Convido aos leitores deste blog a colaborarem conosco enviando-nos suas referências bibliográficas. O nome do colaborador irá constar junto às referências cedidas.

Segue abaixo a primeira versão das referências bibliográficas:

Bibliografia sobre processos de software (metodologias).
• KRUCHTEN, Philippe; Introdução ao RUP Rational Unified Process; Editora Ciência Moderna.
• JACOBSON, I.; BOOCH, G.; RUNBAUGH, J.; The Unified Software Development Process; Addison Wesley.

Bibliografia sobre UML (Unified Modeling Language).
• Fowler, M.; “UML Essencial – Um breve guia para a linguagem padrão de modelagem de objetos”; Bookman; 2000.
• Booch, G.; Rumbaugh J.; Jacobson I.; “UML Guia do Usuário”; Ed. Campus; 2006.
• OMG; Unified Modeling Language: Superstructure; Versão 2.1; ptc/2006-04-02.
• Larman, Craig; Utilizando UML e Padrões; 2ª Edição; Bookman, 2002.
• Pender, Tom; UML a Bíblia; Editora Campus; 2004.
• Borges, C.C.P.; Sistema de Controle de Eventos Utilizando Metodologia ICONIX; Dissertação de Mestrado; UFJP; 2005.

Bibliografia sobre Gestão de Requisitos.
• Bittner, K; Spence, I; Use Case Modeling; Addison Wesley;
• Cockburn, Alistair; Escrevendo Casos de Uso Eficazes; Bookman; 2007.
• LEFFINGWELL, D; WIDRIG, D.; Managing Software Requirements – A Unified Process; Addison Wesley.

Bibliografia sobre Análise-Design Orientado a Objetos
• Jones, M.P; Fundamentos do Desenho Orientado a Objetos com UML; Makron Books; 2001.
• Fowler, M.; “Analysis Patterns: Reusable Object Models, MA.; Addison-Wesley; 1996.

Bibliografia sobre Engenharia de Software.
• SWEBOK – Software Engineering Body of Knowledge; Versão 2004; IEEE.
• OMG – Object Management Group; UML Superstructure Specification, v2.1; ptc/2006-04-02; April/2006.

Uso de Templates

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Template é um formulário que é usado para facilitar a criação padronizada de um documento ou artefato. Deveria ser um instrumento de trabalho que levasse o analista a realizar o seu trabalho com sucesso.

Tenho percebido que os templates, algumas vezes, se transformam em um problema para o sucesso de um projeto. Vou explicar relatando um episódio que ocorreu comigo, na ocasião em que eu estava aplicando um processo de coaching em um projeto.

Um analista estava tendo alguns problemas na descrição de um caso de uso, porque era grande e complexo, com muitos fluxos alternativos, fluxos de exceção e regras de negócio. Percebia claramente que o analista não conseguia definir corretamente os fluxos alternativos e de exceção. Para resolver o problema sugeri que ele elaborasse um diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso e, a partir desta visão pudesse definir corretamente os fluxos de eventos.

Surpreendi-me quando ele disse-me que não iria fazer o diagrama porque não era obrigatório e também não estava elencado como um produto contratado. Argumentei que embora não fosse um entregável, era importante para que ele produzisse uma descrição do caso de uso com precisão e qualidade.

Posteriormente o gerente entrou na discussão alegando que a elaboração deste diagrama não estava previsto no cronograma e que a sua elaboração iria consumir um tempo que não tinha sido planejado e pediu-me, portanto, que eu não insistisse sobre o diagrama de atividades.

A conclusão dessa história é que o caso de uso foi descrito de uma forma altamente imprecisa, incompleta, não retratando o comportamento esperado. O tempo que aquele analista gastou para descrever aquele caso de uso foi, no mínimo, três vezes maior do que ele gastaria se estivesse elaborado o tão popular diagrama de atividades.

Para concluir a história, quando a equipe de design foi realizar aquele caso de uso, criando o modelo de design com o diagrama de classes e diagrama de sequência, não conseguiram concluir o trabalho, porque o caso de uso não estava claro, era impreciso e muitas coisas não faziam sentido. Com isso, aquele analista teve que fazer vários ciclos de alterações na descrição até que tivesse totalmente pronto para atender aos rigores da equipe de desenvolvimento.

É interessante notar que além do tempo excessivo que o analista gastou na descrição inicial do caso de uso, gastou ainda muito mais tempo para fazer as correções exigidas pelos desenvolvedores, além do tempo que a equipe de desenvolvimento gastou para entender e sugerir correções para o analista.

Lembra-se do gerente do projeto? Aquele que disse que não havia tempo para gastar com o diagrama de atividades? Coitado, passa maior parte do tempo atualizando cronogramas e levando pancada do cliente, que reclama que ele não consegue cumprir o planejamento inicial.

Porque tudo isso aconteceu? Porque tanto o gerente do projeto quanto o analista de negócio/requisitos, trabalham orientados à template. Para eles, o importante é preencher os campos do template. Esquecem-se de que os diagramas da UML poderiam ser de grande ajuda para se obter o entendimento do problema e para a definição adequada de uma solução. Esses diagramas possuem a excelente propriedade de oferecer múltiplas visões da solução idealizada. Essas visões irão colaborar para uma descrição clara, precisa, consistente e não ambígua dos casos de uso.

Não tenham medo de gastar tempo na elaboração do diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso. Certamente você irá ganhar tempo no cômputo geral do projeto. Além do que você irá evitar perda de tempo da equipe de design e de implementação.

Template é um excelente instrumento de trabalho, mas antes de preenchê-lo, pense, mas pense usando os excelentes diagramas da UML.

Treinamento em Gestão de Requisitos com Casos de Uso

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.


Este curso objetiva preparar profissionais especializados no gerenciamento de requisitos com casos de uso. Foi totalmente idealizado para analistas, gerentes e líderes de projetos que fazem levantamento de requisitos junto aos clientes (internos e/ou externos) e que elaboram toda a documentação necessária para o design e construção do sistema.

Não é um curso de informação. Trata-se de um curso de formação, com uma abordagem gerencial e operacional para que o aluno conclua o curso com capacidade de gerenciar e produzir requisitos especificados de forma a fazer sentido para a equipe de desenvolvimento, que tanto sofre com documentação incompleta, imprecisa, inconsistente e ambígua.

O curso faz uma abordagem gerencial ensinando técnicas de planejamento da gestão de requisitos, gerenciamento de escopo, gerenciamento de mudanças e análise de riscos dos requisitos de software. Apresenta o processo operacional da gestão dos requisitos de um projeto de software. Define uma matriz de perfis e responsabilidades dos profissionais que devem ser envolvidos e mostra a importância estratégica do gerenciamento dos requisitos no sucesso de um projeto. Para aqueles que usam metodologias baseadas no modelo de processo incremental e iterativo, o curso ensina como fazer o planejamento de iterações do projeto.

Do ponto de vista operacional, serão ensinadas técnicas de elicitação (identificação) de requisitos junto a clientes de nível estratégico, operacional e tático da empresa, fazendo análise de problemas de negócio e definindo soluções específicas para as causas-raiz dos problemas identificados. A partir do problema analisado, o curso ensina a modelar processos de negócio, regras de negócio, requisitos do cliente (features), casos de uso, requisitos não funcionais com uso na norma ISO-9126.

Programa

• Conceitos introdutórios de gestão de requisitos com casos de uso em um processo incremental e iterativo.
• Análise do problema de negócio.
• Definição das necessidades dos stakeholders a partir da análise do problema.
• Modelagem de processos de negócio como fonte de requisitos funcionais.
• A ISO-9126 como fonte de requisitos não-funcionais.
• Descrição detalhada de requisitos não-funcionais. 
• Planejamento de Gestão de Requisitos.
• Documento de Visão.
• Definição de atributos de requisitos.
• Gestão do escopo do projeto.
• Gestão de mudança de requisitos.
• Análise de riscos dos requisitos.
• Elicitação (identificação) de atores e casos de uso.
• Modelagem de casos de uso.
• Descrição detalhada de casos de uso (fluxos de eventos, pré e pós-condições, restrições, requisitos especiais, realização de regras de negócio e definição de atributos de casos de uso).
• Estruturação de modelos de casos de uso (include, extend).
• Regras de negócio.
• Glossário.
• Gestão da rastreabilidade.
• Empacotamento dos casos de uso.
• Processo de gestão de requisitos.
• Planejamento de Iterações.

Carga horária.

32 horas, distribuídas em 4 (quatro) sábados, de 9:00 até 18:00 horas com uma hora de almoço e dois coffee-breaks.

Local:

Veris – IBTA

Av. Paulista, 302, em frente a estação do metrô Brigadeiro.
São Paulo - SP. 

Data PREVISTA: 
Previsão para a primeira quinzena de Setembro/2011. 
Por ser um curso sob demanda, a data exata só será divulgada quando o número mínimo de alunos for alcançado. 
O curso será realizado em 4 (quatro) sábados. Horário: de 09:00 às 18:00 horas com intervalo de uma hora para almoço. 

Faça sua inscrição 

Fone:  (11) 9631-1247 begin_of_the_skype_highlighting            (11) 9631-1247      end_of_the_skype_highlighting;  
E-mail:  evandro@wm2info.com.br 

Regra de Negócio Não é Requisito de Software

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Um dos problemas mais comuns que encontro no gerenciamento de requisitos é a dificuldade que os analistas de negócio (analistas de requisitos ou de sistemas) têm em diferenciar requisitos funcionais de regras de negócio.

Segundo Leffingwell, “requisito de software é uma condição ou capacidade que deve ser atendida pelo sistema”. O IEEE estende um pouco mais essa descrição: “É uma condição ou capacidade que deve ser atendida pelo software, necessária a um usuário para solucionar um problema ou atender a um objetivo”.

O RUP define Regra de Negócio como “declarações sobre políticas ou condições que devem ser satisfeitas”. Note que, ao contrário do requisito, a descrição de regra de negócio não afirma que deve ser satisfeita pelo sistema (software). Regra de negócio é uma restrição imposta pelo negócio que regulamenta o comportamento de um procedimento operacional do negócio. São políticas definidas pela administração da empresa. São originárias das leis, portarias e normas definidas por órgãos governamentais.

Regras de negócio têm vida totalmente independente de sistemas. Podem ser criadas e obedecidas sem uso de sistemas. Como exemplo, podemos citar uma microempresa totalmente desprovida de computadores ou qualquer tipo de automação de processos de negócio. A administração da empresa definiu como política, que a venda a prazo só poderá ser feita para clientes adimplentes. Note que essa política restringe as operações de venda da empresa e não precisa de sistema para ser atendida.

Como se vê, uma regra de negócio pertence somente ao domínio do negócio. Entretanto, nada impede que regras de negócio venham a ser automatizadas, isto é, seja realizada por um sistema. Neste caso deverá haver alguma funcionalidade, ou seja, algum requisito funcional que realizará a regra de negócio.

Vamos supor que a administração da empresa (do nosso exemplo) resolva automatizar o processo de vendas. Assim, o sistema deverá possuir uma funcionalidade que conterá uma condição (“IF THEN ESE”) a qual irá verificar se o cliente é adimplente. Se for adimplente, então o sistema permitirá a venda. Caso contrário o sistema irá bloquear a venda para o cliente em foco.

Portanto, uma regra de negócio pode ser expressa no formato “IF THEN ELSE”. Isso não quer dizer, também, que todo IF THEN ELSE implícito em um fluxo de eventos dentro de um caso de uso represente uma regra de negócio. Um caso de uso pode ter implicitamente um ou mais IF THEN ELSE que não corresponda a regras de negócio, mas que conduzam a variações de comportamento do caso de uso.

Como exemplo, podemos citar um caso de uso de cadastramento de cliente, onde um evento do fluxo básico verifica que o cliente já está cadastrado. O analista de requisitos define um fluxo alternativo para descrever o comportamento adequado que impeça o cadastramento redundante do cliente. Note que existe, implicitamente, um IF THEN ELSE, o qual não corresponde a uma regra de negócio. Corresponde a uma restrição de integridade de banco de dados que impede redundância de clientes. Como se vê, nem todo IF THEN ELSE corresponde a uma regra de negócio, Contudo, toda regra de negócio pode ser descrita na forma na forma de IF THEN ELSE.

Em resumo, podemos caracterizar uma regra de negócio da seguinte forma:
• A sentença que descreve uma regra de negócio não possui um caráter verbal. Sua abordagem é restritiva. Sempre possui termos tais como, “se”, “sempre que”, “somente”, “só” ou “quando”.
• Restringe o processo operacional da empresa.
• É percebida pela administração da empresa.
• Não descreve como a regra será verificada nem como as operações deverão ser realizadas. Descreve somente o que o processo irá executar em função da regra.
• Sua descrição não pode conter elementos de soluções de tecnologia. Se você estiver descrevendo uma regra de negócio e sentir a necessidade de referenciar uma solução de sistema, com certeza se trata de um requisito de software e não de uma regra de negócio.
• Tem vida própria. Poderia ser atendida sem uso de sistema.
• Pertence ao domínio do negócio e não do sistema.
• Pode ser descrito no formato “IF THEN ELSE”.

Para concluir gostaria de salientar que uma regra de negócio não é um requisito funcional, mas um requisito funcional pode realizar uma regra de negócio.