Introduction to Program Management: The System Development Life Cycle

There are many theories on how best to manage the development of a system. Many revolve around the idea of a system development life cycle. The analogy being that a system is conceived, is born, grows up, gets a job, and eventually dies.

There are more formulations of the system development life cycle than there are chili recipes. However, they all share a common set of activities.

I break the activities down as follows:

• Inception — Some people call this a “kick off.” I used to call it “initiation,” until somebody pointed out to me that at an institute of higher learning with an active Greek community, that term has other connotations. Regardless of what you call it, it starts with the moment when a business need or opportunity is identified, documented, approved, and a champion is appointed to pursue it.

• Operational Concept Development — This activity gives the customer an opportunity to describe and document their need without getting mired in technicalities that can be dealt with later. This is where you’ll see flowery terms like “reliable” or “easy to use.” You might also see suggestions for ways to implement the solution, but these are only suggestions. Use them to explore concerns about solution strategies, looking for design constraints. In a case where the effort is a modification to an existing system, this is an opportunity to make up for poor existing documentation and establish a baseline for it.

• Program Management (PM) Planning — Once you have a good idea what the need is, you have to think about how it impacts what you are already doing in terms of development. Does it fit with your group’s objectives? When is it needed? Is there sufficient manpower available to adequately address the expected activity? Does the group have the necessary technical resources? Does it have the necessary skill set?

• Analysis — System Requirements Specification — In this activity you identify the raw “black box” requirements — interface, functional, data, performance, security, maintainability, and so on — and from them you build “well-formed” requirements that describe capabilities the system should have and the conditions and constraints that apply to them. At the end of the activity you should be able to present an organized set of requirements that if implemented, should satisfy the identified need.

• Design (not what you think it is) — In the design activity, you look inside the black box for the first time. You come up with a plan to implement the requirements. You identify and document the components inside the box, how they interconnect, and what each has to do.

• Development — Once you know what you need inside the box, you need to figure out how you are going to provide each of those components. You’ll decide which components you are going to build and that you’ll buy, and then you’ll build and buy. At the end of this activity you should have a bunch of components ready to put together for the first time.

• Integration and Test — This is where you roll up your sleeves and put it all together, make it work, and show that it meets its requirements.

• Implementation — Once you have shown your system meets its requirements you can build as many as you need.

• Operations and Maintenance — Working systems almost always need to be watched and occasionally nudged to keep them working. This is where you do that.

• Evaluation — We would all like to think we get everything right the first time, but that never actually happens. While a system is in operation, you should evaluate whether and how it addresses the real needs of its users. If there are shortcomings, you should consider starting on a revision of, or a replacement for the system.

• Disposition — All good things come to an end. Eventually the business need will go away, or be solved in a different way that makes the system obsolete. This is where you clean up the flotsam and jetsam of the life cycle.

Update: Typically a Manufacturing phase would follow Development and precede Integration and Test. However, I believe it unlikely that anyone at Penn State will do any manufacturing as part of a system development, so I have ignored it for the purposes of this discussion.

Share: Delicious | Facebook