System Development Life Cycle
System Analysis and Design
Systems Development
• THERE EXIST VARIOUS THOUGH SIMILAR APPROACHES AND
REPRESENTATIONS OF SYSTEM DEVELOPMENT PROCESS AND ITS
PHASES.
• IN THESE LECTURE NOTES; YOU WILL FIND SOME OF THEM FROM
THE BELOW RESOURCES
• Laudon and Laudon, 2015. Management Information SystemsManaging the Firm in Digital Age,Pearson
• Anon (2013) Systems Analysis and Design – Complete
Introductory Tutorial for Software Engineering, (adapted in
UML approach)
• Systems analysis and design /Alan Dennis, Barbara Haley
Wixom, Roberta M. Roth.–2012, 5th ed. p. cm.
• Yıldırım, N. Lecture Notes in MIS – 2009-2019
Introduction
• The trends of increasing technical complexity of the systems, coupled
with the need for repeatable and predictable process methodologies,
have driven System Developers to establish system development models
or software development life cycle models.
• With the developments in IT and with the growing operations of
organizations, the need to automate the various activities increased,
since for manual procedures it was becoming very difficult, slow and
complicated.
• Since there were a lot of organizations, which were opting for
automation, it was felt that some standard and structural procedure or
methodology be introduced in the industry so that the transition from
manual to automated system became easy.
• The concept of system life cycle came into existence then.
System Development
• System development begins with the recognition of user needs.
• Then there is a preliminary investigation stage. It includes
evaluation of present system, information gathering, feasibility
study, and request approval.
• Feasibility study includes technical, economic, legal and operational
feasibility. In economic feasibility cost-benefit analysis is done.
• After that, there are detailed analysis, design, implementation,
testing and maintenance stages.
Information System Concepts Revisited
Seven key system elements
• 1.Boundary
• 2.Environment
• 3.Inputs
• 4.Outputs
• 5.Components
• 6.Interfaces
• 7.Storage
In System Analysis and Design, we aim to
define these elements by using logical
representation methods.
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Information System Concepts Revisited
1.BOUNDARY
• Delineation of which elements
are within the system and which
are outside
• Where to draw the boundary
depends on:
- What can be controlled
- What scope is manageable within
a given time frame
- The impact of a boundary change
2. ENVIRONMENT
• Everything outside the system
(Supra and neighbor, integrated systems)
3. INPUTS
• Resources from the environment that
are consumed and manipulated within
the system
(Data and instructions)
4. OUTPUTS
• Resources or products provided to the
environment by the activities within the
system
(Data, Information, Reports, Queries,
Screens etc.)
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Information System Concepts Revisited
5. COMPONENTS
• Activities or processes within the
system that transform inputs into
intermediate forms or that
generate system outputs
• Some system components can be
viewed as systems with their own
sets of interrelated components =
subsystems
(Modules and Functions of the
System)
6. INTERFACES
• The place where two components
or the system and its environment
meet or interact
(User Interfaces)
7. STORAGE
• Holding areas used for the
temporary and permanent
storage of information, energy,
materials, etc. system
(Databases)
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Information System Concepts Revisited
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Five Key Design Principles for Information Systems
Two principles stem from key systems characteristics:
1.Choose an appropriate scope
• Selecting the boundary for the IS greatly influences complexity and
success of the project
2.Logical before physical
• You must know what an IS is to do before you can specify how a
system is to operate
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Systems Development Life Cycle Steps
• The activities that go into producing an information system solution to an
organizational problem or opportunity are calles SYSTEMS DEVELOPMENT.
• Systems development is a STRUCTURED PROBLEM SOLVING with DISTINCT
activities like:
•
•
•
•
•
•
•
•
•
Planning and Preliminary Investigation
System Analysis
System Design
System Implementation (corresponds to Programming in Software System
Development)
Unit Testing (included in Implementation for Software System Development),
System and Acceptance Testing, Validation, Review
Conversion
(Production)- optional for SW system development)
Maintenance and Improvement
The System Development Process
Planning or Preliminary
Investigation lacks !
NY
There can exist
Production in
between Testing
and Conversion
NY
 Activities here take place in SEQUENTIAL ORDER.
 But, some of these activities may be repeated or take place
simultaneously, depending on the approach to system
building.

http://msdn.microsoft.com/en-us/beginner/dd547995.aspx

http://msdn.microsoft.com/en-us/beginner/dd569713.aspx

http://msdn.microsoft.com/en-us/beginner/dd569717.aspx
System Development Loop
Project Planning
Preliminary
Investigation
System
design
FINDING THE SOLUTION : Designing/Defining the
“needed/required” system– Specifications, “How it
should be?”
System
implementation
Documentation
Training
Structural Change
(+Revision)
IMPLEMENTING THE SOLUTION :
Building, Project, Hands-on work,
“Closing the Gap”
PERFORMANCE
System
EVALUATION : Control,
Validation control Check, “Measuring the
There can exist
Production in
between Testing
and Conversion
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009-2019
Corrective Actions
Preventive Actions
DEFINING THE PROBLEM : Understanding the
current system or need for the system –
Requirements List, “Contract”, What is the Gap?
Revisions
Modifications
System
analysis
Gap”
System
maintenance
and improvement
System Development Stages and Loop
Laudon and Laudon (2015) MIS Text Book
Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)
System Development Stages and Loop
Planning or
Preliminary
Investigation
(NY)
Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)
System Development Stages and Loop
https://coggle.it/diagram/V-y1bCLBY9gtDTZO/t/6-2-system-development-life-cycle-star
Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)
Systems analysis and
design /Alan Dennis,
Barbara Haley Wixom,
Roberta M. Roth.–2012,
5th ed.
p. cm.
Systems analysis and
design /Alan Dennis,
Barbara Haley Wixom,
Roberta M. Roth.–5th ed.
p. cm.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.–5th ed.
Planning Phase
(also called Preliminary Investigation)
• First stage of any system development
INITIAL INVESTIGATION: Problem is identified, Need for the new or the enhanced system is established.
ESTABLISHING THE NEED FOR NEW OR IMPROVED SYSTEM: All possible alternate solutions are ("candidate systems»)
: determined, weighed, the best alternative is selected as the solution, which is termed as the "proposed system".
Identify Opportunity:
Understanding the customer
request for the new or
improved system
• Identify the problem
• Understand the background
• Review the Environment of
the system
Thinking of possible solutions
• Current Solutions (similar)
• Available solutions
(package or contracted)
P.S.: These phases correspond to the «Preliminary
Analysis» section» of ISL 343E MIS Term Project. A part of
it is presented in «Project Proposal» presentation by your
group
Identify
solutions
Decision on the solution
Analysing each possible
solution
• Benchmark and Decision
Matrix (MDM)
• ascertained whether that
system is practically
possible or not)
In the end of
preliminary analysis
all the findings and
recommendations for
which solution to use,
are presented to
management, which
finally decide whether
to accept the
proposal or reject it.
Assess
the Feasibilities of each solution
Decide on the Most feasible
solution
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009-2019
Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)
Planning Phase
(also called Preliminary Investigation)
https://its.ucsc.edu/drb/sdlc/prob-sol.html
P.S.: These phases in Red Circles correspond to the «Preliminary
Analysis» section» of ISL 343E MIS Term Project. A part of it is
presented in «Project Proposal» presentation by your group
Planning Phase (also called Preliminary
You can use Cause
Investigation)
and Effect Diagrams
.
• The analysis of the problem to be solved with an
information system.
•
•
•
•
.
Defining the problem
.
Identifying the causes
Specifying the solution
Identifying the information requirements to be met.
Environment
Example
Fishbone
Diagram
• Create a road map of existing organisation and system
• Identify the primary owners and users of data
• Identify the existing hardware and software.
• Detail the problems of existing system
• Examine documents, work papers, procedures
• Observe system operations
• Interview key users of the systems
• Identify the problem areas and objectives of the
solution
• Building a new IS
• Improving an existing IS
Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009-2019
Users and owners of the data Example
System
Project
Request
Management
Approval
Feasibility
(Project plan
Analysis
• The fundamental process of understanding why an information system should be built and determining how
the project team will go about building it. It has two steps:
1. Project initiation: the system’s business value to the organization is identified
—how will it lower costs or increase revenues? Most ideas for new systems come from outside the IS area
(from the marketing department, accounting department, etc.) in the form of a system request.
A system request presents a brief summary of a business need, and it explains how a system that supports the
need will create business value. The IS department works together with the person or department generating
the request (called the project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key
aspects of the proposed project:
■ The technical feasibility (Can we build it?)
■ The economic feasibility (Will it provide business value?)
■ The organizational feasibility (If we build it, will it be used?)
The system request and feasibility analysis are presented to an information systems approval committee
(sometimes called a steering committee), which decides whether the project should be undertaken.
2. Project management: Once the project is approved, it enters Project management, the project manager
creates a work plan, staffs the project, and puts techniques in place to help the project team control and direct
the Project through the entire SDLC.
The deliverable for project management is a project plan that describes how the project team will go about
developing the system.
Planning Phase
Investigation
Project Inıtıation
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
• System request is a document that describes the business reasons for
building a system and the value that the system is expected to
provide.
• The project sponsor usually completes this form as part of a formal
system project selection process within the organization.
• Most system requests include five elements:
1.
2.
3.
4.
5.
project sponsor,
business need,
business requirements,
business value, and
special issues.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Project
Inıtıation
Planning Phase
Problem Definition
Examples
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
In conclusion, the current problem is: “The process complexity of the Erasmus+ Exchange
Mobility Program among the participants and active individuals in the process”
Major difficulties are:



Sending Erasmus documents to the responsible departments within ITU
Making LA change to be approved by the responsible departments
Selecting and comparing courses for preparing the LA and making them to be
approved by the responsible departments

Meeting with coordinator / appointment system via face-to-face or online
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Approval
Project
Management
(Project plan
Planning Phase
System Request
Example
Project
Inıtıation
System
Request
Feasibility
Analysis
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Approval
Project
Management
(Project plan
Planning Phase (Also called
Preliminary Investigation )
• EVALUATION & FEASIBILITY
• Whether it is practical and beneficial to build that system.
• Evaluated from developer and customer's point of view
• Developer sees whether they have the required technology or manpower to
build the new system.
• Is building the new system really going to benefit the customer?
• Does the customer have the required money to build that type of a
system?
•
•
•
•
Technical,
economical, and
operational.
Legal
Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)
Suppose in an office all leaveapplications are processed
manually.
Now this company is recruiting
many new people every year.
So the number of employee in
the company has increased.
So manual processing of leave
application is becoming very
difficult.
So the management is
considering the option of
automating the leave processing
system.
If this is the case, then the system
analyst would need to investigate
the existing system, find the
limitations present, and finally
evaluate whether automating the
system would help the
organization.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Approval
Project
Management
(Project plan
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
• Is the solution feasible?
• Is the solution achievable?
(Financial, technical, organisational standpoints)
• Feasibility study
• Technical feasibility: Can the development of the proposed system be done with current equipment,
existing software technology, and available personnel? Does it require new technology? Is the
technology needed for the system available? Can the technology needed be handled by the firms’ IT
professionals?
• Economic feasibility: Are there sufficient benefits in creating the system to make the costs acceptable?
An important outcome of the economic feasibility study is the cost benefit analysis. Is the proposed
system a good investment?
• Legal feasibility: It checks if there are any legal hassle in developing the system.
• Operational feasibility: Will the system be used if it is developed and implemented? Will there be
resistance from users that will undermine the possible application benefits? Can the organisation
handle the changes brought by the system?
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
Technical feasibility :
• The extent to which the system can be successfully designed, developed, and installed by the IT group.
• Technical feasibility analysis is, in essence, a technical risk analysis that strives to answer the question:
“Can we build it?”
• Many risks can endanger the successful completion of the project. First and foremost is the users’ and
analysts’ familiarity with the application. When analysts are unfamiliar with the business application area,
they have a greater chance of misunderstanding the users or missing opportunities for improvement. The
risks increase dramatically when the users themselves are less familiar with an application, such as with the
development of a system to support a new business innovation (e.g., Microsoft starting up a new Internet
dating service). In general, the development of new systems is riskier than extensions to an existing system,
because existing systems tend to be better understood.
• Familiarity with the technology is another important source of technical risk. When a system will use
technology that has not been used before within the organization, there is a greater chance that problems
and delays will occur because of the need to learn how to use the technology.
• Risk increases dramatically when the technology itself is new (e.g., web development using Ajax).
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
Technical feasibility :
• Project size : Measured as the number of people on the development team, the length of time it will take to
complete the project, or the number of distinct features in the system.
• Larger projects present more risk, because they are more complicated to manage and because there is a greater
chance that some important system requirements will be overlooked or misunderstood.
• Integratability: The extent to which the project is highly integrated with other systems (which is typical of large
systems) can cause problems, because complexity is increased when many systems must work together.
• Compatibility: Teams need to consider the compatibility of the new system with the technology that already
exists in the organization. Systems rarely are built in a vacuum—they are built in organizations that have
numerous systems already in place.
New technology and applications need to be able to integrate with the existing environment for many reasons.
They may rely on data from existing systems, they may produce data that feed other applications, and they may
have to use the company’s existing communications infrastructure.
• A new CRM system, for example, has little value if it does not use customer data found across the organization in existing sales
systems, marketing applications, and customer service systemsAjax).
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
Economic Feasibility
• also called a cost–benefit analysis – HARDEST TASK IN ıNFORMATION SYSTEM PROJECTS
• As the economic returns are generally not tangible-measurable, NPV etc is hard to be applied.
Generally the savings from the labor and facility cost is utilized as Cash in Flows. However, overall
efficiency increases, motivational effects can occur. As well, inventories can be reduced and value
stream maps can be needed.
• This attempts to answer the question
• “Should we build the system?”
• Economic feasibility is determined by identifying costs and benefits associated with the
system, assigning values to them, calculating future cash flows, and measuring the financial
worthiness of the project.
• As a result of this analysis, the financial opportunities and risks of the project can be
understood.
• Keep in mind that organizations have limited capital resources and multiple projects will be
competing for funding. The more expensive the project, the more rigorous and detailed
the analysis should be
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Economic Feasibility
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
a) Identify Costs and Benefits
The systems analyst’s first task when developing an economic feasibility analysis is to identify the kinds of costs
and benefits the system will have and list them along the left-hand column of a spreadsheet.
The costs and benefits can be broken down into four categories:
(1) Development costs : Tangible expenses that are incurred during the creation of the system, such as salaries for
the project team, hardware and software expenses, consultant fees, training, and Office space and equipment.
Development costs are usually thought of as one-time costs.
(2) Operational costs : Tangible costs that are required to operate the system, such as the salaries for operations
staff, software licensing fees, equipment upgrades, and communications charges. Operational costs are usually
thought of as ongoing costs.
(3) Tangible benefits: include revenue that the system enables the organization to collect, such as increased sales.
In addition, the system may enable the organization to avoid certain costs, leading to another type of tangible
benefit: cost savings.
• For example, if the system produces a reduction in needed staff, lower salary costs result. Similarly, a reduction in required
inventory levels due to the new system produces lower inventory costs. In these examples, the reduction in costs is a tangible
benefit of the new system.
(4) Intangibles: Intangible costs and benefits are more difficult to incorporate into the economic feasibility analysis
because they are based on intuition and belief rather than on “hard numbers.” Nonetheless, they should be listed
in the spreadsheet along with the tangible items.
NOTE: Visit other Courses’ Notes (Project Man., Finance etc.) on RoI, NPV, and investment analysis (IS Development
is an Investment!) for Systems
Costanalysis
Benefit
Analysis
and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Economic Feasibility
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Approval
Project
Management
(Project plan
Planning Phase
Economic Feasibility
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
b) Assign Values to Costs and Benefits
• Once the types of costs and benefits have been identified, the analyst needs
to assign specific dollar values to them.
• How can someone quantify costs and benefits that haven’t happened yet?
And how can those predictions be realistic?
• The most effective strategy for estimating costs and benefits is to rely on the
people who have the best understanding of them.
• For example, costs and benefits that are related to the technology or the project itself
can be provided by the company’s IT group or external consultants, and business users
can develop the numbers associated with the business (e.g., sales projections, order
levels).
• The company also can consider past projects, industry reports, and vendor
information, although these sources probably will be a bit less accurate.
Likely, all of the estimates will be revised as the project proceeds.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Economic Feasibility
Project
Inıtıation
System
Request
Feasibility
Analysis
b) Assign Values to Costs and Benefits - Example
Notice that the customer
service intangible benefit
has been quantified,
based on a decrease in
customer complaint
phone calls.
The intangible benefit
of being able to offer
services that
competitors currently
offer was not quantified,
but it was listed so that
the approval committee
will consider the benefit
when assessing the
system’s economic
feasibility.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Approval
Project
Management
(Project plan
Planning Phase
Economic Feasibility
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
b) Assign Values to Costs and Benefits
• If predicting a specific value for a cost or benefit is proving difficult, it
may be useful to estimate a range of values for the cost or benefit and
then assign a likelihood (probability) estimate to each value. With this
information, an expected value for the cost or benefit can be calculated.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Economic Feasibility
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
b) Assign Values to Costs and Benefits
• Sometimes, it is acceptable to list intangible benefits, such as improved
customer service, without assigning a monetary value.
• Other times, estimates have to be made regarding how much an intangible
benefit is “worth.”
• We suggest that you quantify intangible costs or benefits if at all possible.
• If you do not, how will you know if they have been realized?
• Suppose that a system claims to improve customer service. This benefit is intangible,
but let’s assume that the improvement in customer service will decrease the number of
customer complaints by 10% each year over three years and that $200,000 is currently
spent on phone charges and phone operators who handle complaint calls. Suddenly, we
have some very tangible numbers with which to set goals and measure the originally
intangible benefit.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
Economic Feasibility
• HARDEST TASK IN INFORMATION SYSTEM PROJECTS
• As the economic returns are generally not tangible-measurable, NPV etc is hard
to be applied.
• Generally the savings from the labor and facility cost is utilized as Cash in Flows.
However, overall efficiency increases, motivational effects can occur.
• As well, inventories can be reduced and value stream maps can be needed.
• RETURN OF THE NEW SYSTEM MAY NOT BE FORESEEN
• For measures like «increase in sales», it is hard to eliminate the impact
of other factors (imagine a regression model that only runs with IT
system development?)
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
Organizational Feasibility
• How well the system ultimately will be accepted by its users and
incorporated into the ongoing operations of the organization?
• There are many organizational factors that can have an impact on the
project, and seasoned developers know that organizational feasibility
can be the most difficult feasibility dimension to assess.
• In essence, an organizational feasibility analysis attempts to answer the
question
• “If we build it, will they come?”
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
Organizational Feasibility
• Strategic Allignment: Understand how well the goals of the project align with
business objectives.
• Strategic alignment is the fit between the project and business strategy—the
greater the alignment, the less risky the project will be, from an
organizational feasibility perspective.
• For example, if the marketing department has decided to become more customer
focused, then a CRM project that produces integrated customer information would
have strong strategic alignment with marketing’s goal.
• Many projects fail if the IT department alone initiates them and there is little
or no alignment with businessunit or organizational strategies.
NOTE: Visit the Course Notes on Strategic Objectives of Information Systems
(IS) for strategic Fit
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
c) Organizational Feasibility- Stakeholders Analysis
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Approval
Project
Management
(Project plan
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
c) Organizational Feasibility
• Stakeholders: Conduct a stakeholder analysis.
• A stakeholder is a person, group, or organization that can affect (or can be affected by) a new system.
•
•
•
•
•
The most important stakeholders in the introduction of a new system are
the project champion,
system users, and
organizational management ,
IT IS Departments
• the IS department is a stakeholder as the provider/supplier of the system
• IS dept can be a stakeholder of a system because IS jobs or roles may be changed significantly after
the system’s implementation
• (but systems sometimes affect other stakeholders as well. )
• One key stakeholder—outside of the champion, users, and management—in Microsoft’s project that
embedded Internet Explorer as a standard part of Windows was the U.S. Department of Justice.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
c) Organizational Feasibility - STAKEHOLDERS
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
• The champion : is a high-level executive and is usually, but not always, the project sponsor who created the
system request.
• The champion supports the Project by providing time and resources (e.g., money) and by giving political support within the
organization by communicating the importance of the system to other organizational decision makers.
• More than one champion is preferable because if the champion leaves the organization, the support could leave as well.
• Organizational management While champions provide day-to-day support for the system, also needs to
support the project.
• Such management support conveys to the rest of the organization the belief that the system will make a valuable contribution
and that necessary resources will be made available
• Ideally, management should encourage people in the organization to use the system and to accept the many changes that the
system will likely create.
• System Users : who ultimately will use the system once it has been installed in the organization.
• Too often, the project team meets with users at the beginning of a project and then disappears until after the system is created.
• In this situation, rarely does the final product meet the expectations and needs of those who are supposed to use it, because
needs change and users become savvier as the project progresses.
• User participation should be promoted throughout the development process to make sure that the final system will be accepted
and used, by getting users actively involved in the development of the system (e.g., performing tasks, providing feedback, and
making decisions)
NOTE: Visit the Course Notes on SOFTWARE DEVELOPMENT MODELS and in them
«Agile approaches to System Development Projects «for USER INVOLVEMENT
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Feasibility Example
Project
Inıtıation
System
Request
Feasibility
Analysis
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Approval
Project
Management
(Project plan
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
• Written systems proposal report describing the costs and benefits, pros and cons of alternatives. The
result of the feasibility study is a formal document, a report detailing the nature and scope of the
proposed solution. It consists of the following:
• Management assessment
• Statement of the problem
• Details of findings
• Findings and recommendations in concise form
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Planning Phase
Project
Inıtıation
System
Request
Feasibility
Analysis
Approval
Project
Management
(Project plan
PROJECT MANAGEMENT – PROJECT PLAN – System Development
Project Methodology Options
• Systems Development Life Cycle (SDLC) provides the foundation for the
processes used to develop an information system.
• A methodology is a formalized approach to implementing the SDLC (i.e., it
is a list of steps and deliverables).
• There are many different systems development methodologies, and they vary
in terms of the progression that is followed through the phases of the SDLC.
• Some methodologies are formal standards used by government agencies,
while others have been developed by consulting firms to sell to clients. Many
organizations have their own internal methodologies that have been refined
over the years, and they explain exactly how each phase of the SDLC is to be
performed in that company.
NOTE: VISIT LECTURE NOTES ON SOFTWARE DEVELOPMENT MODELS
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
System
Analysis Phase
Analysis
Strategy (AS IS)
Requirements
Gathering
Concept
(Models:
Database
Process)
Combination
• The analysis phase answers the questions of
System PROPOSAL
• who will use the system,
Requirements List
(THE ANALYSES)
• what the system will do, and
• where and when it will be used.
During this phase, the project team investigates any current system(s), identifies improvement opportunities,
and develops a concept for the new system.
This phase has three steps:
• 1. Development of an analysis strategy : to guide the project team’s efforts. Such a strategy usually includes
a study of the current system (called the as-is system) and its problems, and envisioning ways to design a
new system (called the to-be system).
• 2. Requirements gathering (e.g., through interviews, group workshops, or questionnaires). The analysis of
this information—in conjunction with input from the project sponsor and many other people—leads to the
development of a concept for a new system
• STRATEGIC : The system concept is then used as a basis to develop a set of business analysis models that
describes how the business will operate if the new system were developed. The set typically includes
models that represent the data and processes necessary to support the underlying business process.
• 3. System Proposal : The analyses, system concept, and models are combined into a document called the
system proposal, which is presented to the project sponsor and other key decision makers (e.g., members of
the approval committee) who will decide whether the project should continue to move forward.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Analysis Phase
Analysis Strategy
(AS IS)
Establishing Information and Process Requirements
Requirements
Gathering
System Concept
(Models: Database
Process)
Combination
System PROPOSAL
Requirements List
(THE ANALYSES)
P.S.: These phases in Red Circles correspond to the
«System Analysis» Section of ISL 343E MIS Term Project.
https://its.ucsc.edu/drb/sdlc/req-def.html
Analysis Strategy
(AS IS)
Analysis Phase
Requirements
Gathering
System Concept
(Models: Database
Process)
Establishing Information and Process Requirements
• Hardest task – what a system should do to meet information
requirements
• Who needs
•
•
•
•
What information?
Where?
When?
How?
• Carefully define the objectives of the system
• Develop a detailed description of functions that the system should
perform
• Faulty requirements analysis is a leading cause of systems failure
and high costs
• Either be discarded because of poor performance
• Or undergo major modifications
• Alternative approaches for requirements analysis
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009-2019
Combination
System PROPOSAL
Requirements List
(THE ANALYSES)
Analysis Strategy
(AS IS)
Analysis Phase
Requirements
Gathering
System Concept
(Models: Database
Process)
Establishing Information and Process Requirements - Examples
Example 1. ITU COURSE SELECTION ASSISTANT
preliminary course selection and early warning system for capacity for courses
Example 2. Digitalization of ITU Erasmus Process
1. Defined Needs for “Digitalization of ITU Erasmus Process”





Uploading the necessary documents to the system online
Easing the course approval process
Counter-curriculum course compatibility
Use of data from the same institutions' previous Erasmus students
Simplifying LA change operations.
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009-2019
Combination
System PROPOSAL
Requirements List
(THE ANALYSES)
Analysis Strategy
(AS IS)
Analysis Phase
Requirements
Gathering
System Concept
(Models: Database
Process)
Establishing Information Requirements, Limitations and s - Examples
Example 3: Work demand and workflow system between departments and IT Department
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009-2019
Combination
System PROPOSAL
Requirements List
(THE ANALYSES)
Analysis Strategy
(AS IS)
Analysis Phase
System Concept
Requirements
Gathering
(Models: Database
Process)
Establishing Information Requirements, Limitations and s - Examples
Example 4: Event Organization Service Providers Platform
(like
2.4.3. System
Gap Armut.com)
Analysis
2.4.1 Problem with Existing System
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Selecting activity on site that is hard.
Writing understanding of activity is time consuming.
User cannot select two or more organization service(like decoration and entertainment) on the same time
User cannot select two or more catering service (like cocktail and food) on the same time.
User cannot select two or more material request (like chair and desk sheet) on the same time.
User must advertise activity, it is not usable for user. Providers should meet user’s needs.
User must wait for maximum 15 days. Consuming time issue for users.
Service provider’s information is not accessible for public.
There is no voting or comment opportunity on organization for users. It is not opaque.
Prices of activities is not clear.
System is not dynamic, users should wait service providers.
Service provider’s information is not clear when user looking for activity.
There is no easily integration with services.
System take care of service providers, not users.
2.4.2 Needs
●
Users should select what their request from the activity.
●
Price of activity should be almost determined.
●
System should be dynamic.
●
User should select two or more organization service(like decoration and entertainment) on the same time
●
User should select two or more catering service (like cocktail and food) on the same time.
●
User should select two or more material request (like chair and desk sheet) on the same time.
●
System should include voting or comment opportunity on organization for users. It should be opaque.
●
System take care of users.
●
Selecting activity on site should be usable.
●
Service provider information should be clear when user looking for activity
●
Easy integration between activities
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009-2019
Site should not be time consuming for users
Table 2.4.3: Gap Analysis
Combination
System PROPOSAL
Requirements List
(THE ANALYSES)
Design Phase
Design
Strategy
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Database
Specs
Process, Data
Flow (Program)
Design
Program
Specs
System Specifications
• The design phase decides how the system will operate in terms of the
hardware, software, and network infrastructure that will be in place;
the user interface, forms, and reports that will be used; and the
specific programs, databases, and files that will be needed.
• Although most of the strategic decisions about the system are made
in the development of the system concept during the analysis phase,
the steps in the design phase determine exactly how the system will
operate.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Design Phase
Design
Strategy
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Database
Specs
Process, Data
Flow (Program)
Design
Program
Specs
System Specifications
• The design phase has four steps:
1. The design strategy must be determined.
• This clarifies whether the system will be developed by the company’s own programmers, whether its
development will be outsourced to another firm (usually a consulting firm), or whether the company will
buy an existing software package.
2. This leads to the development of the basic architecture design for the system that describes the hardware,
software, and network infrastructure that will be used. In most cases, the system will add to or change the
infrastructure that already exists in the organization.
The interface design specifies how the users will move through the system (e.g., by navigation methods such
as menus and on-screen buttons) and the forms and reports that the system will use.
3. The database and file specifications are developed. These define exactly what data will be stored and where
they will be stored.
4. The analyst team develops the program design, which defines the programs that need to be written and
exactly what each program will do.
This collection of deliverables (architecture design, interface design, database and file specifications, and
program design) is the system specification that is used by the programming team for implementation. At the
end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another
decision is made by the project sponsor and approval committee about whether to terminate the project or
continue.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Design Phase
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Design Phase
Design
Strategy
Architecture
development
Interfac
e Design
Basic
Architecture
HW, SW, NW
Interface
s
Database
Design
Database
Specs
Process, Data
Flow
(Program)
Design
Program
Specs
System Specifications
• The purpose of the design phase is to plan a solution of the problem specified by
the requirement document – first step for moving from problem domain to the
solution domain.
• The design of a system is perhaps the most critical factor affecting the quality of
the software, and has a major impact on the later phases, particularly testing and
maintenance.
• The output of this phase is the design document.
• This document is similar to a blue print or plan for the solution, and is used later
during implementation, testing and maintenance.
Design Phase
Design
Strategy
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Database
Specs
Process, Data
Flow (Program)
Design
Program
Specs
System Specifications
• Shows how the system will fulfill the objective of systems analysis
• Systems design is the OVERALL PLAN or MODEL FOR THE SYSTEM
• Like Blue print of a building – like houses and buildings IS may have many possible designs
• Consists of all specifications that give the system its FORM and STRUCTURE
• Carefully define the objectives of the system
• Detail the system specifications that will deliver the functions identified during the systems analysis
• Specs should adress all components of the system solution
• Managerial
• Organisational
• Technological
• Each design represents a unique blend of all components- Alternative approaches for requirements analysis
• Superior design is the “easy and efficient” design that
• fulfills USER REQUIREMENTS
• Within a specific set of CONSTRAINTS (technical, organisational, financial, time)
Design Phase
• The design activity is often divided into two separate
phase-system design and detailed design. 2
documents are prepared.
• System design, ( top-level design): what
components are needed
• identify the modules that should be in
the system,
• interactions with each other to produce
the desired results.
• At the end of system design all the major
data structures, file formats, output
formats, as well as the major modules in
the system and their specifications are
decided
• Detailed design: how the components can be
implemented in software is the issue
• the internal logic of each of the modules
specified in system design
• further details of the data structures and
algorithmic design of each of the
modules is specified.
• The logic of a module is usually specified
in a high-level design description
language, which is independent of the
target language in which the software
will eventually be implemented.
Like every other phase, the design phase
ends with verification of the design
Design
Strategy
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Process, Data
Flow (Program)
Design
Database
Specs
Program
Specs
System Specifications
Design Activity
Detailed Design
(Component
Design)
System (TopLevel) Design
Modules of The
System
Specifications of
these modules
Interactions
among modules
OUTPUT: Major data structures,
file formats, output formats,
as well as the major modules in the system
and their specifications are decided
Internal logic of
each of
modules
Verification of
the Design
Detailed Design
of interactions
of components
OUTPUT: Details of the data
structures and algorithmic
design of each of the modules
is specified.
Design Phase
Design
Strategy
Example: A Learning Management System (LMS like Ninova)
Management Functions
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Process, Data
Flow (Program)
Design
Database
Specs
Program
Specs
System Specifications
Design Activity
Detailed Design
(Component
Design)
System (TopLevel) Design
Modules of The
System
Specifications of
these modules
Interactions
among modules
OUTPUT: Major data structures,
file formats, output formats,
as well as the major modules in the system
and their specifications are decided
Internal logic of
each of modules
Verification of
the Design
Detailed Design
of interactions
of components
OUTPUT: Details of the data
structures and algorithmic
design of each of the modules
is specified.
Design Phase
Design
Strategy
The software design process
and activities and outputs
•
•
•
•
•
•
Architectural design
Abstract specification
Interface design
Component design
Data structure design
Algorithm design
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Database
Specs
System Specifications
Process, Data
Flow (Program)
Design
Program
Specs
Design
Strategy
Design Phase
 Types of specifications to be
produced by system design
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Database
Specs
System Specifications
Process, Data
Flow (Program)
Design
Program
Specs
Design
Strategy
Design Phase
Structured methods
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Database
Specs
System Specifications
• Systematic approaches to developing a software design.
• The design is usually documented as a set of graphical models.
• Possible models
•
•
•
•
•
Structural model (Functional model, breakdown of functions, context
diagrams )
Database Model (Entity Relationship Model)
Work Flow Models (Process - Sequence model)
Data-flow model (Data Flow Diagrams)
Use-Case Model
P.S.: These methods correspond to the models used in both «System Analysis» and in
«System Design» Section of ISL 343E MIS Term Project.
Process, Data
Flow (Program)
Design
Program
Specs
Design Phase
Design
Strategy
Architecture
development
Interface
Design
Basic
Architecture
HW, SW, NW
Interfaces
Database
Design
Database
Specs
System Specifications
Role of End Users
• User information requirements drive the entire system-building effort
• Users must have sufficient control over the design process to ensure
the system reflects their priorities and information needs
• Not the biases of technical staff
• Working on design increases users’ understanding and acceptance of
the system
• Insufficient user involvement in the design effort is a major cause of
system failure
• USer participation in alternative system development methods
Process, Data
Flow (Program)
Design
Program
Specs
Construction
Implementation (Built
and Test)
Phase
Programmed
System
Installation
/Conversion
New
System
Support Plan
• The final phase in the SDLC is the implementation phase, during which the system is
actually built (or purchased, in the case of a packaged software design and installed).
• This is the phase that usually gets the most attention, because for most systems it is the
longest and most expensive single part of the development process.
This phase has three steps:
1. System construction is the first step. The system is built and tested to ensure that it
performs as designed. Since the cost of fixing bugs can be immense, testing is one of the
most critical steps in implementation. Most organizations spend more time and attention
on testing than on writing the programs in the first place.
2. The system is installed. Installation is the process by which the old system is turned off
and the new one is turned on. There are several approaches that may be used to convert
from the old to the new system. One of the most important aspects of conversion is the
training plan, used to teach users how to use the new system and help manage the
changes caused by the new system.
3. The analyst team establishes a support plan for the system. This plan usually includes a
formal or informal post-implementation review, as well as a systematic way for identifying
major and minor changes needed for the system.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Implementation
(Programming)
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
• System specs are translated into software program
code. May be ;
• Outsourced
• Purchase of the software package from a vendor
• Purchase of software services from ASP (Application
Service Provider)
• Developed in-house
NOTEs
: VISIT LECTURE NOTES ON TYPES OF SOFTWARE » available in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/MIS_Week 2_ 3 Software
Definition and Classification.ppt «Types of Application Software» slide)
VISIT LECTURE NOTES ON Outsourcing and TCO» available in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/MIS_Week 2_3 Software
Ownership_Languages_Trends.ppt «Outsourcing» and «Total Cost Ownership» slides)
Implementation
(Programming)
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
• Once the design is complete, most of the major decisions about the system
have been made.
• The goal of the coding phase is to
• translate the design of the system into code in a given programming language.
• to implement the design in the best possible manner.
• The coding phase affects both testing and maintenance profoundly. A well
written code reduces the testing and maintenance effort.
• the focus should be on developing programs that are easy to write.
Simplicity and clarity should be strived for, during the coding phase.
New
System
Support Plan
Implementation
(Programming)
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
Programming
• Translating a design into a program and removing errors from that
program.
• Programming is a personal activity - there is no generic
programming process.
NOTE: VISIT LECTURE NOTES ON TYPES OF SOFTWARE » available in Ninova Ders Kaynakları/Lecture
Notes/Midterm Exam Coverage/MIS_Week 6_7 Programming_Languages_Trends
Implementation
Phase
(Debugging)
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
The debugging process (Intermediary or shared process between
Programming and Testing)
Programmers carry out some program testing to discover faults in the
program and remove these faults in the debugging process.
Implementation Construction
(Built and Test)
Phase
Software validation
Programmed
System
Installation
/Conversion
• Verification and validation (V & V) is intended to show that a
system conforms to its specification and meets the
requirements of the system customer.
• Involves checking and review processes and system testing.
• System testing involves executing the system with test cases
that are derived from the specification of the real data to be
processed by the system.
New
System
Support Plan
Implementation Construction
(Built and Test)
Phase
Programmed
System
Installation
/Conversion
New
System
Support Plan
Testing
• Exhaustive and thorough testing to ascertain whether the system produces the right
results
• Will the system produce the desired results under known conditions?
•
•
•
•
Do not underrate the time needed for testing in project plan
Test data must be carefully prepared
Results must be reviewed
Corrections must be made
• Maybe a part of the system will be redesigned
Implementation Construction
(Built and Test)
Phase
The testing process
Programmed
System
Installation
/Conversion
New
System
Support Plan
Implementation
Phase
Testing phases
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
Implementation
Phase
Testing stages
Component or unit
testing
• Individual
components
are tested
independently;
• Components
may be
functions or
objects or
coherent
groupings of
these entities.
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
System testing
• Testing of the
system as a
whole.
• Testing of
emergent
properties is
particularly
important.
Acceptance testing
• Testing with
customer data
• to check that
the system
meets the
customer’s
needs.
Implementation
Phase
Testing Steps
Construction
(Built and Test)
1. Component or Unit
Testing (Program
testing)
to locate errors in
the programs
To focus on finding
all the ways to make
a program fail
Programmed
System
New
System
Support Plan
3. Acceptance Testing
2. Systems Testing
Try to determine
whether the discrete
modules function
together as planned
Final certification of
the system – ready
to be used in
production
DESIGN SPEC TEST
REQUIREMENTS
DOCUMENT
ALGORITHM AND
DATA RUN
(PROGRAM AND
DATA
IMPLEMENTATION)
TEST
Try to determine
discrepencies that
exist between the
way system works
and the way it was
conceived
(Not to quarantee
that programs are
error free- it is
impossible)
• Performance time
• Capacity for file
storage
• Handling peak
loads
• REcovery and start
capabilities
Find the problem,
than correct it
Installation
/Conversion
Acceptance tests are
evaluated by users
and reviewed by
management- all
parties should be
satisfied
Testing Steps
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
• Work with users to devise a systematic test plan
• Test plan includes all preperations of all testing types
• When developing a test plan, the various conditions should be tested, the requirements
of each condition tested, and the expected results. Test plans require input from both
end users and IT specialists.
Example of a test plan: Condition being tested is a record change. The documentation consists of a series of
test plan screens maintained on a database (perhaps a PC database) that is ideally suited to this application.
New
System
Support Plan
Testing Plan
Construction
(Built and Test)
1) Indicate the type of the test plans to be included in
Testing
• Master Test Plan: A single high-level test plan for a
project/product that unifies all other test plans.
• Testing Level Specific Test Plans: Plans for each level of
testing.
• Unit Test Plan
• System Test Plan (including Integrations)
• Acceptance Test Plan
• Testing Type Specific Test Plans: Plans for major types of
testing like Performance Test Plan and Security Test Plan
2) Scope and Features: List the Tested Items
(software/products) and their versions. List the Features
to be Tested and not to be tested
• Provide references to the Requirements and/or Design
specifications of the features to be tested
• Specify the reasons these features won’t be tested.
3) List the Major Constraints
• Any organizational or technical constraints that impact the
testintg (lack of resources, personnel, incomplete
programming etc.)
Programmed
System
Installation
/Conversion
4) Approach:
New
System
Support Plan
• Mention the overall approach to testing.
• Specify the testing methods [Manual/Automated; Black, white,
grey box]
5) Item Pass/Fail Criteria:
• Specify the criteria that will be used to determine whether
each test item (software/product) has passed or failed testing.
6) Schedule:
• When and how often will the tests will be done?
7) Staffing Needs and Responsibilities/approvals
• Specify staffing needs by role and required skills.
• List the responsibilities of each team/role/individual.
7) Staffing Needs and Responsibilities/approvals
• Specify staffing needs by role and required skills.
• List the responsibilities of each team/role/individual.
Construction
(Built and Test)
Testing Methods
Black Box Testing, also known as
Behavioral Testing, is a software testing
method in which the internal
structure/design/implementation of the
item being tested is not known to the
tester. Example: A tester, without
knowledge of the internal structures of a
website, tests the web pages by using a
browser; providing inputs (clicks,
keystrokes) and verifying the outputs
against the expected outcome. The
higher the level, and hence the bigger
and more complex the box, the more
black box testing method comes into
use.
Programmed
System
Installation
/Conversion
New
System
Support Plan
White Box Testing is a software testing method in
which the internal structure/design/implementation
of the item being tested is known to the tester. The
tester chooses inputs to exercise paths through the
code and determines the appropriate outputs.
Programming know-how and the implementation
knowledge is essential. White box testing is testing
beyond the user interface and into the nitty-gritty of
a system. Example: tester, usually a developer as
well, studies the implementation code of a certain
field on a webpage, determines all legal (valid and
invalid) AND illegal inputs and verifies the outputs
against the expected outcomes, which is also
determined by studying the implementation code.
Generally used for unit testing
Construction
(Built and Test)
UNIT Testing Plan
Programmed
System
Installation
/Conversion
New
System
Support Plan
Implementation
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
Conversion
• Process of changing from the old system to the new system.
• 1. Parallel Strategy: Both the old system and its potential replacement run
together for a time until everyone is assured that the new one functions
correctly.
• Safest conversion approach for the event of errors or processing
disruptions, the old system can be used as back up.
• Most expensive , requires resource allocation
• 2. Direct Cutover: replaces the old system entirely with the new system on
an appointed day.
• Risky approach,
• May be costly then running two systems if serious problems occur. Testing
the functioning to the IS as a whole.
• 3. Pilot Study : introduces the new system to only a limited area, such as a
single department or unit.
• When this version is complete and working smoothly, it is installed
thoroughout the rest of the organisation.
• 4. Phased Approach: introduces the new system in stages, either by
functions or by organisational units.
NOTEs
READ Article on Conversion Strategies in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/MIS_Week 2_3 Software
Ownership_Languages_Trends.ppt» «Total Cost Ownership» slides)
New
System
Support Plan
Implementation
Phase
Construction
(Built and Test)
Conversion Methods
Parallel Method
The parallel conversion strategy is when both the old and new
information systems operate alongside one another for a specified
time (Vermaat, M.E, 2016). Once the results have been compared
between the old and new system, the organisation may choose to
gradually welcome in the new system or immediately end the
previous system.
• Direct Cut Over
• The direct cut over strategy is when the company stops using
the old system and immediately starts using the new system.
Programmed
System
Installation
/Conversion
New
System
Support Plan
ADVANTAGES:
1 By using the parallel method, small minor errors can be easily seen
2 Companies are able to fix any problems with the new system
before ending the previous system
DISADVANTAGES:
1 It is very costly as two systems are being operated simultaneously,
so there will be the costs for more power for example
2 Operating two systems simultaneously is also very time consuming
and stressful as there is more work involved, such as creating more
reports
ADVANTAGES:
1 It is less costly as it is a direct change over
2 It is not very time consuming as once the old system has
stopped being used the new system is immediately being set up
DISADVANTAGES:
1 If the system has not been implemented properly the new
system may fail to work and this will affect the whole
organisation.
2 It is very difficult to detect small errors in the new system
Vermaat, M.E (2016). Enhanced Discovering Computers ©2017. USA: Cengage Learning. 526.Methods of system
conversion , O’Brien & Marakas (2006, p. 424)
Implementation
Phase
Construction
(Built and Test)
Conversion
PILOT METHOD
The pilot conversion method is when the new system is introduced to
a single department/location at a time, this strategy is mainly used for
testing the new system in different environments. The pilot method is
very helpful for organisations which have several locations.
PHASED METHOD
This method replaces the old system in stages, this method is
different to the pilot method as the pilot strategy tests in one
Whereas the phased strategy introduces the new system tlocation
and then is implemented in the whole organisation. o one
department at a time.
Programmed
System
Installation
/Conversion
New
System
Support Plan
ADVANTAGES:
1.Risk is reduced
2.Allows the organisation to see whether the new system will
meet the organisations needs in one department/location
before using it throughout the entire organisation
DISADVANTAGES:
1.Too much time is involved testing in one location, there is
also increased development and labour costs
ADVANTAGES:
1 As the system is tested at every stage, there is very little chance
of error
2 This strategy is more user friendly. Because the new system is
implemented one department at a time, the IT staff are able to
draw their attention to training one department effectively to
using the new system.
DISADVANTAGES:
1 It takes a lot of time to implement the whole new system to the
entire organisation.
Vermaat, M.E (2016). Enhanced Discovering Computers ©2017. USA: Cengage Learning. 526.
O’Brien & Marakas (2006, p. 424)
Implementation
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
Production and Maintanance
• After the new system is installed and conversion is complete, the system is said to be in
production.
• The system will be reviewed by both users and technical specialists to
• determine “how well it has met its original objectives”
• to decide “whether any revisions/modifications are needed”.
• Is a “postimplementation audit” needed?
• After the system is fine tuned, it must be maintained while it is in production to correct
errors, meet requirements, improve efficiency
• Maintenance: Changes in hardware, software, documentation, procedures.
• 20% percent of maintenance time is used for “debugging” or “correcting” emergency
problems.
• 20% percent of maintenance time is concerned with changes in data, files, reports,
hardware, system software
NOTEs
VISIT LECTURE NOTES ON Outsourcing and TCO» available in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/MIS_Week 2_3 Software
Ownership_Languages_Trends.ppt» «Total Cost Ownership» slides)
Post Implementation
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
Software evolution
• Software is inherently flexible and can change.
• As requirements change through changing business
circumstances, the software that supports the business must
also evolve and change.
• Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new.
Post Implementation
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
System evolution
Post Implementation
Phase
Construction
(Built and Test)
Programmed
System
Installation
/Conversion
New
System
Support Plan
• Support
Figure 15.11 Activities in systems support
NOTEs
VISIT LECTURE NOTES ON Outsourcing and TCO» available in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/MIS_Week 2_3 Software
Ownership_Languages_Trends.ppt» and «Total Cost Ownership» slides)
Software System Development
Sample Project Life Cycle
You will find out
Or you will
create
Term
Project
Scope
You already
know or
You can guess
Key points – Concluding Remarks
•
•
•
•
•
•
•
•
•
Software processes are the activities involved in producing and evolving a software
system.
Software process models are abstract representations of these processes.
General activities are specification, design and implementation, validation and
evolution.
Generic process models describe the organisation of software processes. Examples
include the waterfall model, evolutionary development and component-based software
engineering.
Iterative process models describe the software process as a cycle of activities.
Requirements engineering is the process of developing a software specification.
Design and implementation processes transform the specification to an executable
program.
Validation involves checking that the system meets to its specification and user needs.
Evolution is concerned with modifying the system after it is in use.
•
•
Homework and Questions to practice –
CASE: ITU Distance Learning System Convergence Project
Act as ITU BIDB
For Planning Phase (Problem and High-level Solution Definition)
•
•
Define High Level Requirements
Develop Candidate Solution Options (Existing IT Inventory, External Solution Options, Review Solutio etc)
•
•
•
•
•
•
•
•
•
Zoom (Bilkent, ODTÜ, Ege, Boğaziçi, Sabancı, İstanbul Üniv.) – Premium üyelik ve paket verildi., ABD’de yoğun kullanım)
Bilgi Moodle+Zoom -ve Boğaziçi Moodle
Microsoft Teams , Skooler (Gebze teknik, 9 Eylül, Galatasaray Univ),
Blackboard (MEF, Koç Univ, Maltepe)
Googlemeets (Sabancı) , Hangouts (Yeditepe, Tıp) Lab derslerinde) - Entegrasyon
UZAM üzerinden Perculus (Türk uygulayıcı Firma (Marmara üniversitesi) – Süre sınırı
YILDIZ TEKNİK KENDİ SİSTEM (ilk kullanımda sorun yaşandı)
Bahçeşehir üniv., Kültür Üniv Adobe Connect
Define Preliminary System Scope with a diagram.
•
•
•
•
Which information system/s of ITU are affected by Distance Learning System Convergence?
Which functions in ITU Course Management System is affected by Distance Learning System Convergence? (Including Outputs)
Which functions in ITU Ninova System is affected by Distance Learning System Convergence?
Which steps would you skip in scope definition?
•
For Feasibility , which steps would you take and how?
•
For system level design, try to guess how did BIDB design interactions among modules?
•
For component design, what kind of data, program and interface design took place?
•
•
•
•
•
•
For Testing, which steps would you take and how?
•
•
•
•
Ninova’da Uzaktan Eğitim Ekranı- Online.itu.edu.tr sayfası açıldı,
Access, Data Entry- (I-P-0 Ders oluşturma) Ninova’da
Ders Videoları – Zoom’da depolanıyo- Yeni bir veri tipi
Kullanıcı verileri – Zoom’a öğrenci ve öğretim elemanı verileri iletildi.
Uzaktan VPN servisi için Database oluşturdu. Öğrenci verileri, CRN’lerden alınarak (Öğretim Üyesi CRN bildirdi BİDB’ye- VPN istediği sınıflar için)
Performance testing kısa sürede sınırlı yapıldı
Acceptance testing yapılamadı. Improvement cycle dönmedi.
Mimarlık fakültesinde bitirme jürisi provası yapılmış. DENEME Jurisi, herkes girmiş, bütün dışarıdan gelen jüriler de katılmış.
What kind of CONVERSION STRATEGY is adapted in Distance Learning System convergence in İTU during the Covid19 Pandemic? Why and how?
•
Which accomplishments and implications/complications do you observe?
Linking Software System Development Process to
Next Topics on Methods of Database and Process
Analysis Methods
For Details
VISIT LECTURE NOTES on System Modelling approaches in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/System Modelling Methods
Linking Software System Development Process to Next Topics on
Methods of Database and Process Analysis Methods
Structured Methodologies
! THESE METHODS ARE THE ONES WE PREFERRED TO
•Procedural-oriented:
USE IN TERM PROJECT BOTH IN SYSTEM ANALYSIS
AND SYSTEM DESIGN PHASES !
- Most common approach
-Include data-oriented, sequential, process-oriented
activities
! FROM THESE METHODS, WE WILL UTILIZE ONLY THE
USE CASE DIAGRAMS AND CLASS DIAGRAMS FROM
UML (UNIFIED MODELLING APPROACH) IN TERM
PROJECT!
•Object-oriented:
- Newer approach
- Works well for GUIs and multimedia applications
.
NOTEs
VISIT LECTURE NOTES on System Modelling approaches in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/System Modelling Methods
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Procedural-oriented Structured Methodologies
Describe what you have, define what you want, and
describe how you will make what you want.
1.As-Is (what you have)
2.Logical To-Be (what you want)
3.Physical To-Be (how to make what you want)
! THESE ARE THE AIMS OF TERM PROJECT!
NOTEs
VISIT LECTURE NOTES on System Modelling approaches in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/System Modelling Methods/System
Models 1.ppt
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Procedural-oriented Structured Methodologies
1.As-Is
•Identifies existing processes, external participants, other databases or applications, and
inputs and outputs
2.Logical To-Be
•Describes “what” rather than “how”
•High-level model of a nonexistent new system
•Identifies processes and data
•Does not identify who does activity, where accomplished, or type of hardware or software
3.Physical To-Be
•Maps the logical requirements to available technology
! THESE ARE THE AIMS OF TERM PROJECT!
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Structured Methodologies For As- IS and TO- BE
• Structured refers to the fact that techniques are step by step, with each step building on
the previous one.
• Data flow diagram: Primary tool for structured analysis that graphically illustrates a
system’s component processes and the flow of data between them.
• Process specifications: Specifications that describe the logic of he processes occurring
within the lowest levels of a data flow diagram.
• Context Diagram and Structure chart: System documentation showing each level of
design, the relationship among the levels, and the overallplace in the design ; can document
one program, one system, or part of one program.
! THESE METHODS ARE THE ONES THAT SHOULD BE
USED IN TERM PROJECT BOTH IN SYSTEM ANALYSIS
AND SYSTEM DESIGN PHASES !
NOTEs
VISIT LECTURE NOTES on System Modelling approaches in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/System Modelling Methods/System
Models 1.ppt
Software System Development
Structured Methodologies For As- IS and TO- BE
• Data flow diagram: Primary tool for structured analysis that graphically illustrates a system’s
component processes and the flow of data between them.
EXAMPLE DATA FLOW DIAGRAM
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Structured Methodologies For As- IS and TO- BE
Context and Structure chart: System documentation showing each level of design, the
relationship among the levels, and the overallplace in the design ; can document one program, one
system, or part of one program.
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Structured Methodologies For As- IS and TO- BE
- Basic and detailed, swimlane Process Flowcharts
E R Diagram
Figure 15.6 A flowchart describing a sales bonus system
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Structured Methodologies
• For As- IS and TO- BE
- Database Management Models,
- E-R Diagrams
E R Diagram
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Object Oriented Methodologies for AS-IS and TO-BE
•Primary advantages: Facilitates object reuse & quick prototyping
Unified Modeling Language (UML) : A set of standardized techniques and notations
for O-O analysis and design
•Examples of UML diagrams:
- Use Case diagram
- Sequence diagram
- Class diagram
We will perform in our Term Project
- Use case Diagrams
- Class Diagrams
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Object Oriented Methodologies for AS-IS and TO-BE
We will perform in our Term Project
- Use case Diagrams
- Class Diagrams
USE case Diagram
(UML)
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Object Oriented Methodologies for AS-IS and TO-BE
CLASS DIAGRAM WILL BE USED IN DATABASE
RELATIONAL MODEL ANALYSIS AND DESIGN
(Can be replaced by other notations if
needed)
We will perform in our Term Project
- Use case Diagrams
- Class Diagrams
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Object Oriented Methodologies for AS-IS and TO-BE
We will perform in our Term
Project
- Use case Diagrams
- Class Diagrams
Sequence Diagrams include Codes
in Classes.
Usage of Sequence Diagrams in
Term Project is OPTIONAL
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software System Development
Object Oriented Methodologies for Physical TO-BE
• INTERFACE DESIGN (Linking Need to Technology)
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION
EXHIBIT 1. QUANTIFYING SYSTEM SIZE
ESTIMATING THE SYSTEM SIZE
The function point approach
A more precise approach to estimation is called the function point
approach.
This approach is a more complex—and, it is hoped, more
reliable—way of estimating time and effort for a project. The
details of the function point approach are explained in Appendix
2A.
The function point approach
An estimating technique that can be used to estimate
• the size of the new system,
• the effort that will be required to complete the
• system, and
• the time the project will require.
This approach requires detailed knowledge of system
to be developed.
When this knowledge is available, the function point
approach produces a much more precise estimate for
the Project
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.–5th ed.
EXHIBIT 1. FUNCTION POINT
QUANTIFYING SYSTEM SIZE ESTIMATING THE SYSTEM SIZE
The first step is to estimate the size of
a project by using function points, a
concept
developed in 1979 by Allen Albrecht of
IBM. A function point is a measure of
program size that is based on the
system’s number and complexity of
inputs, outputs, queries, files, and
program interfaces.
To calculate the function points for a
project, components are listed on a
worksheet to represent the major
elements of the system. For example,
data-entry screens are kinds of inputs,
reports are outputs, and database
queries are kinds of queries. (See
Figure 2A-2.)
The project manager records the total
number of each component that the
system will include, and then he or she
breaks down the number to show the
number of components that have low,
medium, and high complexity.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.–5th ed.
EXHIBIT 1. FUNCTION POINT QUANTIFYING
SYSTEM SIZE - ESTIMATING THE SYSTEM SIZE
In Figure 2A-2, there are 19 outputs that
need to be developed for the system, 4 of
which have low complexity, 10 that have
medium complexity, and 5 that are very
complex.
After each line is filled in, a total number of
points are calculated per line by multiplying
each number by a complexity index.
The line totals are added up to determine the
total unadjusted function points (TUFP) for
the project.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.–5th ed.
EXHIBIT 1. FUNCTION POINT QUANTIFYING SYSTEM
SIZE - ESTIMATING THE SYSTEM SIZE
The complexity of the overall system is greater than the sum of
its parts.
To create a more realistic size for the project, a number of
additional system factors such as end-user efficiency,
reusability, and data communications are assessed in terms of
their effect on the project’s complexity.
These assessments are totaled and placed into a formula to
calculate an adjusted project complexity (APC) factor. The APC
factor has a baseline value of 0.65, and the total Processing
Complexity (PC) score (converted to hundredths) is added to
the baseline amount.
The TUFP value is multiplied by the APC factor to determine
the ultimate size of the project in terms of total adjusted
function points (TAFP).
This number should give the project manager a reasonable
idea as to how big the project will be.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.–5th ed.