SDLC-Guiding Principles

In my experiences, when a lot of resources speak about SDLC (short for software development lifecycle) in my organization they immediately focus on the concrete portions of the process. Tangible things such as roles and responsibilities, phases, activities, and artifacts all come in to mind. While these things are important, to a lesser and greater degree, depending on your point of view, they miss the most important point of a methodology, which is to describe the overall rationale and goals of the methodology itself.

The problem with using tangible, physical components to describe how an organization should develop software becomes immediately obvious to anybody who has tried to follow anybody else's SDLC. Primarily, a working environment, even one within an organization, fluctuates wildly from project to project. Resource experience is almost never consistent, team size can never be a given, nor is the scale of the solution. Other things such as technology, resource distribution, and project risks are also rarely a constant. What this means is that even a well thought out SDLC will never be more than partially applicable to any given project. I've seen organizations attempt to create a methodology that "scales" to various environmental factors. What this means is that a base SDLC is created, then offshoots are developed for projects that are smaller, larger, offshore, et cetera. Unfortunately, this has the effect of creating an incredibly dense and complex library of processes and approaches which become unwieldy in terms of communication and maintenance. Of course compounding this issue is actual process compliance, which is something that very few organization (I do not know of any) realistically achieve. In my personal experience, the majority of project members within organizations claiming to be CMI level XXX certified really just do the minimum they can to survive a project audit, and do not actually get a lot of value from their SDLC, often not following the "intent" of the SDLC.

So where do methodologies add value? IMHO, the most important part of any methodology is the section that describes the Best Practices and Guiding Principles of the SDLC. If your organization's SDLC does not frame its processes, artifacts and other tangible assets within a set of overriding goals and quantifiable values then resources will have no guidance around what to do when a process does not properly fit into a specific situation. (most situations in my experience) Best practices and guiding principles offer guidance on how software teams can/should strive towards success. They are goal/value oriented, and can thus be more applicable to many different situations than a set of concrete/tangible items such as processes, gating criteria etc. Principles and Practices also have the benefit of typically being shorter than a complex roles/responsibilities/process map which means that more people will actually read it, and may even actually follow it.

I recently was asked to put together a customization of the Rational Unified Process by one of my clients. While I believe the Rational Unified Process has a lot of value within it, much of this value is hidden away in detailed activities, artifact description, and low-level guidelines. I wanted to make sure that followers of the customization focused on the right values represented by the framework, which in my opinion was the emphasis on iterative work, modeling and extraction, and scenario driven requirements. I also wanted to put a clear emphasis on some of the more agile aspects of software delivery which are all compatible with RUP. The first two sections of the methodology customization dealt with these values. I have decided to post them here, as an example of what I believe IMHO is a good best practices and guiding principles section for an SDLC.

It should be noted, that I am about to share around three to four pages of advice on how to proceed for a number of different situations relating to development, requirements, testing etc. There's still a lot of leeway on how to interpret this advice, which I believe to be a good thing. Telling somebody that scenario driven requirements are a good thing and why, is much more valuable than telling somebody what the exact table of contents has to be for a requirements document. A particular artifact on a project might follow a specific template to the letter, but still miss the entire intent of the artifact. Better to focus on the values, some overall best practices and patterns, and allow the resources who are creating and/or using a particular artifact to determine what exactly needs to go in and go out.

Guiding principles

Uses an iterative approach:
· An iteration incorporates a set of activities from multiple disciplines (requirements, analysis and design, implementation, test, etc.) in various proportions depending on where in the development cycle the iteration is located.
· The schedule and scope of an iteration is fixed.
Risks are mitigated earlier, as most disciplines are engaged in the process from inception onward.

Follows a use case/scenario driven requirements approach:
· Requirements are organized in a way that tells a story of how someone may use the system, and how the system reacts to user behavior. Related scenarios are grouped into a specific use case or epic/theme.
· Nonfunctional requirements are captured in the context of one or more scenario driven requirements.
· Systems are developed by realizing requirements as part of the analysis and design discipline.
It is easier to develop requirements that are complete and consistent using stories.
A scenario driven approach provides a better understanding of a requirement from a user's perspective.

Is architecture centric:
· Design activities are centered around the notion of system architecture.
· The focus of early iterations of the process is to address architectural uncertainty
· Subsequent iterations may than reuse this architecture and focus more on completing business functionality
Technical risk is managed early on in the process
Greater control of system complexity and integrity

Is based on modeling visually:
· Visual representations of the system allow understanding at a higher level of abstraction than browsing through source code and other implementation artifacts
· Design models should focus on 3 fundamental aspects of the system
· Architecturally significant components, frameworks, and patterns
· A business domain model that clearly expresses the system in terms of business concepts understandable by business domain experts and system developers alike
· Common models/interfaces with other systems/programs that must be integrated
· While UML allows for the illustration of clear and unambiguous design decisions, it should not be the only modeling notation used (workflow, storyboards, ERD, etc.)
Modeling helps shorten the learning curve to understanding a complex system for both technical and business stakeholders

Is Agile, both in terms of development and documentation:
· All documents should have a specific audience, and the level of detail should be directed to that audience
· It is often not necessary to document all aspects of the system, focus on sections that are architecturally significant, difficult to understand, or have significant business logic
· Travel light when creating documentation. Every document that is created must be maintained over time. Some documents need only be temporary in nature
· All documentation should have a clear audience and purpose, and should assist in developing useful, high-quality software. Creating and maintaining documentation should not be a burden to the development team
· Use an evolutionary test driven approach to requirements and design
· Don't overcomplicate system design in an upfront manner in an effort to predict future requirements
· Use automated testing and build frameworks to enable the team to embrace change
· Architecture, requirements, and business concept should be prototyped with real code as early as possible, often in parallel with the documentation effort
· Continually validate with business stakeholders throughout the lifecycle of the project
Being Agile allows for greater emphasis on developing working software over comprehensive documentation and allows resources to “embrace change”, not resist it

Best Practices

Methodology Based Best Practices

Model and develop using an iterative, evolutionary approach
· Use more than one modeling artifact when determining requirements, design or architecture.
· Many modeling approaches, complement each other and may be conducted in parallel
o Use case, business domain, UI-prototyping
o Class modeling, database modeling, sequence modeling
· Architecture, requirement, and business concepts should be prototyped/validated with real code as early as possible, often in parallel with the modeling/documenting effort
· Within the same core team, design and implementation activities should be broken up into "miniature iterations" involving stakeholder review and clear testability

Use the simplest approach possible when modeling and developing the solution
· Use the simplest modeling tools necessary
o For smaller engagements involving co-located teams, whiteboards, sticky notes and other informal tools can be used
o As projects increase in scope, introduce case tools as necessary
· Avoid over designing solutions for requirements that have not yet been defined, as this can unnecessarily complicate the solution
· It is more important to have models that are correct than complete
o The purpose of models is to abstract knowledge and conveying meaning
o Extensive, overly detailed models typically obscure this meaning

Include testing activities within all phases of the lifecycle
· In order to support a culture that is able to embrace change, testing must be done early and often
· Modeling efforts should be validated with real code before committing to extensive documentation
· Automated testing harnesses should be used to validate all major system components
· When doing any work (documenting, planning, coding, etc.) always ask the question "how can I test/validate this?

Focus documentation efforts on creating essential artifacts necessary to develop and support the solution
· It is usually unnecessary to document all aspects of the system, focus on architectural significant pieces and business domain logic
· Some documentation and models, are used for understanding purposes only, and need only be temporary in nature
· Focus on creating detailed documentation (if necessary) after prototyping and other validation activities
· Clearly documented interface contracts are required between teams and systems
· Document with a purpose
o Focusing effort on what is required from the readers point of view
o Involve the "user" of the document to determine essential content

Take advantage of agile approaches , but structure them within more prescriptive processes as necessary
· Organize manageable units of work (app. 2 to 3 weeks) around moderately sized, co-located teams using XP, SCRUM, AM or other agile processes
· Document clearly defined interfaces between teams and major systems
· Organize these units of work using more prescriptive processes such as rup or sip

Organizational Best Practices

System stakeholders must be active participants in the development process
· Business representatives should own the requirements and be empowered to make decisions
· Organizational structure should support fluid lines of communication
· Requirements should be allowed to grow and evolve
Emphasize collaboration and communication
· Have a clear strategy that ensures that all documentation, modeling, and other system artifacts are clearly accessible to all project members and stakeholders
· Encourage collective ownership and development of system artifacts
· Ensure that the right tools are in place to support extensive collaboration and communication when using offshore/global teams

Favor staffing generalists, as opposed to specialists on projects
· Modern software development require a large number of skill sets to be successful (requirement gathering, interface development, object-oriented analysis and design, development, database, etc.)
· Employing "single artifact resources" will cause project resource counts to become unnecessarily large
· Specialists tend to be too narrowly focused on their own problem domain, and have difficulty seeing the larger picture (if the only tool you have is a hammer, all problems look like nails)
· Large amount of "document handoff required" resulting in information loss
· Hire/train resources to have 1 or 2 specialties, but have good general knowledge of the overall SDLC lifecycle
· Generalists require more experience than specialists and are not always readily available.
· However, working to maximize the number of generalists available for projects is essential to increasing delivery capability

Work to eliminate institutional barriers to change
· There are built in barriers to change specifically around infrastructure and databases in many IT organizations
· Processes and approaches can often be streamlined to be more responsive
Implement a governance model to support an enterprise system and process view
· Agile and iterative approaches are successful with small teams and 1 or 2 business experts
· Enterprise efforts require an enterprise view and a governance model to support a cohesive architecture and consistent approach

When taking advantage of offshore/global delivery capability use an agile approach to prepare key artifacts prior to hand off
· Functional prototypes, requirements, information architecture, and other artifacts can be prepared and validated using agile approaches
· Once validated, formally document these artifacts and transfer them to offshore/global resources

Technology-Based Best Practices
Focus development effort on mitigating areas of highest risk
· Elaboration and early construction iteration should be focused on addressing
o New/untested architecture
o Complex business logic
o Integration with external systems
· Risky areas of the system should be comprehensively covered by automated unit tests to ensure an early warning of possible faults
· Integration points
· Reusable assets
· Architectural risk
· Business process support

Make the right tools and resources available to support rapid application development
· Modeling/case tools are required for moderately sized and larger efforts
· Tools should support a superset of the uml notation (UML alone is not sufficient)
· Automated testing and build tools are the cornerstone to successfully implementing solutions using an iterative/ highly responsive approach
· Resources must have access to adequate development, staging, and testing environments

Develop using an appropriate platform supported by a robust technical architecture
· A solid enterprise architecture is a foundation that supports the ability to rapidly implement functional requirements
· Iterative and agile techniques along nicely to J2EE/.NET technologies
· Most web scripting and legacy technologies, languages lack appropriate tool support, and often are implemented using a more serial/waterfall approach

Implement a best in class Configuration Management Suite
· A comprehensive Configuration Management process is one of the most fundamental requirements of an iterative process:
o Automated unit testing support
o Automated build support
o Continuous integration several times a day
o Flexible versioning, release support
o Mock or stub object generation