quinta-feira, 22 de março de 2012

Como descrever casos de uso - Parte 4

Nosso blog está mudando de endereço. Acesse.


Durante a modelagem de casos de uso uma das coisas mais importantes é descrever o comportamento de cada caso de uso. Essa descrição é também chamada de Especificação de Caso de Uso.
RUP define um template que indica os itens que devem compor a especificação. Esse template é bastante extenso, mas eu sempre o uso como base para sugerir um template mais simples e ágil....

sexta-feira, 2 de março de 2012

Como elicitar Casos de Uso? Parte 3


Dando continuidade à sequência de posts sobre casos de uso, vou comentar agora sobre a importância da obtenção de valores agregados ao negócio na elicitação de casos de uso.

Um dos pontos mais críticos em uma gestão de requisitos com casos de uso é a correta elicitação dos casos de uso. Na hipótese disso não ser muito bem feito, trará conseqüências desastrosas à eficácia do projeto.

Um caso de uso pode ser identificado respondendo a seguinte pergunta feita a um usuário: O que você pretende obter usando o sistema? A resposta que ele dará é algo relacionado ao resultado de valor que ele espera obter ao usar o sistema. Na verdade, a modelagem de casos de uso é a arte de identificar valores que o sistema deve agregar ao negócio. Por isso quando estamos elicitando casos de uso, devemos estar muito atentos para que todos esses resultados de valor sejam obtidos. Nossa preocupação é fazer com que o conjunto dos casos de uso que modelarmos, entregue todos esses valores esperados. O escopo de cada caso de uso está fortemente associado à obtenção de valores agregados ao negócio.

Leia mais acessando nosso novo endereço:  

quarta-feira, 29 de fevereiro de 2012

Estamos mudando para outro endereço.

Prezado leitor.

Estamos mudando para um outro endereço:

www.wm2info.com.br
ou
www.evandrionico.com.br

Aguardo você no nosso site.

Abraço

Evandro Moreira Pinto

Treinamento em Análise-Design de Serviços com SOAML

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

A Análise-Design é um disciplina da Engenharia de Software de fundamental importância para a elaboração da arquitetura da aplicação a ser desenvolvida, bem como para definir os modelos necessários que irão guiar todo o processo de implementação e implantação. Podemos dizer que se trata da “Planta Baixa” do sistema a ser desenvolvido.
Da mesma forma que a construção de uma casa, edifício ou qualquer tipo de edificação, necessita de um projeto arquitetônico e um projeto detalhado de construção, o software também necessita de um conjunto de modelos que são criados com uso de boas práticas de Análise-Design.
O conceito de Orientação a Serviços agrega valor à Análise-Design, trazendo uma capacidade maior de distribuir os Serviços em nuvens que podem estar cada vez mais espalhadas em provedores de Serviços especializados. Com essa realidade cada vez mais presente, profissionais de tecnologia precisam estar aptos a lidar com esta realidade e capazes de projetar sistemas e modelos de Serviços adequados a cada situação.
O curso iniciará com uma recapitulação dos conceitos de Análise-Design OO, UML e Modelagem de Processos de Negócio, assuntos que são pré-requisitos para a elicitação e especificação de Serviços com SOAML.
SOAML é uma extensão da UML, definida pela OMG – Object Management Group, usada na modelagem de Serviços em uma Arquitetura Orientada a Serviços (SOA).
O curso proverá conhecimentos sobre padrões e modelos necessários para compreender, identificar e produzir especificações de Serviços para o desenvolvimento de softwares em uma Arquitetura Orientada à Serviços.
Público Alvo
Analistas, arquitetos, desenvolvedores e líderes de projeto com formação e/ou experiência na área de Tecnologia da Informação e que desejam conhecer especialmente a Análise e Design de Web Services e a construção de Modelos de Serviços utilizados para viabilizar sua implementação.
Programa
  • Revisão de conceitos sobre Análise e Design em Orientação a Objetos
  • Revisão de conceitos sobre UML
  • Fundamentos de SOA
  • Conceitos Básicos sobre Processos de Negócio
  • Padrões Fundamentais de Definição de Serviços
  • Técnicas de Identificação Serviços Candidatos e Hierarquia de Serviços
  • Orientação a Serviços e Separação de Interesses
  • Princípios aplicados à modelagem de serviços
  • Processo de Especificação e Modelagem de Serviços
  • Camadas Lógicas de Abstração de Serviços e Classificação de Modelo de Serviços
  • Tipos e Escopos Comuns de Granularidade
  • Conceitos fundamentais de Web Services
  • Protocolos fundamentais para utilização de Web Services
  • Padrões de interoperabilidade adotados no mercado
  • Estudo de Casos
  • Exercício Prático
Ferramenta utilizada:
  • Enterprise Architect (EA)
Data de Início
Trata-se de um curso sob demanda, ou seja, a data de início é definida quando o número de inscritos atingir o mínimo necessário para a formação da turma. A data prevista para início é: 17/03/2012 (17, 24, 31/03 e 14/04). Não haverá aula no dia 07/04 devido à semana santa. Esta data poderá ser alterada.
Carga horária
32 horas (4 sábados de 8 horas) de 09 a 18:00 horas com uma hora de intervalo para almoço.
Será oferecido dois coffeebreaks por sábado. Almoço e estacionamento serão de responsabilidade do aluno.
Local
Laboratório da Veris – IBTA do Grupo IBMEC. Av. Paulista, 302, (em frente a estação do metrô Brigadeiro); São Paulo – SP.
Professor
Gregório Momm
Com uma longa experiência no desenvolvi-mento de softwares, trabalhou em mais de 50 diferentes projetos em plataformas variadas desde dispositivos móveis, aplicações Web, sistemas em Mainframe e outros. Bacharel em Ciência da Computação e Desenvolvimen-to de Software, cursou Unicamp e Universi-dade Anhembi Morumbi, trabalhando na IBM desde o ano 2001, atualmente  Arquiteto de Software com atuação em diversos projetos que utilizam Arquitetura Orientada à Serviços.

terça-feira, 28 de fevereiro de 2012

WM2info lança curso de Análise-Design de Serviços com SOAML

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


A Análise-Design é um disciplina da Engenharia de Software de fundamental importância para a elaboração da arquitetura da aplicação a ser desenvolvida, bem como para definir os modelos necessários que irão guiar todo o processo de implementação e implantação. Podemos dizer que se trata da Planta Baixa do sistema a ser desenvolvido.

Da mesma forma que a construção de uma casa, edifício ou qualquer tipo de edificação necessita de um projeto arquitetônico e um projeto detalhado de construção, o software também necessita de um conjunto de modelos que são criados com uso de boas práticas de Análise-Design.

A WM2info está lançando um curso de Análise-Design de Serviços com uso de SOAML. Será feita uma recapitulação dos conceitos de Análise-Design OO, UML e Modelagem de Processos de Negócio, assuntos que são pré-requisitos para o curso. SOAML é uma extensão da UML, definida pela OMG – Object Management Group que é usada na modelagem de Serviços em uma Arquitetura Orientada a Serviços (SOA).

Para ministrar esse curso, convidamos o Gregório Momm, Arquiteto de Software e Arquiteto Empresarial da IBM, possuidor de larga experiência com mais de 50 (cinqüenta) projetos que utilizam Arquitetura Orientada a Serviços (SOA) e plataformas variadas, tais como dispositivos móveis, aplicações WEB, Mainframe e outros.

Gregório Momm também é Professor em cursos de Pós-Graduação da VERIS – IBTA do Grupo IBEC, palestrante e instrutor em Arquiteturas de Software e Empresarial.

Seja bem vindo Gregório.


quarta-feira, 1 de fevereiro de 2012

Que é Caso de Uso? - Parte 2

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

Dando prosseguimento à sequência de publicações que estou fazendo sobre Requisitos de Software, pretendo nesta segunda parte tratar do assunto Caso de Uso, porque é uma ferramenta que tem sido usada em todo o mundo. Corretamente usada, ou não, mas tem sido de enorme valia para projetos de desenvolvimento de sistemas de grande porte e de elevado grau de complexidade para alta e baixa plataformas.

Afinal de contas, o que é Caso de Uso? Existem algumas descrições que busquei na literatura para deixar claro e de forma inequívoca seu significado. Foram obtidas de autores de renome e fontes de aceitação internacional.

• A OMG – Object Management Group, conforme a UML Superstructure Specification, v2.0, Casos de Uso são meios para a especificação de usos necessários de um sistema. Normalmente, eles são usados para capturar os requisitos de um sistema, isto é, o que um sistema é suposto fazer. Observe que a OMG aborda o aspecto voltado para a captura de requisitos de software.

• Kurt Bittner no seu livro “Use Case Modeling”, afirma que Caso de Uso é uma técnica poderosa de modelagem de requisitos. Note que o autor salienta mais uma faceta do Caso de Uso, ou seja é uma técnica que pode ser usada na captura de requisitos de software.

• O RUP, por que vez, classifica Caso de Uso como um artefato. Neste ponto de vista o Caso de Uso é apresentado como um produto de trabalho que possui um ciclo de vida composto de fases que inicia na sua elicitação e termina na forma de um artefato implementado, testado e entregue ao usuário para uso operacional. Deve ser gerenciado como um importante Item de Configuração.

• O RUP acrescenta ainda um outro conceito, que descreve um conjunto de instâncias formadas por sequências de ações realizadas pelo sistema para produzir um resultado de valor observável pelo ator. São interações formando um diálogo entre o Usuário e o Sistema. Essa é a forma mais popular de entendimento do que significa Casos de Uso. Esse diálogo conta uma Estória de relacionamento entre o Usuário e o Sistema. Guarde esse termo “Estória”, pois iremos usá-la posteriormente nas próximas publicações que farei.

• Cockburn, no seu livro “Escrevendo Casos de Uso Eficazes” afirma que um Caso de Uso captura um contrato entre os stakeholders de um sistema sobre seu comportamento. É interessante notar que, usando Casos de Uso, podemos discutir soluções sem necessitar entrar em detalhes de implementação. Particularmente acho isso sensacional, porque nos permite concentrar nossa atenção na obtenção do valor esperado pelo usuário. Nesta ocasião, não estamos preocupados com telas e qualquer tipo de solução de interface gráfica. Estamos preocupados na eficácia do projeto, ou seja, em produzir o resultado de valor do ponto de vista do negócio.

• Cockburn afirma ainda que “casos de uso não especificam interfaces externas, formatos de dados, regras de negócio e fórmulas complexas. Eles constituem somente uma fração (talvez um terço) de todos os requisitos que você precisa coletar – uma fração muito importante, no entanto, uma fração”. Acho essa definição sensacional porque simplifica a especificação dos Casos de Uso, não descrevendo esses elementos (interfaces gráficas, tipos de dados, requisitos não-funcionais, regras de negócio, etc.). As Especificações de Casos de Uso referenciam esses elementos, mas não os descrevem.

Todas as definições acima listadas podem ser resumidas da seguinte forma sobre Casos de Uso:
• É uma técnica usada para a captura de requisitos do sistema.
• É um artefato que deve ser gerenciado como um item de configuração.
• Descreve interações entre o Usuário e o Sistema.
• Descrevem “cláusulas contratuais” entre o usuário e o projeto de desenvolvimento.
• Sua especificação não envolve a descrição de interfaces do usuário, interfaces com outros sistemas, tipos de dados, requisitos não-funcionais, fórmulas complexas e regras de negócio.

Percebo muito claramente os seguintes problemas na Modelagem de Casos de Uso.

1. Os templates usados na descrição dos casos de uso possuem itens desnecessários e contribuem fortemente para que as especificações sejam “gordas”. Noto que alguns analistas de qualidade dão muita atenção à forma, ou seja, à qualidade que eu, evandrionicamente, chamo de “qualidade cosmética”. Esquecem da essência do caso de uso, a qual é a produção do resultado de valor esperado pelo usuário (ainda vou falar muito sobre isso nos próximos posts). A Gestão da Qualidade deve se preocupar com o conteúdo, garantindo que o conjunto dos Casos de Uso entregará os valores esperados pelos stakeholders. A palavra chave é “Valor”. Perde-se muito tempo e esforço no preenchimento obrigatório de campos. Já vi templates que obrigam o analista a justificar porque não está preenchendo um determinado campo que é considerado obrigatório, fazendo com que seja gasto um tempo valioso na tentativa de dar a justificativa exigida pela “qualidade”. Isso é um absurdo. É por isso que eu odeio templates. Veja uma crônica que postei algum tempo atrás sobre esse assunto.

2. Tenho percebido que interfaces gráficas (telas), produzidas a partir de especificações detalhadas de Casos de Uso, são modificadas quando apresentadas ao Usuário para validação. É válido notar que a descrição (detalhada) desses casos de uso já tinha sido validada pelo próprio Usuário. Isso mostra que o detalhamento das interações Usuário X Sistema na especificação de casos de uso, nem sempre tem sido eficaz, porque não é visual. Um protótipo de tala (que é visual) é extremamente mais eficaz do que um texto, por mais detalhado que seja. Por isso, recomendo fortemente que não gastem esforços e tempo no detalhamento das interações Usuário X Sistema. A especificação dos Casos de Uso deverá descrever o essencial, o suficiente para dar a percepção de que o produto de valor esperado pelo Usuário será entregue na ocasião em que ele executar o Caso de Uso. Tenho aplicado essa abordagem em vários projetos e obtido agilidade e melhoramento nas comunicações com os Usuários, Web Designers, Arquitetos, Projetistas e Desenvolvedores. Nos treinamentos que ministramos abordamos largamente todos esses aspectos.

3. A inserção de soluções de tecnologia na especificação de Casos de Uso traz problemas de sustentabilidade. Em outras palavras, os casos de uso, por si só, não se sustentam porque quando chegam na fase de design, frequentemente a tecnologia especificada no Caso de Uso é incompatível com os padrões gráficos ou padrões de navegação usados no projeto. Ocorre, nesta ocasião, um conflito. O que deve prevalecer? O que está especificado no Caso de Uso ou que já está padronizado e combinado com a Empresa contratante do projeto? Certamente, o que irá prevalecer é o padrão que foi definido pelos Web Designers e Arquitetos em conjunto com a equipe técnica da empresa contratante. Esses detalhes de implementação não são de conhecimento dos Analistas de Negócio. Por isso os Casos de Uso precisarão ser alterados para ficar corretos. Isso consumirá recursos, tempo, elevando o custo e reduzindo a produtividade, que é tudo que não queremos. É por isso que muita gente por aí, ingenuamente, joga a culpa nos Casos de Uso. A culpa não está na técnica, e sim naquele que usou erroneamente a técnica.

4. A UML é uma notação que possui itens de estrutura, de comportamento, de agrupamento e de anotações. Tenho observado que profissionais com pouco conhecimento em UML, tendem a inserir na especificação de Casos de Uso, todos esses itens que serão definidos ao longo do ciclo de vida do projeto. Isso eleva desnecessariamente a complexidade do Caso de Uso, além de não resolver o problema de comunicação com a equipe de desenvolvimento, porque geralmente esses elementos adicionais são incompletos e descritos de forma ambígua e inconsistente. Percebi que isso ocorre porque o RUP diz que o Modelo de Casos de Uso influencia na elaboração de todos os demais modelos desenvolvidos (quando é desenvolvido) ao longo do projeto. O RUP está correto, mas isso não significa que elementos desses modelos devam constar da especificação dos Casos de Uso. Modelo de Caso de Uso é uma coisa, Modelo de Design é outra coisa, Modelo de Implementação também é outra coisa, e assim por diante. Esses modelos possuem elementos que realizam os Casos de Uso, mas isso não significa que fazem parte da especificação dos Casos de Uso. Lembrem-se do que Cockburn afirmou (veja acima) que Casos de Uso capturam somente um terço dos requisitos de um sistema. Os demais requisitos são capturados através de outras técnicas e artefatos. Casos de uso não é uma panacéia que veio para resolver todos os problemas da Engenharia de Software. É simplesmente um item de um dos 13 (treze) diagramas oferecidos pela UML.

Conclusão.
• A agilidade em um projeto é obtida, não na pressa, mas nas mínimas coisas, ou seja, na forma que os artefatos são produzidos e principalmente na comunicação. Lembrem-se sempre disso, a comunicação é um dos maiores pontos de atenção de um projeto, pois é fonte de muitos riscos.
• Nunca misture elementos de diferentes níveis de abstração em um único artefato. Por exemplo: Não insira soluções de tecnologia em um documento que deveria abordar aspectos conceituais. Soluções de tecnologia pertencem ao nível de abstração de implementação. Casos de Uso pertencem ao nível de abstração conceitual. É como óleo e água. Não se misturam.
• Caso de uso é uma ferramenta gerencial e operacional. Ela é excelente para o Gerenciamento de Escopo de projetos de software. Com uso do conceito de rastreabilidade, poderemos facilmente gerenciar mudanças de requisitos, tão frequentes nos projetos que participamos.
• Casos de Uso permitem a captura de requisitos. Isso não quer dizer que todos os requisitos capturados são descritos na Especificação dos Casos de Uso. Existem artefatos apropriados para cada tipo de requisito, regra de negócio, estrutura de dados, interfaces gráficas, etc.
• O objetivo da Modelagem de Casos de Uso não é definir as interfaces gráficas e sim definir os valores que o sistema irá produzir para o negócio. Esta é a essência da modelagem de casos de uso. Um bom Modelo de Casos de Uso se converte em um guia para a elaboração do Modelo de Design, Modelo de Implementação, Modelo de Implantação (deploy) e Modelo de Processos da aplicação. O conjunto desses modelos forma o Modelo de Visões Arquiteturais 4+1, que é o cerne da arquitetura de uma aplicação.
• Para concluir gostaria de deixar a seguinte mensagem: “Tudo que for fazer, faça-o com agilidade. Agilidade não é fazer as coisas apressadamente. Agilidade é fazer somente as coisas essenciais”.

BIBLIOGRAFIA.
1. Bittner, K; et. al.; Use Case Modeling; Addison-Wesley; 2003.
2. Jacobson, I., Spence, I., Bitnner, K.; Use Case 2.0 – The Guide to Succeeding with Use Cases; Ivan Jacobson International, Dez/2011.
3. OMG – Object Management Group; UML Superstructure Specification, v2.0.
4. Cockburn, A.; Escrevendo Casos de Uso Eficazes. Bookman, 2001.
5. BOOCH, G.; et al.; UML Guia do Usuário; Editora Campus; 2005.
6. RUP – Rational Unified Process. Versão 2002.


terça-feira, 24 de janeiro de 2012

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

terça-feira, 15 de novembro de 2011

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

quinta-feira, 4 de agosto de 2011

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.

segunda-feira, 28 de fevereiro de 2011

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