terça-feira, 16 de novembro de 2010

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 




segunda-feira, 15 de novembro de 2010

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.