Conteúdos - Página: 363 - Colaborar Portfólios

Vamos recordar os diagramas de classes?! Bem, eles mostram as classes do sistema, seus inter- relacionamentos, incluindo herança, agregação e associação e as operações e atributos das classes. Eles são usados para uma ampla variedade de propósitos, incluindo modelagem conceitual, de domínio e modelagem de projeto detalhado.

Os desenvolvedores não entendem os requisitos (convide os desenvolvedores a passarem um tempinho na operação, de preferência fazendo o papel do usuário, uma semana é o suficiente para eles entenderem tudo).

As partes interessadas do projeto exigem formalidade significativa em relação aos requisitos (evite essa armadilha, partes interessadas muitas vezes não conhecem toda a solução e querem garantias impossíveis, pedir por detalhamento é um tipo de transferência de responsabilidade. Num projeto ágil, os requisitos e a própria arquitetura vão se revelando aos poucos);

As partes interessadas do projeto estão excessivamente focadas em um tipo de requisito (reuniões do tipo Delphy ou Brainstorming ajudam a tirar essas travas);

Os desenvolvedores não entendem o domínio do problema (é importante os desenvolvedores estudarem o negócio em profundidade, não existe mais desenvolvedor “trancado numa sala”; eles precisam ter contato com a operação para amadurecerem e melhorarem seu entendimento sobre o negócio e sobre o mundo);

As partes interessadas do projeto não entendem os artefatos de modelagem. (conte uma história, pessoas se encantam com histórias, a técnica de story telling veio para ficar);

As partes interessadas do projeto têm medo de ser fixadas (é uma questão cultural, às vezes, é necessário tempo e confiança, afinal, as partes interessadas devem ter responsabilidades pelo bom andamento do projeto);

As partes interessadas do projeto não sabem o que querem (mais comum do que parece, nesse caso, seja um guia ou “terapeuta”);

Partes interessadas do projeto geograficamente dispersas (estão distantes em outras cidades, países ou regiões de difícil acesso. Nesse caso use reuniões remotas síncronas ou documentos como questionários);

Tome cuidado porque há desafios no processo de levantar requisitos e convertê-los em artefatos. Abaixo listo alguns, mas dê muita atenção a todos eles para não cometer essas faltas. Acesso limitado às partes interessadas do projeto (clientes e usuários);

Recomendo que você crie, inicialmente, todos os diagramas de caso de uso, como o demonstrado acima, para os cartões de história do usuário como requisitos e verifique se não falta nada, se há lógica e complementaridade e principalmente se o “bicho tem cabeça tronco e membros”.

Caso você esteja no nível mais inicial possível, ainda pode recorrer ao bom e velho, e sem dúvida alguma, muito útil, diagrama de caso de uso.

Por isso vemos tanta coisa sem sentido por aí, porque deixaram a critério do desenvolvedor algo que não é missão dele fazer. Lembre-se, [interface do usuário, front end e back end] são grandes atividade que se deve trabalhar seguindo padrões e metodologias porque uma depende da outra.

Nas fases posteriores, declare analiticamente como no segundo exemplo, afinal, fica difícil para um desenvolvedor saber o que ele tem que fazer sem as regras de negócios ou as telas da interface do usuário (camada de apresentação) que foram criadas.

Dessa forma, na fase inicial do planejamento, use casos de uso simples como o do primeiro exemplo para completar ou ilustrar os cartões de história do usuário para dar mais clareza.

Comunicação é tudo e, nesse caso, é preciso feedback com a equipe, porque quanto mais tempo você passar sem pedir feedback para o cliente/usuário, maior será o perigo de se modelarem coisas que não refletem o que as partes interessadas realmente precisam.

Se você realmente precisa desse nível de detalhe e, na prática, raramente o faz, pode capturá-lo quando realmente precisar.

Temos aqui a descrição do mesmo caso de uso totalmente documentado. Este é um exemplo maravilhoso de um caso de uso bem construído, mas apresenta muito mais detalhes do que você possivelmente precisa no primeiro momento.

Bem, você percebeu como é importante ser analítico, crítico e lógico nessa nossa profissão. A clareza e declaração sem ambiguidade são fundamentais quando estamos elicitando requisitos e/ou desenvolvendo casos de uso.

Porém, podemos detalhar isso, num caso de uso mais aprofundado, a que chamaremos de caso de uso expandido.

A descrição acima contém informações suficientes para você entender o que o caso de uso escrito faz e, na verdade, pode conter informações demais para este ponto do ciclo de vida, já que apenas o nome do caso de uso pode ser suficiente para que o time de desenvolvimento ou outra parte interessada entenda os fundamentos do que se pede.

O sistema valida se a disciplina se encaixa na trilha de aprendizagem do aluno; O sistema calcula e exibe as taxas para que o aluno pague por aquela disciplina; O aluno verifica o custo e indica que deseja se inscrever ou não; O sistema inscreve o aluno na disciplina e cobra por ela; O sistema imprime o comprovante de inscrição na disciplina quando o departamento de contas a receber der baixa no crédito.

O sistema valida se o aluno está qualificado para se inscrever naquela disciplina (pode haver disciplinas anteriores como pré-requisito). Se não for elegível, o aluno é convidado a escolher outra disciplina;

O sistema verifica se o aluno está qualificado para se inscrever no curso. Se não for elegível, o aluno será informado e o caso de uso será encerrado; O sistema exibe uma lista de disciplinas do curso disponíveis (naquele mês); O aluno escolhe uma disciplina ou decide não se inscrever;

Veja esse exemplo de um caso de uso geral: Nome do caso de uso geral (macro): Inscrever-se numa Disciplina Curso Básico de Ação (trata-se de um caso de uso normal): Aluno digita seu nome e número de aluno;

Mas afinal, que nível de detalhes você realmente precisa? Minha experiência é que você precisa de artefatos de requisitos que sejam bons o suficiente para lhe dar esse entendimento e nada mais, portanto, pense simples, porém direto.

Modelo de interface do usuário: para projetos intensivos de interface de usuário, você deve considerar o desenvolvimento de alguns esboços de tela, ou até mesmo um protótipo de interface de usuário. (conforme coloquei no tópico Wireframe desse material).

Seu modelo não precisa ser completo, ele só precisa cobrir informações suficientes para que você se sinta confortável com os conceitos de domínio primário. (coloquei literatura de referência na sessão de Material Complementar e deve ser mandatoriamente lida, por gentileza);

Este modelo de domínio conterá apenas informações suficientes: as principais entidades do domínio, seus principais atributos e os relacionamentos entre essas entidades.

Modelo de domínio inicial: identifica os tipos de entidade de negócios fundamentais e os relacionamentos entre eles. Os modelos de domínio podem ser descritos como uma coleção de cartões, um diagrama de classe macro, ou até mesmo um modelo de dados geral.

« Anterior 1 … 361 362 363 364 365 … 476 Próximo »