Maine State SDLC Policy and Procedure

by Jonathan A. Ives and B. Victor Chakravarty

The Maine State Software Development Lifecycle (SDLC) defines a standard method for the creation and upgrade of software applications. This SDLC is a derivative of the IBM Rational Unified Process (RUP), and is structured in two dimensions: Phases and Disciplines. Phases represent the sequential evolution of an application project through time; they are: Inception, Elaboration, Construction, Transition, and Production. Disciplines are the specialized activities that take place over the life of an application project; they are: Business Modeling, Requirements, Analysis & Design, Implementation, Test, and Deployment. The mutual inter-relationship between Phases and Disciplines is represented in the so-called Hump Chart. For more details, see Scott Ambler's whitepaper, A Manager's Introduction to the Rational Unified Process (RUP) .

The Maine State SDLC Policy and Procedure were created by a statewide committee during last summer, Victor Chakravarty chaired that committee. Jonathan Ives, also a member of that committee, subsequently made a DevCon presentation (only accessible from the intranet) on this topic. The two of us wanted to take this opportunity to answer some frequently asked questions.

Why create both a Policy and a Procedure? What is the difference between the two?

Besides defining applicability, overall responsibility, etc., the Policy establishes basic terminology, whereas the Procedure defines the actual deliverables to be produced. Compliance with the Policy is measured by the successful creation of the deliverables specified in the Procedure.

Why not use a simpler SDLC model, such as Waterfall?

The Maine State SDLC is a more realistic representation of modern best practices. In the Waterfall model, for instance, Business Modeling takes place exclusively during Inception. While that was the typical approach up until the 1980s, it has not been the case since then. Now, customers routinely expect a more proactive role in both the early prototyping and the subsequent iterative refinement cycle. The entire requirements of Business Modeling are seldom fully revealed during Inception. Admittedly, the bulk of Business Modeling does take place during Inception, but it does not stop there. Business Modeling actually extends all the way through Elaboration and Construction, as additional requirements continue to evolve. Thus, in spite of its simplicity, the Waterfall model fails to properly capture current software development best practices, which are inherently iterative.

How to manage projects where each deliverable is refined through multiple iterations?

An iterative development approach has significant ramifications on cost, timeline, and procurement management. For instance, if a vendor payment is conditional upon the Business Modeling deliverable, then when is that payment actually due? At the end of Inception? At the end of Elaboration? At the end of Construction? There is no one-size-fits-all answer. One approach could be to agree on a graduated payment schedule: 60% at the end of Inception, 30% at the end of Elaboration, and the remaining 10% at the end of Construction. In developing a project schedule, is the Business Model tracked as one deliverable, or multiple? One approach could be to have a “Business Model – Conceptual Draft” created during Inception, then a “Business Model – Design Draft” created during Elaboration, and finally, the “Business Model – Final Implementation” created during Construction. In this case, a single deliverable, the “Business Model”, may continue to evolve over the life of the project. If this approach is used, then the acceptance criteria for each Phase need to be well-defined so that it can be easily determined whether the current draft is complete enough to advance to the next Phase.

How does the Deployment Certification Policy relate to the SDLC Policy? And what is the role of the Enterprise PMO in each policy?

The Deployment Certification Policy is really a part of the SDLC Policy. The Enterprise PMO owns both policies, and they actively work with project managers and technical leaders across the State to identify best practices for both policies. In the future, sample SDLC deliverables will be available through the Enterprise PMO site.

We already create Project Management documentation. Now come the SDLC requirements. Does that double our work?

It is not the intent of the SDLC Policy and Procedure to create duplicate work. Projects may generate the contents of the SDLC deliverables under different names or contexts, which may adequately suffice in terms of compliance with the SDLC Policy. Partner with the Enterprise PMO to arrive at the optimal list of deliverables for your specific project.

The Maine State SDLC Policy and Procedure are still relatively new, and we eagerly look forward to obtaining the feedback of the State IT community .