terça-feira, outubro 17, 2006

Requisitos - Aula 2

Olá! Agora estou postando a segunda aula de requisitos da série de apresentações que fizemos. Claro que boa parte do material foi apresentado oralmente frente a uma apresentação... o que segue é um resumo da seunda aula, mas que pode ajudar bastante. Na empresa temos um processo baseado no RUP, ou seja, uma customização, por isso pode have algo diferente do que você vê por aí em termos de artefatos, mas os conceitos são os mesmos! Abraço!


Resumo Requisitos – Aula 2


Artefato

Artefato é tudo aquilo que é gerado a partir de nosso trabalho a fim de documentação; é o produto gerado durante o desenvolvimento de software. Podemos citar como exemplo de artefatos o documento de visão, plano de projeto, relatórios de acompanhamento, diagramas de caso de uso, entre outros. Esses artefatos podem ser tanto consumidos quanto produzidos, resultantes da execução de uma atividade, estando presente em todo o ciclo de vida do desenvolvimento. Devemos evitar a negligência da documentação, fato que ocorre por diversos motivos e fazem com que os desenvolvedores deixem-na em segundo plano.

Glossário

Mesmo sendo produto da atividade de “Elicitar Requisitos”, pode ser atualizado a qualquer momento do projeto. Por alguns termos do projeto serem de difícil interpretação, o glossário surge para facilitar a comunicação e capturar um vocabulário comum para que qualquer pessoa possa ler e entender a documentação, evitando desentendimentos. Os termos do glossário podem estar agrupados e organizados de diversas formas, normalmente por ordem alfabética ou por assunto. Ex:
Acordo de Barreiras Técnicas (TBT)
Acordo multilateral que visa eliminar as barreiras técnicas, que dificultam o comércio internacional. Foi instituído na Rodada Uruguai e é gerenciado pela OMC.

Documento de Visão

Pertencente à atividade “Elicitar Requisitos”, o documento de visão tem o propósito de expor as necessidades e seus motivos, e as funcionalidades gerais (soluções para as necessidades), objetivos e restrições da aplicação. Há dois tipos de documento de visão: o de projeto, que documenta as necessidades e funcionalidades alteradas ou afetadas no projeto, ou de sistema, de detém todas as necessidades e funcionalidades do sistema e deve ser alterado/atualizado a cada projeto.
A diferença física entre os dois tipos de projeto, é que o documento de visão de projeto possui:
  • Posicionamento
  • Partes interessadas
  • Restrições
  • Expectativa de entrega
Partes do Documento de Visão

Na composição de um documento de visão observamos:
  • O cenário, que nada mais é que a situação atual com que se encontra o cliente e o motivo pela construção do sistema.
  • A oportunidade de negócio oferece uma visão do que o projeto proporcionará, em virtude do cenário atual.
  • As partes interessadas (stakeholders) são todos aqueles envolvidos ou beneficiados pelo projeto e pelo sistema, influenciando em seu desenvolvimento (cliente, desenvolvedores)
  • Os atores são todos os que utilizam diretamente o sistema que está sendo especificado, podendo ser tanto uma pessoa quanto uma máquina ou um outro sistema (usuário [sistema específico], usuário Polícia Federal, impressora, [sistema de autenticação central])
  • As necessidades e funcionalidades que, como já abordado, oferecem, respectivamente, uma visão dos problemas ou motivos que o cliente possui e as soluções para isto.

Modelo de Diagrama

Descreve os diagramas da UML (Unified Modeling Language) que o sistema irá possuir. Mantém a conexão entre os casos de uso com os diagramas de classe e de interação, oferecendo rastreabilidade entre eles. Os diagramas são elaborados utilizando a ferramenta Rational Rose.

Os casos de uso especificam o comportamento do sistema a ser desenvolvido, as funções da aplicação que caracterizam as funcionalidades do sistema, mas não a maneira com que será implementado. O diagrama de caso de uso é descrito como na UML, ou seja, tem a finalidade de facilitar o entendimento do grupo de desenvolvimento fazendo com que sua interpretação seja correta e sem ambigüidade dos modelos gerados por outros analistas.

A interação entre o caso de uso e um ator ou outro caso de uso é feita por uma linha ou seta (que simboliza quem inicia).

No caso de uso temos os relacionamentos de:
  • Inclusão, que sugere uma ação obrigatória do caso de uso chamado no caso de uso base. Este tipo de relacionamento, que evita escrever o mesmo comportamento várias vezes, é simbolizado por uma seta tracejada partindo do caso de uso base para o caso de uso chamado; opcionalmente, mas por padrão, utiliza-se o estereótipo <> ao lado da seta.
  • Extensão, que sugere uma ação opcional/condicional do caso de uso estendido durante as ações do caso de uso base. Este tipo de relacionamento é também representado por uma seta tracejada, porém, parte do caso de uso estendido para o caso de uso base; também utiliza-se o estereótipo <>.
  • Generalização, indica que um caso de uso ou um ator possui características comuns a outros, e assim estes, chamados de “pai” (generalizado), são referenciados por uma seta vazia (triângulo) vindas dos casos de uso ou atores “filhos” (especializados) que possuem características ou comportamentos próprios, mas que herdam outras do elemento geral.

Relação de Casos de Uso

Apesar de não ser obrigatório, é um documento que possui a representação gráfica de todos os casos de uso que compõem o sistema, além do nome e a descrição sucinta de cada caso de uso presente no diagrama.
As informações nele presentes podem ser encontradas nos artefatos Modelo de Diagrama e Matriz de Atributos (Casos de Uso).

As informações contidas neste artefato podem ser obtidas automaticamente pelas ferramentas Rose (Diagrama de Interação) e RequisitePro – Matriz de Atributos (Casos de Uso). Desta forma, para que não haja o risco de inconsistência devido à cópia de informações, será opcional para os que estiverem utilizando as ferramentas acima citadas. Pode também ser inserido um link para o diagrama no Rose.

Esse documento será utilizado para relação de todos os casos de uso. Os casos de usos já especificados em ECU não estarão marcados como requisitos de [Ferramenta para Gestão de Requisitos]. Marcaremos apenas os requisitos do legado, para a composição de rastreabilidade mínima.

Um comentário:

Daniel disse...

1. Fred Says:
Março 14th, 2007 at 16:07 e

Daniel, encontrei o sei blog por acaso pesquisando informações sobre cmmi e resolvi dar uma olhada em outras informações.

Acabei observando que você se equivocou na definição de artefatos. De acordo com o RUP “Um artefato é um produto de trabalho do processo: os papéis usam os artefatos para executar atividades e produzem artefatos ao executarem as atividades”

“Os artefatos podem ter vários formatos ou formas:

Um modelo como o Modelos de Caso de Uso ou o Modelo de Design, que contém outros artefatos.
Um elemento do modelo, isto é, um elemento dentro de um modelo, como uma Classe de Design, um Caso de Uso ou um Subsistema de Design
Um documento, como o Caso de Negócio ou o Documento de Arquitetura de Software
O código fonte e executáveis (tipos de Componentes)
Os executáveis”

Espero ter ajudado.

[]’s

Fred
2. Daniel Says:
Março 15th, 2007 at 8:20 e

Muito obrigado Fred. Seu comentário complementa a definição, já que o resumo postado não contém exemplos.
Abraço!