Ch. 5-1: The Systems Development Lifecycle

[5.1.1.3.2] Waterfall

"Cascades" linearly through the 7 phases moves through each of the seven phases above in linear, step-order fashion in which each phase is executed only once in its entirety

[5.1.1.1.6] Implementation

1. Implementation is when the system is ready to be delivered to the users/customers to "go live" - handle real transactions. It is during this phase that the development team must train users how to use the new system. There are a handful of different approaches to implementation. We discuss the four most common approaches below: (see other terms)

[5.1.1.1.4] Development (Construction)

1. Main actors: programmers, testers 2.This is where the actual programming takes place. The primary deliverable during this phase is a prototype or "alpha" system that can then be tested for quality assurance. 3. The testing phase, listed next, will actually begin during the development phase and much of these two phases are performed together

[5.1.1.1.1] Planning

1. Main actors: project manager, project sponsor (usually a VP or other high-level manager who pushed this project into approval), senior analysts 2. Planning is exactly what it sounds like: the systems development team makes a plan for the systems development project. During this phase, it is vital to conduct several types of feasibility analyses, in order to assess whether developing the system is a good idea. (see other terms) 3. An end result of the planning phase is a formal approval (usually signed off by management) that the project will move forward and high-level requirements matrix: a list of approved features and key characteristics of the new system that are required for success

[5.1.1.1.2] Analysis

1. Main actors: systems analysts, business analysts 2. One of the key tasks during the analysis phase is determining user requirements (i.e., what do they want the system to be able to do). Users might be customers, clients, our own organization, or other stakeholders. This is called requirements gathering, or requirements elicitation. These requirements are then compiled in a requirements definition document: a more detailed version of the requirements matrix

[5.1.1.1.7] Maintenance

1. Maintenance includes continued support for the system even after implementation. If an error is discovered, the development team will fix it. If new features are requested, the development team can negotiate for developing the new features. This phase is consistently the most expensive phase of the SDLC. Eventually, as maintenance costs get high enough, that is a signal that a new system should be built

[5.1.1.1.3] Design

1.Main actors: project manager, system architects, programmers (in a support role; not programming), users (to give input and advice) 2.During this phase, the system is laid out using "mockups" (if graphical) and the basic modules and logic for the software portion of the system are outlined. This means that example screens and windows are developed (sort of like storyboarding in cinema) to illustrate the basic flow and feel of the system. Hardware requirements are also determined during this phase.

[5.1.1.1.5] Testing

1.Main actors: testers, programmers 2. This is exactly what it sounds like: users try out the system, find bugs, see if they can break it, and provide feedback to the development team in order to refine the system. Don't think that this is a boring job! This is not like some of those video game testing jobs that students sometimes fill where you simply execute a set of pre-specified sequences in order. Testers have to be creative; their job is to find ways to break the system. This also includes what we call system penetration testing, or "white hat" hacking, which is designed to see if the system can be easily hacked for sensitive data or external control 3. Although there are many types of testing, you should be generally familiar with the following types: (see other terms)

[5.1.1.1.6.4] Pilot Conversion

Activate and test the new system in one branch of an organization, then implement it in other branches once the pilot branch has figured out all the bugs.

[5.1.1.1.6.3] Phased Conversion

Activate the new system one module at a time

[5.1.1.3.1] Commercial off the shelf (COTS)

Buy a ready made solution

[5.1.1.1.6.2] Parallel Conversion

Continue to run the old system until the new one is activated and working

[5.1.1.1.1.2] Economic Feasibility

Do benefits exceed costs? (e.g. ROI)

[5.1.1.1.1.3] Legal Feasibility

Does the system meet all regulations and laws?

[5.1.1.1.1.5] Scheduling Feasibility

Is the project timeline realistic given our resources?

[5.1.1.1.1.1] Technical Feasibility

Is the system realistic, and de we have the expertise to develop it?

[5.1.1.2] Make/Build/Buy Decision

Make means that the organization will write the software code—or some portion of it—themselves using their own programmers. Build means that the organization will hire an external consulting company to build the system—or some portion of it—for them. Buy means that the organization will buy some off-the-shelf software to meet their needs.

[5.1.1.1] SDLC Phases

SDLC has seven main phases: Planning, Analysis, Design, Development, Testing, Implementation, and Maintenance.

[5.1.1.1.6.1] Direct Conversion

Switch from the old system to the new one "overnight"

[5.1.1] Systems Development Lifecycle

The Systems development lifecycle (SDLC) is the process of developing software or information systems from start to finish.

[5.1.1.3] SDLC Methodologies

There are many different methodologies for carrying out an IT project. These approaches fall along varying spectrums of flexibility and agility.

[5.1.1.4] Quality Constraints

Time/Cost/Scope One major consideration throughout the SDLC is the project quality constraint triangle shown below. These three variables are interdependent. You cannot change one without changing the others. Project management during the SDLC is the science of making intelligent trade-offs among time, cost, and scope.

[5.1.1.1.1.4] Operational Feasibility

Will our organization be able to operate the system?

[5.1.1.1.5.1] Unit Testing

do individual components of the code work properly? E.g. If I click the Submit button, does my information get stored as it should

[5.1.1.1.5.3] System Testing

does the entire system of groups of units work properly? This occurs after integration testing and makes sure that all requirements have been met in an integrated system.

[5.1.1.1.5.2] Integration Testing

higher-level than unit testing, integration testing will test whether individual units work together properly

[5.1.1.3.3] Agile

i.e. "quick" & "flexible" Small projects delivered quickly & frequently; daily collaboration with users •Rapid Application Development (RAD) Rapid prototyping; interactive user involvement •Extreme Programming (XP) Methodology Tiny manageable phases; iterate with user feedback

[5.1.1.1.5.4] User Acceptance Testing

this is arguably the most ignored, yet most important, of all types of testing: does the end user actually use this system the way it is intended, in a manner that allows them to perform their job successfully, and will be continually followed by the user after nobody is looking over their shoulder. Many expensive systems have been scrapped after implementation because they were not properly user acceptance tested