Aplicação do modelo fábrica de software CMMI especializado em data warehouse com técnicas de heurísticas para a definição de soluções

Transcrição

1 Aplicação do modelo fábrica de software CMMI especializado em data warehouse com técnicas de heurísticas para a definição de soluções Denis Ávila Montini Msc. Engenharia de Produção São Paulo - SP Av. Paulista 949 (0xx11) Denisavila.montini@tcs.com Francisco Supino Marcondes Bsc. Sistemas de Informação Instituto Tecnológico de Aeronáutica São José Dos Campos - SP Praça. Marechal Eduardo Gomes 50 (0xx12) yehaain@gmail.com Luiz Alberto Vieira Dias PhD. Space Physics Instituto Tecnológico de Aeronáutica Praça. Marechal Eduardo Gomes 50 (0xx12) vdias@ita.br Adilson Marques da Cunha Dsc. Computer Engineering Instituto Tecnológico de Aeronáutica Praça. Marechal Eduardo Gomes 50 (0xx12) cunha@ita.br RESUMO Estudo de caso de uma metodologia para linha de produção especializada em data warehouse aplicada em fábricas de sofware, segundo Kimball, em conformidade com um modelo de qualidade que suporte a construção adequada desse tipo de sistema de software. Para tal, um projeto foi iniciado com aplicativos de banco de dados, partindo do nível setorial de uma corporação, até a sua integração em um aplicativo para uma corporação e posteriormente para uma empresa holding. A consolidação dos aplicativos desde setoriais até o projeto de uma data warehouse resultante com um nível de qualidade compatível como o CMMI nível 3 foi atingida. A composição, complementada pela utilização da técnica de heurísticas para a definição de soluções, a qual não é abordada pela proposta de Kimball, especializa o modelo de fábrica genérico do CMMI para data warehouse. Palavras-Chaves: Banco de Dados Coporativos, Desenvolvimento de Sistemas de Banco de Dados; Experiência acadêmica de Graduação e Pós-Graduação; Estratégia de Integração Iterativa no desenvolvimento de processos com times distribuídos. 1. INTRODUÇÃO Este trabalho foi realizado tendo como foco uma célula em uma fábrica de software [01], voltada para a construção de componentes para banco de dados [02], com aplicação em data warehouses DW, proposta por [03] e descrita em maiores detalhes por [04] [05] [06] [07] [08] [09]. O ambiente o qual constrói software de maneira iterativa e incremental, definido por políticas de qualidade para produto [12], apoiado por ferramentas de desenvolvimento e gestão integrados ao processo [10], apresenta semelhanças com uma linha de montagem industrial [11]. Por isso, o termo fábrica de software se aplica a empresas que desenvolvam e tenham como produto final o software, analisando o seu processo, independente do maior ou menor nível de personalização ou variedade desse produto. Neste trabalho o software será considerado como produto decorrente de um processo, embora haja correntes, e até Legislação, que tratam o software como propriedade intelectual. A construção de um DW exige da equipe de desenvolvimento um perfeito entendimento do propósito e aplicação do sistema para que ele atenda as necessidades do cliente sem desperdiçar recursos e seguindo padrões internacionais de qualidade alicerçados em normas do International Organization for Standarization - ISO, e no modelo de qualidade: Capability Maturity Model Integration - CMMI. A dimensão de qualidade, quando aplicada num DW, incorpora como atributos qualificadores: 1) elicitação dos requisitos específicos para sua construção; 2) desenvolvimento de um processo para análise de viabilidade; 3) definição de modelos que atendam as características de qualidade do processo e do produto; e 4) um framework (forma preestabelecida de trabalho) de trabalho específico. A linha de produção tipificada foi uma célula de manufatura na qual o estudo foi aplicado. A Figura 01 apresenta as características deste contexto, com: 1) CMMI - nível 3, garantia de qualidade definida do produto; 2) processos produtivos, Kimbal - DW; e 3) suporte automatizado, Service Oriented Architecture SOA este ítem não será abordado neste artigo. Figura 01 A fábrica de componentes de software (Fonte: MONTINI apud FERNANDES, 2005). Copyright 2007 Page 1 of 8

2 2. A ESTRATÉGIA DE OBTENÇÃO DO MODELO RILSTON COM A HEURÍSTICA DO OBJETIVO. As técnicas sugeridas para especificação de requisitos funcionais e não funcionais [13] não delineiam de maneira completa e precisa os requisitos de DW, tais como: funcionalidades, conhecimento do negócio, fatores de qualidade, dentre outros. A construção de um DW visa o suporte tecnológico para que a área de negócio tenha informações sobre o comportamento de sua operação [15]. Na estruturação da linha, adicionalmente aos requisitos definidos para a organização, precisam ser definidos pessoas, com papéis, responsabilidades, ativadades e metas de projeto; apenas a dimensão de atividades será abordada. Para a concepção do modelo proposto para fábrica de software especializada em DW com CMMI nível 3, foi constatado que o processo de desenvolvimento de aplicações de DW proposto por [09], não atende a todas a dimensões dos principais modelos de qualidade existentes no mercado. Em vista disso não serão analisadas todas as incompatibilidades, mas o tema a ser desenvolvido é para resolver uma destas incompatibilidades. Para atender tanto o modelo proposto que visa adequar o processo desenvolvido por Kimball, quanto para completar o modelo de qualidade CMMI nível 3 sistema de desenvolvimento de software definido. Conforme mostra a Figura 02, o modelo foi proposto de forma que partindo de um processo de engenharia de requisitos fosse possível, utilizando a notação Integration Definition for Function Modeling IDEF0 [14], organizar sequencialmente os conceitos de como os produtos de software necessários a integração fossem gerados. Com a definição desse arranjo foi possível realizar, como um sub-processo, a criação e a integração dos aplicativos de banco de dados [15]. A aplicação de técnicas para gerenciamento de requisitos aliadas às práticas (heurísticas) de coleta de dados, serviram para definir um instrumento para rastreabilidade dos requisitos possibilitando que as visões dimensional e de requisitos estejam sempre ajustadas às necessidades do usuário. Figura 02 Contexto desta pesquisa para a integração das práticas CMMI x Kimball x Rilston. A composição das abordagens apresentadas na Figura 02, provocaram a necessidade da revisão do processo para adequá-lo às necessidades de qualidade requeridas pelos modelos CMMI e o proposto por Kimball [09]. O CMMI apresenta diretrizes para formalizar o processo de desenvolvimento do sistema de software, no qual foi aliado com o modelo de Kimball para DW, resolvendo as necessidades de definição de soluções para se especificar adequadamente os requisitos, de acordo com as práticas da engenharia de software, para promover um nível de gestão integrada de projeto, propiciando decisões mais acuradas e minimizando os efeitos colaterais. As estruturações das soluções e do modelo criado foram baseadas na notação IDEF0, em formato de visualização HTML- WEB com base em artefatos descritos na metodologia da empresa, nota-se que o modelo proposto atende a maior parte dos atributos se comparado com as metodologias desenvolvidas pelos autores referenciados na Figura 03. A despeito da preocupação com a separação entre requisitos e aspectos de implementação, uma especificação em alto nível do sistema é obtida, mesmo que parcialmente, na abordagem de Kimball, pois ainda há a possibilidade de se identificar corretamente a problemática a ser pesquisada. A estratégia de obtenção do modelo [13] se ocupa em utilizar o modelo de Kimball e complementar a sua utilização para atender a necessidade de validação da qualidade dos processos conforme instituições que detenham certificações de qualidade internacionais como a TCS Tata Consultance Services. O modelo proposto, apresentado neste trabalho suplanta essas deficiências, oferecendo um arcabouço de técnicas, artefatos e procedimentos que possibilitam uma definição precisa e em alto nível com as heurísticas das soluções que norteam o processo de especificação de requisitos para um DW. A relação comparativa entre os métodos estudados está representada na Figura 03. Na Figura 04, para o processo de mentoring (processo de capacitação e treinamento de uma equipe para replicar conhecimento) procurou-se fornecer meios para a elicitação e documentação dos requisitos de DW, com subsídio para a modelagem de aspectos mais relacionados ao domínio multidimensional. O cenário desenvolvido nesta metodologia, envolve a utilização de técnicas de engenharia de software conformadas com padrões de qualidade CMMI nível 3, para a construção de um DW, essas técnicas, foram associadas com as práticas de coleta de dados que formam a base para o DW. Essa abordagem visa aumentar o grau de maturidade da gestão de projetos: 1) na qualidade do processo de desenvolvimento de DW; 2) no controle dos riscos do projeto desse tipo de sistema; e 3) na redução do desperdício de recursos envolvidos na manutenção de projetos semelhantes. Para a construção dos datamarts iniciais foram definidas técnicas e processos para organizar os requisitos de um DW genérico. Foi realizada uma derivação, para a estratégia de obtenção, similar a dos processos [17] partindo dos requisitos de software, englobando desde o processo de elicitação até a validação e integração. A complementação do processo de requisitos é então realizada com a implementação da gestão de escopo, controle de mudanças, rastreamento da evolução dos requisitos, gerência de riscos associados à camada problema e a camada solução, e finalmente uma etapa de Post-Mortem. Para avaliação e melhoria continuada da aplicação do processo de requisitos no projeto de software. A execução plena desses passos chama-se gerenciamento dos requisitos do software. Copyright 2007 Page 2 of 8

3 No decorrer das etapas, devem prevalecer as reuniões por grupos de papéis desempenhados. No fechamento de cada fase, pode haver uma reunião com os representantes de cada um dos grupos de papéis. Centrada em um modelo de fases que direciona o processo de especificação dos requisitos, enquanto propõe um conjunto de artefatos para a coleta dos aspectos funcionais, nãofuncionais e multidimensionais que integram a solicitação de serviço. A proposta de abordagem apresenta um processo iterativo de análise e especificação dos requisitos por meio de refinamentos sucessivos, em comum com as demais metodologias, procedimentos e artefatos para a definição de requisitos multidimensionais. A preocupação neste estudo foi com o planejamento da gerência dos requisitos do sistema para a identificação do problema a ser elecitado e a montagem das bases. O processo desenvolvido foi embasado e complementado com as disciplinas CES-30 Técnicas de Banco de Dados e CE-240 Projeto de Sistemas de Banco de Dados ministradas, respectivamente, para os alunos 5º ano do Programa de Graduação em Engenharia de Computação e do Programa de Pós-graduação em Engenharia Eletrônica e Computação, na área de informática, PG/EEC-I, do Instituto Tecnologico de Aeronáutica ITA, durante o 1º Semestre de A integração dos conceitos de heurística as quais permitiram a adoção de outros modelos como os modelos de dados da engenharia de processos, do Processo Pessoal de Software, Personal Software Process PSP, para o controle de fábrica desenvolvido por Watts Humphrey [08] um dos autores da série do CMM. O contra ponto do estudo consistiu no fato de que há a necessidade de se estudar linhas de produção especializadas visando ter um método de customização que maximize as diversas vertentes que integram a solução como por exemplo a flexibilização do método Kimball. A heurística da solução, permite o gerenciamento de requisitos nos níveis operacionais, táticos e estratégicos. A utilização de uma heurística propicia a integração, o aumento da eficiência no processo de desenvolvimento e redução da probabilidade de ocorrência de defeitos, falhas e erros na produção de um software. Como base para a concepção do DW e para a sua estruturação com a utilização das boas práticas da engenharia de requisitos, na Atividade do Processo Iterativo com Refinamentos Sucessivos - APIRS, os fundamentos obtidos nas disciplinas de Técnicas de Bancos de Dados (CES-30) e Projeto de Sistemas de Bancos de Dados (CE-240) [18], contribuíram com a estruturação do processo da heurística da solução na atividade APIRS, apresentada na Figura 03. O modelo pôde então ser testado de forma acadêmica, para a APIRS, na construção de um sistema de banco de dados corporativo da holding, através de uma equipe de 46 alunos em nível de graduação e pós graduação do ITA. Foram realizadas as execuções dos ciclos de integração sucessivos, em 4 (quatro) níveis diferentes, com duração de duas semanas cada um. Figura 03 - Estratégias comparativas de obtenção com a de sistemas de data warehouse Denis adaptado de (Rilston, 2003). Como resultado da utilização da técnica de heurística da solução para a integração de um aplicativo de banco de dados holding, no qual obteve-se 13 (treze) aplicativos de bancos de dados Nível 1, 4 (quatro) bancos de dados setoriais de Nível 2, 2 (dois) bancos de dados corporativos de Nível 3, e 1 (um) banco de dados da holding. Para verificação dos bancos de dados descritos acima, eles foram implementados fisicamente e populados. Assim, este experimento prático permitiu, o desenvolvimento acadêmico de um protótipo de um sistema corporativo de banco de dados de uma holding que se tornou a infra-estrutura necessária para a próxima etapa, o estabelecimento das próximas atividades necessárias para a construção do DW. Os principais resultados alcançados com a utilização de 26 Técnicas de banco de dados, aprendidos na disciplina CE240 ITA 2007 são representados no Quadro 01. Nesta experiência foram comprovados pela implementação, com sucesso, do seguinte protótipo de um banco de dados integrado. O referido protótipo contém aproximadamente 110 (cento e dez) entidades, 520 (quinhentos e vinte) atributos, 215 (duzentas e quinze) consultas, 25 (vinte e cinco) views, 25 (vinte e cinco) triggers e 25 (vinte e cinco) stored procedures, mapeando-se assim o contexto do negócio. Copyright 2007 Page 3 of 8

4 Quadro Técnicas de banco de dados CE240 ITA Fases Pré analise Análise Pr oc es so 1 Tematização 2 Motivação Técnicas 3 Contextualização 4 Objetivação 5 Intitulação 6 Especificação de requisitos Descrição do Processo Esta primeira Técnica de Tematização consiste na utilização de um conjunto de procedimentos para a escolha apropriada, pelos Alunos, de uma Temática Principal e duas Temáticas Alternativas para a Pesquisa e o Desenvolvimento de um Aplicativo de Banco de Dados (BD). Colocar no relatório "O que é que motivou a realizar o trabalho"... (Esforço mínimo, necessário suficiente e objetivo.) Esta segunda Técnica de Motivação consiste na adoção de um ou mais critérios para a apresentação do que motivou o Aluno a escolher a sua Temática do Aplicativo de BD e sua descrição. Por exemplo, critério cronológico, geográfico, área interesse ou gosto pessoal, importância da Temática Escolhida no Domínio do Conhecimento, necessidade de sua Especialização ou Pós-Graduação, entre outros. Colação da tematização e da motivação em um momento ou situação.(uma definição de política). Contextualizar é realizar uma síntese do Contexto do Negócio em que está inserido ou se baseia o Desenvolvimento de um Sistema de Software Aplicativo de BD. Uma Contextualização Típica pode conter, por exemplo, 5 + ou - 2 parágrafos, onde cada parágrafo deve possuir 5 + ou - 2 linhas. Esses parágrafos devem representar o Modelo Descritivo ou Textual, que precede a formulação de um Modelo Conceitual ou Lógico de um Projeto de Sistema de Banco de Dados, mais conhecido como Modelo Entidade Relacionamento MER. Esses parágrafos devem mencionar, de forma sintética, as Principais Entidades de Interesse para o Projeto do Sistema de BD derivadas dos principais Substantivos contidos no texto ou contexto. Definição do problema, e das alternativas de soluções.mutuamente exclusiva em relação ao objetivo. Identificiação do Problema. Elementos variáveos, ou causas x relação de causa efeito, tarefas mais o propósito. Efeitos adveros, pode ter uma ou mais Causas. Objetivar é aplicar a Heurística do Objetivo tanto na Definição do Problema - Principal quanto na Definição da Alternativa de Solução Escolhida. Para fins didáticos, as Soluções Escolhidas, por cada um dos alunos dessas disciplinas para o Projeto de Sistemas de BD deverão, necessariamente, envolver o desenvolvimento de cada um de seus Protótipos de Aplicativo de BD. A aplicação da Heurística do Objetivo realizada na Definição do Problema e na Definição da Solução Escolhida poderá, por exemplo, resultar em apenas um parágrafo, com o seguinte formato. Heurística do Objetivo = [(Um verbo transitivo direto e/ou bitransitivo + um objeto direto) + (Um complemento, Finalidade ou Propósito, contendo uma idéia de otimização de algo, em termos de Maximização de Lucros e/ou Minimização de Prejuízos ou Desperdícios)]. Esta Técnica será detalhada nas próximas aulas de Definição de Problemas e Definição de Alternativas de Soluções., APA. A definição do texto deve estar de acordo com o contexto a ser analizado. O Título de um Protótipo de Aplicativo de BD, ou de até mesmo de um Projeto de Pesquisa qualquer, deve ser consistente com o Enunciado da Alternativa de Solução Escolhida ASE para resolver um Problema definido a priori. Para fins didáticos, é desejável que um Título caiba, por exemplo, numa só linha, e contenha apenas 5 + ou 2 termos principais ou palavras-chave. Esta Técnica também será detalhada nas próximas aulas de Definição de Problemas e Definição de Alternativas de Soluções. Esta Técnica de Especificação de Requisitos deverá ser aplicada pelos alunos,individualmente, a cada um dos seus Protótipos de Aplicativo de BD, e poderá ser utilizada em qualquer outro Projeto de Pesquisa, com a Heurística mostrada no último parágrafo. Para fins didáticos, uma Especificação de Requisitos poderá, por exemplo, ser composta apenas de 5 + ou - 2 tópicos, a serem conformados, verificados e validados mais tarde, quando cada Protótipo de Aplicativo de BD estiver pronto. Heurística da Especificação de Requisitos = "O Protótipo de Aplicativo de BD (Nome do Aplicativo de BD do Aluno) deverá ser capaz de propiciar: 1),...; 2)...; 3)...; etc..." 7 Normalização Regras de normalização das tabelas do sistema. 8 Modelagerm Regras para o desenho de uma solução através de um modelo. Copyright 2007 Page 4 of 8

5 9 Dicionarização 10 Trigramação Auditoria de Modelo e de Projeto de Aplicativos de BD. Implementação de um Projeto Físico de BD 1) Um Dicionário de Dados; 2) Um Diretório de Dados; 3) Um Dicionário de Recursos de Dados; e 4) Um Dicionário de Metadados. Deve possuir pelo menos 04 (quatro) Componentes: Um TRIGRAMA é uma cadeia de caracteres normalmente constituída pelas três primeiras letras ou pelas três letras mais significativas de uma ENTIDADE, que são utilizadas como prefixo dos Atributos ou Nomes de Campos de uma TABELA. Para se escolher o nome mais adequado de um Atributo, sugere-se a adoção de uma Notação Padronizada, utilizando a Técnica de TRIGRAMAÇÃO. Para integrar os Aplicativos de BD, deve-se, de forma iterativa, continuada e incremental aplicar as Técnicas de BD, de baixo para cima, quando necessário: 1) Modelar, re-modelar, normalizar, re-normalizar, denormalizar, dicionarizar e redicionarizar os MERs dos Aplicativos de BD; 2) Integrar os MERs aos Modelos de Dados Setoriais MDSs, modelar, remodelar, normalizar, re-normalizar, denormalizar, dicionarizar e redicionarizar os MDSs; 3) Integrar os MDSs aos Modelos de Dados Corporativos MDCs, modelar, re-modelar, normalizar, re-normalizar, denormalizar, dicionarizar e redicionarizar; 4) Integrar os MDCs ao Modelo de Dados da Holding MDH, modelar, remodelar, normalizar, re-normalizar, denormalizar, dicionarizar e redicionarizar o MDH, sempre que for necessário. Criação da Estrutura do Aplicativo de BD em Linguagem de Definição de Dados LDD (Data Definition Language DDL), e demais componentes (Georreferenciados); Implementação e Testes de Massa de Dados Implementação e Testes de Massa de Dados Implementação e Testes de Massa de Dados Em Linguagem de Manipulação de Dados LMD (Data Manipulation Language DML); num Sistema de Informação Geográfica SIG (Geographical Information System GIS); eventualmente, em Linguagem de Marcação Estendida LME (extended Markup Language XML); 16 Implementação e Testes, eventuais, dos conceitos de Armazém de Dados (Data Warehouse - DW); 17 Implementação e Testes, eventuais, dos conceitos de Mineração de Dados (Data Mining - DM); Projeto Lógico Testes e Integração de 1º Nível de um Modelo de Dados de Aplicativos Conversão do Modelo Relacional MDA (Applications Data Model ADM) - por meio de Consultas Operacionais; - para os Modelos Hierárquico, Rede e Orientado à Objetos; 20 Renormalização, Remodelagem e Redicionarização - para a Integração de 2º Nível de um Modelo de Dados Setorial - MDS (Subject Data Model SDM); 21 Implementação, Testes e Integração De 2º Nível do MDS - por meio de Consultas Táticas; 22 Renormalização, Remodelagem e Redicionarização - para a Integração de 3º Nível de um Modelo de Dados Corporativo MDC (Corporate Data Model CDM); 23 Implementação, Testes e Integração de 3º Nível do MDC por meio de Consultas Estratégicas; 24 Verificação e Validação do Banco de Dados Corporativo BDC (Corporate Data Base CDB) num Estudos de Caso Corporativo; 25 Renormalização, Remodelagem e Redicionarização para a Integração de 4º Nível 4º Nível de um Modelo de Dados Holding MDH (Holding Data Model HDM); 26 Implementação, Testes e Integração - de 4º Nível 4º Nível do MDH, por meio de Consultas Estratégicas, Dirigidas para o Cumprimento da Missão (Mission Driving), envolvendo o Merge de Empresas Copyright 2007 Page 5 of 8

6 Corporativas, Jogos de Empresas ou Jogos de Guerra. 3. PRODUTOS E PROCESSO DO TRABALHO DE DESENVOLVIMENTO E PRINCIPAIS RESULTADOS OBTIDOS. A utilização da estratégia de obtenção do modelo Rilston acoplado à heurística da solução objetivo para a construção de um aplicativo de banco de dados, aqui denominada APIRS, para a gestão e o controle de uma fábrica de software, no qual foi utilizada em um DW de um cliente da área financeira da TCS Brasil, consistiu em: 1) aplicar o modelo de Kimbal em um projeto de DW segundo a linha de produção TCS; 2) conformar os processo do projeto com as requisições do CMMI nível 3; e 3) estabilizar o sistema de gestão do projeto com as regras propostas pelo método. Essa etapa teve foco na integração dos bancos de dados setoriais (BDS) [13], para a determinação do datamart que serviu de base para a criação do DW especificado, e testou o uso do modelo de Kimball em composição com estruturação do modelo de CMMI. Para se poder visualizar o fluxo do processo, a APIRS foi descrita utilizando a notação IDEF0, representada na Figura 4. A notação IDEF0 organiza as relações entre os insumos, entradas do processo, as regras e novas diretrizes do processo proposto, o fluxo informacional, estabelecimento de hierarquia, e a ordem com que cada um dos processos descritos dentro da caixa tem de ser realizados para produzir de forma organizada os produtos de software resultantes da metodologia utilizada, estabelecendo assim a lei de formação da linha de produção. O modelo de Rilston complementado pelo heurística da solução [18], Quadro 01, verifica se a especificação de requisitos foi delineada de forma precisa para os requisitos voltados ao conhecimento do negócio. A heurística da solução [18] foi organizadas por fase e constitui um processo que apresenta um sequenciamento de técnicas e fatores de qualidade para um projeto, na qual visa o suporte conceitual sobre a área de banco de dados precisa para a constituição da área de negócio. Adicionalmente aos requisitos definidos pela APIRS para a organização, a TCS precisou definir os papéis, as responsabilidades, as metas de projeto e processos específicos para a gestão de fábrica. Normalmente a especificação de banco de dados de projetos extensos não são tão amplamente utilizados de acordo com as diretrizes da IDEF0; como por exemplo em processos específicos e gestão integrada de processos na fábrica. Com a utilização da IDEF0 é possível acompanhar o aumento das funcionalidades inseridas durante a construção do DW. Em toda a parte do ciclo de desenvolvimento as alterações de requisitos podem ser rastreadas e sua implementação ser verificada e validada. Essa forma propicia uma melhoria de eficiência corporativa e a redução do desperdício de recursos. Este ganho é percebido ao encontrar informações e a especificação que deu origem a sua criação, desta forma implementando o conceito da rastreabilidade bidirecional. A organização do sistema informacional da empresa passou a contar com uma ferramenta que permitiu contextualizar a APIRS com o Rilston. Esta ferramenta, descrita na Figura 04, AIOWIN [19], colaboraou com o suporte da aplicação de ferramentas, técnicas e procedimentos voltados para os projetos de sistemas de banco de dados que compõe o DW. Figura 04 - Processo e produto organizado através do uso da notação IDEF0 no AIOWIN. A heurística da solução, ou modelo de Cunha [18] tem por objetivo identificar o problema e a solução corretamente, que difere do processo de elicitação pois o processo procura desenvolver os casos de uso, e funcionalidades necessárias a aplicação. Assim a composição da metodologia de Kimball e da heurística de Cunha se complementam. O resultado do processo da heurística da solução consiste em representar o resultado da pesquisa através de uma regra de formação de um parágrafo que contenha os seguintes elementos: [(Um verbo transitivo direto e/ou bitransitivo + um objeto direto) + (um complemento, finalidade ou propósito, contendo uma idéia Copyright 2007 Page 6 of 8

7 de otimização de algo, em termos de maximização de lucros e/ou minimização de prejuízos ou desperdícios)]. Com essa composição o APIRS apresenta uma técnica robusta para todas as fases de desenvolvimento de um DW, testado com sucesso em ambiente acadêmico e que deverá ser validado em uma linha de produção de célula de manufatura na TCS Brasil. 4. CONCLUSÃO Para a integração incremental dos bancos de dados a TCS visou o atendimento das necessidades dos datamarts previstos. O desenvolvimento de aplicações DW tem sido fortemente influenciado, ao longo dos anos, pela organização física do banco de dados adotados. A implementação do APIRS teve como principal objetivo assegurar a identificação correta do problema de negócio, de forma que a aplicação a ser construída atendeu as necessidades de informações que o processo heurístico identificou. Essa abordagem tem como conseqüência direta aumentar a qualidade da especificação de requisitos. A disciplina estudada, CE240, apresentou técnicas, APIRS, que colaboraram no processo de elicitação de requisitos do modelo estudado na TCS. O presente artigo relatou a comprovação da viabilidade da utilização do método heurístico, APIRS, para apoiar uma das fases do modelo de Rilston de construção de DW. A complementação de um modelo de DW por meio de um processo específico que visou a melhor identificação do problema e sua respectiva solução devidamente estudada pela heurística da solução. A solução apresentada teve como objetivo o suporte à decisão de desenvolvimento e planejamento, e a minimização dos efeitos colaterais através da busca da reais necessidades do sistema a ser desenvolvido. A qualidade da informação agrega informações que contribuiram para melhorar o grau de sucesso dos projetos. 5. RECOMENDAÇÕES O modelo aqui reportado, sugere que é possível e devem ser realizadas atividades visando a aplicação de técnicas heurísticas para especificar aplicativos de banco de dados. Produziu-se uma aplicação corporativas utilizando o estado da arte em termos tecnológicos para facilitar o processo de desenvolvimento e a integração dos profissionais em formação. Para minimizar o retrabalho utilizou-se estas técnicas para atender o mais cedo possível as necessidades do mercado, com o envolvimento de diversos processos de desenvolvimento de projetos de software. A utilização da fase da heurística, APIRS, não é só de caráter essencialmente técnico, mas também é um ponto de vista de relacionamentos inter-pessoal, como identificado durante a realização dos trabalhos em equipe. A aplicação repetitiva do ciclo de integração incremental possibilitou a convergência da aplicação utilizando-a como um ponto de retomada para todas as etapas em cada iteração. A técnica precisou ser submetida a uma equipe com um treinamento prévio incorporado às práticas das áreas chaves do nível 2 do CMMI [10]. Isto representou um aumento de maturidade, nos processos de desenvolvimento de software. Uma parte deste trabalho só foi possível devido a particiação do PSF, que contribuíu com o capital intelectual para a sua realização [21]. 6. REFERÊNCIAS BIBLIOGRÁFICAS [1]. SWANSON, K., MCCOMB, D, SMITH, J., McCUBBREY, D. The application software factory: applying total quality techniques to systems development, pg [2]. DATE, C. J. Introdução a Sistemas de Banco de Dados 7ª Ed., Editora Campus, RJ, [3]. INMON, William H - Data architecture: The information paradigm [4]. MONTINI, Denis Ávila, Modelo de indicadores de risco para o orçamento de componentes de software para célula de manufatura. / Denis Ávila Montini.360p.Dissertação (Mestrado) em Engenharia de Produção Universidade Paulista - (2005). [5]. MONTINI, Denis Ávila; ALBUQUERQUE, Antonio Roberto Pereira Leite de; NASCIMENTO, Marcos Ribeiro Do. Strategy for the use of the model of personal software process for the establishment of measurement and analysis for obtain CMMI level 2 in a study of case of a brazilian software factory.. In: ASEE - 5th ASEE Global Colloquium on Engineering Education, Rio de Janeiro, Copyright 2007 Page 7 of 8

8 [6]. MONTINI, Denis Ávila; SPINOLA, Mauro de Mesquita; SACOMANO, José Benedito; NASCIMENTO, Marcos Ribeiro do; BATTAGLIA, Danilo. Application of model PSP manual and supported by tool in a study of case of brazilian plant of software. Revista produção on line, Florianópolis - SC - Brasil, [7]. MONTINI, Denis Ávila; NASCIMENTO, Marcos Ribeiro Do; BATTAGLIA, Danilo; ANDRADE, Dalton Cernach. Metodologia de gestão de vulnerabilidades para fábrica de software. In: WCCSETE' World Congress on Computer Science, Engineering and Technology Education, 2006, Itanhaém, São Paulo, Brasil, [8]. MONTINI, Denis Ávila; SPINOLA, Mauro de Mesquita; SACOMANO, José Benedito; NASCIMENTO, Marcos Ribeiro Do; BATTAGLIA, Danilo. Aplicação do Modelo PSP Manual e amparado por ferramenta CASE em um estudo de caso de Fábrica de Software Brasileira. Simpósio, Hotel Serra Azul - Gramado, RS, [9]. KIMBALL, Raph The Microsoft Data Warehouse Toolkit: With SQL Server 2005 and the Microsoft Business Intelligence Toolset [10]. HUMPHREY, Watts. S., Managing the Software Process, Addison-Wesley Inc., [11]. CORRÊA, H. L. Administração de produção e operações: manufatura e serviços: uma abordagem estratégica. São Paulo: Editora Atlas, p , [12]. HUMPHREY, Watts. S., Managing the Software Process, Addison-Wesley Inc., [13]. RILSTON, Fábio Silva Paim, Uma Metodologia para Definição de Requisitos em Sistemas Data Warehouse, Dissertação de Mestrado em Ciência da Computação, Universidade Federal de Pernambuco, - Recife [14]. IDEF0, Integration Definition for Function Modeling. Disponível no site: < idf.com >. Acesso em: jun [15]. KORTH, H. F., SILBERSCHATZ, A. SUDARSHAN, S Sistema de Banco de Dados, 3ª Ed., Makron Books, SP, [16]. RUP, Rational Software Corporation, Rational Unified Process, 2003 [17]. MONTINI, Denis Ávila; SEKHAR, Chandra; NEGRY, Tatiana Tavares; NASCIMENTO, Marcos; BATTAGLIA, Danilo. Strategy for the use of the model of personal software process for the establishment of measurement and analysis for obtain CMMI level 2 in a study of case of a brazilian software factory. In: Montivideu: TACTICS Iberoamerica [18]. CUNHA, A. M., Notas de Aula Projeto de Sistemas de Banco de Dados (CE-240), Instituto Tecnológico de Aeronáutica (ITA), [19]. KBSI, Knowledge Based Systems Inc Disponível no site: Acesso em: jun [20]. PSF, Pesquisadores sem fronteira, ONG of support the scientific research of the state of São Paulo, Brasil Copyright 2007 Page 8 of 8