Table of Contents

System Development Lifecycle (SDLC)

Information Lifecycle Management (ILM)

Battling the Bulging Inbox

The Magic of Rounding

What is the best System Development Lifecycle (SDLC)?

Each of the models presented here stand on their own merit, however, the project manager should use a model that best delivers the product efficiently.

Whatever method is chosen, project managers should consider the 80/20 rule and Service Oriented Architecture (SOA) when planning a new SDLC.

The 80/20 Rule in Application Devleopment

With the 80/20 rule we are not looking for perfect solutions. We are not trying to do requirements ad nauseum. Instead, we get 80% solutions in place in a relative quick cycle time and look at enhancements later (the 20%) —but get the base platform in quickly. 80% works all the time. Packages, suites, not best of breed solutions. Pre-integrated suites of systems. Service Oriented Architecture (SOA) should also be considered in development consideration.

Service Oriented Architecture (SOA)

SOA expresses a perspective of software architecture that defines the use of loosely coupled software services to support the requirements of the business processes and software users. In an SOA environment, resources on a network[1] are made available as independent services that can be accessed without knowledge of their underlying platform implementation.

A service-oriented architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including REST, RPC, DCOM, CORBA or Web Services. SOA can be implemented without any of these protocols, and might, for example, use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having pre-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

Preferred method of System Development Lifecycle (SDLC)

Synchronize and stabilize method combines the advantages of the spiral model with the technology for overseeing and managing source code. This model is a sort of hybrid model.

• Allows many teams to work efficiently in parallel.

Examples:

1. Run nightly compilation (called a build) of the entire project bringing together all the current components.
2. Establish release dates and expand considerable effort to stabilize the code before it is released.
3. Alpha release for internal testing; one or more beta releases (usually feature-complete) for wider testing outside the company or internal customers.
4. Release candidate leading to a gold master, which is released to production.

At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs.

Allows management of millions of lines of code as specifications change and evolve over time. Design reviews and strategy sessions are frequent, and everything is documented.

Need to build contingency time into schedules, and when release deadlines get close, scale back product features rather than let milestone dates slip.

Waterfall

This method is a good basic model for most application development and is the oldest of the models. The waterfall method assumes, however, that the only role for user is in specifying requirements, and that all requirements can be specified in advance.

Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Consequently, many other SDLC models have been developed.

This model is a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:

• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation.
• Implementation: The real code is written here.
• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs in the actual business structure.
• Maintenance: What happens during the rest of the software’s life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

The Fountain Model

This model recognizes that although some activities can’t start before others – such as you need a design before you can start coding – there’s a considerable overlap of activies throughout the development cycle.

The Spiral Model

This model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It’s actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.

Build and Fix

This is probably the crudest of the methods. Write some code, then keep modifying it until the customer is happy. Without planning, this is a very open-ended and can be risky.

Rapid Prototyping or Rapid Application Development

With this model, initial emphasis is on creating a prototype tat looks and acts like the desired product in order to test its usefulness. This mode provides the user with a “look and feel” which serves to stimulate the process senses. The prototype is an essential part of the requirements determination phase, and may be created using tools different from those used for the final product. Once the prototype is approved, it is discarded and the “real” software is written.

Incremental

The incremental model divides the product into builds, where sections of the project are created and test separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after its written.

Works Cited