Requisitos e Modelos: colaborando para o entendimento da necessidade

Transcrição

1 Requisitos e Modelos: colaborando para o entendimento da necessidade Falar da importância de conhecer e entender as necessidades do cliente em um projeto de desenvolvimento de software é chover no molhado. Porém, nem sempre ter tais informações traduzidas na forma de requisitos garante o perfeito entendimento. Neste sentido, é preciso derivar modelos que, de forma visual, contribuam fortemente no esclarecimento sobre o que se espera do software. Tendo como ponto de partida a coleta e a transcrição das necessidades do cliente, ou seja, as atividades de elicitação de requisitos, utilizamos o Borland Caliber DefineIT, que nos ajuda fortemente nesta tarefa. Com ele escrevemos cenários que explicitam o que acontecerá com uma determinada funcionalidade e, automaticamente, é gerado um diagrama visual com o fluxo de ações que tal funcionalidade irá percorrer. Como exemplo desta situação, criamos um projeto no Borland Caliber DefineIT chamado Gestão Hospitalar e em seguida o requisito Autenticar Usuário.

2 Figura 01 Novo requisito (Autenticar Usuário) Para este requisito descrevemos um cenário em forma textual, o que normalmente é feito em uma atividade de definição de requisitos.

3 Figura 02 Descrição dos Passos do Cenário Ao finalizarmos a descrição do requisito, o Borland Caliber DefineIT gera automaticamente um digrama do cenário descrito, o que possibilita percebermos visualmente qual o fluxo de informações no momento da autenticação do usuário.

4 Figura 03 Cenário e Diagrama Isso é apenas o começo, pois as atividades de definição evoluem com novas interações com o usuário, pesquisa de documentos e a especificação propriamente dita. A conseqüência disso é um aumento do nível de detalhes em relação aos requisitos e as informações a serem passadas ao time de desenvolvimento de software se tornam ainda mais claras. Para exemplificar, no cenário visto através da figura 03, não conseguimos identificar claramente um tratamento de erro em caso de insucesso na autenticação do usuário. Porém, com a evolução do requisito (ver figura 04) já percebemos uma etapa de decisão que determina qual a ação será tomada em caso de erros. Figura 04 Cenário já evoluído e visualmente percebido

5 Esse processo evolutivo dos requisitos acontece fortemente no início dos projetos, o que não implica em desaparecimento ao longo do tempo, pois mudanças com certeza irão acontecer e os requisitos continuarão a evoluir. Seguindo essa linha de contínua evolução e considerando os requisitos como um dos alicerces da qualidade do software a ser entregue, temos que, de forma tranqüila, sairmos do mundo dos requisitos e entrarmos no mundo dos modelos e arquitetura, pois o alinhamento da esfera de negócio com a técnica é extremamente dependente dessa passagem de bastão. Como podemos verificar, começamos um trabalho em relação ao o quê será feito e estamos no ponto de passarmos a pensar em como fazer o software. Nesta transição, entra na jogada o Borland Together, que é uma ferramenta de modelagem visual criada para apoiar os arquitetos, desenvolvedores, designers de UML, analistas de processos de negócios e modeladores de dados na criação acelerada de aplicações de software de alta qualidade. Quer você esteja mudando processos de negócios, criando novas aplicações ou extraindo informação de design de sistemas existentes, o Together dá aos envolvidos no projeto uma compreensão visual comum das importantes decisões com impacto sobre o design da arquitetura do software. Para tornar isso real, a partir do DefineIT criamos artefatos no formato de trabalho no Together, os quais serão abertos e evoluídos por este.

6 Figura 05 Exportação do DefineIT para o Together

7 Figura 06 Importação dentro do Together Ao término dessa transferência, teremos no Borland Together um projeto criado e uma série de artefatos já gerados a partir da definição inicial.

8 Figura 07 Artefatos no Together e oriundos do DefineIT De posse dos artefatos oriundos do DefineIT, as pessoas envolvidas com a modelagem podem usar toda a potencialidade do Borland Together para evoluir ainda mais os diagramas e torná-los mais completos para as atividades de desenvolvimento propriamente ditas. Temos claro que as informações descobertas no momento do levantamento podem facilmente se tornar artefatos iniciais para o processo de modelagem e, consequentemente, desenvolvimento. Além disso, tais modelos podem e devem ser apresentados aos responsáveis de negócio para certificar se os artefatos conceituais (diagrama de caso de uso, por exemplo) estão efetivamente de acordo com as necessidades impostas pelo negócio que o software pretende atender. Sendo assim, tendo a garantia que a propagação das informações não será um telefone sem fio e que o software será trabalhado com um perfeito entendimento sobre o que deve ser atendido, podemos afirmar categoricamente que menos erros serão encontrados e, é óbvio, um maior nível de qualidade será atingido. Robinson Caiado é Bacharel em Ciência da Computação pela Universidade Federal de Uberlândia e Pós- Graduado em Gestão de Projetos PMI pela CPLAN. Com 10 anos de experiência no mercado de TI, atualmente atua em consultorias especializadas em gestão de projetos, gestão de requisitos e gestão de configuração de software e também como instrutor oficial pela Borland Latin America.