Transformando Etiquetas em uma Base de Conhecimentos
Extensão do capítulo "Etiquetando Ativos de Software", penúltimo capítulo publicado até agora na série "Gerenciando Ativos de Software".
Neste ponto eu começaria a escrever sobre os processos necessários para a administração de ativos de software e para o reuso. O ponto de partida e um dos fatores mais importantes e críticos tanto para o reuso quanto na implementação de uma SOA é a Engenharia de Requisitos -- ou, colocando em outro padrão, o Desenvolvimento e o Gerenciamento de Requisitos. Para explicar a importância desta disciplina no contexto da série, basta lembrar uma frase que citei em um dos primeiros capítulos: "Oportunidades de reuso são como bugs: quanto antes elas forem encontradas, melhor" [1].
As similaridades e as diferenças entre aplicações são encontradas em dois lugares principais: nos requisitos e na arquitetura. O primeiro delimita o problema. A segunda aponta uma forma de solução. Foi aqui que esbarrei numa questão que acabou 'forçando' este post: afinal, como coletar requisitos com o objetivo de detectar oportunidades de reuso?
A busca pela resposta acabou me levando de volta para uma antiga briga*: sem uma base de conhecimentos bem estruturada, esse levantamento é uma tarefa hercúlea, cara e nada ágil. Se boa parte das ferramentas para administração de requisitos ainda não achou uma boa solução para a rastreabilidade*, o que esperar então da forma como elas tratarão essa "nova" demanda?
Porque não se trata apenas de recuperar os requisitos. Devemos ter condições de analisar todo o histórico de construção - observar todas as derivações (modelos, código etc) e conhecer as decisões tomadas. Conhecer todo o ciclo de vida de um ativo pode ser um fator determinante para a sua reutilização.
As etiquetas RAS, apresentadas anteriormente, suprem uma parte dessas necessidades. Mas tanto as suas informações quanto a sua forma de persistência não atenderiam plenamente a demanda pela busca e comparação de requisitos.
Uma deficiência do padrão, apontada anteriormente, é o fato dele não contemplar o histórico de (re)uso do ativo. Se considerarmos então tudo o que precisamos saber sobre os requisitos, definitivamente o padrão RAS não é suficiente. Sua forma de armazenamento (arquivos XML em um sistema de arquivos tradicional) também não facilita as tarefas de busca. Precisamos de uma base de conhecimentos bem estruturada. E sua persistência em um sistema gerenciador de bancos de dados parece ser a melhor alternativa.
O padrão RAS é extensível. E ele já recebe informações sobre requisitos na entidade/classe "Artefato". O que eu sugiro no diagrama acima é uma extensão do padrão, de forma que ele possa contemplar informações mais específicas sobre os requisitos e sobre o negócio. Utilizei três fontes para traçar o diagrama conceitual: a base que descrevi no artigo supra-citado*, o "Requirements Knowledge Model" de Suzanne e James Robertson [2], e o meta-modelo básico de conceitos de modelagem de negócios proposto por Hans-Erik Eriksson e Magnus Penker [3].
Todos os requisitos são associados aos casos de uso do negócio que, por sua vez, são vinculados à processos de negócio. A caracterização e descrição dos processos é apoiada por quatro elementos básicos: seus Objetivos, Recursos, Eventos e Regras. Informações básicas sobre o negócio podem facilitar a busca e a comparação de requisitos.
Os requisitos também são associados aos elementos que formam a solução. A vinculação direta é com os casos de uso do produto ou serviço que, segundo o padrão RAS, também são cadastrados como "Artefatos". Desta forma é possível rastrear todas as derivações que ocorreram durante o desenvolvimento de determinada solução.
Na parte inferior do diagrama eu apenas sinalizo a possibilidade de classificar e detalhar melhor os requisitos.
É importante salientar que nós não reusamos UM requisito. Não buscamos isso. O que se reutiliza é um conjunto (cluster) de requisitos. Todos os descritores e entidades sugeridas acima existem para possibilitar a formação um conjunto. Por exemplo: podemos selecionar todos os requisitos de um determinado processo de negócio; todos os requisitos funcionais que referenciem determinado recurso; os requisitos não-funcionais de determinado produto / serviço; e assim por diante.
Não é minha intenção aprofundar muito nas questões colocadas neste post. Tanto que ele nem está no 'padrão de escrita' da série. Posteriormente, na versão editada desta série e em outros artigos, falarei mais sobre a construção de uma Base de Conhecimentos para organizações que desenvolvem software.
* Obs.: Na realidade, preciso reescrever e corrigir este artigo. É de 2003, e até hoje tá ali no canto, falando de "requerimentos".
Referências:
Neste ponto eu começaria a escrever sobre os processos necessários para a administração de ativos de software e para o reuso. O ponto de partida e um dos fatores mais importantes e críticos tanto para o reuso quanto na implementação de uma SOA é a Engenharia de Requisitos -- ou, colocando em outro padrão, o Desenvolvimento e o Gerenciamento de Requisitos. Para explicar a importância desta disciplina no contexto da série, basta lembrar uma frase que citei em um dos primeiros capítulos: "Oportunidades de reuso são como bugs: quanto antes elas forem encontradas, melhor" [1].
As similaridades e as diferenças entre aplicações são encontradas em dois lugares principais: nos requisitos e na arquitetura. O primeiro delimita o problema. A segunda aponta uma forma de solução. Foi aqui que esbarrei numa questão que acabou 'forçando' este post: afinal, como coletar requisitos com o objetivo de detectar oportunidades de reuso?
A busca pela resposta acabou me levando de volta para uma antiga briga*: sem uma base de conhecimentos bem estruturada, esse levantamento é uma tarefa hercúlea, cara e nada ágil. Se boa parte das ferramentas para administração de requisitos ainda não achou uma boa solução para a rastreabilidade*, o que esperar então da forma como elas tratarão essa "nova" demanda?
Porque não se trata apenas de recuperar os requisitos. Devemos ter condições de analisar todo o histórico de construção - observar todas as derivações (modelos, código etc) e conhecer as decisões tomadas. Conhecer todo o ciclo de vida de um ativo pode ser um fator determinante para a sua reutilização.
As etiquetas RAS, apresentadas anteriormente, suprem uma parte dessas necessidades. Mas tanto as suas informações quanto a sua forma de persistência não atenderiam plenamente a demanda pela busca e comparação de requisitos.
Uma deficiência do padrão, apontada anteriormente, é o fato dele não contemplar o histórico de (re)uso do ativo. Se considerarmos então tudo o que precisamos saber sobre os requisitos, definitivamente o padrão RAS não é suficiente. Sua forma de armazenamento (arquivos XML em um sistema de arquivos tradicional) também não facilita as tarefas de busca. Precisamos de uma base de conhecimentos bem estruturada. E sua persistência em um sistema gerenciador de bancos de dados parece ser a melhor alternativa.
O padrão RAS é extensível. E ele já recebe informações sobre requisitos na entidade/classe "Artefato". O que eu sugiro no diagrama acima é uma extensão do padrão, de forma que ele possa contemplar informações mais específicas sobre os requisitos e sobre o negócio. Utilizei três fontes para traçar o diagrama conceitual: a base que descrevi no artigo supra-citado*, o "Requirements Knowledge Model" de Suzanne e James Robertson [2], e o meta-modelo básico de conceitos de modelagem de negócios proposto por Hans-Erik Eriksson e Magnus Penker [3].
Todos os requisitos são associados aos casos de uso do negócio que, por sua vez, são vinculados à processos de negócio. A caracterização e descrição dos processos é apoiada por quatro elementos básicos: seus Objetivos, Recursos, Eventos e Regras. Informações básicas sobre o negócio podem facilitar a busca e a comparação de requisitos.
Os requisitos também são associados aos elementos que formam a solução. A vinculação direta é com os casos de uso do produto ou serviço que, segundo o padrão RAS, também são cadastrados como "Artefatos". Desta forma é possível rastrear todas as derivações que ocorreram durante o desenvolvimento de determinada solução.
Na parte inferior do diagrama eu apenas sinalizo a possibilidade de classificar e detalhar melhor os requisitos.
É importante salientar que nós não reusamos UM requisito. Não buscamos isso. O que se reutiliza é um conjunto (cluster) de requisitos. Todos os descritores e entidades sugeridas acima existem para possibilitar a formação um conjunto. Por exemplo: podemos selecionar todos os requisitos de um determinado processo de negócio; todos os requisitos funcionais que referenciem determinado recurso; os requisitos não-funcionais de determinado produto / serviço; e assim por diante.
.:.
Não é minha intenção aprofundar muito nas questões colocadas neste post. Tanto que ele nem está no 'padrão de escrita' da série. Posteriormente, na versão editada desta série e em outros artigos, falarei mais sobre a construção de uma Base de Conhecimentos para organizações que desenvolvem software.
* Obs.: Na realidade, preciso reescrever e corrigir este artigo. É de 2003, e até hoje tá ali no canto, falando de "requerimentos".
.:.
Referências:
- Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002). - Requirements-Led Project Management
Suzanne Robertson e James Robertson
Addison-Wesley (2005). - Business Modeling with UML - Business Patterns at Work
Hans-Erik Eriksson e Magnus Penker
Wiley (2000).
Marcadores: engenharia_de_requisitos, gerenciamento_de_ativos, mps, reuso, soa, spi
terça-feira, 23 de janeiro de 2007 |
Assine o finito
Lista completa no del.icio.us
neste post
Qual é a sua opinião?