Scribd
Upload
223 views8 pages

04-Systems Development Life Cycle

The document describes the seven phases of the Systems Development Life Cycle (SDLC): 1) Identifying problems and objectives 2) Determining information requirements 3) Analyzing system needs 4) Designing the recommended system 5) Developing and documenting software 6) Testing and maintaining the system 7) Implementing and evaluating the system Each phase has unique activities and involves different personnel like analysts, users, designers, programmers, and management. The SDLC provides a systematic approach to solving business problems through information systems development.

Uploaded by

ron-dulay-4384
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
223 views8 pages

04-Systems Development Life Cycle

The document describes the seven phases of the Systems Development Life Cycle (SDLC): 1) Identifying problems and objectives 2) Determining information requirements 3) Analyzing system needs 4) Designing the recommended system 5) Developing and documenting software 6) Testing and maintaining the system 7) Implementing and evaluating the system Each phase has unique activities and involves different personnel like analysts, users, designers, programmers, and management. The SDLC provides a systematic approach to solving business problems through information systems development.

Uploaded by

ron-dulay-4384
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Lecture 04:

Systems Development
Life Cycle (SDLC)

“The software development process may be referred to as the software life cycle because it describes
the life of a software product from its conception to its implementation, delivery, use, and
maintenance.” [Pfleeger, p. 46]

Systems Development Life Cycle (SDLC)


• The systems development life cycle is a systematic approach to solving business problems.
• It is divided into seven phases.
• Each phase has unique activities.

[Kendall & Kendall, 2002]

Phase 1: Identifying problems, opportunities, and objectives


• Requires that the analyst honestly analyze what is occurring in a business.
• The analyst should check aspects of information systems by addressing specific problems or
opportunities.
• The analyst should be able to see if some aspects of information systems applications can help the
business reach its objectives through addressing specific problems or opportunities.

Page 1 of 8
• Identifying:
• Problems – make sure you’re addressing the correct problems!
• Opportunities - situations that can be improved
• Objectives - how can the organization reach its objectives via computerized IS
• Personnel involved:
• Analyst.
• User management.
• Systems management.

A problem can be defined as the difference between things as perceived and things as desired. If a
difference does not exist between what you perceive you have and what you desire to have, then there
is no problem. In our process, we first need to understand if there really is a problem.

This definition of a “problem” is different from many other ways to define the word “problem.” It
addresses the gap between our perceptions of what our customer wants and what they actually desire.
One advantage of this definition is that it emphasizes that there are many ways to solve a problem:
• Change the customers’ perception of what they have now. For example, many of the requests for
enhancements that Microsoft gets are for features that already exist.
• Change the customers’ current desire. For example, if the customers find that what they want will
cost millions of dollars over their budget, then maybe they will scale back their desires and focus on
solving a simpler problem.
• Change the gap between what customers want and what they actually desire. A software solution is
usually an attempt to narrow the gap.

Problem Analysis Steps:


1. Identify stakeholders.
2. Understand the root causes.
3. Gain agreement on the problem definition.
4. Identify constraints on the system or project.
5. Identify and validate the solution against the root causes.
6. Define the solution system boundary.

Above is a list of activities that you go through when performing problem analysis. Start by identifying
stakeholders for the problem. These stakeholders are people who are affected by the problem.
Next, understand the root causes for the problem (the real problem behind the problem). Once the real
problem (root cause) has been identified, get all your stakeholders to agree to a description of the
problem.
Armed with a description of the problem, identify any constraints that may be imposed on any solution.
These constraints typically limit the solution you may provide.

Page 2 of 8
Next, identify possible solutions for the problem. It is important that you identify more than one
possible solution. By doing this, you can then compare and contrast the solutions to find the best
possible solution.
An additional step not described above is to expand the set of stakeholders to include those affected by
the specific solution you have identified.
The final step is to define the boundary of the solution. This is used to limit the scope during Understand
Stakeholder’s Needs.

Phase 2: Determining Information Requirements


• The analyst strives to understand what information users need to perform their jobs.
• Determining information requirements:
 Interview management, operations personnel.
 Gather systems/operating documents.
 Use questionnaires.
 Observe the system and personnel involved.
• Understand how the business functions and have complete information on the people, goals, data,
and procedures
• The systems analyst needs to know the details of current system functions:
 Who (the people who are involved)
 What (the business activity)
 Where (the environment in which the work takes place)
 When (the timing)
 How (how the current procedures are performed)
 Why (why the business uses the current system)
• Personnel involved:
 Analyst.
 User management.
 User operations workers.
 Systems management.

Phase 3: Analyzing Systems Needs


• Analyze system needs through the following:
 Create data or process flow diagrams.
 Document procedural logic and narratives for the diagrams.
 Complete the data dictionary.
 Make semi-structured decisions.
 Prepare and present the system proposal.
 Recommend the optimal solution to management.
• Personnel involved:
 Analyst.
 User management.

Page 3 of 8
 Systems management.
• Analyst makes recommendations to management
• Management decides whether to continue or not
Phase 4: Designing the Recommended System
• The systems analyst uses the information collected earlier in order to accomplish the logical design
of the information system.
• Designing the recommended system:
 Design the user interface.
• Design output.
• Design input.
 Design system controls.
 Design files and/or database.
 Produce program specifications.
 Produce decision trees or tables.
• Personnel involved:
 Analyst.
 System designer.
 User management.
 User operations workers.
 Systems management.

Phase 5: Developing and Documenting Software


• SA works with users and communicates to the developers what needs to be programmed and
documented
• Developing and documenting software involve:
 Documenting detailed design
 Walkthrough of program design
 Writing computer programs
 Document software with help files, procedure manuals, and Web sites with Frequently
Asked Questions.
• SA works with users for the development of worthwhile documentation for software, including
procedure manuals.
• Personnel involved:
 Analyst.
 System designer.
 Programmers.
 Systems management.

Phase 6: Testing and Maintaining the System


• A series of tests to pinpoint problems is run first with sample data and eventually with actual data
from the current system.

Page 4 of 8
• Testing and maintaining the system:
 Test and debug computer programs.
 Test the computer system.
 Enhance system.
• Personnel involved:
 Analyst
 System designer
 Programmers
 Systems management

Phase 7: Implementing and Evaluating the System


• Activities:
 Plan conversion.
 Train users.
 Purchase and install new equipment.
 Convert files.
 Install system.
 Review and evaluate system.
• This involves training users to use the system
• A key criterion that must be satisfied is whether the intended users are indeed using the system.
• Review and evaluate system - whether the intended users are indeed using the system
• Personnel involved:
 Analyst.
 System designer.
 Programmers.
 User management.
 User operations workers.
 Systems management.
• Training:
 New system training must be performed.
 Analysts must consider:
• Who needs to be trained.
• Who will train them.
• Objectives of training.
• Methods of instruction to be used.
• Sites.
• Materials.
 Possible sources of training for users of information systems include:
• Vendors.
• Systems analysts.
• External paid trainers.

Page 5 of 8
• In-house trainers.
• Other system users.

Appropriate training objectives, methods, sites and materials are:

What is System Maintenance or Support?


• System maintenance is:
 Removing undetected errors, and
 Enhancing existing software.
• Time spent on maintenance typically ranges from 48-60 percent of total time.

Software Reality

• The earliest approach: Code and Fix!


 Write code
 Fix it to eliminate any errors that have been detected, to enhance existing functionality,
or to add new features
• Source of difficulties and deficiencies

Page 6 of 8
 impossible to predict
 impossible to manage
• Finally.. the conclusion: Better Models are Needed!!!
Waterfall Model (document driven)

Evolutionary/Iterative Development (Experience-Driven)

Page 7 of 8
Spiral (risk-driven)

Kendall, K.E., & Kendall, J.E. (2002). Systems analysis and design (6th ed.). New Jersey: Prentice Hall.

McConnell, S. (1996). Rapid development: Taming wild software schedules. Redmond, WA: Microsoft
Press.

Pfleeger, S.L. (2001). Software engineering: Theory and practice (2nd ed.). New Jersey: Prentice Hall.

Page 8 of 8

You might also like