1. Introduction to Computer Technology
Session_3
Systems Development Life Cycle
Akanferi Albert

2. Session Objectives Understand system development life cycle
Understand Management Perspective of SDLC
Understand Technical Perspective of SDLC
Identify types of testing in systems development
Identify systems changeover strategies

3. Introduction
System development is a problem solving procedure for examining the existing information system and improving upon it or developing a complete new system.
System development can be viewed from two perspectives, Management and technical approaches.

4. MANAGEMENT APPROACH TO SYSTEMS DEVELOPMENT
A system development from management perspective is made up of four phases,
Diagnosing information needs,
Evaluating information technology needs,
Designing responsive and
Implementing information system

5. Diagnosing information needs
Diagnosing information needs of users involves identifying and describing the problem of the existing system.
The context in which it occurs, the type of information available, the type of information required to solve the problem and the possible way of securing the needed information.

6. Evaluating information technology needs
Evaluating hardware, software, database and data communication of the company by assessing the current technology and systems, comparing available systems and selecting the technology that can address the problem.

7. Designing responsive systems
It involves correcting the deficiencies in the existing or acquiring a complete new system to address the existing problem.

8. Implementing information systems
Implementation involves putting the systems into action or operation.

9. TECHNICAL PERSPECTIVE (SDLC)
A process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership.
The SDLC framework provides system designers and developers to follow a sequence of activities.
Consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one.
Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.

10. SDLC MODELS
Waterfall
Iterative Waterfall
Prototype
Evolutionary

11. Software Development Life Cycle (SDLC PHASES)
A system development from technical perspective is made up of six phases:
Preliminary investigation,
Systems analysis,
Systems Design
Systems Development
Systems Implementation
System Evaluation (Maintenance)

12. SDLC PHASES Maintenance Analysis Design Implementation Development
Preliminary
Investigation
Maintenance
Analysis
Design
Implementation
Development

13. Preliminary Investigation/ Problem Identification
It’s the initial idea of the project
Primary objective is to determine whether the existing system is satisfying the goals and objectives of the organization.
Forming project team and carrying out feasibility (Technical, economic, operational, schedule) studies.
Establishing goals, selecting a system development method and submitting an investigation report.

14. Systems Analysis, Requirements Definition
It is the study of the existing system, its strength and weakness.
It involves assembling an analysis team, collecting and analyzing data, developing report on the existing system.
Data collection seeks individual information about the problems and needs identified.
Systems analysis goal is to determine where the problem is in an attempt to fix the system.
Often there has to be a lot of communication to and fro to understand these requirements.
System Analysis: This step involves breaking down the system in different pieces to analyze the situation, analyzing project goals, breaking down what needs to be created and attempting to engage users so that definite requirements can be defined.
Requirement Definition: gathering is the most crucial aspect as many times communication gaps arise in this phase and this leads to validation errors and bugs in the software program.

15. Systems Design Determines the best system out of several alternatives.
System design dimensions are conceptual design, logical design and physical design.
Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation.
The output of this stage is called system specifications.
The design stage takes as its initial input the requirements identified in the approved requirements document.
Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo code, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the software with minimal additional input design.

16. Data flow diagram and computer programs Flow charts
Flow charts provide a graphical representation of the conceptualized and logical structure and sequence of operation in a program.
The symbols in flow charts are

17. Terminator
Process
Arrow
Decision or control
Connector

18. Development The real code is written here.
Modular and subsystem programming code will be accomplished during this stage.
Unit testing and module testing are done in this stage by the developers.
This stage is intermingled with the next in that individual modules will need testing before integration to the main project.

19. Types of Testing: White box testing Defect testing Regression testing
Automation testing
User acceptance testing
Performance testing
Defect testing
Path testing
Data set testing.
Unit testing
System testing
Integration testing
Black box testing

20. Implementation
This phase places the new or modified systems into operation or action.
The system put into action and staff given enough training on how to use the system.
System change over may take the direct/immediate, parallel, pilot or phase approach.
Changeover crisis are the problems associated with each change over method.

21. CHANGEOVER STRATEGIES
Now that a new system has been completely developed, it should be implemented.
The process of replacing existing system with a new one is termed changeover.
Changeover takes different approaches depending on certain changeover factors such as:
Costs,
System criticality,
User computer experience,
System complexity,
User resistance and
Time.

22. The four changeover strategies
Direct cutover
Parallel operation
Pilot operation
Phased operation
1. Direct cutover: Causes the changeover from the old system to the new system to occur immediately when the new system becomes operational. It is the least expensive but involves more risks than other changeover methods.
2. Parallel operation: Requires that both the old and the new information systems operate fully for a specified period. Data is input to both systems and output generated by the new system is compared with the equivalent output from the old system. When users, management, and IT group are satisfied that the new system operates correctly then the old system is terminated. It is the most costly changeover method and involves lower risks.
3. Pilot operation: Involves implementing the complete new system at a selected location of a company. Direct cutover method and operating both systems for only the pilot site. The group that uses the new system first is called the pilot site. By restricting the implementation to a pilot site reduces the risk of system failure as compared with is less expensive than a parallel system.
4. Phased operation: The phased operation changeover method involves implementing the new system in stages, or modules. We can implement each subsystem by using any of the other three changeover methods. In this approach risk of errors or failures is limited to the implemented module only as well as it is less expensive than the full parallel operation.

23. Comparison of Changeover Strategies
Advantages
Disadvantages.
Direct cutover
Minimal cost
Minimal work load
Quick to implement
High risk of failure
Could disrupt operation
If fails, will be costly.
Parallel Running
Build – in safety
Provides way of verifying results of new system
Costly since two system need to be operated
Time-consuming
Additional workload
Pilot operation
Less risky than direct changeover
Less costly then complete parallel running
Can take a long time to achieve total changeover
Not as safe as complete parallel running
Phased changeover
Less risky than a single direct changeover
Other operations unaffected. Any problem is restricted to one area.
Interfaces between the parts of the system may make this impractical.

24. System evaluation (Maintenance)
The purpose system evaluation is to keep the system operating efficiently and effectively.
It involves the periodic evaluation or review of the system i.e. monitoring the system and ensures its operation.
Involves making changes to the system, problems and major concerns come out and review can trigger the start of the complete system development process.
This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
Maintaining the system is an important aspect of SDLC.
As key personnel change positions in the organization, new changes will be implemented, which will require system updates.
What happens during the rest of the software's life: changes, correction, additions, and moves to a different computing platform and more.

25. Business strategic information systems
The objectives of an organization define what the organization is trying to achieve.
The objectives outline what the organization intends to do or the overall direction of the organization.
To achieve the objectives of the organization, its critical success factors must be identified.
Critical success factors are vital areas in an organization where things must be done right for the business to succeed or gain competitive advantage.
Organizations should design information systems inline with their objectives.