Inicialmente foi introduzido o conceito de refatora¸c˜ao de sistemas segundo Fowler e de como a aplica¸c˜ao deste mesmo conceito poderia ser adaptado a banco de dados. Foi apresentado ent˜ao o conceito de bancos evolutivos e o papel central que a refatora¸c˜ao de banco desempenha neste conceito. As se¸c˜oes seguintes aprofundaram a discuss˜ao, com defini¸c˜oes importantes `a sua compreens˜ao, como a semˆantica informacional e a semˆantica comportamental, al´em de quest˜oes pr´aticas de aplica¸c˜ao e implanta¸c˜ao.
A descri¸c˜ao do processo de aplica¸c˜ao de refatora¸c˜oes em bancos de dados seguiu a seq¨uˆencia descrita no diagrama da Figura3.2, com dez passos para uma aplica¸c˜ao segura. Tamb´em foi apresen- tado um procedimento para implanta¸c˜ao em produ¸c˜ao, em um m´etodo bastante seguro sugerido por Ambler. Por fim, uma lista das refatora¸c˜oes e transforma¸c˜oes mais prov´aveis em um DW evolutivo foi feita na Tabela3.2.
Cap´ıtulo 4
Aplica¸c˜ao de Pr´aticas ´Ageis em Projetos Evolutivos de
DW
A complexidade de um projeto de DW, como descrito no Cap´ıtulo 2, causa uma consider´avel demora na entrega de funcionalidades aos usu´arios finais do ambiente anal´ıtico. ´E comum que este tipo de projeto seja bastante burocr´atico, com documenta¸c˜oes extensas e itera¸c˜oes de desenvolvi- mento grandes e demoradas. O Cap´ıtulo 2 define em detalhes o m´etodo de engenharia proposto por Kimball [38], que busca construir, de forma iterativa, diversos data marts, que devem ser gradual- mente integrados para constru¸c˜ao do DW, em uma vis˜ao ´unica da empresa.
O m´etodo de Kimball abrange todas as necessidades de um DW, ´e funcional e bastante utilizado no mercado mas, apesar de ser um processo iterativo, n˜ao ´e uma proposta ´agil. Esta afirma¸c˜ao ´e justificada porque o escopo de um data mart pode ser muito grande e, neste caso, o m´etodo vai exigir todo o conjunto de burocracias de um grande projeto de software. Essa ´e a limita¸c˜ao da proposta do Kimball pois, para ele, o data mart deve ser inteiramente desenvolvido, antes que um novo ciclo se inicie.
4.1 M´etodos ´Ageis
Desde a d´ecada de 1950 a importˆancia do software vem aumentando cada vez mais. O seu surgimento fez valer a “lei das conseq¨uˆencias n˜ao pretendidas”, onde o surgimento de uma nova tecnologia tem influˆencias profundas em diversas outras ´areas da ciˆencia [45]. Com seu crescimento, o desenvolvimento do software passou a ser uma atividade pr´opria de engenharia, chamada“Engenharia de Software”, que tem duas conhecidas defini¸c˜oes formais:
Engenharia de software ´e a cria¸c˜ao e utiliza¸c˜ao de s´olidos princ´ıpios de engenharia a fim de obter softwares econˆomicos, que sejam confi´aveis e que trabalhem eficientemente
em m´aquinas reais. — Fritz Bauer [42]
Engenharia de software ´e (1) Aplica¸c˜ao de uma abordagem sistem´atica, disciplinada e quantificada para o desenvolvimento, opera¸c˜ao e manuten¸c˜ao do software, isto ´e, a aplica¸c˜ao da engenharia ao software e; (2) O estudo de abordagens como em (1).
— IEEE [25]
Um modelo de processo ´e uma abstra¸c˜ao de como deve ser o desenvolvimento do software em suas diversas etapas. Ele proporciona informa¸c˜oes parciais sobre o processo [50] mas, ao mesmo tempo, oferece uma estrutura ´util que pode ser utilizada para colocar ordem no caos do desenvolvimento de software [45]. Para uma melhor compreens˜ao hist´orica da engenharia de software, ´e importante citar alguns dos principais modelos de desenvolvimento, pois os m´etodos ´ageis surgem como uma op¸c˜ao evolutiva a estes modelos tradicionais. O objetivo n˜ao ´e detalhar cada modelo de processo e, para maiores informa¸c˜oes sobre cada um, a referˆencia pode ser consultada.
O Modelo em Cascata [41, 50], tamb´em conhecido por “ciclo de vida cl´assico” ´e intuitivo e de f´acil gerenciamento, mas apresenta diversos problemas decorrentes de sua estrutura, que prop˜oe um desenvolvimento em fases seq¨uenciais. O Modelo Incremental [50] ´e parecido com o modelo em cascata, mas ´e iterativo e entrega funcionalidades parciais aos usu´arios, a cada itera¸c˜ao. O Modelo RAD[45], ou Rapid Appplication Development, ´e um modelo incremental cuja implementa¸c˜ao ´e baseada em componentes, com desenvolvimento por equipes paralelas em blocos modularizados do software. A Prototipagem [12, 45] mostra os passos a serem seguidos para a cria¸c˜ao de um prot´otipo anterior ao desenvolvimento da aplica¸c˜ao e muitos autores a vˆeem apenas como uma t´ecnica a ser utilizada por qualquer modelo de processo. O Modelo Espiral [11,45,50] tem uma natureza iterativa e c´ıclica e ´e uma abordagem bastante realista para desenvolver sistemas de grande porte, pois realiza uma evolu¸c˜ao natural do sistema.
Apesar de ainda serem muito utilizados, os modelos tradicionais sofrem duras cr´ıticas por seus conhecidos problemas. Segundo Cockburn [14], os m´etodos tradicionais se esquecem da fragilidade dos engenheiros de software, pois estes n˜ao s˜ao robˆos e exibem grande variedade de estilo, habili- dade, criatividade, conhecimento, espontaneidade, entre outras caracter´ısticas. Para Larman [39], o software n˜ao ´e algo previs´ıvel ou imune a mudan¸cas e seu processo de engenharia deve ser capaz de lidar com estas caracter´ısticas. O Manifesto ´Agil [8] se originou de uma reuni˜ao realizada em Utah, por um grupo de 17 experientes desenvolvedores, consultores e l´ıderes na comunidade de software e seu objetivo era discutir id´eias e alternativas `as metodologias tradicionais de desenvolvimento de softwares. Nele, foram definidos os seguintes valores:
• Indiv´ıduos e intera¸c˜oes s˜ao mais importantes que processos e ferramentas;
• Software funcionando ´e mais importante que documenta¸c˜ao completa e detalhada; • Colabora¸c˜ao com o cliente ´e mais importante que negocia¸c˜ao de contratos;