The Glacial MethodologyTM For Software Development
|
|
The Glacial MethodologyTM For Software Development |
|
|
The Glacial Methodology™ is a data-centric approach to software development based on sound software engineering concepts. As you can see in Figure 1, which depicts a typical timeline for a Glacial project, the Glacial lifecycle takes a traditional data-centric approach to software development which is serial in nature. The Glacial Methodology is composed of seven distinct phases: |
|
Figure 1. A typical Glacial timeline.
During this phase you put together your project team and project plan. A Glacial team is typically comprised of a Project Manager, a Data Team lead (the person who is actually in charge), a Senior Data Architect, several Junior Data Architects, several Data Analysts, a Database Administrator (DBA), one or two application developers, and perhaps a tester or two. Your project plan will be driven by the lifecycle of Figure 1, with critical milestones being the delivery of the conceptual data model, the logical data model, and the physical data model.
You must also put important control processes in place, the most important one being a comprehensive requirements change management to prevent scope creep. All change requests must go through a change control board (CCB). In the case of requests affecting the database, the CCB must defer to the data group to ensure data quality. Instead of considering changed requirements immediately, it is far better to invest the time to consider each potential change thoroughly. Better yet, by following such an approach your stakeholders will soon learn to stop suggesting all but the most important changes – with the Glacial Methodology™, bureaucracy becomes your ally because it helps to minimize, if not completely avoid, change.
Conceptual data models explore the main business concepts and their interrelationships. Your conceptual data model forms the foundation upon which all development is based and that it is therefore imperative that you start with a highly detailed, reviewed, and accepted model. It is possible to finalize a conceptual data model within the first six to eight weeks of your project.
The third Glacial step is detailed logical data modeling. A logical data model (LDM) fleshes out business entities with detailed descriptions of their data attributes and the relationships between entities. Data requirements are gathered during this stage, information which is captured within your LDM as well as in your data requirements specification – Glacial data professionals understand the importance of comprehensive documentation. Following this methodology you will potential put your LDM into 74th normal form, although practically you only need to go somewhere between 67th and 72nd normal form.
Ensure that you seek the one truth when you are modeling data. Regardless of how long that it takes to come to consensus, strive to enforce a single definition for all data elements and entities. Without such a consensus there is no possible way for your organization to work effectively.
You should still focus on developing an LDM even though the application development team covers the exact same ground, faster and more thoroughly, with their object modeling activities. A side benefit of the Glacial Methodology™ is that it ensures a large and growing data group within your IT department regardless of the obvious redundancy which they represent.
With a Glacial approach you develop a detailed physical data model (PDM) based on your reviewed and accepted LDM. The PDM is used to generate your database schema and to help drive the modeling efforts of the application developers (they still need to worry about a few secondary issues listed below). You need to invest significant time modeling it because it needs to be right, due to the fact that it is incredibly difficult to make changes to your database schema once it is in use.
After several months of comprehensive modeling development activities are permitted to begin. Now that the physical database schema is defined and baselined, it doesn't really matter what the application developers do from now on. In fact, they might even choose to completely ignore the wonderful work done by the data professionals with the naive excuse that working software needs to be delivered sometime this decade. Pay this no heed, even if the application developers do go rogue you'll be able to prevent them from deploying into production because the business stakeholders respect your opinion.
Following the traditions of the traditional data community, the Glacial Methodology ignores trivial issues which are better left to application development teams. These issues include, but are not limited to understanding the usage requirements for the system, system usability, security, network architecture, hardware architecture, deployment, scheduling, estimation, component design, user interface design, overall functionality, and testing. These minor issues will be addressed by the development team when it goes rogue.
So what should data professionals do when the application developers attempt to actually get something done? The Glacial MethodologyTM includes strategies to deal with this very issue, such as:
Although there is likely no time left at the end of the project, the Glacial MethodologyTM promotes comprehensive testing at the end of the lifecycle. System testing, in particular load and integration testing, are particularly important at this point.
A key to your success is acceptance testing to make it look as if your business stakeholders actually still want whatever it is that has been built. Call it like it is, after spending millions of dollars on the system, the business stakeholders are going to accept the system like it or not. When you think about it, traditional acceptance testing such as this should be called "Ram it down their throat" testing.
Assuming the project hasn't been cancelled by this point, you will deploy whatever was actually built into production.
Yes, the Glacial Methodology is an April Fool's joke. If this methodology sounds similar to how your organization works, you've likely got a serious problem. Here is a list of resources for alternative techniques which you may want to consider:
|
|
|
|
Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation. It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts. Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner. |
 |
This book describes, in detail, how to refactor a database schema to improve its design. The first section of the book overviews the fundamentals evolutionary database techniques in general and of database refactoring in detail. More importantly it presents strategies for implementing and deploying database refactorings, in the context of both "simple" single application databases and in "complex" multi-application databases. The second section, the majority of the book, is a database refactoring reference catalog. It describes over 60 database refactorings, presenting data models overviewing each refactoring and the code to implement it.
|
 |
This book describes the philosophies and skills required for developers and database administrators to work together effectively on project teams following evolutionary software processes such as Extreme Programming (XP), the Rational Unified Process (RUP), the Agile Unified Process (AUP), Feature Driven Development (FDD), Dynamic System Development Method (DSDM), or The Enterprise Unified Process (EUP). In March 2004 it won a Jolt Productivity award. |
|
|
Copyright © 2006-2007
Scott W. Ambler Last updated: April 1, 1976 |
 |
