Week one Lecture - an Overview of the Systems Development Life Cycle

Week One Lecture

An Overview of the Systems Development Life Cycle

It's time to get started with our course work on the Fundamentals of Business Systems Development. This is the first in a series of courses you will complete at the University of Phoenix leading to your degree. There are many approaches taken in the IS world to this undertaking. Ours will be built around what is known as the Systems Development Life Cycle. We will provide information about other approaches and encourage you to bring into our discussions other methods you may have seen used on the job or studied in the past.

The most important lesson you will learn in this module, aside from particular techniques, is the importance of having a methodology for development. Stories of systems development failures are legion in the industry. Most often the reason for failure was not the people involved in the project or the technical nature of the project itself. Instead the failure can be traced to a lack of cohesive methodology or the failure to follow the methodology established in the beginning. The ins and outs of a particular method are secondary. Having a plan that all involved in the project can follow is the most important part.

The Systems Development Life Cycle method organizes the project by breaking it down into discrete phases that, for the most part, do not overlap and have very specific milestones and deliverables which can be used to monitor the progress and efficiency of the project while providing input for the next phase of development.

Tasks that Span Phases

This class approaches development in a very phased approach. It's a good way to explain things. But, there are four central tasks crucial to Information Systems development success that span all phases of the life cycle. I'd like us to discuss them. They are;

* Project Management

* Documentation

* Testing

* Deliverables

Project Management is the process that monitors all activity, based on tasks and timelines developed in the Strategy and Analysis phase, and insures that appropriate resources, human, monetary, equipment, facilities and time among others, are allotted and tracked. There is a complete module on project management in the curriculum so we will devote attention to it here only as it relates to interconnecting the life cycle phases,

Documentation is often called the orphan child of systems development. Nobody wants to take the time to explain what they are developing in a formal written way and yet without a good documentation set it soon becomes difficult to know what has been developed or how to maintain the implemented system when things go wrong or need to be changed. It is crucial to begin documentation of the system from the very beginning and make it a part of tasks tracked through project management.

When I first came to Housing there was very little in the way of technical support. Quite often when a staff person had a project that they thought would help their operation they allowed a student assistant to develop it. (Often the project was suggested by a student assistant because it went along with their class work.) This approach worked fine as long as the student was there to run what ever was developed. Once the student left, however, it was a different story. No documentation was developed for these efforts and, often, no one else was formally trained. On several occasions I was brought in to get our staff person what they needed. More often than not it was easier to simply start from scratch than try to decipher from the code what it was the student developer had done.

For small modular programs and systems there was no big loss and I was able to use it as an opportunity to bring the functionality into our mainstream systems but if a major system is developed without supporting documentation a business could become hostage to the few people who understand it.

Testing is done on many levels throughout the project. For example, the basic concepts of the business problem or opportunity that is being solved or developed must be challenged early and often to insure that the proposed solution addresses the issues at hand.

More formally, modules created in the Implementation phase must be tested with realistic data to insure that they perform as intended. If these things are attended to then the most important tests, those done by the eventual client or users of the system will go much more smoothly.

Deliverables are specific items defined in advance and shared with the client at predetermined times. Deliverables can be documents, code, configured hardware or whatever is needed in the project. We'll look at specific deliverables for the various phases as we go but bear in mind, mine is not a complete list.

System Development Life Cycle

Many different names and strategies for breaking them out are used for the phases of an Information Systems development project. The text uses eight phases. I discuss Design and detailed design as one phase and add one for acceptance as follows;

* Scope

* Feasibility

* Systems Analysis

* Systems Design

* Implementation

* User / Client Acceptance

* Changeover

* Maintenance

This course will take you through each of the steps in this process and the tasks and deliverables associated with them. Our purpose this week is to develop a broad outline of what these phases are and how they work together.

Scope refers to the process of determining what is to be addressed in the project and what is not. All systems begin with a business problem that needs to be solved or, even better, a business opportunity the organization wants to take advantage of. The situation must be closely examined without regard to the particular tools that may be used to actually develop the system.

Deliverables from the Scope phase should include;

* A Business Plan or Model including explicit sponsorship and funding.

* A statement of what problems, opportunities or elements of the business the system is specifically intended to address.

* A statement of what problems, opportunities or elements of the business the system is specifically not intended