Topic 1

Introduction to Information Systems Engineering

ISP550
INFORMATION SYSTEMS
ENGINEERING

1
 Learning Objectives

• Define Information Systems Engineering

• Define Information System Analysis and Design
• Describe the Systems Development Life Cycle (SDLC)
• Describe the System Development Methodologies such as agile
methodologies, eXtreme Programming, Scrum, and RUP
• Describe the roles and responsibilities of participants in SDLC

2
 Introduction
• Information systems support almost everything organizations do, whether the
systems are developed for internal use, for exchanges with business partners, or
for interactions with customers.

• Networks, especially the Internet are crucial for connecting organizations with
their partners and their customers
• Information systems form the foundation for every major organizational activity and
industry, from retail to healthcare to manufacturing to logistics.

3
 Definition of Information System

Information systems are computer-based infrastructures, organizations,

personnel, and components that collect, process, store, transmit, display,
disseminate, and act on information.
▪Information systems generally provide computer-based
assistance to people engaging their environment as illustrated in
Figure 1, where engagements and environments are often too
complex and dynamic to be handled manually.

4
 Definition of Information System (continue)
Complex, dynamic engagements and environments require people to analyze and draw
conclusions from an abstracted representation of the world, which enables them to make
discrete decisions to achieve a desired effect in the world commensurate with their roles,
tasks and capabilities.
The abstraction is sometimes portrayed as a hierarchy
(Figure 2) known as the Data, Information, Knowledge,
and Wisdom (DIKW) paradigm.

5 Ackoff, R. L., “From Data to Wisdom,” J. Appl. Syst. Anal. 16, 3–9 (1989).
Cleveland, H., “Information as Resource,” The Futurist, 34–39 (Dec 1982).
 Definition of Information System (continue)
Data Knowledge
• are the smallest symbolic units • symbols are sufficiently abstract to enable
that describe measured or people to make decisions about and interact
estimated phenomena. with their environments.
• i.e.: sensors produce large • combination of information with necessary
volumes of data, but very little is data and judgment of historical patterns
understood by humans. (experience).
Information Wisdom
• information is a more abstract • is knowledge combined with insights and
understanding of the data common sense.
derived by fusing data • It is typically achieved by humans based on
• lowest layer where the symbolic knowledge, information, and data.
units are interpretable by • hard to derive automatically from lower-level
humans. information representations.
6
 TERM INFORMATION SYSTEMS ENGINEERING

▸ CONFERENCE ON ADVANCED INFORMATION INTERNATIONAL COUNCIL ON SYSTEMS

SYSTEMS ENGINEERING (ISE COMMUNITY) ENGINEERING (INCOSE)
Information systems engineering is situated at
the intersection of information systems, ▸ Information Systems Engineering is an
databases and software engineering. The term was interdisciplinary approach and means to enable
coined around 1990, possibly in connection with the the realization of successful information systems.
start-up of the later so successful CAiSE (Conference ▸ ISE focuses on defining customer needs and
on Advanced Information Systems Engineering) required functionality early in the development
series of conferences. cycle, documenting requirements, then
proceeding with design synthesis, and system
validation and deployment while considering the
It is notable that there are indeed three research
complete problem: - Operations & Maintenance,
communities corresponding to each of the above- Performance, Cost & Schedule, Test, Realization,
mentioned fields, the ISworld, DBworld and SEworld Training & Support, Disposal, Social aspects
communities.
7
Information Systems Engineering: What Is It? (Wangler and Backlund, 2005)
 TERM INFORMATION SYSTEMS ENGINEERING

There are at least three broad areas of

• Information Systems Engineering integrates all
knowledge that are needed for successful work in
the disciplines and specialty groups into a team
information systems engineering (cf. Iivari [19]):
effort forming a structured development process
• knowledge of information systems domains
that proceeds from concept to production to
and applications,
operation.
• knowledge about methods, models, and tools
for business and systems analysis and design,
• Information Systems Engineering considers
deployment, and operations and maintenance,
both the business and the technical needs of all
• knowledge of the technology needed for
customers with the goal of providing a quality
building systems and integrating them with
product that meets the user needs.
legacy components.

8
 Developing Information Systems and the
Systems Development Life Cycle
Systems development methodology
• A standard process followed in an organization to conduct all the steps
necessary to analyze, design, implement, and maintain information systems

The systems development life cycle (S D L C)

• The traditional methodology used to develop, maintain, and replace
information systems
• Features several phases that mark the progress of the systems analysis and
design efforts
Notes: The systems development life cycle (SDLC) is a common methodology for systems development in many organizations; it features
several phases that mark the progress of the systems analysis and design effort. Every textbook author and information systems
development organization uses a slightly different life-cycle model
9
 Systems Development Life Cycle
The life cycle can be thought of as a circular process in which
the end of the useful life of one system leads to the beginning
of another project that will develop a new version or replace
an existing system altogether (see Figure 3).

At first glance, the life cycle appears to be a sequentially

ordered set of phases, but it is not. The specific steps and
their sequence are meant to be adapted as required for a
project, consistent with management approaches.

For example, in any given SDLC phase, the project can return
to an earlier phase if necessary. Similarly, if a commercial
product does not perform well just after its introduction, it
may be temporarily removed from the market and improved
before being reintroduced
10
Figure 3: Systems Development Life Cycle
 Phases of the S D L C

• Planning
• Need for a new or enhanced system is identified
• Needs are identified, analyzed, prioritized, and arranged
• Determine the scope of the proposed system
• A baseline project plan is developed
• Analysis
• System requirements are studied from user input and structured
• Requires careful study of current systems, manual and computerized, that might be
replaced or enhanced
• Output is a description of the alternate solution recommended by the analysis team

11
 Phases of the S D L C

• Design
• The analyst converts the alternate solution into logical and physical
specifications
• Logical Design
• The design process part that is independent of any specific hardware or software platform
• Physical Design
• The logical specifications of the system from logical design are transformed into technology-
specific details from which all programming/system construction can be accomplished
• Choices of language, database, and platform are many times already decided by the
organization or client
12
 Phases of the S D L C

• Implementation
• Occurs when the information system is coded, tested, installed, and
supported in the organization
• New systems become part of the daily activities of the organization
• Maintenance
• The phase in which an information system is systematically repaired and
improved
• Organization’s needs may change over time requiring changes to the system
based on user’s needs
13
 Products of SDLC Phases
Phase Products, Outputs, or Deliverables
Planning • Priorities for system and projects; an architecture for data, networks, and selection
hardware, and information systems management are the result of associated
systems
• Detailed steps, or work plan, for project
• Specification of system scope and planning and high-level system requirements or
features
• Assignment of team members and other resources
• System justification or business case
Analysis • Description of the current system and where problems or opportunities exist, with a
general recommendation on how to fix, enhance, or replace current system
• Explanation of alternative systems and justification for chosen alternative
Design • Functional, detailed specifications of system elements (data, processes, inputs, and
outputs)
• Technical, detailed specifications of all system elements (programs, files, network,
system software, etc.)
• Acquisition plan for new technology
Implementation • Code, documentation, training procedures, and support capabilities
Maintenance • New versions or releases of software with associated updates to documentation,
14 training, and support
 15
Instead of systems requirements being produced in analysis, systems specifications being created in
design and coding and testing being done at the beginning of implementation, current practice combines
these activities into a single analysis–design–code–test process. These activities are the heart of systems
development, as we suggest in Figure 1-7. This combination of activities is typical of current practices in
agile methodologies.

Figure 1-6: Systems

Figure 1-7: Heart of
Development Life Cycle
Systems Development
 General approaches to the SDLC

Predictive Approach

• Waterfall model
• Assumes the project can be planned and that the information system can be developed
according to the plan
• Requirements are well understood and/or low technical risk

Adaptive Approach to the SDLC

• Agile /Iterative model

• Assumes the project must be more flexible and adapt to changing needs as the project
progresses
• Requirements and needs are uncertain and/or high technical risk
16
 The SDLC Traditional Waterfall Problems
o Once one phase ends Figure 1-8: Traditional Waterfall SDLC
another begins, going
downhill until complete
o Makes it difficult to go back
o Results in great expense to
make changes
o Role of system users or
customers narrowly
defined
o Focused on deadlines
17
 Agile methodologies
o Two well-known instances of agile methodologies are
eXtreme Programming and Scrum, although there are other
variations.
o Agile methodologies share three key principles:
1. A focus on adaptive rather than predictive methodologies
2. A focus on people rather than roles
3. A focus on self-adaptive processes

18
 The Agile Manifesto
The agile methodologies group (The Seventeen Anarchists) argues
that software development methodologies adapted from engineering
generally do not fit with real-world software development.

The Seventeen Anarchists uncover better ways of developing software

by doing it and helping others do it. They have come to value 12 Agile
Principles.
--Kent Beck, Mike Beedle, Are van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew
Hunt, Ron Jefferies, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
(www.AgileAlliance.org)

19
 The Agile Manifesto
12 Agile Principle
1. The highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference for the shorter timescale.
4. Businesspeople and developers work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
20
 The Agile Manifesto
12 Agile Principle
7. Working software is the primary measure of progress
8. Continuous attention to technical excellence and good design enhances
agility.
9. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
10. Simplicity—the art of maximizing the amount of work not done—is
essential.
11. The best architectures, requirements, and designs emerge from self-
organizing teams.
12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

21
 Agile Methodologies—Not for
Every Project
• Agile methodologies are not for everyone
• Fowler recommends an agile process if your project involves
• unpredictable or dynamic requirements
• responsible and motivated developers
• customers who understand the process and will get involved

22
 Five Critical Factors that Distinguish Agile and 23

Traditional Approaches to System Development

Factor Agile Methods Traditional Methods
Size Well-matched to small products and teams Methods evolved to handle large products and
Reliance on tacit knowledge limits scalability teams Hard to tailor down to small products

Criticality Untested on safety-critical products Methods evolved to handle highly critical products
Potential difficulties with simple design and lack Hard to tailor down to products that are not critical.
of documentation
Dynamism Simple design and continuous refactoring Detailed plans and Big Design Up Front, are
are excellent for highly dynamic environments excellent for a highly stable environment but a
but a source of potentially expensive rework for source of expensive rework for highly dynamic
highly stable environments environments

Personnel Requires continuous presence of a critical mass Needs a critical mass of scarce experts during
of scarce experts. Risky to use non-agile people project definition but can work with fewer later in the
project, unless the environment is highly dynamic
Culture Thrives in a culture where people feel Thrives in a culture where people feel comfortable
comfortable and empowered by having many and empowered by having their roles defined by
degrees of freedom (thriving on chaos) clear practices and procedures (thriving on order)
 Agile in Practice
• Three primary factors critical for success
• Delivery strategy: Continuous delivery of working software in
short time scales
• Following agile software engineering practices
• Team capability: Agile principle of building projects around
motivated individuals
• Agile development offers managers and programmers more
choices in their efforts to produce good systems that come in on
time and under budget
24
 eXtreme Programming
o Short, incremental development cycles
o Focus on automated tests written by
programmers
o Emphasis on two-person programming teams
o Customers to monitor the development
process
o Relevant parts of eXtreme Programming that
relate to design specifications are
1. How planning, analysis, design, and
construction are all fused into a single
phase of activity
2. It’s unique way of capturing and presenting
system requirements and design
25 specifications
 eXtreme Programming
oCoding and testing are related parts of the same process
oAdvantages include
• Increased communications among developers
• Higher levels of productivity
• Higher quality code
• Reinforcement of other practices in eXtreme Programming
• Include code-and-test discipline
26
 SCRUM
• Originated in 1995 by Sutherland and
Schwaber
• Most popular methodology for agile (58%)
• Scrum framework includes
• Scrum teams with associated roles,
events, artifacts, and rules
• Each team consists of three roles
• Product owner
• Development team
• Scrum master
27
 SCRUM oScrum designed for speed and
multiple functional product
releases
oPrimary unit is the Sprint (runs two
weeks to a month)
oStarts with an eight-hour Sprint
planning meeting
oWhat needs to be delivered
by the end of the sprint
oHow will the team
accomplish that work
oDaily Standup: A 15-minute
meeting held to evaluate
progress made within the past
24 hours and what needs to be
done
28
 • At the end of the sprint, two additional
SCRUM meetings
• The Sprint Review: (4 hours)
focusing on the product, what has
been accomplished, and what
needs to be done
• The Sprint Retrospective: (3 hours)
focusing on team performance
and how it can improve
• Three primary artifacts in the Scrum
process
1. Product Backlog: Listing of
potential requirements
2. Sprint Backlog: Listing of only
items to be addressed in a
particular sprint
3. Increment: Represents the sum of
all the Product Backlog items
completed during a sprint.

29
 Object-Oriented Analysis and
Design (OOAD)
oBased on objects rather than data or processes
oCombines data and processes (called methods) into single entities call
objects
oObject: A structure that encapsulates attributes and methods that operate
on those attributes
oInheritance: Hierarchical arrangement of classes enabling subclasses to
inherit properties of superclasses
oObject Class: Logical grouping of objects that have the same attributes and
behaviors

30
 Relational Unified Process (RUP)

o Relational Unified Process (RUP) is an object-

oriented systems development methodology
o Based on an iterative, incremental approach to
systems development
o RUPs four phases (each can be further divided)
o Inception
o Elaboration
o Construction
o Transition

31
 Other Approach to System Development
In recent years, several software development methodologies have emerged beyond Agile and
Waterfall, reflecting the evolving needs of the industry.

DevOps is more of a culture or a set of practices rather than a formal methodology. It emphasizes
collaboration between development (Dev) and operations (Ops) teams to automate and streamline the
software delivery process.
Key Principles:
• Continuous Integration/Continuous Deployment (CI/CD)
• Infrastructure as Code (IaC)
• Monitoring and Logging
• Collaboration and Communication
Benefits: Faster delivery of software, improved quality, reduced time to market, and more reliable
releases.

32
33
Roles and Responsibilities of participants in SDLC
Roles Responsibilities
Project Manager • Overseeing the entire project from inception to completion.
(PM) • Managing resources, timelines, and budgets.
• Ensuring that the project meets its objectives and is delivered on time.
• Coordinating communication between the team, stakeholders, and clients.
• Managing risks and issues that arise during the development process.

Business • Gathering and analyzing business requirements.

Analyst (BA) • Translating business needs into functional specifications.
• Acting as a liaison between stakeholders and the development team.
• Ensuring that the final product aligns with business goals.

System • Designing the overall system architecture.

Architect • Ensuring that the system meets the required performance, security, and scalability standards.
• Selecting the appropriate technologies and frameworks for development.
• Providing technical guidance to the development team.

Development • Writing code according to the specifications provided.

Team • Implementing the software design, including both the front-end and back-end.
• Conducting unit testing to ensure that individual components work as expected.
• Collaborating with other team members to integrate different modules.
Quality Assurance • Developing and executing test plans and cases.
(QA) Team • Performing various types of testing, such as functional, integration, system, and regression testing.
• Identifying, documenting, and tracking defects.
34 • Ensuring that the software meets the required quality standards before release.
Roles and Responsibilities of participants in SDLC
Roles Responsibilities
UI/UX Designer • Designing the user interface and user experience for the software.
• Creating wireframes, mockups, and prototypes.
• Ensuring that the design is user-friendly and meets accessibility standards.
• Collaborating with developers to ensure the design is implemented correctly.
DevOps • Managing the deployment, automation, and maintenance of the development, testing, and
Engineer production environments.
• Implementing Continuous Integration/Continuous Deployment (CI/CD) pipelines.
• Monitoring system performance and ensuring uptime.
• Managing infrastructure as code and ensuring security and compliance.
Database • Designing, implementing, and maintaining the database systems.
Administrator • Ensuring data integrity, security, and availability.
(DBA) • Optimizing database performance and performing regular backups.
• Collaborating with developers to integrate the database with the application.
End Users • Providing feedback during the design and testing phases.
• Participating in user acceptance testing (UAT) to ensure the product meets their needs.
• Using the final product and reporting any issues or enhancement requests.
Stakeholders • Providing input on the project’s requirements and objectives.
• Reviewing progress and making key decisions throughout the SDLC.
• Approving the final product before release.
35
 Roles of an Information System Engineer
An Information Systems Engineer (ISE) plays a crucial role in designing, developing, managing, and
optimizing information systems that meet the needs of an organization. The role combines technical
expertise with an understanding of business processes to ensure that technology solutions align with
organizational goals

….not a job title, but a role that people play:

36
 Summary

In this chapter you learned how to:

• Define Information Systems Engineering

• Define Information System Analysis and Design
• Describe the Systems Development Life Cycle (SDLC)
• Describe the System Development Methodologies such as agile
methodologies, eXtreme Programming, Scrum, and RUP
• Describe the roles and responsibilities of participants in SDLC

37
Topic 2
The Origins of Software

ISP550
INFORMATION SYSTEMS
ENGINEERING

1
 Learning Objectives

• Explain outsourcing
• Describe six different sources of software
• Discuss how to evaluate off-the-shelf software
• Explain reuse and its role in software development

2
 Introduction

• In the past software development for

organizations was done mostly in-house and
from scratch
• Today, there are many different sources of
software
• Now focus is on where you can obtain the
many pieces and components that you will
combine into an application that you have
been asked to create

3
 Outsourcing
• Outsourcing – turning over responsibilities for some or all of an
organization’s information systems applications and operations to
an outside firm
• Reasons for outsourcing:
• Freeing up internal resources
• Increasing the revenue potential of the organization
• Reducing time to markets
• Increasing process efficiencies
• Outsourcing non-core activities
4
 Sources of Software

• Sources of software can be

categorized into six major groups:
• Information technology services firms
• Packaged software producers
• Enterprise solutions software
• Cloud computing
• Open-source software
• In-house development

5
 Information Technology Service Firms

• IT service firms help companies develop customer

information systems for internal use
• These firms employ skilled IT people
• Some examples of these companies are seen in the table
2-1

6
Table 2-1: Leading Software Firms and Their
Development Specializations
Specialization Example Firms or Websites
IT Services Accenture
Computer Sciences Corporation (CSC)
IBM
HPE
Packaged Software Providers Intuit
Microsoft
Oracle
SAP AG
Symantec
Enterprise Software Solutions Oracle
SAP AG
Cloud Computing Amazon.com
Google
IBM
Microsoft
Salesforce.com
Open Solution SourceForge.net
Package Software Producers

• Serve many market segments

• Prepackaged software is off-the-shelf and is not
customizable
• Examples include Quicken, QuickBooks, Microsoft Word,
TurboTax
• Meets 70% of an organization’s needs
• An example of Microsoft Word is on the next slide
Figure 2-2: Document Created in Microsoft Word

(Source: Microsoft Corporation)

Enterprise Solutions Software

• Enterprise resource planning (ERP) systems integrate

individual traditional business functions into a series of modules
so that a single transaction occurs seamlessly within a single
information system rather than several separate systems
• Benefits include:
• A single repository resulting in more consistent and accurate
data
• Less maintenance
• SAP AG is the leading vendor of ERP systems
Cloud Computing (1 of 2)

• Cloud computing – the provision of computing

resources, including applications, over the Internet, so
customers do not have to invest in the computing
infrastructure needed to run and maintain the resources
• Users pay on a per-use system or license the software
• Global market, based on cloud computing, is estimated at
$209.2 billion and estimated to grow to $383.3 billion by
2020
Cloud Computing (2 of 2)

• Cloud computing examples include:

• Google docs, Sheets, and Slides
• Share, create docs, spreadsheets, presentations
• SalesForce.com (Customer relationship management)
• Allows software as a service (SaaS)
• Benefits include:
• Freeing internal staff
• Faster access to applications
• Lower-cost to corporate-quality applications
• Concerns include security and reliability
Figure 2-3: Presentation Edited in Google Slides

(Source: Reprinted by permission from Joey F. George)

Open-Source Software

• Freely available, including source code

• Developed by a community of interested people
• Performs the same functions as commercial software
• Examples: Linux, mySQL, Firefox
• Two ways to make money with open-source software:
• Provide maintenance and services
• Sell a more full-featured version of the free software
In-House Development

• Involves using an organization’s staff to create systems

• Can lead to more maintenance needs
• Not unusual to incorporate a hybrid of in-house and
purchased components as seen in the table on the next
slide
Table 2-2: Comparison of Six Different Sources of
Software Components
When to Go to This Type of Internal Staffing
Producers Organization for Software Requirements
IT services firms When task requires customer Internal staff may be needed
support and system can’t be build depending on application
internally or system needs to be
sourced
Packaged software When supported task is generic Some IS and user staff to define
producers requirements and evaluate
packages
Enterprise-wide For complete systems that cross Some internal staff necessary
solutions vendors functional boundaries but mostly need consultants
Cloud computing For instant access to an application; Few; frees up staff for other IT
when supported task is generic work
Open-source When supported task is generic but Some IS and user staff to define
software cost is an issue requirements and evaluate
packages
In-house developers When resources and staff are Internal staff necessary though
available, and system must be built staff size may vary
from scratch
 Choosing Off-the-Shelf Software

• Criteria to consider when choosing off-the shelf software:

• Cost (compare developing in-house v s. purchasing or licensing the software
ersu

package)
• Functionality (the tasks that the software can perform and the mandatory,
essential, and desired system features)
• Vendor Support (can vendor provide support and how much it can provide)
• Flexibility (the ease with which software is customized)
• Documentation (understandable and up-to-date user’s manual and technical
documentation)

17
 Validating Purchased Software Information

• Request for Proposal (RFP) – document provided to vendors

asking them to propose hardware and system software that will
meet the requirements of a new system
• If soliciting RFPs from more than one vendor be sure to:
• Create a scoring value for each item requested
• Calculate a total score for each vendor after RFPs are received
• Select a vendor with a high score

18
 Reuse

• Reuse – the use of previously written software resources, especially objects and
components, in new applications
• Reuse is commonly applied to two different development technologies:
• Object-oriented development
• Object class encapsulates data and behavior of common organizational
entities (e.g. employees)
• Component-based development
• Components can be as small as objects or as large as pieces of software
that handle single business functions

19
 Reuse

• Reuse has become a standard part of corporate development

• Factors relating to successful reuse include:
• Knowledge of the domain in which reuse is to occur
• Customer support
• Commitment and understanding of senior management
• Sound organizational processes
• Skilled and experienced developers

20
Figure 2-4: Investments Necessary to Achieve
Reusable Components

(Source: Royce, Walker, Software Project Management: A Unified Framework, 1 st ed., ©1998. Reprinted and
Electronically reproduced by permission of Pearson Education, Inc. Upper Saddle River, New Jersey)
Three Basic Steps of Software Reuse

1. Abstraction
▹Involves design of reusable software
2. Storage
▹ Making software assets available for others to use

3. Recontextualization
▹Making the software understandable to developers

Grinter, 2001
 Approaches to Reuse

• Ad-hoc – Individuals are free to find or develop reusable assets on

their own
• Facilitated – developers are encouraged to practice reuse
• Managed – the development, sharing, and adoption of reusable
assets is mandated
• Designed – assets mandated for reuse as they are being designed
for specific applications

23
Table 2-3: Four Approaches to Reuse
Approach Reuse Level Cost Policies and Procedures
Ad hoc None to low Low None
Facilitated Low Low Developers are encouraged to reuse but
are not required to do so
Managed Moderate Moderate Developers, sharing, and adoption of
reusable assets are mandated;
organizational policies are established for
documentation, packaging, and
certification
Designed High High Reuse is mandated; policies are put into
place so that reuse effectiveness can be
measured; code must be designed for
reuse during initial development,
regardless of the application it is originally
designed for; there may be a corporate
office for reuse
(Source: Based on Griss, 2003.)
 Summary

• In this chapter you learned how to:

• Explain outsourcing
• Describe six different sources of software
• Discuss how to evaluate off-the-shelf software
• Explain reuse and its role in software development

25
Topic 3
Managing Information Systems Project

ISP550
INFORMATION SYSTEMS
ENGINEERING

1
 Learning Objectives

• Explain the process of managing an information systems project, including project

initiation, project planning, project execution, and project closedown
• Describe how to represent and schedule project plans using Gantt charts and
network diagrams
• Explain how commercial project management software packages can be used to
assist in representing and managing project schedules

2
 Introduction
• Project Management (PM) is:
– the application of knowledge, skills, tools and techniques
to project activities to meet project requirements.
• arguably the most important aspect of an information
systems development project
• Effective PM helps to ensure that systems development
projects:
– Meet customer expectations
– Are completed on time and within budget
• Focus has changed to the implementation of packaged
software or ERP solutions

3
 Why develop systems?

• Problems, either real or anticipated, that require corrective action

• Opportunities to improve a situation despite the absence of complaints
• Directives to change a situation regardless of whether anyone has
complained about the current situation

4
 Reasons for Project Failures

5
 Managing the Information Systems
Project
• Project manager – systems analyst with a diverse set of
skills—management, leadership, technical, conflict
management, and customer relationship—who is
responsible for initiating, planning, executing, and closing
down a project.
• Project – planned undertaking of related activities to reach
an objective that has a beginning and an end
• Deliverable – an end product of an SDLC phase

6
 Figure 3-1: A Project Manager Juggles
Numerous Activities

(Source: Media Bakery13/Shutterstock)

7
 Table 3-1: Common Activities and
Skills of a Project Manager
Activity Description Skill
Leadership Influencing the activities of others Communications; liaison between management, users, and
toward the attainment of a common developers; assigning activities; monitoring progress
goal through the use of intelligence,
personality, and abilities
Management Getting projects completed through Defining and sequencing activities; communicating
the effective utilization of resources expectations; assigning resources to activities; monitoring
outcomes
Customer Working closely with customers to Interpreting system requests and specifications; site
relations ensure that project deliverables preparation and user training; contact point for customers
meet expectations
Technical Designing and sequencing activities Interpreting system requests and specifications; defining
problem solving to attain project goals activities and their sequence; making trade-offs between
alternative solutions; designing solutions to problems
Conflict Managing conflict within a project Problem solving; smoothing out personality differences;
management team to assure that conflict is not compromising; goal setting
too high or too low
Team Managing the project team for Communication within and between teams; peer evaluations;
management effective team performance conflict resolution; team building; self-management
Risk and change Identifying, assessing, and Environmental scanning; risk and opportunity identification and
management managing the risks and day-to-day assessment; forecasting; resource redeployment
changes that occur during a project

8
 Project Management

• Project Management – controlled process of initiating,

planning, executing, and closing down a project
• Phases of project management:
– Initiating
– Planning
– Executing
– Closing down

9
10
 Initiating the Project
• Project initiation – first phase
of the project management
process in which activities are
performed to assess the size,
scope, and complexity of the
project and to establish
procedures to support later
project activities

11
 12

Figure 3-2: Six Project Initiation

Activities
13
 Planning the Project

• Project planning – the second phase of the project

management process that focuses on defining clear,
discrete activities and the work needed to complete
each activity within a single project
• Work breakdown structure – the process of dividing
the project into manageable tasks and logically
ordering them to ensure a smooth evolution between
tasks
• Gantt chart – graphical representation of a project
that shows each task as a horizontal bar whose
length is proportional to its time for completion

14
 Figure 3-3: Ten Project Planning
Activities

15
 Figure 3-4: Gantt Chart Showing Project
Tasks, Duration Times for Those Tasks,
and Predecessors

(Source: Microsoft Corporation)

16
 Developing a Communication Plan
• Who are the stakeholders for this project?

• What information does each stakeholder need?

• When does the information need to be produced?

• What sources will be used to gather this information?

• Who will collect, store, and verify the accuracy of the info?

• Who will organize and package this info into a document?

• Who is the contact person for each stakeholder?

• What format will be used to package this information?

• What communication medium should be used?

17
 Executing the Project

• Project execution – the third

phase of the project
management process, in
which the plans created in the
prior phase (project initiation
and planning) are put into
action

18
 Figure 3-5: Five Project Execution
Activities

19
 Figure 3.6 – The Project Life Cycle
(PLC) and the Systems Development
Life Cycle (SDLC)

20
 Closing Down the Project

• Project closedown –
final phase of the
project management
process, which
focuses on bringing a
project to an end

21
 Figure 3-7: Three Project Closedown
Activities

22
 Using Project Management Software

• Many powerful software tools exist for assisting with

project management
• Microsoft Project is an example that can be used to:
– Establish a project starting or ending date
– Enter tasks and assign task relationships
– Select a scheduling method to review project reports

https://mopinion.com/top-20-best-project-management-software-an-
overview/#:~:text=Project%20Management%20Software%20is%20software,documentation%20exchanged%
20throughout%20a%20project.

23
 Figure 3-8: Establishing a Project
Starting Date in Microsoft Project

24
 Figure 3-9: Entering Tasks and Assigning
Task Relationships in Microsoft Project

25
 Figure 3-10: Viewing Project Information as
a Network Diagram in Microsoft Project

(Source: Microsoft Corporation)

26
 Figure 3-11: Gantt Chart Showing
Progress of Activities (Right Frame)
Versus Planned Activities (Left Frame)

(Source: Microsoft Corporation)

27
 Summary

• In this chapter you learned to:

• Explain the process of managing an information systems
project, including initiation, project planning, project
execution, and project closedown
• Describe how to represent and schedule project plans
using Gantt charts and network diagrams
• Explain how commercial project management software
packages can be used to assist in representing and
managing project schedules
28
Topic 4
Project Planning and Initiation

ISP550
INFORMATION SYSTEMS
ENGINEERING

1
 Learning Objectives
• Describe the project identification and selection process
• Describe the steps involved in the project initiation and planning process
• List and describe various methods for assessing project feasibility
• Describe the classes of Internet electronic commerce applications:
business-to-consumer, business-to-employee, and business-to-
business

2
 Figure 3.6 – The Project Life Cycle (PLC) and
the Systems Development Life Cycle (SDLC)

Figure From
the previous
topic

3
Introduction
• Obtaining integrated, enterprise-wide computing presents
significant challenges for both corporate and information
system management
• The acquisition, development, and maintenance of
information systems consume resources for most
organizations
• This leads to the need to have a formal process for
identifying and selecting projects

4
 5

Figure 4-1: Systems Development Life Cycle with Project

Identification and Selection Highlighted
1. Identifying and Selecting Systems
Development Projects

• Identifying and selecting systems development projects is

part of the first phase (Planning) of the SDLC
• Many firms follow a very formal process for selecting
projects
• Requests come from a variety of sources:
– By managers needing to replace aging existing
systems
– By managers wanting to make a system more efficient
– By managers needing a new system

6
Identifying and Selecting Projects (1 of 3)

• Project identification and selection consists of three

primary activities:
1. Identifying potential development projects
▪ By key member of top management
▪ By steering committee (top-down source)
▪ By user departments (bottom-up source)
▪ By development group or senior IS manager

7
 8

Identifying and Selecting Projects (2 of 3)

2. Classifying and ranking IS development projects

• Using value chain analysis or other evaluation
criteria
• Value chain analysis – used in analyzing an
organization’s activities to determine where
value is added to products and/or services
and the costs incurred for doing so; it usually
also includes a comparison with the activities,
added value, and costs of other organizations
for the purpose of making improvements in
the organization’s operations and
performance
 9

Identifying and Selecting Projects (3 of 3)

3. Selecting IS development projects
Selection Method Characteristics
Top Management Greater strategic focus
Largest project size
Longest project duration
Enterprise-wise consideration
Steering Committee Cross-functional focus
Greater organizational change
Formal cost-benefit analysis
Larger and riskier projects
Functional Area Narrow, nonstrategic focus
Faster development
Fewer users, management layers, and business functions involved
Development Group Integration with existing systems focus
Fewer development delays
Less concern with cost-benefit analysis

Table 4-1: Characteristics of Alternative Methods for Making Information Systems

Identification and Selection Decisions
 10

Table 4-2: Possible Evaluation Criteria When Classifying and Ranking

Projects
Evaluation Criteria Description
Value Chain Analysis Extent to which activities add value and costs when developing
products and/or services
Strategic Alignment Extent to which the project is viewed as helping the organization
achieve its strategic objectives and long-term goals

Potential Benefits Extent to which the project is viewed as improving profits, customer
service, and so forth, and the duration of these benefits

Resource Availability Amount and type of resources the project requires and their
availability
Project Size/Duration Number of individuals and the length of time needed to complete
the project
Technical Difficulty/Risks Level of technical difficulty to successfully complete the project
within given time and resource constraints
 11

Figure 4-1: Organizations Can Be Thought of as a Value

Chain, Transforming Raw Materials into Products for
Customers

(Sources: Left to right: Bram van Broekhoven/Shutterstock; Alexey Fursov/Shutterstock; Hacohob/Shutterstock; Syda
Productions/Shutterstock)
 12

Figure 4-2: Project Selection Decisions Must Consider

Numerous Factors and Can Have Numerous Outcomes
 13

Table 4-3: Elements of Project Initiation

Elements of Project Initiation

• Establishing the project initiation team
• Establishing a relationship with the customer
• Establishing the project initiation plan
• Establishing management procedures
• Establishing the project management environment and
project workbook
• Developing the project charter
#Refer Topic 3, slide 12
 14

Table 4-4: Elements of Project Planning

Elements of Project Planning
• Describing the project scope, alternatives, and feasibility
• Dividing the project into manageable tasks
• Estimating resources and creating a resource plan
• Developing a preliminary schedule
• Developing a communication plan
• Determining project standards and procedures
• Identifying and assessing risk
• Creating a preliminary budget
• Developing the project scope statement
• Setting a baseline project plan
#Refer Topic 3, slide 15
 15

Deliverables and Outcomes (1 of 2)

• Business case – justification for an information system,
presented in terms of the tangible and intangible economic
benefits and costs and the technical and organizational feasibility
of the proposed system
• Baseline Project Plan (BPP) – major outcome and deliverable
from the project initiation and planning phase that contains the
best estimate of a project’s scope, benefits, costs, risks, and
resource requirements
• Project Scope Statement (PSS) – a document prepared for the
customer that describes what the project will deliver and outlines
generally at a high level all work required to complete the project
 16

2. Initiation and Planning Projects

• When does project initiation and planning (PIP) end
and execution begin?
• Three important questions must be considered when
making this decision:
• How much effort should be expended on the
project initiation and planning phase?
• Who is responsible for performing the project
initiation and planning process?
• Why is project initiation and planning such a
challenging activity?
 17

Assessing Project Feasibility

• Most feasibility factors are represented by the
following categories:
1. Economic
2. Technical
3. Operational
4. Scheduling
5. Legal and contractual
6. Political
 18

Assessing Economic Feasibility

• Economic feasibility – process of identifying the financial
benefits and costs associated with a development project
• Tangible benefit – benefit from the creation of an information
system that can be measured in dollars and with certainty
• Most tangible benefits:
• Cost reduction and avoidance
• Error reduction
• Increased flexibility
• Increased speed of activity
• Improvement of management planning and control
• Opening new markets and increasing sales opportunities
• Intangible benefit – benefit derived from the creation of an
information system that cannot be easily measured in dollars or
with certainty (See Table 4-5)
 19
Table 4-5: Intangible Benefits from the
Development of an Information System
Intangible Benefits from the Intangible Benefits from the
Development of an IS Development of an IS
• Competitive necessity • More confidence in decision quality
• More timely information • Improved processing efficiency
• Improved organizational planning • Improved asset utilization
• Increased organizational flexibility • Improved resource control
• Promotion of organizational learning • Increased accuracy in clerical
and understanding operations
• Availability of new, better, or more • Improved work process that can
information improve employee moral or customer
satisfaction
• Ability to investigate more alternatives • Positive impacts on society
• Faster decision making • Improved social responsibility
• Better usage of resources (“greener”) Blank

(Source: Based on Parker & Benson, 1988; Brynjolfsson & Yang, 1997; Keen, 2003; Cresswell, 2004)
 20

Assessing Technical Feasibility

• Technical feasibility – process of assessing the
development organization’s ability to construct a proposed
system
• Potential consequences of not accessing and managing
risks can include the following:
• Failure to attain expected benefits from the project
• Inaccurate project cost estimates
• Inaccurate project duration estimates
• Failure to achieve adequate system performance levels
• Failure to adequately integrate the new system with
existing hardware, software, organizational procedures
 21

Assessing Other Feasibility Concerns

• Operational feasibility – process of assessing the degree to
which a proposed system solves business problems or takes
advantage of business opportunities
• Schedule feasibility – process of assessing the degree to which
the potential time frame and completion dates for all major
activities within a project meet organizational deadlines and
constraints for affecting change
• Legal and contractual feasibility – process of assessing potential
legal and contractual ramifications due to the construction of a
system
• Political feasibility – process of evaluating how key stakeholders
within the organization view the proposed system
ELECTRONIC COMMERCE APPLICATIONS:
IDENTIFYING AND SELECTING SYSTEMS DEVELOPMENT
PROJECTS

• Identifying and selecting systems development

projects for an Internet-based electronic commerce
application is no different from the process followed
for more traditional applications.
• Nonetheless, there are some special considerations
when developing an Internet-based application.
• In this section, we highlight some of those issues
that relate directly to the process of identifying and
selecting Internet-related systems development
projects.

22
 23

Internet Basics

• Internet – large, worldwide network of networks that use

a common protocol to communicate with each other
• Internet of Things (IoT) – broad class of physical objects
that feature an Internet address and connectivity that
communicate between these objects and other Internet
enabled devices and systems
• Electronic commerce (EC) – Internet-based
communication to support day-to-day government,
business, and consumer activities
 24

EC Business Models
• A broad range of business models include:
• Business-to-Business (B2B)
• Business-to-Consumer (B2C)
• Consumer-to-Consumer (C2C)
• Consumer-to-Business (C2B)
• Business-to-Government (B2G)
• Government-to-Business (G2B)
• Government-to-Citizen (G2C)
• Thing-to-Thing (T2T)
 25

Figure 4-3: The Internet of Everything

 26

Table 4-6: Unknowns That Must Be Dealt with When

Designing and Building Internet Applications

Factor Unknowns That Must Be Dealt With

User • Concern: Who is the user?
• Example: Where is the user located? What is the user’s
expertise or education? What are the user’s
expectations?
Connection Speed • Concern: What is the speed of the connection and
what information can be effectively transported?
• Example: WiFi, cellular
Access Method • Concern: What is the connection device?
• Example: Web browser, tablet, smartphone, smart
watch
27
 Summary

In this chapter, you learned to:

• Describe the project identification and selection process
• Describe the steps involved in the project initiation and planning
process
• List and describe various methods for assessing project feasibility
• Describe the classes of Internet electronic commerce applications:
business-to-consumer, business-to-employee, and business-to-
business
28
Topic 5
Requirements Elicitation

ISP550
INFORMATION SYSTEMS
ENGINEERING

1
 Learning Objectives
• Define Requirements and Requirements Engineering
• Describe Requirements Engineering Activities
• Describe traditional and contemporary requirements elicitation
techniques
• Document workflows with activity diagram
• Describe the types of requirements

2
http://www.cvr-it.com/images/PM_Build_Swing.gif

Requirements are considered

as an input to design,
implementation and
validation phase of software
product development.

Thus, a software project is

successful or a failure during
software development
because of poor requirement
elicitation as well as in
requirements managing
process (Pfleeger and Atlee,
2006).

In summary, there are many reasons for software project failures; however, poorly engineered requirements process
contributes immensely to the reason why software projects fail (Inam, 2015).
Definition of Requirements &
Requirements Engineering

Requirements:
A condition or capability needed by a user to solve a
problem or achieve an objective.

Requirements Engineering:
A systematic and disciplined approach to the
specification and management of requirements
Requirements Engineering Activities
• The activities used for Requirements Engineering vary
widely depending on the application domain, the
people involved and the organisation developing the
requirements.
• However, there are a number of generic activities
common to all processes
• Requirements elicitation;
• Requirements analysis;
• Requirements validation;
• Requirements management.
• In practice, RE is an iterative activity.
A Spiral View of the RE Process
Traditional Methods of Eliciting Requirements
Traditional Methods of Eliciting Requirements
• Individually interview people informed about the operation and
issues of the current system and future systems needs
• Interview groups of people with diverse needs to find synergies
and contrasts among system requirements
• Observe workers at selected times to see how data are handled
and what information people need to do their jobs
• Study business documents to discover reported issues, policies,
rules, and directions as well as concrete examples of the use of
data and information in the organization
• Distributing questionnaire
Contemporary Methods of Eliciting Requirements

Contemporary Methods of Eliciting Requirements

Bringing session users, sponsors, analysts, and others
together in a J A D session to discuss and review system
requirements
Iteratively developing system prototypes that refine the
understanding of system requirements in concrete terms by
showing working versions of system features

A JAD is a Joint Application Development (or Design) session. It is an

opportunity for stakeholders with different points of view to come together to
understand business requirements and brainstorm what the best technical
approach might be for meeting the customer's needs.
Requirements Elicitation

Problems discovered during Requirements Elicitation

• Problems of scope: The boundary of system is ill-

defined. Or unnecessary details are provided.
• Problems of understanding: The users are not sure
of what they need, and don’t have full
understanding of the problem domain.
• Problems of volatility: the requirements change
overtime.
 Requirements Elicitation
• Guidelines of Requirements Elicitation
• Assess the business and technical feasibility for the proposed system
• Identify the people who will help specify requirements.
• Define the technical environment (e.g. computing architecture,
operating system, telecommunication needs) into which the system
or product will be placed
• Identify “domain constraints” (i.e. characteristics of the business
environment specific to the application domain) that limit the
functionality or performance of the system or product to build
• Define one or more requirements elicitation methods (e.g.
interviews, team meetings, ..etc)
• Solicit participation from many people so that requirements are
defined from different point of views.
• Create usage scenarios of use cases to help customers/ users better
identify key requirements.
Interviewing
• Formal or informal interviews with stakeholders are part of
most requirements elicitation processes.
• Types of interview
• Closed interviews based on pre-determined list of
questions
• Open interviews where various issues are explored with
stakeholders.
• Effective interviewing
• Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
• Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by
working together on a prototype system.
Interviewing Users and Other Stakeholders

• Prepare detailed questions

• Meet with individuals or groups of users
• Obtain and discuss answers to the questions
• Document the answers
• Follow up as needed in future meetings or
interviews
Themes for Information Gathering Questions
Preparing for Interview
Interview
Session
Agenda
Interviews in Practice
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall understanding of
what stakeholders do and how they might interact with the
system.
• Interviews are not good for understanding domain
requirements
1. Requirements engineers cannot understand specific
domain terminology;
2. Some domain knowledge is so familiar that people
find it hard to articulate or think that it isn’t worth
articulating.
Distribute and
Collect
Questionnaires
Review Inputs, Outputs, and Procedures
An Invoice Form from Microsoft Excel

(Source: Microsoft Corporation)

Comparison of Observation and Document Analysis
Characteristic Observation Document Analysis
Information High (many channels) Low (passive) and old
Richness
Time Required Can be extensive Low to moderate
Expense Can be high Low to moderate
Chance for Follow- Good: probing and clarification Limited: probing possible only if
Up and Probing questions can be asked during or after original author is available
observation
Confidentiality Observee is known to interviewer; Depends on nature of document; does
observee may change behavior when not change simply by being read
observed
Involvement of Interviewees may or may not be involved None, no clear commitment
Subject and committed depending on whether
they know if they are being observed
Potential Audience Limited numbers and limited time Potentially biased by which documents
(snapshot) of each were kept or because document was
not created for this purpose
Documenting Workflows with Activity Diagrams

• Workflow– sequence of processing steps that completely

handles one business transaction or customer request
• Activity Diagram– describes user (or system) activities, the
person who does each activity, and the sequential flow of
these activities
• Useful for showing a graphical model of a workflow
• A UML diagram
Activity Diagrams Symbols
Activity
diagram
example (1)
Activity diagram example (2)
Types of Requirements (1/2)

• Functional Requirements:
• Defines functions of a software system or its
components. They may be calculations,
technical details, data manipulation and
processing and other specific functionality that
define “what a system is supposed to
accomplish?”
• They describe particular results of a system.
• Functional requirements are supported by Non-
functional requirements.
Types of Requirements (2/2)
• Non-Functional Requirements:
• They are requirements that specify criteria that can be used
to judge the operation of a system, rather than specific
behavior.
• Functional requirements define what the system is
supposed to do, whereas non-functional requirements
define how a system is supposed to be.
• Non-functional requirements can be divided into two main
categories:
• Execution qualities, such as security and usability, which
are observable at runtime.
• Evolution qualities, such as testability, maintainability
and scalability.
FURPS+ Requirements Acronym

Functional requirements
Usability requirements
Reliability requirements
Performance requirements
Security requirements
+ even more categories…
FURPS+ Requirements Acronym
 Summary

In this chapter, you learned to:

• Define Requirements and Requirements Engineering
• Describe Requirements Engineering Activities
• Describe traditional and contemporary requirements elicitation
techniques
• Document workflows with activity diagram
• Describe the types of requirements

29
Topic 6
Requirements Analysis & Modelling (I)

ISP550
INFORMATION SYSTEMS
ENGINEERING
 Learning Objectives
• Explain why identifying use cases is the key to defining functional
requirements
• Describe the two techniques for identifying use cases
• Apply the user goal technique to identify use cases
• Apply the CRUD technique to validate and refine the list of use cases
• Describe the notation and purpose for the use case diagram
• Draw use case diagrams by actor and by subsystem
• Write fully developed use case descriptions
• Develop activity diagrams to model flow of activities

2
Overview

• Students have been exposed to two types of

requirements, i.e. Functional & Non-functional
requirements (refer to previous lecture)
• This topic focuses on identifying and modelling the
key aspect of functional requirements– use cases

3
Overview
• A use case might have different flow of activities, depending
on the actor invoking the use case
• These flow of activities are called scenarios or use case
instances
• A use case description is a textual model that list and
describes the processing details for a use case
• Brief description
• Fully developed description

4
Use Cases
• Use case — an activity that the system performs,
usually in response to a request by a user
• It shows how a user uses the system
• Use cases define functional requirements
• Analysts decompose the system into a set of use
cases (functional decomposition)
• Two techniques for Identifying use cases
• User goal technique
• Event decomposition technique (not emphasised in this
class)
• Name each use case using Verb-Noun
5
User Goal Technique
• This technique is the most common in industry
• Simple and effective
• Identify all the potential categories of users of the
system
• Interview and ask them to describe the tasks the
computer can help them with
• Probe further to refine the tasks into specific user
goals, “I need to Ship items, Track a shipment, Create
a return”

6
 User Goal Technique:
Specific Steps
1. Identify all the potential users for the new system
2. Classify the potential users in terms of their
functional role (e.g., shipping, marketing, sales)
3. Further classify potential users by organizational level
(e.g., operational, management, executive)
4. For each type of user, interview them to find a list of
specific goals they will have when using the new
system (current goals and innovative functions to add
value)

7
 User Goal Technique
Specific Steps (continued)
5. Create a list of preliminary use cases organized by
type of user
6. Look for duplicates with similar use case names and
resolve inconsistencies
7. Identify where different types of users need the
same use cases
8. Review the completed list with each type of user
and then with interested stakeholders

8
 Use Cases and CRUD Technique
• CRUD is Create, Read/Report, Update, and Delete
(archive)
• Often introduced in database context
• Technique to validate, refine or cross-check use
cases
• NOT for primarily identifying use cases

9
Use Cases and CRUD Technique
• For Customer domain class, verify that there are use
cases that create, read/report, update, and delete
(archive) the domain class

10
 CRUD Technique Steps
1. Identify all the data entities or domain classes involved
in the new system.
2. For each type of data (data entity or domain class),
verify that a use case has been identified that creates a
new instance, updates existing instances, reads or
reports values of instances, and deletes (archives) an
instance.
3. If a needed use case has been overlooked, add a new
use case and then identify the stakeholders.
4. With integrated applications, make sure it is clear
which application is responsible for adding and
maintaining the data and which system merely uses
the data.
11
Use Cases and
Brief Use Case Descriptions
⚫ Brief use case description is often a one
sentence description showing the main steps in a
use case
⚫ Actor (who) + Verb + Noun

12
Use Case Diagrams
⚫ Use case diagram— a Unified Modeling Language
(UML) model used to graphically show uses cases and
their relationships to actors
⚫ Recall UML is Unified Modeling Language, the
standard for diagrams and terminology for developing
information systems
⚫ Actor is the UML name for a end user
⚫ Automation boundary— the boundary between the
computerized portion of the application and the users
who operate the application

13
Use Case Diagrams Symbols

14
Use Case
Diagrams
Draw for each
subsystem

15
Use Case
Diagrams
Draw for actor,
such as customer

16
Use Case Diagram

17
Use Case Diagrams
The <<Includes>> relationship
⚫ A relationship between use cases where one use case is
stereotypically included within the other use case— like a
called subroutine. Arrow points to subroutine

18
Use Case Diagrams: Steps
1. Identify all the stakeholders and users who would
benefit by seeing a use case diagram
2. Determine what each stakeholder or user needs to
review in a use case diagram: each subsystem, for
each type of user, for use cases that are of interest
3. For each potential communication need, select the use
cases and actors to show and draw the use case
diagram. There are many software packages that can
be used to draw use case diagrams
4. Carefully name each use case diagram and then note
how and when the diagram should be used to review
use cases with stakeholders and users
19
 The Software Requirements Document
• The software requirements document is the official
statement of what is required of the system developers.
• Should include both a definition of user requirements and a
specification of the system requirements.
• It is NOT a design document. As far as possible, it should set
of WHAT the system should do rather than HOW it should do
it.
• Information in requirements document depends on type of
system and the approach to development used.
• Systems developed incrementally will, typically, have less
detail in the requirements document.
• Requirements documents standards have been designed e.g.
IEEE standard. These are mostly applicable to the
requirements for large systems engineering projects.

20
Requirements Specifications
• A Software Requirements Specification (SRS) – a
requirements specification for a software system –
is a complete description of the behavior of a
system to be developed.
• It includes a set of use cases that describe all the
interactions the users will have with the software.
• In addition to use cases, the SRS also contains non-
functional requirements (such as performance
requirements, quality standards, or design
constraints)
21
 Requirements Specifications
• A Software Requirements Specification (SRS)
• The software requirement specification document enlists all necessary
requirements for project development. To derive the requirements, we
need to have clear and thorough understanding of the products to be
developed.
• A general organization of an SRS is as follows:
• Introduction
• Purpose, Scope, Definitions, System Overview, References
• Overall Description
• Product Perspective, Product functions, User characteristics, constraints,
assumptions and dependencies.
• Specific Requirements
• External Interface requirements, functional requirements, performance
requirements, design constraints, logical database requirement, software system
attributes.

22
Users of a Requirements Document
http://cnx.org/content/m14621/latest/graphics4.jpg

23
 Use Case Descriptions
• Provide information about each use case, including actors,
stakeholders, preconditions, post conditions, the flow of activities
and exceptions conditions
• Activity diagrams can also be used to show the flow of activities for a
use case
• Brief description of use cases are shown below:

24
Use Case Descriptions
• Typical use case description templates include:
• Use case name
• Scenario (if needed)
• Triggering event
• Brief description
• Actors
• Related use cases (<<includes>>)
• Stakeholders
• Preconditions
• Post conditions
• Flow of activities
• Exception conditions

25
Fully Developed
Use Case
Description

Use case:
Create customer account

26
Fully Developed Use Case Description:
Precondition
• Preconditions
• What must be true before the use case begins
• What objects must exist, information must be available, condition of actor

27
Fully Developed Use Case Description: Post-
condition
• Post conditions
• What must be true after the use case
is completed
• What objects are created, updated;
how objects are associated
• Purpose:
• Use for planning test case expected
results
• Indicated what objects are important
during design

28
Fully Developed Use Case
Description: Flow of Activities

Sequence of steps and the response

29
Fully Developed Use Case Description
Exception/Alternative Conditions

30
Use Case UML Activity Diagram
Create
Customer
Account

Note: this
shows flow of
activities only
Another way to
document a
use case
description 31
Use Case UML Activity Diagram

Fill shopping cart

Note: this shows use
case with
<<includes>>
relationship

32
 Summary
In this chapter, you learned to:
• Explain why identifying use cases is the key to defining
functional requirements
• Describe the two techniques for identifying use cases
• Apply the user goal technique to identify use cases
• Apply the CRUD technique to validate and refine the list of use
cases
• Describe the notation and purpose for the use case diagram
• Draw use case diagrams by actor and by subsystem
• Write fully developed use case descriptions
• Develop activity diagrams to model flow of activities
33
Topic 6
Requirements Analysis & Modelling (II)

ISP550
INFORMATION SYSTEMS
ENGINEERING
 Learning Objectives

• Explain how the concept of “things” in the problem domain

also define requirements
• Identify and analyze data entities and domain classes
needed in the system
• Read, interpret, and create a domain model class diagram
• Develop system sequence diagrams

2
 Things in the Problem Domain
• Problem domain—the specific area (or domain) of
the users’ business need that is within the scope of
the new system.
• “Things” are those items users work with when
accomplishing tasks that need to be remembered
• Examples of “Things” are products, sales,
shippers, customers, invoices, payments, etc.
• These “Things” are modeled as domain classes or
data entities

In this course, we will call them domain classes. In

database class, you called them data entities
 Things in the Problem Domain
Two Techniques for Identifying them
• Brainstorming Technique
• Use a checklist of all of the usual types of things
typically found and brainstorm to identify
domain classes of each type
• Noun Technique
• Identify all of the nouns that come up when the
system is described and determine if each is a
domain class, an attribute, or not something we
need to remember
 Brainstorming Technique
• Are there any
tangible things?
• Are there any
organizational
units?
• Sites/locations?
• Are there incidents
or events that need
to be recorded?
Brainstorming Technique:
Steps
1.Identify a user and a set of use cases
2.Brainstorm with the user to identify things involved when
carrying out the use case—that is, things about which
information should be captured by the system.
3.Use the types of things (categories) to systematically ask
questions about potential things, such as the following:
• Are there any tangible things you store information about?
• Are there any locations involved?
• Are there roles played by people that you need to remember?
4.Continue to work with all types of users and stakeholders
to expand the brainstorming list
5.Merge the results, eliminate any duplicates, and compile
an initial list
The Noun Technique
• A technique to identify problem domain classes
(things) by finding, classifying, and refining a list
of nouns that come up in in discussions or
documents
• Does end up with long lists and many nouns that
are not things that need to be stored by the
system
• Difficulty in identifying synonyms and things that
are really attributes
• Good place to start when there are no users
available to help brainstorm

7
Partial List of
Nouns

With notes on
whether to include
as domain class
The Noun Technique: Steps
1.Using the use cases, actors, and other
information about the system— including inputs
and outputs—identify all nouns.

2.Using other information from existing systems,

current procedures, and current reports or forms,
add items or categories of information needed.
The Noun Technique: Steps
(continued)

3.As this list of nouns builds, refine it. Ask these questions about each
noun to help you decide whether you should include it:
1. Is it a unique thing the system needs to know about?
2. Is it inside the scope of the system I am working on?
3. Does the system need to remember more than one of these items?
Ask these questions to decide to exclude it:
1. Is it really a synonym for some other thing I have identified?
2. Is it really just an output of the system produced from other information
I have identified?
3. Is it really just an input that results in recording some other information
I have identified?
Ask these questions to research it:
1. Is it likely to be a specific piece of information (attribute) about some
other thing I have identified?
2. Is it something I might need if assumptions change?
The Noun Technique: Steps
(continued)

4. Create a master list of all nouns identified and then

note whether each one should be included, excluded,
or researched further.

5. Review the list with users, stakeholders, and team

members and then define the list of things in the
problem domain.
Details about Domain Classes
1. Attribute— describes one piece of information about
each instance of the class
• Customer has first name, last name, phone number
2. Identifier or key
• One attribute uniquely identifies an instance of the class.
Required for data entities, optional for domain classes.
Customer ID identifies a customer
3. Compound attribute
• Two or more attributes combined into one structure to simplify
the model. (E.g., address rather than including number, street,
city, state, zip separately). Sometimes an identifier or key is a
compound attribute.
Attributes and Values
⚫ Class is a type of thing. Object is a specific instance of the class.
Each instance has its own values for an attribute
Associations Among Things
• Association— a naturally occurring relationship
between classes (UML term)
Just to Clarify…
⚫ Called association on class diagram in UML
⚫ Multiplicity is term for the number of associations between classes:
1 to 1 or 1 to many
⚫ We are emphasizing UML in this text
⚫ Called relationship on ERD in database class
⚫ Cardinality is term for number of relationships in entity relationship
diagrams: 1 to 1 or 1 to many
⚫ Associations and Relationships apply in two directions
⚫ Read them separately each way
⚫ A customer places an order
⚫ An order is placed by a customer
Minimum and Maximum Multiplicity
⚫ Associations have minimum and maximum constraints
⚫ minimum is zero, the association is optional
⚫ If minimum is at least one, the association is mandatory
The Domain Model Class Diagram
⚫ Class
⚫ A category of classification used to describe a
collection of objects
⚫ Domain Class
⚫ Classes that describe objects in the problem domain

⚫ Class Diagram
⚫ A UML diagram that shows classes with attributes
and associations (plus methods if it models software
classes)
⚫ Domain Model Class Diagram
⚫ A class diagram that only includes classes from the
problem domain, no methods
Domain Class Notation
⚫ Domain class has no methods
⚫ Class name is always capitalized
⚫ Attribute names are not capitalized and use camelback
notation (words run together and second word is
capitalized)
A Simple Domain Model Class Diagram

⚫ A customer places zero or more orders

⚫ An order is placed by exactly one customer
⚫ An order consists of one or more order items
⚫ An order item is part of exactly one order
UML Notation for Multiplicity
Domain Model Class Diagram
for a bank with many branches
Domain Model Class Diagram
for course enrollment at a university

⚫ Where is each student’s grade remembered in this model?

⚫ Each section has many grades and each grade is association with a student

⚫ Each student has many grades and each grade is association with a section
 Refined Course Enrollment Model
with an Association Class CourseEnrollment
⚫ Association class— an association that is treated as a class in a
many to many association because it has attributes that need to
be remembered, such as grade

23
More Complex Issues about Classes:
Generalization/Specialization Relationships

⚫ Generalization/Specialization
⚫ A hierarchical relationship where subordinate classes are
special types of the superior classes. Often called an
Inheritance Hierarchy
⚫ Superclass
⚫ the superior or more general class in a
generalization/specialization hierarchy
⚫ Subclass
⚫ the subordinate or more specialized class in a
generalization/specialization hierarchy
⚫ Inheritance
⚫ the concept that subclasses classes inherit characteristics of
the more general superclass
Generalization/Specialization
Inheritance

25
Generalization/Specialization
Inheritance for Three Types of Sales

⚫ Abstract class— a class that allow subclasses to inherit

characteristics but never gets instantiated.
⚫ Concrete class— a class that can have instances
 Generalization/Specialization
Inheritance for the Bank with Special Types of Accounts

⚫ A SavingsAccount
has 4 attributes
⚫ A CheckingAccount
Has 5 attributes
⚫ Note: the subclasses
inherit the
associations, too
System Sequence Diagram (SSD)
• An SSD is usually used together with use case
description/activity diagram
• Use case description/activity diagram identify the flow
of activities within a use case
• However, they do not explicitly identify inputs or
outputs
• This is provided by SSD
• Use case diagram shows how actor uses the system
• System sequence diagram shows how actor interacts
with system
• Enters input data
• Receive output data

28
System Sequence Diagram (SSD)
Shows interactions
between objects
Shows the
sequence of
messages
between an
external actor and
the system

29
SSD Notation
• Actor
• :System
• Lifeline
• Message
• Note

30
SSD Notation
Loop Frame

31
SSD Notation
Loop Alternate

32
SSD Notation
Opt Frame

33
SSD Notation
Alt Frame

34
Creating an SSD

35
Recall Use
Case
Description
Create
Customer
Account

36
Recall Activity
Diagram
Create
Customer
Account

37
Steps for Developing SSD
1. Identify input message
2. Describe the message from the external actor to the system
using the message notation
3. Identify any special conditions on input messages
4. Identify and add output return values
• On message itself: aValue:= getValue(valueID)
• As explicit return on separate dashed line

38
Identify Input Message 1

39
Describe the message 2
• Verb-noun: what the
system is asked to do
• createNewCustomer()
• enterAddress()
• enterCreditCard()

• Consider parameters
the system will need
• Name, phone, emails
• Address
• Credit card information

40
Identify Special Condition 3

• Iteration/loop frame
• Opt or Alt frame

• Example- multiple addresses

41
Identify and Add 4
Output Return Values
• On message itself: aValue:= getValue(valueID)

• As explicit return on separate dashed line

42
43
Integrating requirements model

44
Integrating Requirements Models

45
 Summary
In this chapter, you learned to:
•Explain how the concept of “things” in the problem domain also
defines requirements
•Identify and analyze data entities and domain classes needed in the
system
•Read, interpret, and create a domain model class diagram
•Develop system sequence diagrams

46
Summary

• Explain how the concept of “things” in the

problem domain also define requirements
• Identify and analyze data entities and domain
classes needed in the system
• Read, interpret, and create a domain model class
diagram
• Develop system sequence diagrams
Topic 7
System Design

ISP550
INFORMATION SYSTEMS
ENGINEERING
 Learning Objectives

• Describe the difference between systems analysis and systems design

• Describe the major hardware and network environment options
• Describe the various hosting services available
• Explain each major design activity

2
 Overview
• Analysis says “what” is required and design tells us
“how” the system will be configured and
constructed
• This topic introduces system design and the design
activities involved in systems development
• Design bridges the gap between requirements to
actual implementation
• Objective of design is to define, organize, and
structure the components of the final solution to
serve as a blue-print for construction
 Two Levels of Design

• Architectural Design
• Broad design of the overall system structure
• Also called General Design and Conceptual Design
• Detailed Design
• Low level design that includes the design of the specific
program details
• Design of each use case
• Design of the database
• Design of user and system interfaces
• Design of controls and security
Figure 7.1: Analysis versus Design
Objectives

5
Figure 7.2: Analysis vs. Design Models
Figure 7.3: Design Activities
Design Activities and Key Question
Table 7.1: Key Questions of Design Activities
Design Activities:
Design the environment
• The environment is all of the
technology required to support the
software application
• Servers, Desktop computers
• Mobile devices, Operating systems
• Communication capabilities, Input and output
capabilities
Design the Environment
The design activity now in more detail
1. Design for Internal Deployment
a. Stand alone software systems
► Run on one device without networking
► Major issue: need to be deployed on various devices /
platforms
b. Internal network-based systems
► Local area network, client-server architecture
► Desktop applications and browser-based applications
c. Three-layer client server architecture
► View layer, domain layer, and data layer
► Desktop and browser-based applications
Design the Environment
(continued)
2. Design for External Deployment: related issues
A. Configuration for Internet deployment
► Advantages: accessibility, low-cost, widely-implemented
standards
► Risks: security, throughput, changing standards
B. Hosting Alternatives for Internet deployment
(http://www.exabytes.my)
► Colocation
► Managed services
► Virtual Servers
► Cloud computing (refer to Topic 2, slide#7)
C. Diversity of Client Devices with Internet deployment
► Full size, tablets and notebooks, smart phones
Hosting Alternatives for Internet Deployment

► Hosting:
► Running and maintaining a computer system on
someone’s behalf where the application software
and the database reside
► The process of providing physical servers at a secure
location and selling those services to other
businesses that wish to deploy Web sites
► Issues when considering hosting alternatives
► Reliability,security, physical facilities, staff,
potential for growth
Hosting Alternatives for Internet Deployment
(continued)

Table 7.2: Hosting Alternatives

Hosting Alternatives for Internet Deployment
(continued)

► Colocation
►a hosting service with a secure location but in which the
computers are usually owned by the client businesses
► Managed Services
► a client owns software but may want to purchase
additional services, such as installing and managing the
operating system, the Internet servers, database servers,
and load balancing software
► Virtual servers
► the client company leases a virtual server that is
configured as a real server, with a certain amount of CPU
capacity, internal memory, hard drive memory, and
bandwidth to the Internet
Hosting Alternatives for Internet Deployment
(continued)

► Cloud Computing
► an extension of virtual servers in which the resources
available include computing, storage, and Internet
access and they appear to have unlimited availability
► a client should be able to buy computing capacity much
like one purchases such a utility as water or electricity
► the client shouldn’t have to be concerned with such
environmental issues as how or where this computing
capacity is provided, just as an individual doesn’t have
to worry about how electricity is generated
► Service Level Agreement
► For all alternatives, part of the contract between a
business and a hosting company that guarantees a
specific level of system availability
Design Activities:
Design the application architecture and software

► Partition system into subsystems

► Define software architecture
► Three layer or model-view-controller
► Detailed design of each use case
► Design class diagrams
► Sequence diagrams
► State machine diagrams
Figure 7.4:
Design Class
Diagram

Detail design for

two use cases:
Process New Sale
Make payment
Design Activities:
Design the system interfaces

► Information system interacts with many other systems,

internal and external
► Much more integration now
● System Interface – the inputs and outputs that require
minimal human intervention
● Inputs captured automatically
● Outputs direct to other systems
● Printed and distributed outputs (statements, reports)
► System interfaces connect with other systems in many
different ways
► Save data another system uses
► Read data another system saved
► Real time request for information
► Software services
Design Activities:
Design the user interfaces

► Defining
the manner in which humans and
computers exchange inform
► Dialog design begins with requirements
► Use case flow of activities
► System sequence diagram
► Design adds in screen layout, look and feel,
navigation, user experience
► Now we require interface design for many
different environment and devices
► Smart phone
► Notebooks, tablets, iPads
Figure 7.5: Specification Outline for the
Design of Interfaces and Dialogues
Methods of Interacting

► Five widely used styles of interacting include:

► Command line
►Includes keyboard shortcuts and function keys
► Menu

► Form

► Object-based

► Natural language
Command Language Interaction
► Command language interaction – human-computer
interaction method whereby users enter explicit
statements into a system to invoke operations
► Example from Linux command prompt:
$ cp file.doc newfile.doc
►Makes a copy of file.doc and names it newfile.doc
►The dollar sign is the command prompt from Linux, not
part of the command itself
Menu Interaction
► Menu interaction – human–computer interaction method
in which a list of system options is provided and a
specific command is invoked by user selection of a menu
option
► Menus can differ significantly in design and
complexity
► Larger systems might use menu hierarchies providing
navigation
► Variationin menu arrangement can greatly influence
system usability
Figure 7.6: Single-Level Menu for Selecting
Settings in the Chrome Web Browser

(Source: Google, Inc.)

Figure 7.7: Various Types of Menu
Configurations

(Source: Based on Shneiderman et al., 2016)

Pop-Up Menu

► Pop-up
menu – menu-positioning method that places a
menu near the current cursor position
► Also called a dialogue box
► Users don’t have to move their position or eyes to view
system options
► Drop-down menu – menu-positioning method that places
the access point of the menu near the top line of the
display; when accessed, menus open by dropping down
onto the display
Table 7.3: Guidelines for Menu Design
Wording • Each menu should have a meaningful title.
• Command verbs should clearly and specifically describe operations.
• Menu items should be displayed in mixed uppercase and lowercase letters
and have a clear, unambiguous interpretation.
Organization • A consistent organizing principle should be used that relates to the tasks the
intended users perform; for example, related options should be grouped
together, and the same option should have the same wording and codes
each time it appears.
Length • The number of menu choices should not exceed the length of the screen.
• Submenus should be used to break up exceedingly long menus.
Selection • Selection and entry methods should be consistent and reflect the size of the
application and sophistication of the users.
• How the user is to select each option and the consequences of each option
should be clear (e.g., whether another menu will appear).
Highlighting • Highlighting should be minimized and used only to convey selected options
(e.g., a check mark) or unavailable options (e.g., dimmed text).
Figure 7.8:Contrasting Menu Designs (a) Poor
Menu Design (b) Improved Menu Design

(a)

(b)
Form Interaction
► Form interaction – highly intuitive human-computer
interaction method whereby data fields are formatted in
a manner similar to paper-based forms
► Allows users to fill in the blanks when working with a
system
Figure 7.9: Example of Form Interaction from
the Google Advanced Search Engine

(Source: Google, Inc.)

Object-Based Interaction

► Object-basedinteraction – human-computer interaction

method in which symbols are used to represent commands
or functions
► Icon– graphical picture that represents specific functions
within a system
► Take up little screen space
► Quickly understood by most users
Figure 7.10: Object-Based (Icon) Interface
from Microsoft’s Snipping Tool

(Source: Microsoft Corporation)

Natural Language Interaction

► Natural language interaction – human-computer

interaction method whereby inputs to and outputs from
a computer-based application are in a conventional
spoken language such as English
► Based on research in artificial intelligence
► Current implementations are tedious and difficult to
work with, not as viable as other interaction methods
Table 7.4: Common Devices for
Interacting with an Information System
Device Description and Primary Characteristics or Usage
Keyboard Users push an array of small buttons that represent symbols that are then translated into words and
commands. Keyboards are widely understood and provide considerable flexibility for interaction.
Mouse A small plastic box that users push across a flat surface and whose movements are translated into cursor
movement on a computer display. Buttons on the mouse tell the system when an item is selected. A mouse
works well on flat desks but may not be practical in dirty or busy environments, such as a shop floor or
check-out area in a retail store. Newer pen-based mice provide the user with more of the feel of a writing
implement.
Joystick A small vertical lever mounted on a base that steers the cursor on a computer display. Provides similar
functionality to a mouse.
Trackball A sphere mounted on a fixed base that steers the cursor on a computer display. A suitable replacement for
a mouse when work space for a mouse is not available.
Touch Selections are made by touching a computer display. This works well in dirty environments or for users with
Screen limited dexterity or expertise.
Light Pen Selections are made by pressing a pen-like device against the screen. A light pen works well when the user
needs to have a more direct interaction with the contents of the screen.
Graphic Moving a pen-like device across a flat tablet steers the cursor on a computer display. Selections are made
Tablet by pressing a button or by pressing the pen against the tablet. This device works well for drawing and
graphical applications.
Voice Spoken words are captured and translated by the computer into text and commands. This is most
appropriate for users with physical challenges or when hands need to be free to do other tasks while
interacting with the application.
Designing Interfaces
► Should use standard forms for forms/reports
► Typical paper-based form has several common general areas such as:
► Header information
► Sequence and time-related information
► Instruction or formatting information
► Body or data details
► Totals or data summary
► Authorization or signatures
► Comments
Figure 7.11: Paper-Based Form for Reporting
Customer Sales Activity
Figure 7.12: Computer-Based Form Reporting
Customer Sales Activity

(Source: Microsoft Corporation)

Figure 7.13: Contrasting the Navigation Flow Within a
Data Entry Form (a) Proper Flow Between Data Entry
Field (b) Poor Flow Between Data Entry Fields

(a)

(b)
Designing Dialogues

► Dialogue– sequence of interaction between a user and a

system (refer to SSD)
► Three major steps in the dialogue design process:
► Designing a dialogue sequence
► Building a prototype
► Assessing usability
Table 7.5: Guidelines for the Design of
Human–Computer Dialogues
Guideline Explanations
Consistency Dialogues should be consistent in sequence of actions, keystrokes, and terminology (e.g., the same
labels should be used for the same operations on all screens, and the location of the same information
should be the same on all displays).
Shortcuts and Allow advanced users to take shortcuts using special keys (e.g., CTRL-C to copy highlighted text). A
Sequence natural sequence of steps should be followed (e.g., enter first name before last name, if appropriate).
Feedback Feedback should be provided for every user action (e.g., confirm that a record has been added, rather
than simply putting another blank form on the screen).
Closure Dialogues should be logically grouped and have a beginning, middle, and end (e.g., the last in the
sequence of screens should indicate that there are no more screens).
Error All errors should be detected and reported; suggestions on how to proceed should be made (e.g.,
Handling suggest why such errors occur and what user can do to correct the error). Synonyms for certain
responses should be accepted (e.g., accept either “t,” “T,” or “TRUE”).
Reversal Dialogues should, when possible, allow the user to reverse actions (e.g., undo a deletion); data should
not be deleted without confirmation (e.g., display all the data for a record the user has indicated is to
be deleted).
Control Dialogues should make the user (especially an experienced user) feel in control of the system (e.g.,
provide a consistent response time at a pace acceptable to the user).
Ease It should be a simple process for users to enter information and navigate between screens (e.g.,
provide means to move forward, backward, and to specific screens, such as first and last).

(Source: Based on Shneiderman et al., 2016)

Figure 7.14: Wireframes are Often Used
for Testing Usability
 Design Activities: Design the database

• Designing physical files/databases requires the following

information:
– Normalized relations, including volume estimates
– Definitions of each attribute
– Descriptions of where and when data are used:
entered, retrieved, deleted, and updated (including
frequencies)
– Expectations or requirements for response time and
data integrity
– Descriptions of the technologies used for
implementing the files and database so that the range
of required decisions and choices for each is known
42
Design Activities: Design the database

► Starting with the domain model class diagram

(or ERD)
► Choose database structure
► Usuallyrelational database
► Could be ODBMS framework

► Design architecture (distributed, etc.)

► Design database schema
► Tables and columns in relational
► Design referential integrity constraints
► Foreign key references
Figure 7.15: Database Table
Definition Using MySQL
Design Activities:
Design the security and system controls

► Protect the organization’s assets

► Becomes crucial in Internet and wireless
► User interface controls
► Application controls
► Database controls
► Network controls
Design Activities:
Design the security and system controls

► As shown in Figure 6-9, controls are incorporated into

various parts of the system. Some of the controls—called
integrity controls—must be integrated into both the
application programs that are being developed and the
database that supports them.
► Other controls—usually called security controls—are part of
the operating system and the network. Integrity controls
ensure correct system function by rejecting invalid data
inputs, preventing unauthorized data outputs, and
protecting data and programs against accidental or
malicious tampering.
Design Activities:
Design the security and system controls
Design Activities:
Design the security and system controls

The primary objectives of integrity controls

are:
■ To ensure that only appropriate and
correct business transactions occur
■ To ensure that the transactions are
recorded and processed correctly
■ To protect and safeguard the assets of the
organization (including hardware,
software, and information)
Summary
● There are six design activities: design the environment,
design the application architecture and software, design
user interfaces, design system interfaces, design the
database, and design system controls and security.
● System design is the bridge between requirements and
implementation—a blue-print for what needs to be built.
● Design occurs at two levels: architectural design and
detail design.
Summary (continued)

● Models of the functional requirements (domain model

class diagrams, use case diagrams, system sequence
diagrams, use case descriptions, state machine
diagrams, and activities diagrams) are used as the basis
for creating design models.
● Hosting alternatives include colocation, managed
services, virtual servers, and cloud computing.
Topic 8
System Implementation

ISP550
INFORMATION SYSTEMS
ENGINEERING
Learning Objectives
Provide an overview of the system implementation process
Describe how software applications are tested
Apply four installation strategies: direct, parallel, single-location, and
phased installation
List the deliverables for documenting the system and for training and
supporting users
Explain why system implementation sometimes fails
Describe the threats to system security and remedies that can be
applied
Show how traditional implementation issues apply to electronic
commerce applications

Copyright © 2020 Pearson Education Ltd.

Figure 13-1: Systems Development Life
Cycle with the Implementation Phase
Highlighted

Copyright © 2020 Pearson Education Ltd.

System Implementation

• Purpose:
– To convert final physical system specifications into
working and reliable software
– To document work that has been done
– To provide help for current and future users

Copyright © 2020 Pearson Education Ltd.

Table 13-1: Deliverables for Coding,
Testing, and Installation
1. Coding
a. Code
b. Program documentation
2. Testing
a. Test scenarios (test plan) and test data
b. Results of program and system testing
3. Installation
a. User guides
b. User training plan
c. Installation and conversion plan
i. Software and hardware installation schedule
ii. Data conversion plan
iii. Site and facility remodeling plan

Copyright © 2020 Pearson Education Ltd.

Documenting the System, Training
Users, and Supporting Users

• Two audiences for final documentation:

– Information systems personnel who will maintain the
system throughout its productive life
– People who will use the system as part of their daily
lives
• User Training
– Application-specific
– General for operating system and off-the-shelf
software
Copyright © 2020 Pearson Education Ltd.
Table 13-2: Deliverables for Documenting
the System, Training and Supporting Users
1. Documentation
a. System documentation
b. User documentation

2. User training plan

a. Classes
b. Tutorials

3. User training modules

a. Training materials
b. Computer-based training aids

4. User support plan

a. Help desk
b. Online help
c. Bulletin boards and other support mechanisms
Copyright © 2020 Pearson Education Ltd.
Software Application Testing

• A master test plan is developed during the analysis phase

• During the design phase, unit, system and integration test
plans are developed
• The actual testing is done during implementation
• Written test plans provide improved communication among
all parties involved in testing

Copyright © 2020 Pearson Education Ltd.

Table 13-3: Table of Contents of a
Master Test Plan (1 of 3)

1. Introduction
a. Description of system to be tested
b. Objectives of the test plan
c. Method of testing
d. Supporting documents
2. Overall Plan
a. Milestones, schedules, and locations
b. Test materials
i. Test plans
ii. Test cases
iii. Test scenarios
iv. Test log

Copyright © 2020 Pearson Education Ltd.

Table 13-3: Table of Contents of a
Master Test Plan (2 of 3)

3. Testing Requirements
a. Hardware
b. Software
c. Personnel
4. Procedure Control
a. Test initiation
b. Test execution
c. Test failure
d. Access/change control
e. Document control

Copyright © 2020 Pearson Education Ltd.

Table 13-3: Table of Contents of a
Master Test Plan (3 of 3)

5. Test-specific or component-specific test plans

a. Objectives
b. Software description
c. Method
d. Milestones, schedule, progression
e. Locations
f. Requirements
g. Criteria for passing tests
h. Resulting test materials
i. Execution control
j. Attachments

(Source: Adapted from Mosley, 1993.)

Copyright © 2020 Pearson Education Ltd.

Seven Different Types of Tests (1 of 4)

• Software application testing is an umbrella term that

covers several types of tests
• Static or dynamic techniques
– Static testing means that the code being tested is not
executed
– Dynamic testing involves execution of the code
• Automated testing v s manual testing
ersu

– Automated means computer conducts the test

– Manual means that people complete the test

Copyright © 2020 Pearson Education Ltd.

Table 13-4: Categorization of Test
Types

Blank Manual Automated

Static Inspections Syntax checking
Dynamic Walk-through Unit test
Desk checking Integration test
System test

(Source: Adapted from Mosley, 1993)

Copyright © 2020 Pearson Education Ltd.

Seven Different Types of Tests (2 of 4)

• Seven types of testing:

1. Inspections – testing technique in which participants
examine program code for predictable language-
specific errors
2. Walk-throughs (code walk-throughs) should be done
frequently when pieces of work are reviewed and
before formal testing. It is an informal process.

Copyright © 2020 Pearson Education Ltd.

Figure 13-2: Steps in a Typical
Walk-Through

(Source: Based on Yourdon, 1989)

Copyright © 2020 Pearson Education Ltd.

Seven Different Types of Tests (3 of 4)

• Seven types of testing:

3. Desk checking – testing technique in which the
program code is sequentially executed manually by the
reviewer
4. Unit testing – process of testing each module alone in
an attempt to discover any errors in its code
5. Integration testing – process of bringing together all of
the modules that a program comprises for testing
purposes. Modules are typically integrated in a top-
down, incremental fashion.

Copyright © 2020 Pearson Education Ltd.

Seven Different Types of Tests (4 of 4)

• Seven types of testing:

6. System testing – bringing together of all of the
programs that a system comprises for testing
purposes. Programs are typically integrated in a top-
down, incremental fashion.
7. Stub testing – technique used in testing modules,
especially where modules are written and tested in a
top-down fashion, where a few lines of code are used
to substitute for subordinate modules

Copyright © 2020 Pearson Education Ltd.

The Testing Process (1 of 2)

• Two important things to remember when testing information

systems:
1. The purpose of testing is to confirm that the system satisfies
requirements
2. Testing must be planned
• A test case is a specific scenario of transactions, queries, or
navigation paths that represent a typical, critical, or abnormal
use of the system
– Should be repeatable
– Need to determine if new software work with other existing
software
Copyright © 2020 Pearson Education Ltd.
Figure 13-3: Test Case Description
Form

(Source: Adapted from Mosley, 1993)

Copyright © 2020 Pearson Education Ltd.

Figure 13-4: Test Case Results Form

(Source: Adapted from Mosley, 1993)

Copyright © 2020 Pearson Education Ltd.

The Testing Process (2 of 2)

• Testing harness – automated testing environment used to

review code for errors, standards violations, and other
design flaws
– Greatly enhances the testing process because it can
automatically expand the scope of the tests beyond the
current development platform

Copyright © 2020 Pearson Education Ltd.

Combining Coding and Testing

• Coding and testing are part of the same process

• Big companies and big projects often have dedicated
testing staffs
• Refactoring – making a program simpler after adding a
new feature
– eXtreme programming is a technique used in
refactoring

Copyright © 2020 Pearson Education Ltd.

Acceptance Testing by Users (1 of 2)

• Acceptance testing – process whereby actual users test

a completed information system, the end result of which is
the users’ acceptance of it
• Alpha testing – user testing of a completed information
system using simulated data
• Beta testing – user testing of a completed information
system using real data in the real user environment

Copyright © 2020 Pearson Education Ltd.

Acceptance Testing by Users (2 of 2)
• Tests performed during alpha testing:
– Recovery testing—forces the software (or environment) to fail in
order to verify that recovery is properly performed
– Security testing—verifies that protection mechanisms built into the
system will protect it from improper penetration
– Stress testing—tries to break the system (e.g., what happens
when a record is written to the database with incomplete
information or what happens under extreme online transaction
loads or with a large number of concurrent users)
– Performance testing—determines how the system performs in the
range of possible environments in which it may be used (e.g.,
different hardware configurations, networks, operating systems,
and so on); often the goal is to have the system perform with
similar response time and other performance measures in each
environment
Copyright © 2020 Pearson Education Ltd.
Table 13-9: Sample of Tests Conducted
on the WebStore During Alpha Testing
Test Type Tests Performed
Recovery • Unplug main server to test power backup system
• Switch off main server to test the automatic switching to
backup server
Security • Try to purchase without being a customer
• Try to examine server directory files both within the PVF
domain and when connecting from an outside Internet
service provider
Stress • Have multiple users simultaneously establish accounts,
process purchases, add to shopping cart, remove from
shopping cart, and so on
Performance • Examine response time using different connection speeds,
processors, memory, browsers, and other system
configurations
• Examine response time when backing up server data

Copyright © 2020 Pearson Education Ltd.

Installation (1 of 5)

• Installation – organizational process of changing over

from the current information system to a new one
• Four installation strategies:
– Direct installation
– Parallel installation
– Single-location installation
– Phased installation

Copyright © 2020 Pearson Education Ltd.

Installation (2 of 5)

• Direct installation – changing over from the old

information system to a new one by turning off the old
system when the new one is turned on
– Users at the mercy of the new system
– Very risky installation
– Least expensive installation

Copyright © 2020 Pearson Education Ltd.

Figure 13-5: Comparison of Installation
Strategies (a) Direct Installation

(Source: Adapted from Bell and Evans, 1989)

Copyright © 2020 Pearson Education Ltd.

Installation (3 of 5)

• Parallel installation – running the old information system

and the new one at the same time until management
decides the old system can be turned off
– Safest approach but very expensive
– Outputs are compared with each system

Copyright © 2020 Pearson Education Ltd.

Figure 13-5: Comparison of Installation
Strategies (b) Parallel Installation

(Source: Adapted from Bell and Evans, 1989)

Copyright © 2020 Pearson Education Ltd.

Installation (4 of 5)

• Single-location installation – trying out a new

information system at one site and using the experience
to decide if and how the new system should be deployed
throughout the organization
– Considered a middle-or-the-road approach
– Usually, a branch office or one department
– Once successful then rolled out to entire company
– Results in extra work for staff

Copyright © 2020 Pearson Education Ltd.

Figure 13-5: Comparison of Installation
Strategies (c) Single-Location Installation (with
Direct Installation at Each Location)

(Source: Adapted from Bell and Evans, 1989)

Copyright © 2020 Pearson Education Ltd.

Installation (5 of 5)

• Phased installation – changing from the old information

system to the new one incrementally, starting with one or
a few functional components and then gradually
extending the installation to cover the whole new system
– An incremental approach (also called staged)
– Usually implemented in a sequence approach
– Requires careful version control

Copyright © 2020 Pearson Education Ltd.

Figure 13-5: Comparison of Installation
Strategies (d) Phased Installation

(Source: Adapted from Bell and Evans, 1989)

Copyright © 2020 Pearson Education Ltd.

Planning Installation

• Of special interest during installation is the conversion of

data
– Must be error free, combined with new data and
loaded into files
– May require current systems to be shut down
– Involves getting people to change the way they work

Copyright © 2020 Pearson Education Ltd.

Documenting the System

• System documentation – detailed information about a

system’s design specifications, its internal workings, and
its functionality
• User documentation – written or other visual information
about an application system, how it works, and how to use
it

Copyright © 2020 Pearson Education Ltd.

Table 13-5: SDLC and Generic Documentation
Corresponding to Each Phase
Generic Life-Cycle Phase Generic Document
Requirements Specification System Requirements Specification
Resource Requirements Specification
Project Control Structuring’ Management Plan
Engineering Change Proposal
System Development:
• Architectural design Architecture Design Document
• Prototype design Prototype Design Document
• Detailed design and implementation Detailed Design Document
• Test specification Test Specifications
• Test implementation Test Reports
System Delivery User’s Guide
Release Description
System Administrator’s Guide
Reference Guide
Acceptance Sign-Off

(Source: Adapted from Bell & Evans, 1989)

Copyright © 2020 Pearson Education Ltd.

Training and Supporting Users

• Support – providing ongoing educational and problem-

solving assistance to information system users. For in-
house developed systems, support materials and jobs will
have to be prepared or designed as part of the
implementation process.

Copyright © 2020 Pearson Education Ltd.

Training Information System Users
• Potential training topics include:
– Use of the system (e.g., how to enter a class
registration request)
– General computer concepts (e.g., computer files and
how to copy them)
– Information system concepts (e.g., batch processing)
– Organizational concepts (e.g., FIFO inventory
accounting)
– System management (e.g., how to request changes to
a system)
– System installation (e.g., how to reconcile current and
new systems during phased installation)
Copyright © 2020 Pearson Education Ltd.
Table 13-7: Types of Training
• Resident expert
• Traditional instructor-led classroom training
• E-learning/distance learning
• Blended learning (combination of instructor-led and e-
learning)
• Software help components
• External sources, such as vendors

Copyright © 2020 Pearson Education Ltd.

Supporting Information Systems Users

• Support is important to users, but has often been

inadequate for users’ needs
• Users consider support to be extremely important
• Increased need for support came from lack of standards
governing client/server products

Copyright © 2020 Pearson Education Ltd.

Automating Support

• Vendor’s have automated support to users in order to cut costs

• Ways vendor’s have automated support:
– Forums offered over the Internet
– Voice-response systems allow users to navigate option
menus
– Vendor knowledge bases
• Help desk – single point of contact for all user inquiries and
problems about a particular information system or for all users in
a particular department (non automated)

Copyright © 2020 Pearson Education Ltd.

Organizational Issues in Systems
Implementation

• Implementation effort sometimes fails because:

– Employees don’t use the new system
– Employee dissatisfaction with new system
• Important factors to implementation success include:
– Commitment to the project
– Commitment to change (willingness to change
behaviors)
– Meeting user expectations

Copyright © 2020 Pearson Education Ltd.

Factors Influencing System Use

• Six factors that influenced the extent to which a system is

used:
1. User’s personal stake
2. System characteristics
3. User demographics
4. Organizational support
5. Performance
6. Satisfaction

Copyright © 2020 Pearson Education Ltd.

Figure 13-9: Implementation Success

(Source: From Lucas, H. C. (1997). Information technology for management. New York: McGraw-Hill. Reprinted by
permission.)

Copyright © 2020 Pearson Education Ltd.

Security Issues

• Increasingly important issue for organizations and their

management
• Malicious software (malware): includes Trojan horses,
worms, viruses, and other kinds
• External sources of threats include laptop theft, system
penetration, and denial of service
• Weakest link: the user!
– Failure to use (or secure) passwords

Copyright © 2020 Pearson Education Ltd.

Developing Test Cases for the
WebStore

• Developing test cases for the WebStore include testing

categories as follows:
– Simple functionality
– Multiple functionality
– Function chains
– Elective functions
– Emergency/crisis

Copyright © 2020 Pearson Education Ltd.

WebStore Test Cases

• Case documentation test form sections include:

– Test Case ID
– Category/Objective of Test
– Description
– System Version
– Completion Date
– Participant(s)
– Machine Characteristics (processor, operating systems, memory,
browser, etc.)
– Test Result
– Comments
Copyright © 2020 Pearson Education Ltd.
Bug Tracking and System Evolution

• Sections of the bug tracking form:

– Bug Number (simple incremental number)
– Test Case ID That Generated the Bug
– Is the Bug Replicable?
– Effects
– Description
– Resolution
– Resolution Date
– Comments
Copyright © 2020 Pearson Education Ltd.
Alpha and Beta Testing the WebStore

• Alpha Testing:
– PVF employees who actively participated received a t-
shirt and $100 to shop
– Development team conducted extensive recovery,
security, stress, and performance testing
• Beta Testing
– PVF recruited several of their established customers to
help in beta testing

Copyright © 2020 Pearson Education Ltd.

Table 13-9: Sample of Tests Conducted
on the WebStore During Alpha Testing
Test Type Tests Performed
Recovery • Unplug main server to test power backup system
• Switch off main server to test the automatic switching to
backup server
Security • Try to purchase without being a customer
• Try to examine server directory files both within the PVF
domain and when connecting from an outside Internet
service provider
Stress • Have multiple users simultaneously establish accounts,
process purchases, add to shopping cart, remove from
shopping cart, and so on
Performance • Examine response time using different connection speeds,
processors, memory, browsers, and other system
configurations
• Examine response time when backing up server data

Copyright © 2020 Pearson Education Ltd.

Project Closedown

• Closing down the project:

– Evaluate team members
▪ Reassign, terminate members as needed
– Conduct post project reviews with users and
customers
– Close out customer contract

Copyright © 2020 Pearson Education Ltd.

Summary
• In this chapter you learned how to:
– Provide an overview of the system implementation process
– Describe how software applications are tested
– Apply four installation strategies: direct, parallel, single-
location, and phased installation
– List the deliverables for documenting the system and for
training and supporting users
– Explain why system implementation sometimes fails
– Describe the threats to system security and remedies that
can be applied
– Show how traditional implementation issues apply to
electronic commerce applications

Copyright © 2020 Pearson Education Ltd.

Topic 9
System Support ( Maintaining IS)

ISP550
INFORMATION SYSTEMS
ENGINEERING
Learning Objectives
• Explain and contrast four types of maintenance
• Describe several factors that influence the cost of
maintaining an information system and apply these factors
to the design of maintainable systems; and
• Describe maintenance management issues, including
alternative organizational structures, quality measurement,
processes for handling change requests, and configuration
management

Copyright © 2020 Pearson Education Ltd.

Figure 14-1: Systems Development Life
Cycle

Copyright © 2020 Pearson Education Ltd.

Maintaining Information Systems

• Four major activities occur within maintenance:

1. Obtaining maintenance requests
2. Transforming requests into changes
3. Designing changes
4. Implementing changes

Copyright © 2020 Pearson Education Ltd.

Figure 14-2: System Service Request for
Purchasing Fulfillment System (PVF)

Copyright © 2020 Pearson Education Ltd.

Figure 14-3: Maintenance Activities
Parallel Those of the SDLC

Copyright © 2020 Pearson Education Ltd.

Deliverables and Outcomes

• SDLC maintenance phase is a subset of the activities of

the entire development process
• Development of a new version of the software and new
versions of all design documents created or modified
during maintenance

Copyright © 2020 Pearson Education Ltd.

Types of Maintenance (1 of 2)

• Maintenance refers to changes made to a system to fix

or enhance its functionality
• Corrective maintenance refers to changes made to a
system to repair flaws in its design, coding, or
implementation
• Adaptive maintenance refers to changes made to a
system to evolve its functionality to changing business
needs or technologies

Copyright © 2020 Pearson Education Ltd.

Types of Maintenance (2 of 2)

• Perfective maintenance refers to changes made to a

system to add new features or to improve performance
• Preventative maintenance refers to changes made to a
system to avoid possible future problems

Copyright © 2020 Pearson Education Ltd.

The Cost of Maintenance (1 of 2)

• Many organizations allocate 60-80% of information

systems budget to maintenance
– Because many organizations have accumulated more
and more older so-called legacy systems that require
more and more maintenance

Copyright © 2020 Pearson Education Ltd.

Figure 14-5: New Development Versus
Maintenance as a Percentage of the Software
Budget over the Years

(Source: Based on Pressman, 2005)

Copyright © 2020 Pearson Education Ltd.

The Cost of Maintenance (2 of 2)

• Maintainability is the ease with which software can be understood, corrected,

adapted, and enhanced

• Factors influencing maintainability:

– Latent defects: unknown errors after installation (increases corrective
maintenance)
– Number of system customers: the greater the number of customers the
greater the maintenance costs
– Quality of system documentation: lack of documentation makes
maintenance harder
– Maintenance personnel: high quality programmers required for maintenance
– Tools: automated documentation and code tools
– Well-structured programs: well designed programs are easier to understand
and fix

Copyright © 2020 Pearson Education Ltd.

Figure 14-6: Quality Documentation
Eases Maintenance

(Source: Based on Hanna, M. (1992, December). Using documentation as a life-cycle tool.

Software Magazine, 41–46.)

Copyright © 2020 Pearson Education Ltd.

Managing Maintenance Personnel

• Traditionally, maintenance and development were separately

staffed
• Organizations are rethinking this. Maybe combine development
and maintenance into one role?
• Another possibility: spread maintenance personnel in different
functional units (marketing, accounting, human resources, etc.)

Copyright © 2020 Pearson Education Ltd.

Table 14-2: Advantages and Disadvantages of
Different Maintenance Organizational Structures

Type Advantages Disadvantages

Separate Formal transfer of systems All things cannot be
between groups improves the documented, so the
system and documentation maintenance group may not
quality know critical information about
the system
Combined Maintenance group knows or Documentation and testing
has access to all assumptions thoroughness may suffer due to
and decisions behind the a lack of a formal transfer of
system’s original design responsibility
Functional Personnel have a vested Personnel may have limited job
interest in effectively mobility and lack access to
maintaining the system and adequate human and technical
have a better understanding of resources
functional requirements

Copyright © 2020 Pearson Education Ltd.

Measuring Maintenance Effectiveness

• In measuring maintenance effectiveness, you must measure the

following factors:
– Number of failures
– Time between each failure
– Type of failure
• Mean time between failures (MTBF) – measurement of error
occurrences that can be tracked over time to indicate the quality
of a system

Copyright © 2020 Pearson Education Ltd.

Figure 14-7: How the Mean Time Between
Failures Should Change Over Time

Copyright © 2020 Pearson Education Ltd.

Controlling Maintenance Requests

• Maintenance requests can be frequent

• Prioritize based on type and urgency of request
• Evaluations are based on feasibility analysis

Copyright © 2020 Pearson Education Ltd.

Figure 14-8: How to Prioritize
Maintenance Requests

Copyright © 2020 Pearson Education Ltd.

Figure 14-9: How a Maintenance Request
Moves Through an Organization

Copyright © 2020 Pearson Education Ltd.

Configuration Management (1 of 2)

• Configuration management – process of ensuring that only

authorized changes are made to the system
• Baseline modules – software modules that have been tested,
documented, and approved to be included in the most recently
created version of a system

Copyright © 2020 Pearson Education Ltd.

Configuration Management (2 of 2)

• System librarian – person responsible for controlling the

checking out and checking in of baseline modules when a system
is being developed or maintained
• Build routines – guidelines that list the instructions to construct
an executable system from the baseline source code
• Special software systems are being created to manage system
configuration

Copyright © 2020 Pearson Education Ltd.

Role of Automated Development Tools
in Maintenance (1 of 3)

• Traditional systems development

– Much time is spent on coding and testing
– Changes are implemented by coding and testing first
– Documentation is done after maintenance is performed
– Keeping documentation current is often neglected due to
time-consuming nature of task

Copyright © 2020 Pearson Education Ltd.

Role of Automated Development Tools
in Maintenance (2 of 3)

• Using automated tools for systems development and

maintenance
– Use data flow diagrams and screen design in lieu of source
code
– Code regeneration using code generators
– Documentation completed during maintenance process

Copyright © 2020 Pearson Education Ltd.

Role of Automated Development Tools
in Maintenance (3 of 3)

• Reverse engineering – automated tools that read program

source code as input and create graphical and textual
representations of design-level information such as program
control structures, data structures, logical flow, and data flow
• Re-engineering – automated tools that read program source
code as input; perform an analysis of the program’s data and
logic; and then automatically, or interactively with a systems
analyst, alter an existing system in an effort to improve its
quality or performance

Copyright © 2020 Pearson Education Ltd.

Website Maintenance (1 of 2)
• Issues and procedures related to website maintenance include:
– 24/7/365: Maintenance is challenging as it has to be done
without taking the site offline
– Check for broken links: Most common issue!
– HTML validation: Pages should be processed by a code
validation routine before publication
– Reregistration: When content significantly changes, site
may need to be reregistered with search engines

Copyright © 2020 Pearson Education Ltd.

Website Maintenance (2 of 2)
• Issues and procedures related to website maintenance include:
– Future editions:
▪ Be consistent to avoid confusing users
▪ Post indications of future changes to the site
▪ Use batch changes to limit frequency of changes

Copyright © 2020 Pearson Education Ltd.

Electronic Commerce Application: Maintaining
an Information System for PVF WebStore

• To maintain PVF’s WebStore, the following questions need to be

addressed:
– How much is our website worth?
– How much does it cost our company when our website goes
down?
– How reliable does our website need to be?
• Pine Valley Furniture needs to immediately develop a plan for
addressing the WebStore’s service level problems

Copyright © 2020 Pearson Education Ltd.

Summary
• In this chapter you learned to:
– Explain and contrast four types of maintenance
– Describe several factors that influence the cost of
maintaining an information system and apply these
factors to the design of maintainable systems
– Describe maintenance management issues, including
alternative organizational structures, quality
measurement, processes for handling change
requests, and configuration management

Copyright © 2020 Pearson Education Ltd.