8.04.

2025

Systems Development
System Development Life Cycle • 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
System Analysis and Design THE BELOW RESOURCES
• Laudon and Laudon, 2015. Management Information Systems‐
Managing 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 System Development

• The trends of increasing technical complexity of the systems, coupled • System development begins with the recognition of user needs.
with the need for repeatable and predictable process methodologies,
have driven System Developers to establish system development models • Then there is a preliminary investigation stage. It includes
or software development life cycle models. evaluation of present system, information gathering, feasibility
• With the developments in IT and with the growing operations of study, and request approval.
organizations, the need to automate the various activities increased, • Feasibility study includes technical, economic, legal and operational
since for manual procedures it was becoming very difficult, slow and feasibility. In economic feasibility cost‐benefit analysis is done.
complicated.
• Since there were a lot of organizations, which were opting for
• After that, there are detailed analysis, design, implementation,
automation, it was felt that some standard and structural procedure or testing and maintenance stages.
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.

1
 8.04.2025

Information System Concepts Revisited Information System Concepts Revisited

Seven key system elements 1.BOUNDARY 2. ENVIRONMENT
• 1.Boundary • Everything outside the system
• Delineation of which elements
• 2.Environment (Supra and neighbor, integrated systems)
are within the system and which 3. INPUTS
• 3.Inputs are outside
• 4.Outputs • Resources from the environment that
• Where to draw the boundary are consumed and manipulated within
• 5.Components the system
• 6.Interfaces
depends on: (Data and instructions)
• 7.Storage ‐ What can be controlled 4. OUTPUTS
‐ What scope is manageable within • Resources or products provided to the
environment by the activities within the
In System Analysis and Design, we aim to a given time frame system
define these elements by using logical (Data, Information, Reports, Queries,
representation methods. ‐ The impact of a boundary change Screens etc.)

Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

Information System Concepts Revisited

Information System Concepts Revisited
5. COMPONENTS 6. INTERFACES
• Activities or processes within the • The place where two components
system that transform inputs into or the system and its environment
intermediate forms or that meet or interact
generate system outputs
(User Interfaces)
• Some system components can be
viewed as systems with their own 7. STORAGE
sets of interrelated components = • Holding areas used for the
subsystems temporary and permanent
(Modules and Functions of the storage of information, energy,
System) materials, etc. system
(Databases)

Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

2
 8.04.2025

Five Key Design Principles for Information Systems 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
Two principles stem from key systems characteristics: activities like:
• Planning and Preliminary Investigation
1.Choose an appropriate scope • System Analysis
• System Design
• Selecting the boundary for the IS greatly influences complexity and • System Implementation (corresponds to Programming in Software System
success of the project Development)
• Unit Testing (included in Implementation for Software System Development),
2.Logical before physical • System and Acceptance Testing, Validation, Review
• Conversion
• You must know what an IS is to do before you can specify how a • (Production)‐ optional for SW system development)
system is to operate • Maintenance and Improvement

Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

The System Development Process System Development Loop

Project Planning
Preliminary
Planning or Preliminary Investigation
Investigation lacks ! DEFINING THE PROBLEM : Understanding the
System
NY current system or need for the system –

Modifications
Revisions

Preventive Actions
Corrective Actions
analysis Requirements List, “Contract”, What is the Gap?

System FINDING THE SOLUTION : Designing/Defining the

There can exist design “needed/required” system– Specifications, “How it
Production in should be?”
between Testing System IMPLEMENTING THE SOLUTION :
and Conversion Building, Project, Hands-on work,
implementation
NY “Closing the Gap”
Documentation
Training PERFORMANCE
System
Structural Change EVALUATION : Control,
 Activities here take place in SEQUENTIAL ORDER. (+Revision)
Validation control Check, “Measuring the
There can exist Gap”
 But, some of these activities may be repeated or take place System
Production in
simultaneously, depending on the approach to system maintenance
between Testing
building. and Conversion and improvement
 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 Yıldırım N. ITU ME, MIS Course Lecture Notes 2009‐2019

3
 8.04.2025

System Development Stages and Loop System Development Stages and Loop

Planning or
Preliminary
Investigation
(NY)

Laudon and Laudon (2015) MIS Text Book

Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach) Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)

System Development Stages and Loop

Systems analysis and

design /Alan Dennis,
Barbara Haley Wixom,
Roberta M. Roth.–2012,
5th ed.
p. cm.

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)

4
 8.04.2025

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 Planning Phase

(also called Preliminary Investigation) (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») In the end of
: determined, weighed, the best alternative is selected as the solution, which is termed as the "proposed system". preliminary analysis
all the findings and
Identify Opportunity: recommendations for
Decision on the solution which solution to use,
Understanding the customer
Thinking of possible solutions Analysing each possible
request for the new or
solution are presented to
improved system management, which
• Identify the problem • Current Solutions (similar) • Benchmark and Decision finally decide whether
• Understand the background • Available solutions Matrix (MDM) to accept the
• Review the Environment of (package or contracted) • ascertained whether that proposal or reject it.
the system system is practically
Identify possible or not)
solutions

P.S.: These phases correspond to the «Preliminary Assess

Analysis» section» of ISL 343E MIS Term Project. A part of the Feasibilities of each solution
it is presented in «Project Proposal» presentation by your P.S.: These phases in Red Circles correspond to the «Preliminary
group Decide on the Most feasible
solution Analysis» section» of ISL 343E MIS Term Project. A part of it is
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) https://its.ucsc.edu/drb/sdlc/prob‐sol.html presented in «Project Proposal» presentation by your group

5
 8.04.2025

Planning Phase (also called Preliminary Investigation

System Project
Investigation) You can use Cause
and Effect Diagrams . Environment
Planning Phase Project Inıtıation
Request
Feasibility
Approval Management
(Project plan
Example Analysis
• The analysis of the problem to be solved with an
information system. . Fishbone • The fundamental process of understanding why an information system should be built and determining how
Diagram the project team will go about building it. It has two steps:
• Defining the problem
• Identifying the causes . 1. Project initiation: the system’s business value to the organization is identified
• Specifying the solution —how will it lower costs or increase revenues? Most ideas for new systems come from outside the IS area
• Identifying the information requirements to be met. (from the marketing department, accounting department, etc.) in the form of a system request.
• Create a road map of existing organisation and system A system request presents a brief summary of a business need, and it explains how a system that supports the
• Identify the primary owners and users of data 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
• Identify the existing hardware and software. aspects of the proposed project:
• Detail the problems of existing system ■ The technical feasibility (Can we build it?)
• Examine documents, work papers, procedures
• Observe system operations
■ The economic feasibility (Will it provide business value?)
• Interview key users of the systems Users and owners of the data Example ■ The organizational feasibility (If we build it, will it be used?)
• Identify the problem areas and objectives of the The system request and feasibility analysis are presented to an information systems approval committee
solution (sometimes called a steering committee), which decides whether the project should be undertaken.
• Building a new IS 2. Project management: Once the project is approved, it enters Project management, the project manager
• Improving an existing IS 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
Anon (2013) Systems Analysis and Design – Complete Introductory Tutorial for Software Engineering, (adapted in UML approach)
developing the system.
Yıldırım N. ITU ME, MIS Course Lecture Notes 2009‐2019 Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Analysis Analysis
• System request is a document that describes the business reasons for Problem Definition
building a system and the value that the system is expected to Examples
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. project sponsor, In conclusion, the current problem is: “The process complexity of the Erasmus+ Exchange
Mobility Program among the participants and active individuals in the process”
2. business need, Major difficulties are:
3. business requirements,  Sending Erasmus documents to the responsible departments within ITU

4. business value, and 
Making LA change to be approved by the responsible departments
Selecting and comparing courses for preparing the LA and making them to be
5. special issues. 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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

6
 8.04.2025

Planning Phase
Planning Phase
Project
Inıtıation
System
Request
Approval
Project
Management
System Request Project
Inıtıation
System
Request
Approval
Project
Management
Feasibility
Analysis
(Project plan
Example Feasibility
Analysis
(Project plan

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, 2012, .–5th ed.

Planning Phase (Also called Suppose in an office all leave‐ Project System Project
applications are processed
Planning Phase Inıtıation Request Management
Preliminary Investigation ) manually.

Now this company is recruiting

Feasibility
Analysis
Approval
(Project plan

• EVALUATION & FEASIBILITY many new people every year.

• Whether it is practical and beneficial to build that system. So the number of employee in
the company has increased.
• Evaluated from developer and customer's point of view
So manual processing of leave
• Developer sees whether they have the required technology or manpower to application is becoming very
build the new system. difficult.
• Is building the new system really going to benefit the customer? So the management is
• Does the customer have the required money to build that type of a considering the option of
automating the leave processing
system? system.
• Technical,
If this is the case, then the system
• economical, and analyst would need to investigate
• operational. the existing system, find the
limitations present, and finally
• Legal evaluate whether automating the
system would help the
organization.
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.

7
 8.04.2025

Project System Project System

Planning Phase Inıtıation Request
Project
Management Planning Phase Inıtıation Request
Project
Management
Approval Approval
Feasibility (Project plan Feasibility (Project plan
Analysis Analysis
• Is the solution feasible?
• Is the solution achievable? Technical feasibility :
(Financial, technical, organisational standpoints) • The extent to which the system can be successfully designed, developed, and installed by the IT group.
• Feasibility study • Technical feasibility analysis is, in essence, a technical risk analysis that strives to answer the question:
• Technical feasibility: Can the development of the proposed system be done with current equipment, “Can we build it?”
existing software technology, and available personnel? Does it require new technology? Is the • Many risks can endanger the successful completion of the project. First and foremost is the users’ and
technology needed for the system available? Can the technology needed be handled by the firms’ IT analysts’ familiarity with the application. When analysts are unfamiliar with the business application area,
professionals? 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
• Economic feasibility: Are there sufficient benefits in creating the system to make the costs acceptable? development of a system to support a new business innovation (e.g., Microsoft starting up a new Internet
An important outcome of the economic feasibility study is the cost benefit analysis. Is the proposed dating service). In general, the development of new systems is riskier than extensions to an existing system,
system a good investment? because existing systems tend to be better understood.
• Legal feasibility: It checks if there are any legal hassle in developing the system. • 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
• Operational feasibility: Will the system be used if it is developed and implemented? Will there be and delays will occur because of the need to learn how to use the technology.
resistance from users that will undermine the possible application benefits? Can the organisation • Risk increases dramatically when the technology itself is new (e.g., web development using Ajax).
handle the changes brought by the system?

Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Analysis Analysis
Technical feasibility : Economic Feasibility
• Project size : Measured as the number of people on the development team, the length of time it will take to • also called a cost–benefit analysis – HARDEST TASK IN ıNFORMATION SYSTEM PROJECTS
complete the project, or the number of distinct features in the system.
• As the economic returns are generally not tangible‐measurable, NPV etc is hard to be applied.
• Larger projects present more risk, because they are more complicated to manage and because there is a greater Generally the savings from the labor and facility cost is utilized as Cash in Flows. However, overall
chance that some important system requirements will be overlooked or misunderstood. efficiency increases, motivational effects can occur. As well, inventories can be reduced and value
stream maps can be needed.
• Integratability: The extent to which the project is highly integrated with other systems (which is typical of large • This attempts to answer the question
systems) can cause problems, because complexity is increased when many systems must work together.
• “Should we build the system?”
• Compatibility: Teams need to consider the compatibility of the new system with the technology that already • Economic feasibility is determined by identifying costs and benefits associated with the
exists in the organization. Systems rarely are built in a vacuum—they are built in organizations that have system, assigning values to them, calculating future cash flows, and measuring the financial
numerous systems already in place. worthiness of the project.
New technology and applications need to be able to integrate with the existing environment for many reasons. • As a result of this analysis, the financial opportunities and risks of the project can be
They may rely on data from existing systems, they may produce data that feed other applications, and they may understood.
have to use the company’s existing communications infrastructure. • Keep in mind that organizations have limited capital resources and multiple projects will be
• 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). 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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

8
 8.04.2025

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Economic Feasibility Analysis Analysis
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.
Economic Feasibility
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!) forSystems
Costanalysis
Benefit 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, 2012, .–5th ed.

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Economic Feasibility Analysis Economic Feasibility Analysis
b) Assign Values to Costs and Benefits
b) Assign Values to Costs and Benefits ‐ Example
• Once the types of costs and benefits have been identified, the analyst needs
Notice that the customer
to assign specific dollar values to them. service intangible benefit
• How can someone quantify costs and benefits that haven’t happened yet? has been quantified,
based on a decrease in
And how can those predictions be realistic? customer complaint phone
• The most effective strategy for estimating costs and benefits is to rely on the calls.
people who have the best understanding of them. The intangible benefit
• For example, costs and benefits that are related to the technology or the project itself of being able to offer
can be provided by the company’s IT group or external consultants, and business users services that competitors
can develop the numbers associated with the business (e.g., sales projections, order currently offer was not
levels). quantified, but it was listed
so that the approval
• The company also can consider past projects, industry reports, and vendor committee will consider the
information, although these sources probably will be a bit less accurate. benefit when assessing the
Likely, all of the estimates will be revised as the project proceeds. system’s economic
feasibility.

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, 2012, .–5th ed.

9
 8.04.2025

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Economic Feasibility Analysis Economic Feasibility Analysis

b) Assign Values to Costs and Benefits b) Assign Values to Costs and Benefits
• Sometimes, it is acceptable to list intangible benefits, such as improved
• If predicting a specific value for a cost or benefit is proving difficult, it customer service, without assigning a monetary value.
may be useful to estimate a range of values for the cost or benefit and
• Other times, estimates have to be made regarding how much an intangible
then assign a likelihood (probability) estimate to each value. With this benefit is “worth.”
information, an expected value for the cost or benefit can be calculated. • 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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Analysis Analysis

Economic Feasibility Organizational Feasibility

• HARDEST TASK IN INFORMATION SYSTEM PROJECTS • How well the system ultimately will be accepted by its users and
• As the economic returns are generally not tangible‐measurable, NPV etc is hard incorporated into the ongoing operations of the organization?
to be applied.
• There are many organizational factors that can have an impact on the
• Generally the savings from the labor and facility cost is utilized as Cash in Flows. project, and seasoned developers know that organizational feasibility
However, overall efficiency increases, motivational effects can occur.
can be the most difficult feasibility dimension to assess.
• As well, inventories can be reduced and value stream maps can be needed.
• RETURN OF THE NEW SYSTEM MAY NOT BE FORESEEN • In essence, an organizational feasibility analysis attempts to answer the
question
• For measures like «increase in sales», it is hard to eliminate the impact • “If we build it, will they come?”
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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

10
 8.04.2025

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Analysis Analysis

Organizational Feasibility c) Organizational Feasibility‐ Stakeholders Analysis

• 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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

Project System Project Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Analysis Analysis
c) Organizational Feasibility ‐ STAKEHOLDERS
c) Organizational Feasibility • The champion : is a high‐level executive and is usually, but not always, the project sponsor who created the
system request.
• Stakeholders: Conduct a stakeholder analysis. • The champion supports the Project by providing time and resources (e.g., money) and by giving political support within the
• A stakeholder is a person, group, or organization that can affect (or can be affected by) a new system. 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.
• The most important stakeholders in the introduction of a new system are
• Organizational management While champions provide day‐to‐day support for the system, also needs to
• the project champion, support the project.
• Such management support conveys to the rest of the organization the belief that the system will make a valuable contribution
• system users, and 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
• organizational management , system will likely create.
• IT IS Departments • System Users : who ultimately will use the system once it has been installed in the organization.
• the IS department is a stakeholder as the provider/supplier of the system • Too often, the project team meets with users at the beginning of a project and then disappears until after the system is created.
• IS dept can be a stakeholder of a system because IS jobs or roles may be changed significantly after • 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.
the system’s implementation • User participation should be promoted throughout the development process to make sure that the final system will be accepted
• (but systems sometimes affect other stakeholders as well. ) and used, by getting users actively involved in the development of the system (e.g., performing tasks, providing feedback, and
making decisions)
• 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. 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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

11
 8.04.2025

Project System Project

Planning Phase Inıtıation Request
Feasibility
Approval Management
Project System Project
(Project plan
Feasibility Example Analysis Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Analysis
• 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.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

System
Project System Project Analysis Requirements Concept
Planning Phase Inıtıation Request
Feasibility
Approval Management
(Project plan
Analysis Phase Strategy (AS IS) Gathering (Models:
Database
Combination

Process)
Analysis
• The analysis phase answers the questions of System PROPOSAL
PROJECT MANAGEMENT – PROJECT PLAN – System Development • who will use the system, Requirements List
Project Methodology Options • what the system will do, and (THE ANALYSES)
• Systems Development Life Cycle (SDLC) provides the foundation for the • where and when it will be used.
processes used to develop an information system. During this phase, the project team investigates any current system(s), identifies improvement opportunities,
• A methodology is a formalized approach to implementing the SDLC (i.e., it and develops a concept for the new system.
is a list of steps and deliverables). This phase has three steps:
• 1. Development of an analysis strategy : to guide the project team’s efforts. Such a strategy usually includes
• There are many different systems development methodologies, and they vary a study of the current system (called the as‐is system) and its problems, and envisioning ways to design a
in terms of the progression that is followed through the phases of the SDLC. new system (called the to‐be system).
• 2. Requirements gathering (e.g., through interviews, group workshops, or questionnaires). The analysis of
• Some methodologies are formal standards used by government agencies, this information—in conjunction with input from the project sponsor and many other people—leads to the
while others have been developed by consulting firms to sell to clients. Many development of a concept for a new system
organizations have their own internal methodologies that have been refined • STRATEGIC : The system concept is then used as a basis to develop a set of business analysis models that
over the years, and they explain exactly how each phase of the SDLC is to be 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.
performed in that company. • 3. System Proposal : The analyses, system concept, and models are combined into a document called the
NOTE: VISIT LECTURE NOTES ON SOFTWARE DEVELOPMENT MODELS 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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

12
 8.04.2025

System Concept System Concept

Analysis Phase Analysis(ASStrategy
IS)
Requirements
Gathering (Models: Database Combination
Analysis Strategy
(AS IS)
Requirements
Gathering (Models: Database Combination

Establishing Information and Process Requirements

Process)
System PROPOSAL Analysis Phase Process)
System PROPOSAL
Requirements List Establishing Information and Process Requirements Requirements List
(THE ANALYSES) (THE ANALYSES)
• 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
P.S.: These phases in Red Circles correspond to the • Or undergo major modifications
«System Analysis» Section of ISL 343E MIS Term Project.
• Alternative approaches for requirements analysis

https://its.ucsc.edu/drb/sdlc/req‐def.html Yıldırım N. ITU ME, MIS Course Lecture Notes 2009‐2019

Analysis Strategy Requirements System Concept Analysis Strategy Requirements System Concept
(Models: Database Combination (Models: Database Combination
(AS IS) Gathering (AS IS) Gathering
Analysis Phase Process)
System PROPOSAL Analysis Phase Process)
System PROPOSAL
Establishing Information and Process Requirements ‐ Examples Requirements List Establishing Information Requirements, Limitations and s ‐ Examples Requirements List
Example 1. ITU COURSE SELECTION ASSISTANT (THE ANALYSES) (THE ANALYSES)
Example 3: Work demand and workflow system between departments and IT Department
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 Yıldırım N. ITU ME, MIS Course Lecture Notes 2009‐2019

13
 8.04.2025

Design Process, Data

Analysis Strategy Requirements System Concept Architecture Interface Database
Combination Design Flow (Program)
(AS IS) Gathering (Models: Database Strategy development Design
Analysis Phase Process)
System PROPOSAL Design Phase Basic
Design

Requirements List Database Program

Establishing Information Requirements, Limitations and s ‐ Examples Architecture Interfaces
Specs Specs
(THE ANALYSES) HW, SW, NW
Example 4: Event Organization Service Providers Platform (like Armut.com)
System Specifications
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 • The design phase decides how the system will operate in terms of the
● 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.
hardware, software, and network infrastructure that will be in place;
●
●
User must wait for maximum 15 days. Consuming time issue for users.
Service provider’s information is not accessible for public.
the user interface, forms, and reports that will be used; and the
●
●
There is no voting or comment opportunity on organization for users. It is not opaque.
Prices of activities is not clear. specific programs, databases, and files that will be needed.
● 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. • Although most of the strategic decisions about the system are made
● System take care of service providers, not users.

2.4.2 Needs
in the development of the system concept during the analysis phase,
●
●
Users should select what their request from the activity.
Price of activity should be almost determined.
the steps in the design phase determine exactly how the system will
●
●
System should be dynamic.
User should select two or more organization service(like decoration and entertainment) on the same time operate.
● 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 Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.
Site should not be time consuming for users

Design Process, Data

Architecture Interface Database
Design Phase Strategy development Design Design Flow (Program)
Design Design Phase
Basic
Database Program
Architecture Interfaces
Specs Specs
HW, SW, NW
• The design phase has four steps: System Specifications
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. Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

14
 8.04.2025

Design Process, Data

Architecture Interface Database
Flow (Program)
Design Architecture Interfac Database
Process, Data
Flow Design Phase Strategy development Design Design
Design
Design Phase Strategy development e Design Design (Program)
Design
Basic
Architecture Interfaces
Database Program
Specs Specs
Basic HW, SW, NW
Interface Database Program
Architecture System Specifications
s Specs Specs
HW, SW, NW
System Specifications
• Shows how the system will fulfill the objective of systems analysis
• The purpose of the design phase is to plan a solution of the problem specified by • 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
the requirement document – first step for moving from problem domain to the • Consists of all specifications that give the system its FORM and STRUCTURE
solution domain. • Carefully define the objectives of the system
• The design of a system is perhaps the most critical factor affecting the quality of • Detail the system specifications that will deliver the functions identified during the systems analysis
the software, and has a major impact on the later phases, particularly testing and • Specs should adress all components of the system solution
• Managerial
maintenance.
• Organisational
• The output of this phase is the design document. • Technological
• Each design represents a unique blend of all components‐ Alternative approaches for requirements analysis
• This document is similar to a blue print or plan for the solution, and is used later
during implementation, testing and maintenance. • Superior design is the “easy and efficient” design that
• fulfills USER REQUIREMENTS
• Within a specific set of CONSTRAINTS (technical, organisational, financial, time)

Design Process, Data Design Process, Data

Architecture Interface Database Architecture Interface Database
Flow (Program) Flow (Program)
Design Phase Strategy development Design Design
Design Design Phase Strategy development Design Design
Design

• The design activity is often divided into two separate Basic Basic
phase‐system design and detailed design. 2 Database Program Database Program
Architecture Interfaces Architecture Interfaces
documents are prepared. Specs Specs Specs Specs
HW, SW, NW HW, SW, NW
• System design, ( top‐level design): what Example: A Learning Management System (LMS like Ninova)
components are needed System Specifications System Specifications
Management Functions
• identify the modules that should be in
the system,
• interactions with each other to produce
the desired results. Design Activity
Design Activity
• 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 Detailed Design Detailed Design
System (Top‐ Verification of System (Top‐ Verification of
decided (Component Level) Design
(Component
the Design
Level) Design the Design Design)
• Detailed design: how the components can be Design)
implemented in software is the issue
• the internal logic of each of the modules Detailed Design
specified in system design Internal logic of Detailed Design
Modules of The Specifications of Interactions Internal logic of of interactions
Modules of The Specifications of Interactions System these modules among modules each of modules
• further details of the data structures and System these modules among modules
each of of interactions of components

algorithmic design of each of the modules of components

modules is specified.
• The logic of a module is usually specified
in a high‐level design description OUTPUT: Major data structures, OUTPUT: Details of the data
language, which is independent of the OUTPUT: Major data structures, OUTPUT: Details of the data file formats, output formats, structures and algorithmic
target language in which the software file formats, output formats, structures and algorithmic as well as the major modules in the system design of each of the modules
will eventually be implemented. as well as the major modules in the system design of each of the modules and their specifications are decided is specified.
Like every other phase, the design phase and their specifications are decided is specified.
ends with verification of the design

15
 8.04.2025

Process, Data Design Process, Data

Design Phase Design
Strategy
Architecture
development
Interface
Design
Database
Design Flow (Program)
Design
Strategy
Architecture
development
Interface
Design
Database
Design Flow (Program)
Design

Basic
Database
Design Phase Basic
Database Program
The software design process Architecture
HW, SW, NW
Interfaces
Specs
Program
Specs  Types of specifications to be
Architecture
HW, SW, NW
Interfaces
Specs Specs

and activities and outputs System Specifications produced by system design System Specifications

• Architectural design
• Abstract specification
• Interface design
• Component design
• Data structure design
• Algorithm design

Design Process, Data Process, Data

Architecture Interface Database Design Architecture Interface Database
Design Flow (Program) Flow (Program)
Strategy development Design Design
Design Phase Strategy development Design Design
Design
Design Phase Basic
Architecture Interfaces
Database Program Basic
Architecture Interfaces
Database Program
Specs Specs Specs Specs
Structured methods HW, SW, NW
System Specifications
HW, SW, NW
System Specifications

• Systematic approaches to developing a software design. Role of End Users

• The design is usually documented as a set of graphical models. • User information requirements drive the entire system‐building effort
• Possible models • Users must have sufficient control over the design process to ensure
the system reflects their priorities and information needs
• Structural model (Functional model, breakdown of functions, context
• Not the biases of technical staff
diagrams )
• Database Model (Entity Relationship Model) • Working on design increases users’ understanding and acceptance of
• Work Flow Models (Process ‐ Sequence model) the system
• Data‐flow model (Data Flow Diagrams) • Insufficient user involvement in the design effort is a major cause of
• Use‐Case Model system failure
• USer participation in alternative system development methods
P.S.: These methods correspond to the models used in both «System Analysis» and in
«System Design» Section of ISL 343E MIS Term Project.

16
 8.04.2025

Implementation (Built
Construction Programmed Installation New Implementation Construction Programmed Installation New

Phase
and Test) System /Conversion System
(Programming) (Built and Test) System /Conversion System

• The final phase in the SDLC is the implementation phase, during which the system is
Support Plan
Phase Support Plan

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 • System specs are translated into software program
longest and most expensive single part of the development process. code. May be ;
This phase has three steps: • Outsourced
1. System construction is the first step. The system is built and tested to ensure that it • Purchase of the software package from a vendor
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 • Purchase of software services from ASP (Application
on testing than on writing the programs in the first place. Service Provider)
2. The system is installed. Installation is the process by which the old system is turned off • Developed in‐house
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 NOTEs
changes caused by the new system. : VISIT LECTURE NOTES ON TYPES OF SOFTWARE » available in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/MIS_Week 2_ 3 Software
3. The analyst team establishes a support plan for the system. This plan usually includes a Definition and Classification.ppt «Types of Application Software» slide)
formal or informal post‐implementation review, as well as a systematic way for identifying VISIT LECTURE NOTES ON Outsourcing and TCO» available in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/MIS_Week 2_3 Software
major and minor changes needed for the system. Ownership_Languages_Trends.ppt «Outsourcing» and «Total Cost Ownership» slides)
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth, 2012, .–5th ed.

Implementation Construction Programmed Installation New Implementation Construction Programmed Installation New
(Programming) (Built and Test) System /Conversion System
(Programming) (Built and Test) System /Conversion System

Phase Support Plan

Phase Support Plan

• Once the design is complete, most of the major decisions about the system Programming
have been made.
• The goal of the coding phase is to
• translate the design of the system into code in a given programming language.
• Translating a design into a program and removing errors from that
• to implement the design in the best possible manner.
program.
• The coding phase affects both testing and maintenance profoundly. A well • Programming is a personal activity ‐ there is no generic
written code reduces the testing and maintenance effort. programming process.
• the focus should be on developing programs that are easy to write.
Simplicity and clarity should be strived for, during the coding phase.
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

17
 8.04.2025

Implementation Construction Programmed Installation New

Implementation Construction Programmed Installation New
Phase (Built and Test) System /Conversion System
Phase (Built and Test) System /Conversion System

(Debugging) Support Plan Support Plan

Software validation
• Verification and validation (V & V) is intended to show that a
The debugging process (Intermediary or shared process between system conforms to its specification and meets the
Programming and Testing) requirements of the system customer.
Programmers carry out some program testing to discover faults in the
program and remove these faults in the debugging process. • 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.

Implementation Construction Programmed Installation New

Implementation Construction Programmed Installation New

Phase (Built and Test) System /Conversion System

Phase (Built and Test) System /Conversion System

Support Plan Support Plan

Testing The testing process
• 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

18
 8.04.2025

Implementation Construction Programmed Installation New

Implementation Construction Programmed Installation New

Phase (Built and Test) System /Conversion System

Phase (Built and Test) System /Conversion System

Support Plan Support Plan

Testing phases Testing stages
Component or unit System testing Acceptance testing
testing

• Individual • Testing of the • Testing with

components system as a customer data
are tested whole. • to check that
independently; • Testing of the system
• Components emergent meets the
may be properties is customer’s
functions or particularly needs.
objects or important.
coherent
groupings of
these entities.

Implementation Construction Programmed Installation New Construction Programmed Installation New

Phase (Built and Test) System /Conversion System Testing Steps (Built and Test) System /Conversion System
• Work with users to devise a systematic test plan
Support Plan Support Plan
Testing Steps • Test plan includes all preperations of all testing types
1. Component or Unit 3. Acceptance Testing
Testing (Program • When developing a test plan, the various conditions should be tested, the requirements
2. Systems Testing
testing) of each condition tested, and the expected results. Test plans require input from both
to locate errors in Try to determine Final certification of end users and IT specialists.
the programs whether the discrete the system – ready
To focus on finding modules function to be used in
all the ways to make together as planned production
a program fail DESIGN SPEC TEST REQUIREMENTS
ALGORITHM AND Try to determine DOCUMENT
DATA RUN discrepencies that Acceptance tests are
(PROGRAM AND exist between the evaluated by users
DATA way system works and reviewed by
IMPLEMENTATION) and the way it was management‐ all
TEST conceived parties should be
(Not to quarantee • Performance time satisfied
that programs are • Capacity for file
error free‐ it is storage
impossible) • Handling peak
Find the problem, loads
than correct it • REcovery and start
capabilities 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.
• Manual procedures

19
 8.04.2025

Construction Programmed Installation New Construction Programmed Installation New

(Built and Test) System /Conversion System (Built and Test) System /Conversion System
Testing Plan
1) Indicate the type of the test plans to be included in
Testing
4) Approach:
Support Plan
Testing Methods Support Plan

• Mention the overall approach to testing. White Box Testing is a software testing method in
• Master Test Plan: A single high‐level test plan for a Black Box Testing, also known as which the internal structure/design/implementation
project/product that unifies all other test plans. • Specify the testing methods [Manual/Automated; Black, white, Behavioral Testing, is a software testing
grey box] of the item being tested is known to the tester. The
• Testing Level Specific Test Plans: Plans for each level of method in which the internal
testing. tester chooses inputs to exercise paths through the
5) Item Pass/Fail Criteria: structure/design/implementation of the
• Unit Test Plan code and determines the appropriate outputs.
• System Test Plan (including Integrations) • Specify the criteria that will be used to determine whether item being tested is not known to the Programming know‐how and the implementation
each test item (software/product) has passed or failed testing. tester. Example: A tester, without
• Acceptance Test Plan knowledge is essential. White box testing is testing
6) Schedule: knowledge of the internal structures of a beyond the user interface and into the nitty‐gritty of
• Testing Type Specific Test Plans: Plans for major types of
testing like Performance Test Plan and Security Test Plan • When and how often will the tests will be done? website, tests the web pages by using a a system. Example: tester, usually a developer as
2) Scope and Features: List the Tested Items 7) Staffing Needs and Responsibilities/approvals browser; providing inputs (clicks, well, studies the implementation code of a certain
(software/products) and their versions. List the Features keystrokes) and verifying the outputs
to be Tested and not to be tested • Specify staffing needs by role and required skills. field on a webpage, determines all legal (valid and
against the expected outcome. The invalid) AND illegal inputs and verifies the outputs
• Provide references to the Requirements and/or Design • List the responsibilities of each team/role/individual.
specifications of the features to be tested higher the level, and hence the bigger against the expected outcomes, which is also
• Specify the reasons these features won’t be tested.
7) Staffing Needs and Responsibilities/approvals and more complex the box, the more determined by studying the implementation code.
• Specify staffing needs by role and required skills. black box testing method comes into Generally used for unit testing
3) List the Major Constraints
use.
• Any organizational or technical constraints that impact the • List the responsibilities of each team/role/individual.
testintg (lack of resources, personnel, incomplete
programming etc.)

Construction Programmed Installation New Implementation Construction Programmed Installation New

(Built and Test) System /Conversion System
Phase (Built and Test) System /Conversion System

Support Plan Support Plan

UNIT Testing Plan
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)

20
 8.04.2025

Implementation Construction Programmed Installation New Implementation Construction Programmed Installation New

Phase (Built and Test) System /Conversion System

Phase (Built and Test) System /Conversion System

Support Plan Support Plan

Conversion Methods ADVANTAGES:
Conversion ADVANTAGES:
Parallel Method 1 By using the parallel method, small minor errors can be easily seen PILOT METHOD 1.Risk is reduced
The parallel conversion strategy is when both the old and new 2 Companies are able to fix any problems with the new system The pilot conversion method is when the new system is introduced to 2.Allows the organisation to see whether the new system will
information systems operate alongside one another for a specified before ending the previous system a single department/location at a time, this strategy is mainly used for meet the organisations needs in one department/location
time (Vermaat, M.E, 2016). Once the results have been compared DISADVANTAGES: testing the new system in different environments. The pilot method is before using it throughout the entire organisation
between the old and new system, the organisation may choose to 1 It is very costly as two systems are being operated simultaneously, very helpful for organisations which have several locations. DISADVANTAGES:
gradually welcome in the new system or immediately end the so there will be the costs for more power for example 1.Too much time is involved testing in one location, there is
previous system. 2 Operating two systems simultaneously is also very time consuming also increased development and labour costs
and stressful as there is more work involved, such as creating more
reports
PHASED METHOD ADVANTAGES:
1 As the system is tested at every stage, there is very little chance
• Direct Cut Over ADVANTAGES: This method replaces the old system in stages, this method is of error
1 It is less costly as it is a direct change over different to the pilot method as the pilot strategy tests in one 2 This strategy is more user friendly. Because the new system is
• The direct cut over strategy is when the company stops using
2 It is not very time consuming as once the old system has Whereas the phased strategy introduces the new system tlocation implemented one department at a time, the IT staff are able to
the old system and immediately starts using the new system.
stopped being used the new system is immediately being set up and then is implemented in the whole organisation. o one draw their attention to training one department effectively to
DISADVANTAGES: department at a time. using the new system.
1 If the system has not been implemented properly the new DISADVANTAGES:
system may fail to work and this will affect the whole 1 It takes a lot of time to implement the whole new system to the
organisation. entire 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 Vermaat, M.E (2016). Enhanced Discovering Computers ©2017. USA: Cengage Learning. 526.
conversion , O’Brien & Marakas (2006, p. 424) O’Brien & Marakas (2006, p. 424)

Implementation Construction Programmed Installation New Post Implementation Construction Programmed Installation New

Phase (Built and Test) System /Conversion System

Phase (Built and Test) System /Conversion System

Support Plan Support Plan

Production and Maintanance Software evolution

• After the new system is installed and conversion is complete, the system is said to be in • Software is inherently flexible and can change.
production.
• The system will be reviewed by both users and technical specialists to • As requirements change through changing business
• determine “how well it has met its original objectives” circumstances, the software that supports the business must
• to decide “whether any revisions/modifications are needed”.
also evolve and change.
• Is a “postimplementation audit” needed?
• After the system is fine tuned, it must be maintained while it is in production to correct • Although there has been a demarcation between
errors, meet requirements, improve efficiency development and evolution (maintenance) this is
• Maintenance: Changes in hardware, software, documentation, procedures.
increasingly irrelevant as fewer and fewer systems are
• 20% percent of maintenance time is used for “debugging” or “correcting” emergency
problems. completely new.
• 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)

21
 8.04.2025

Post Implementation Construction Programmed Installation New Post Implementation Construction Programmed Installation New
(Built and Test) /Conversion System (Built and Test) /Conversion System
Phase System Phase System

Support Plan Support Plan

System evolution • 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 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.
You will find out • General activities are specification, design and implementation, validation and
Or you will evolution.
create
• Generic process models describe the organisation of software processes. Examples
You already include the waterfall model, evolutionary development and component‐based software
know or engineering.
Term You can guess
Project • Iterative process models describe the software process as a cycle of activities.
Scope • 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.

22
 8.04.2025

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
Linking Software System Development Process to
•
•
•
•
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),
Next Topics on Methods of Database and Process
•
•
•
•
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ı)
Analysis Methods
• 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?
• 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)
• For Testing, which steps would you take and how?
• 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ış.
For Details
• 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?
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 Software System Development
Structured Methodologies Procedural‐oriented Structured Methodologies
•Procedural-oriented: ! THESE METHODS ARE THE ONES WE PREFERRED TO
USE IN TERM PROJECT BOTH IN SYSTEM ANALYSIS
Describe what you have, define what you want, and
- Most common approach AND SYSTEM DESIGN PHASES ! describe how you will make what you want.
-Include data-oriented, sequential, process-oriented
activities
! FROM THESE METHODS, WE WILL UTILIZE ONLY THE
•Object-oriented: USE CASE DIAGRAMS AND CLASS DIAGRAMS FROM 1.As-Is (what you have)
UML (UNIFIED MODELLING APPROACH) IN TERM
- Newer approach PROJECT! 2.Logical To-Be (what you want)
- Works well for GUIs and multimedia applications . 3.Physical To-Be (how to make what you want)
! THESE ARE THE AIMS OF TERM PROJECT!
NOTEs NOTEs
VISIT LECTURE NOTES on System Modelling approaches in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/System Modelling Methods 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 Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

23
 8.04.2025

Software System Development Software System Development

Procedural‐oriented Structured Methodologies Structured Methodologies For As‐ IS and TO‐ BE
1.As-Is • Structured refers to the fact that techniques are step by step, with each step building on
the previous one.
•Identifies existing processes, external participants, other databases or applications, and
inputs and outputs • Data flow diagram: Primary tool for structured analysis that graphically illustrates a
system’s component processes and the flow of data between them.

2.Logical To-Be • Process specifications: Specifications that describe the logic of he processes occurring
•Describes “what” rather than “how” within the lowest levels of a data flow diagram.
•High-level model of a nonexistent new system
• Context Diagram and Structure chart: System documentation showing each level of
•Identifies processes and data design, the relationship among the levels, and the overallplace in the design ; can document
•Does not identify who does activity, where accomplished, or type of hardware or software 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
3.Physical To-Be AND SYSTEM DESIGN PHASES !
NOTEs
•Maps the logical requirements to available technology VISIT LECTURE NOTES on System Modelling approaches in Ninova Ders Kaynakları/Lecture Notes/Midterm Exam Coverage/System Modelling Methods/System
! THESE ARE THE AIMS OF TERM PROJECT! Models 1.ppt
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

Software System Development Software System Development

Structured Methodologies For As‐ IS and TO‐ BE Structured Methodologies For As‐ IS and TO‐ BE
• Data flow diagram: Primary tool for structured analysis that graphically illustrates a system’s Context and Structure chart: System documentation showing each level of design, the
component processes and the flow of data between them. relationship among the levels, and the overallplace in the design ; can document one program, one
EXAMPLE DATA FLOW DIAGRAM system, or part of one program.

Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

24
 8.04.2025

Software System Development Software System Development

Structured Methodologies For As‐ IS and TO‐ BE Structured Methodologies
• For As- IS and TO- BE
- Basic and detailed, swimlane Process Flowcharts - Database Management Models,
- E-R Diagrams

E R Diagram
Figure 15.6 A flowchart describing a sales bonus system

E R Diagram
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

Software System Development Software System Development

Object Oriented Methodologies for AS‐IS and TO‐BE 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 We will perform in our Term Project USE case Diagram
- Class Diagrams ‐ Use case Diagrams (UML)
‐ Class Diagrams
Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

25
 8.04.2025

Software System Development Software System Development

Object Oriented Methodologies for AS‐IS and TO‐BE 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 We will perform in our Term
needed) Project
‐ Use case Diagrams
‐ Class Diagrams

Sequence Diagrams include Codes

in Classes.
Usage of Sequence Diagrams in
Term Project is OPTIONAL
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 Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION

EXHIBIT 1. QUANTIFYING SYSTEM SIZE

Software System Development ESTIMATING THE SYSTEM SIZE
Object Oriented Methodologies for Physical TO‐BE The function point approach The function point approach
A more precise approach to estimation is called the function point An estimating technique that can be used to estimate
• INTERFACE DESIGN (Linking Need to Technology) approach. • the size of the new system,
This approach is a more complex—and, it is hoped, more • the effort that will be required to complete the
reliable—way of estimating time and effort for a project. The • system, and
details of the function point approach are explained in Appendix • the time the project will require.
2A. 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

Carol V. Brown. Daniel W. DeHayes. (UML Course in MIT OCW) MANAGING INFORMATION TECHNOLOGY 7th EDITION Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.–5th ed.

26
 8.04.2025

EXHIBIT 1. FUNCTION POINT EXHIBIT 1. FUNCTION POINT QUANTIFYING

QUANTIFYING SYSTEM SIZE ‐ SYSTEM SIZE ‐ ESTIMATING THE SYSTEM SIZE
ESTIMATING THE SYSTEM SIZE To calculate the function points for a
project, components are listed on a In Figure 2A-2, there are 19 outputs that need to
The first step is to estimate the size of a worksheet to represent the major elements be developed for the system, 4 of which have low
project by using function points, a concept of the system. For example, data-entry complexity, 10 that have medium complexity,
developed in 1979 by Allen Albrecht of screens are kinds of inputs, reports are and 5 that are very complex.
IBM. A function point is a measure of outputs, and database queries are kinds of After each line is filled in, a total number of
program size that is based on the system’s queries. (See Figure 2A-2.) points are calculated per line by multiplying
number and complexity of inputs, outputs, each number by a complexity index.
queries, files, and program interfaces. The project manager records the total
number of each component that the system The line totals are added up to determine the total
will include, and then he or she breaks unadjusted function points (TUFP) for the
down the number to show the number of project.
components that have low, medium, and
high complexity.
Systems analysis and design /Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.–5th ed. 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.

27