Appendix A Systems Development Life Cycle

This book covered project management from the perspective of PMI approach. In this appendix, we discuss the Systems Development Life Cycle (SDLC) approach, which is commonly used in managing IT projects. The proclivity of project management methodologies and techniques today, while valuable , may have had an adverse effect on different people working together toward a common goal. Some have had standard systems analysis and design training, and have learned about the Systems Development Life Cycle (SDLC), a more-or-less standardized approach to how people technically trained in Information Technology handle systems development. There are different flavors of the SDLC, but all of them have at their root the elements discussed below.

Project managers with a certification or formal education in project management, as taught by the Project Management Institute (PMI), have a slightly different approach to how projects get done. For starters, the PMI approach, with its five process groups, is more homogeneous in nature ”that is, the project at hand doesn t necessarily matter as long it is handled within the context of the methodologies that PMI espouses. On the other hand, SDLC isn t standardized and yet its base features are so fundamentally well known that IT professionals are accustomed to them.

Another camp ”the agile development people ”have a little different spin on project management, but we won t talk about that in this appendix as it s too far-reaching for the point we re trying to make here.

The differences, while subtle, are vast and could potentially lead to some infighting between your project managers and your technical team. If you know that there are those who think SDLC and those who think PMI, then you ve got some points to discuss. The purpose, of course, is to get people aligned down a common road toward successful completion of your project.

If you ve had training in Information Technology you may have run across a common systems development methodology that has been worked out over many years of refining and building IT systems. This methodology was originally developed for software developers writing code for mainframe systems, but even in today s complex interaction of software applications with disparate server, network, and Web environments, the methodology still fits a variety of different IT systems.

The Systems Development Life Cycle (SDLC) is a way of thinking about developing and implementing IT systems. The SDLC is built around the notion that a corporate IT department (or departments) handles the job of maintaining the IT infrastructure and works with business entities to build and deploy new systems. The SDLC consists of five phases.

Planning

The planning phase begins with a request from a business unit for help in building a new IT system. The request could come from a variety of different people ”the business unit manager, an executive in the corporation, some sort of planning committee, or even a consultant who has been working on a feasibility study. (Note that feasibility studies are actually a part of the SDLC planning phase. In some cases the business unit might ve undertaken the study prior to coming to you with the work request. So even though they re unwitting participants , they re helping you fulfill a component of SDLC ”the feasibility study.

The planning phase also includes the preparation of a formal business unit request. This work request sums up what it is that the business unit is after. Many different types of work might be requested . A business unit might want a completely new system to take the place of time- intensive manual processes. Or they might want a system that replaces an old antiquated system with one that uses current technology. Alternatively, the business unit might be looking for ways to augment its current operations and have ideas in which technology can assist. A request can be phrased in a variety of different ways. It is the system analyst s (SA) job to analyze the request and formalize it in such a way that the business unit and the IT group understand what is being requested.

In order to accomplish this work request, it will probably be required that you undertake a preliminary investigation in order to understand the type of work that is currently being done and how the business unit envisions technology enhancing that work. In the preliminary investigation, you delve into the nature of the problem or the opportunity before you. By coming to a 5,000- foot view of what s being asked, often you can determine that a new system or an upgrade to a previous system isn t in order, a simple business refinement may be the ticket.

In some cases, the project might be so large in scope that you have to perform a feasibility study. Generally you ll use outside sources in the form of consultants who are able to objectively look at what the problem is versus the proposed solution so that you can identify the proposed solution s viability and/or recommended alternatives. In some cases in government work, a feasibility study is required before a project can be undertaken. Executives with a fiduciary duty simply don t want to make a mistake undertaking a multimillion-dollar project before they understand the ramifications of what is being asked for. A feasibility study fleshes out the project s costs and associated outcomes , and recommends a path based on the various factors involved (such as political, financial, and technical capability among others).

The SDLC planning phase somewhat maps to the Guide to the PMBOK s Initiation process group.

Analysis

The analysis phase is a continuation of the planning phase and goes more in-depth into what the actual project requirements are and what they involve. This phase involves the understanding of the business unit s process flows, a very critical element in bringing about high-quality systems.

Often, once an SA understands the work flows, he or she can recommend changes in those flows, apart from technology, so that the work effort is reduced. This is called business process reengineering (BPR) and could potentially be a huge part of an SA s work.

An output of a preliminary investigation will be Data Flow Diagrams (DFD), drawings that highlight the way that the business flows are actually occurring today, along with proposed new flows. The DFDs will become the building blocks toward realizing a complete new system or a remodel of an old one.

Tip

It is key to remember that you must always first understand the business work flows before you apply technology. Too often people get the cart before the horse and wind up with a poor product as a result.

In the Analysis phase you re going in-depth, trying to ascertain how the different users interact with the current system, what the current system documentation (if any) looks like, and so forth. You may even get into things like performing surveys to find out what people think about the different system requirements, or perhaps work on some sampling to get a flavor for how the current setup works. In short, you re trying to utilize any tool in your bag that might help you be certain that you ve trapped in detail exactly what it is that is being asked for.

Getting Your Hands Dirty with SDLC ”Planning and Analysis

Perhaps the best way to think about the SDLC process is to try to imagine a home fix-up project that you ve undertaken ”maybe a landscaping project, a room remodel, or finishing a basement .

Your husband or wife says: Honey, we need to do something with that backyard! This is the work request.

From this humble beginning you might ve started out by drawing the layout of what you were going to work on. In the landscaping example, you d have a rough sketch of the outline of the grounds, coupled with symbols for the trees, bushes, flowers, grasses, and accoutrements such as statuary that you planned on placing in the area. You could roughly analogize that this is your landscaping DFD. You have enough information to understand where things go, but probably not enough to completely understand how you ll fully go about doing your landscaping job.

If the job were big enough, you might actually hire a landscaping architect to develop plans for you before you go about doing your work. This would represent a feasibility study, in which you bring in an expert and ask them how they envision accomplishing what you have in mind. In this case, the landscaping architect provides you with the blueprints ”your DFD ”but you still have to go about doing the work. Note that this work is expensive and you d probably not undertake it with a smaller project.

 

The outcome of this step is a document called the Systems Requirements Document ”a thorough paper that details the requirements that the different parties (managers, end users, recipients of reports , etc.) stipulated, forecasted project costs, and positive takeaways as well as suggesting suitable alternatives to full-scale systems development.

This phase tracks closely to the Guide to the PMBOK s Planning process group .

Design

The design phase represents the real nitty-gritty of the project. It is here that you fully formulate all the aspects of the system in such a way that each step is well understood and translatable to technology. This phase includes any current manual steps. For example, you might have identified in your earlier analysis a step in which a person keys several columns worth of data from another computerized source into a separate tabular format for processing. The computerized version of this step might be to parse the data from the first source and then place it electronically into the second, saving an incredible amount of time.

It is important in the design phase that every element of the process has been identified, is well understood, and is now translated into the way that you see the new technology handling things. The end result of this effort is a document called the Systems Design Specification and will be used by system developers to create the new system.

The point is the same with the System Design Specification document. This doc is a blueprint, a set of lists, a how-to guide, and all of the other things that the folks developing the system will need to get started.

Getting Your Hands Dirty with SDLC ”Design

In our little landscaping project, the landscape architect s blueprint would represent a part of your system design specification document, but you d augment that documentation with things such as:

The kind of soil you d use to prep the grounds before you lay down grass, including how many yards of dirt you ll require and how you ll till it into the existing ground.

The type of mulch you re going to use, where you ll put it, and how much you re going to need.

The type of blocks you ll utilize for the walkways, the amount of sand that you ll require as a base for the blocks, and the pattern that you ll create with them.

And so forth. The point here is that by the time you ve gotten to this stage, you know an awful lot about how you re going to do things.

Note that the System Design Specification is not line-for-line code. That stuff is done by the developers writing the application programs that the system will utilize. But you could use a type of software application called Computer Aided Software Engineering (CASE) Tools that would allow you to develop the basic shell of the system by keying in business rules then hitting a button to tell the CASE software to write the underlying components of the code. CASE Tools are not used heavily in smaller application development environments, but in larger environments they re still a part of the framework that project teams use to make the job go more quickly. Additionally, CASE Tools can be used to help you organize and understand the project s requirements.

The Analysis phase of the SDLC closely maps to the Guide to the PMBOK s Planning process group .

Implementation

The singular objective of the implementation phase is to bring to the customer a complete and fully functioning system that has been carefully and completely documented and thoroughly tested .

In the Implementation phase, project members write the software programs needed by the system, they set up the servers, install the database software, and get the schemas built and working, and so forth. If the system is going to utilize a COTS application, the application is installed and configured.

Testing occurs in the implementation phase. We ve covered some of the testing phases (Unit, System, and User Acceptance) in previous chapters. In the Implementation phase, project members make very sure that the system is fully tested so that it is validated to work as expected. Larger systems may require several phases of testing.

Note

In a software development methodology known as agile development , testing techniques are utilized that allow for testing while the software modules are being created. In this way, programmers can discover problems earlier than at unit testing time and thus push code out the door faster. See www.agilealliance.com/home for more info on agile software development.

There are several other smaller elements involved with the Implementation phase. In this phase, data from old systems is converted and ported to the new system. Users of the system are trained in its functionality. Users are also actually migrated to the new system.

Additionally, system designers will go through a process called Systems Evaluation , in order to evaluate and report that the system does indeed meet the previously identified requirements.

The Implementation phase most closely maps to the Guide to the PMBOK s Execution and Controlling process groups.

Getting Your Hands Dirty with SDLC ”Implementation

Now that you know what your new landscape is going to look like, you ve got a blueprint and all the associated documentation you need to make your yard look fantastic!

You go to your local garden supply store and pick out all of the supplies that you need that you can directly transport home. You also order the delivery of the mulch, soil enhancer (sheep manure), turf, and stones you need ”things you can t haul home in your personal vehicle. You also rent the specialized equipment you ll need, like the tiller.

While awaiting the delivery, you go about doing all of the preparatory work you identified earlier ”things that you can get done in preparation for the big stuff. You till the area where you re going to plant grass. You also dig out the flower beds and lay down the edging that will serve as the boundary for your stone paver patio and walkway. You run the sprinkler system from the grass and sprinkler hose (bubbler system to conserve water) for the plants. You plant the shrubs, flowers, and bushes. You place the statuary.

When the delivery truck(s) arrives, full of big mounds of sand, soil enhancer, mulch, and paving stones, you begin the heavy work of hauling the soil enhancer to the grass beds, then tilling anew to make sure the soil is augmented and ready for the turf delivery folks. You apply the mulch to your garden beds and then lay down the sand in your paving stone areas so you have a nice even surface with which to lay down your pavers. The turf delivery people show up and lay down the sod.

After weeks of work, you test the entire system by walking around in it to make sure you re happy with how it looks, then you plop down in your chaise lounge with a tall, cool drink and slip into a much-deserved nap!

Operations and Support

Unlike the Guide to the PMBOK s Closing process group , where you close out the project and anything new is considered a brand-new project, in the Operations and Support phase you actually work on enhancements, training, and support. The idea behind the Operations and Support phase is solid ”you ve just deployed a system and now a group of people must actively support it. Whether you train new people or you ve been asked to add some enhancements, or you need to pull routine maintenance (such as backups or security patches), all of these elements fall into the Operations and Support phase.

Elements of Operations and Support, such as help-desk operations, clearly fall into the Guide to the PMBOK s Closing process group. In the Closing process group, you would ve written and made available help-desk documentation for the new system but that s where you stop. In the SDLC, you go beyond that and see ongoing help-desk operations as a part of the system. We need to reiterate that when you ve concluded the Closing process, the project s over and enhancements or additions are considered to be a new project. The Guide to the PMBOK doesn t talk about maintenance or enhancements. As far as A Guide to the PMBOK is concerned , technically, you would turn the project over to a support group. Remember that the definition of a project is an endeavor designed to produce a unique product or service and that has a definite beginning and end. However, SDLC accounts for this as the fifth phase of the life cycle and requires that you make accommodation.

Getting Your Hands Dirty with SDLC ”Operations and Support

Several months into your new landscaping project, your sprinkler system clock goes out. Fortunately it s under warranty, but you have to make temporary provisions for it while you send the old one off to the factory for a replacement. You wind up purchasing a cheap little clock that doesn t have as many zones as you require, but at least enough to keep watering the grass. You simply go into the old drag-the-hose routine to make sure the flower beds are watered until you get the replacement clock.

Also, you discover that some of the pavers in the walkway have sunk a half-inch or so and look unsightly. You have to pull them up, add some more sand, tamp it down thoroughly, and then reset the pavers.

Additionally, you had one plant die (you wondered about it when you bought it at the garden supply store) and so you had to replace it.

You ve got a problem with an unusual new bug. You drive over to the local university extension office to ask them about it and get some helpful advice. Turns out the bug isn t harmful ; in fact it s quite useful as it loves to eat aphids. However, this discovery points to the fact that the new trees you planted are loved by aphids ”so much so that you ve got to do something about it ”they ll devour the tree bark in no time!

This is a subtle differentiation to make. Good project managers would, of course, realize that a new system requires ongoing maintenance and caretaking and see to it that steps were taken to accommodate the need. However, the project plan itself does not have any provision for this post-project work.

Comparing the Guide to thePMBOK s Process Groups with the SDLC Phases

In Table A.1, we ve provided you with a chart that may help you understand the close parallels between the Guide to the PMBOK process groups and the SDLC phases. IT projects have a unique character all their own ”we re not building a battleship or a skyscraper ”and so it s important to understand SDLC in order to help shape and bring about an excellent system deployment. However, A Guide to the PMBOK s process groups provide a wonderful project management framework in which to work, so it s quite important to understand how the two juxtapose.

Table A.1: Project Life Cycle Key Elements with SDLC Phases

Project Process Group	Outputs or Key Activities	SDLC
Initiation	Project charter/Project request	Planning phase
		Create formal business unit request
		Provide preliminary investigation
		Complete feasibility study (if necessary)
Planning	Scope statement (Establish project goals and deliverables)	Design and analysis phase
	Critical success factors	Model requirements
	Work breakdown structure (WBS)	Document system requirements
	Resource plan (assignment of tasks)
	Risk management plan
	Communication plan
	Quality plan
	Change control plan
	Project schedule
	Project budget
	Implementation plan
	Support plan
Executing	Implement project team	Implementation phase
	Progress reporting	Development of system
	Take corrective action
Controlling	Overall change control	Implementation phase
	Assess the impact of change	Development of system
	Testing and inspection
	Write user guides
	Write system administration guides
	Provide training
Closing	Obtain sign-off	Operation and support phase
	Document lessons learned	Training
	Evaluate the project	Maintenance
	Archive project information	Enhancement