No post anterior discutimos a respeito dos problemas comuns existentes com os requisitos de software.
Visando reduzir os problemas existentes com requisitos de software, gostaria de lhes apresentar uma série de posts que tratarão de conceitos e técnicas que podem ser aplicados para minimizar as divergências com os requisitos.
Hoje, gostaria de lhes apresentar uma primeira etapa de conceitos que aborda o Gerenciamento de Requisitos de Software e seus aspectos relevantes que devem ser considerados para iniciarmos a organização dos requisitos de software.
Gerenciamento de Requisitos de Software:
O gerenciamento de requisitos trata-se de uma abordagem sistemática para se obter, organizar e documentar os requisitos do sistema. Além disso, é um processo que possibilita manter um acordo entre o cliente e a equipe do projeto sobre a evolução das necessidades do sistema (LEFFINGWELL; WIDRIG, 2000).
O processo de gerenciamento de requisitos visa compreender e controlar as mudanças nos requisitos do sistema. Este processo é realizado juntamente dos demais processos de engenharia de requisitos. O planejamento deve ser realizado ao mesmo tempo em que os requisitos estão sendo levantados e o gerenciamento dos requisitos deve ser iniciado após ter um esboço do documento de requisitos (SOMMERVILLE, 2003).
O planejamento é a primeira etapa do processo de gerenciamento de requisitos. Estabelece o nível de detalhamento necessário para realizar o gerenciamento de requisitos (SOMMERVILLE, 2003).
O processo de gerenciamento de requisitos visa compreender e controlar as mudanças nos requisitos do sistema. Este processo é realizado juntamente dos demais processos de engenharia de requisitos. O planejamento deve ser realizado ao mesmo tempo em que os requisitos estão sendo levantados e o gerenciamento dos requisitos deve ser iniciado após ter um esboço do documento de requisitos (SOMMERVILLE, 2003).
O planejamento é a primeira etapa do processo de gerenciamento de requisitos. Estabelece o nível de detalhamento necessário para realizar o gerenciamento de requisitos (SOMMERVILLE, 2003).
Para realizarmos o gerenciamento de requisitos, precisamos estabelecer alguns aspectos básicos (SOMMERVILLE, 2003):
-Identificação dos Requisitos: Cada requisito precisa ser identificado de forma única para facilitar a realização de rastreamento entre requisitos. Basicamente, cada requisitos precisa ter um “ID” que o identifica e eles nunca deve se repetir;
-Processo de Gerenciamento de Mudanças: Trata-se de um conjunto de atividades que avalia o impacto e o custo das mudanças;
-Políticas de Facilidade de Rastreamento: Definem relações entre requisitos e o projeto de sistema que devem ser registrados e também como devem ser mantidos;
-Suporte de Ferramentas CASE: Como o processo de gerenciamento de requisitos envolve uma grande quantidade de informações, deve-se determinar uma ferramenta para facilitar o trabalho.
Na segunda parte, pretendo lhes apresentar como é realizado o rastreamento de requisitos de software.
Cordialmente,
Marcelo Schumacher
Bibliografia:
LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements: a Unified Approach. Indianapolis: Pearson Education Corporate Sales Division, 2000.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Prcesso de Desenvolvimento (Uma questão de abstração e Idealização)
ResponderExcluirComo sabemos todo projeto deve começar tendo um profissional que relacione-se com o cliente de forma humana para absorver com clareza uma visão geral do que ele precisa. Após deve-se este Analista de Negócio uma comunicação eficaz com o Analista de Sistemas, profissional com competência técnica sólida e habilidades humanas também, que irá abstrair essa idéia de negócio e começara a definir os cenários e os atores necessários.
Apartir desse ponto começara pela parte mais fundamental, a camada de base de dados. Definindo a modelagem e especializando para deixar de modo bem legível identificando um atributo dessa futura tabela que será único (chave primária) para poder se relacionar com outros futuras tabelas onde terá um campo ID também. Relação entre as tabelas é geralmente feita com uma tabela de relacionamento entre esses dois pacotes de requisitos. Claro nessa breve descrição não entramos em detalhes técnicos como cardinalidade onde podemos definir neste exemplo que um profissional poderá atuar em vários departamentos.
Mas evitando nos aprofundarmos no tópico sobre a camada de Base de Dados sigamos nosso raciocínio.
Definido o esqueleto das tabelas cabe ao DBA criar tabelas, stored procedures etc.
Agora passamos para a equipe de camada de interface com o usuário a parte de decidir
qual a maneira mais ergonomica e/ou quais padrões e nomenclaturas seguir ficando a responsabilidade do analista de sistemas descrever previamente quais campos
cada tela deverá ter afim de a camada de Interface com o usuário possa através da
camada de aplicação se comunicar com a base de dados.
Finalmente, chegamos nesse exemplo que trata de um sistema de 3 camadas, a chamada
regra de negócio onde o Analista de Negócios registrou toda a idéia desse 'business' documentando tudo que cada etapa deve fazer, como funciona toda a lógica que o cliente solicitou. Nesse ponto definimos como fazer o Projeto tendo em mente a segurança, estabilidade, custo, capacidade intelectual do time e tipo de aplicação. Após as definições de Business inici-se a tarefa de fazer o esqueleto de todo o sistema. Definimos quais as variavéis de cada cenário, atributos de cada personagem e as ações, eventos que irão acontecer (Eventos,Métodos ou Funções(dependendo da ferramenta utilizada)).
Uma vez a engenharia e a arquitetura esboçadas e definidas começamos a obra.
Distrui-se para a equipe de desenvolvedores as atividades. Esses profissionais, os mais técnicos, recebem o esqueleto definido de cada bloco que recebeu como atividade e codifica as ações da forma mais legível e que apresente o melhor desempenho sempre com o auxílio do analista de sistemas e do analista de testes que também deve participar de todo processo para definir as rotinas de depuração desse sistema afim de garantir a qualidade.
Uma vez as atividades pré-concluídas passa por uma nova revisão e validação para entrega e conclusão da atividade.
Como o próprio artigo trata devemos sempre ter todas as etapas e atividades bem documentadas pois nas tarefas de manutenção precisamos poder rastrear etapas, módulos e atividades feitas. Existem várias ferramentas para gerenciar processos, um exmplo é o Microsoft Project 7, e gerar relatórios de documentação do que foi feito com datas específicas e descrições que facilitem o entendimento para uma necessidade de mudança ou manutenção devido a uma falha de comunicação com o cliente por exemplo.
Entendo que o presente artigo trata de assuntos de requisitos procurando ser o mais breve porém abrangente.
Acabamos, com esse comentário, nos extendendo do tema proposto mas isso se deve a empolgação do comentador e fica o agradecimento pelo espaço disponível. Ah, e estudarei essas Ferramentas CASE para uma futura discussão.
Até mais ...
Thiago Corrêa
E ae, Thiago!
ResponderExcluirMuito bacana esta sua contribuição! Poderia até te virado um post né?
Numa próxima oportunidade, fale comigo mesmo por e-mail "marcelo.schumacher@gmail.com" e vamos e vamos criar um post!
Grande abraço,
Marcelo Schumacher
http://isosoftware.blogspot.com