2022-01-27

A Review of Software
Development Process

Amin Milani Fard – NYIT

Slides mainly from A. Dennis, B. H. Wixom, R. M. Roth, “Systems Analysis and Design”

Learning Objectives
q Describing systems development life cycle and its phases.
q Describing planning phase and methodology selection.
q Explaining analysis phase and classifying requirements.
q Employing the requirement elicitation techniques.
q Explaining the transition from analysis to design.
q Explaining the architecture design.
q Getting familiar with the system construction process.

1
 2022-01-27

“Our civilization runs on software”

Bjarne Stroustrup

How Do Systems Get Built?

q Systems/Software Development Life Cycle (SDLC)
Ø The overall process of systems development (planning,
analysis, design, implementation, test and maintenance)

Implemented System New Project Launched

Testing and Maintenance

Implementation Planning

Planned
System Design Analysis Project
System
Specifications
Requirements

2
 2022-01-27

Planning Phase
q Project Initiation
Ø Prepare system request
Ø Perform preliminary feasibility analysis
q Set Up the Project
Ø Project Plan, including work plan & staffing plan

Analysis Phase
q Determine Analysis Strategy
Ø Study existing system and its problems
q Collect and Analyze Requirements
Ø Develop a new system concept
Ø Describe a new system with analysis models
q Prepare and Present System Proposal
Ø Summarize results of the Analysis Phase
Ø Go/No Go decision made by sponsor and steering committee

3
 2022-01-27

Design Phase
q Determine Design Strategy
Ø Build / Buy / Outsource
q Design system components
Ø Architecture, interface, database, programs
Ø Assemble design elements into System Specification
q Present to steering committee
Ø Go / No Go decision before entering final phase

Implementation Phase
q System construction
Ø Programming and testing
q System installation
Ø Training
Ø Conversion to new system
q On-going system support

4
 2022-01-27

Test and Maintenance Phase

q Check whether the implementation is in line with
the client requirements or not.
q Running test cases and checking for errors (a.k.a
bugs)
q Once the application passed the tests and went to
production, maintenance and support is applied to
perform changes, corrections, and updates.

Systems Analyst Role

q Key role in developing information systems
Ø Analyzing the business situation
Ø Identifying opportunities for improvements
Ø Designing an information system to implement the improvements

q Interaction with
Ø technical specialists (DBAs, network admins, programmers)
Ø business people (users, managers, steering committee)
Ø others (vendors, consultants)

10

10

5
 2022-01-27

Feasibility Analysis
q Is this project really worth doing? Can we do this
project?
q Detailed business case for the project
Ø Technical feasibility
Ø Economic feasibility
q Compiled into a feasibility study

11

11

Technical Feasibility
q Can We Build It?
q Sources of Technical Risk:
Ø Users’ and analysts’ lack of familiarity with the business
application area
Ø Lack of familiarity with technology
Ø Project size (e.g. number of people, time frame, features)
Ø Compatibility with existing systems

12

12

6
 2022-01-27

Economic Feasibility
q Should we build it?
q Identify costs and benefits
q Determine cash flow
q Assess financial viability
Ø Return on investment
Ø Break even point
Ø Net present value

13

13

Feasibility Assessment
q Once risks are known, steps can be taken to
mitigate the risks
Ø For example, if unfamiliar with a new technology
o Provide enough budget for training
o Provide enough budget to hire consultants with
expertise
o Allow more schedule time to move up the learning
curve
o Use a methodology that incorporates experimentation

14

14

7
 2022-01-27

15

15

Selecting a Project Methodology

q Methodology: A formalized approach to
implementing the SDLC
Ø A series of steps to perform and deliverables to produce
q Factors influencing the choice
Ø Clarity of User Requirements
Ø Familiarity with Technology
Ø System Complexity
Ø System Reliability
Ø Time Frame
Ø Schedule Visibility
Structured Systems Development vs. Rapid Application Development
16

16

8
 2022-01-27

Structured Systems Development

q Based upon SDLC
q Assumes a project phase is complete before moving
to the next phase
Ø Waterfall Development
Ø Parallel Development
Ø V-model
q Goal – doing each phase thoroughly before moving
forward ensures correct and high-quality outcomes

17

17

Waterfall Development Methodology

q Move from phase to phase
q Emphasis on deliverables from one phase flowing into the
next phase

18

18

9
 2022-01-27

Waterfall Methodology Assessment

Strengths weaknesses
þ System requirements þ Must wait a long time
identified long before before there is “visible”
construction begins evidence of the new system
þ Requirements are “frozen” þ Takes a long time from start
as project proceeds – no to finish
moving targets allowed

19

19

Parallel Development Methodology

q Subdivide the project into subprojects that can be worked on
at the same time.
q Reduce the overall project length

20

20

10
 2022-01-27

Parallel Methodology Assessment

Strengths weaknesses
þ Reduces overall project þ Creating subprojects
time (compared to requires careful design
Waterfall) decisions
þ Reduces the need for þ Integrating subprojects at
rework; with shorter time the end can be complex and
frame, less chance of difficult
requirements changing

21

21

V-Model Methodology
q Emphasizes system quality through text plan development

22

22

11
 2022-01-27

V-Model Methodology Assessment

Strengths weaknesses
þ Simple and straightforward þ Rigid
þ Quality improves through þ Difficult to use in a dynamic
the emphasis on testing business environment
þ Including Quality Assurance
expertise early in the
project strengthens system
quality

23

23

Rapid Application Development

q Incorporate special techniques and tools:
Ø CASE tools
Ø JAD (Joint Application Design) sessions
Ø Visual programming languages
Ø Code generators
q Goal – get some portion of system
developed quickly and in the users’ hands

24

24

12
 2022-01-27

Three RAD Approaches

q Iterative development
o A series of versions developed sequentially
q System Prototyping
o Create prototype (model) of system and “grow”
it into the final system
q Throw-away prototyping
o Prototype alternative designs in an experimental
way
o Build system following prototype design but
discard the actual prototype

25

25

Iterative Development Methodology

q RAD approach
q Develop system in series of versions

26

26

13
 2022-01-27

Iterative Development Methodology

Assessment
Strengths
þ Users get a system to use
quickly
þ Users identify additional
needs for later versions
based on real experiences
with current version
weaknesses
þ Users faced with using an
incomplete system for a
time
þ Users must be patient and
wait for fully-functional
system

27

27

System Prototyping Methodology

q RAD approach
q Create a rough version of system quickly and “grow” it into
final system with repetitive refinement

28

28

14
 2022-01-27

System Prototyping Methodology

Assessment
Strengths
þ Users get to work with
prototype very quickly
þ Feedback cycles let users
identify changes and refine
real requirements
weaknesses
þ Superficial analysis may
cause problems
þ Initial design decisions may
be poor
þ Overlooked features may be
hard to add later

29

29

Throwaway Prototyping Development

Methodology
q RAD approach
q Adds emphasis on experimenting with design options before
design is finalized
q Design options are thrown-away, but learning from them is
factored into final design

30

30

15
 2022-01-27

Throwaway Prototyping Methodology

Assessment
Strengths weaknesses
þ Uncertainty is minimized þ May take longer (compared
þ Important issues are to system prototyping)
understood before building
the final system

31

31

Agile Development Methodologies

q Extreme Programming (XP), Scrum, and others
q Focus on short cycles that produce a complete software
product
q Highly adaptable in dynamic environments

32

32

16
 2022-01-27

33

33

34

34

17
 2022-01-27

Agile Methodologies Assessment

Strengths
þ Fast delivery of results
þ Works well in projects with
undefined or changing
requirements
weaknesses
þ Requires discipline
þ Significant user involvement
is essential
þ Initial high learning curve

35

35

http://www.softwaretestingstudio.com/
36

36

18
 2022-01-27

Minimum Viable Product (MVP)

37

37

Selection Summary
Ability to develop Waterfall Parallel V-Model Iterative System Throwaway Agile
systems Prototyping Prototyping Development

With unclear user Poor Poor Poor Good Excellent Excellent Excellent
requirements

With unfamiliar Poor Poor Poor Good Poor Excellent Poor

technology

That are complex Good Good Good Good Poor Excellent Poor

That are reliable Good Good Excellent Good Poor Excellent Good

With a short time Poor Good Poor Excellent Excellent Good Excellent
schedule

With schedule Poor Poor Poor Excellent Excellent Good Good

visibility

38

38

19
 2022-01-27

System Analysis Phase

39

39

Overview of the Analysis Phase

q Goal is to develop a clear understanding of the new
system’s requirements
Ø Understand the “As-Is” system
Ø Develop the “To-Be” system concept

q Outline ways to solve the problems in the new

system

40

40

20
 2022-01-27

What is a Requirement?
q A statement of what the system must do; or a
statement of characteristics the system must have

q Types of requirements:
Ø what the business needs (business requirements);
Ø what the users need to do (user requirements);
Ø what the software should do (functional requirements);
Ø characteristics the system should have (nonfunctional
requirements); and
Ø how the system should be built (system requirements).

41

41

User Requirements
q What the user needs to do to complete a needed
job or task
q Focus on user tasks that are integral to business
operations
q Understanding user tasks helps reveal ways that
the new system can support those tasks

42

42

21
 2022-01-27

Functional Requirements
q A process the system should perform as a part of
supporting a user task, or
q Information the system should provide as the user
performs a task
q Specify the support the system will provide to the
user in fulfilling their work tasks

43

43

Functional Description Examples

Requirement
Process-oriented A process the system must
perform; a process the system
must do
• The system must allow registered
customers to review their own order
history for the past 3 years.
• The system must check incoming
customer order for inventory
availability.
• The system should allow students to
view a course while registering for
classes.

Information-oriented Information the system must
contain
• The system must retain customer
order history for 3 years.
• The system must include real-time
inventory level at all warehouses.
• The system must include budgeted
and and actual sale and expense
amount for the current year and 3
previous years.

44

44

22
 2022-01-27

Nonfunctional Requirements
q Behavioral properties the system must have
Ø Operational – physical and technical operating
environment
Ø Performance – speed, capacity, and reliability needs
Ø Security – access restrictions, needed safeguards
Ø Cultural and political – issues that will affect the final
system

45

45

46

46

23
 2022-01-27

Requirements Elicitation
q Ways to discover requirements
q Choose participants carefully
q Make respectful use of people’s time

47

47

Interviews
q Most important and most used fact-finding
technique
o The systems analysts collects information from individuals
face to face
q Interview Structure
o Top-Down (broad to specific; most common)
o Bottom-up (specific to broad; useful for collecting details)
q Question Type
o Open-ended – broad concepts; opinions
o Closed-ended – learn or confirm facts and details
o Probing – resolve confusion; follow-up

48

48

24
 2022-01-27

Interview for Requirements Elicitation

strengths
– Interviewee can respond
freely and openly to
questions.
– Interviewee can be asked
for more feedback.
– Questions can be adapted
or reworded for each
individual.
– Interviewee’s nonverbal
communication can be
observed.
weaknesses
– Very time-consuming,
and therefore costly,
fact-finding approach.
– Success is highly
dependent on the
systems analyst's human
relations skills.
– May be impractical due
to the location of
interviewees.

49

49

Questionnaires
q Special-purpose documents that allow the analyst to
collect information and opinions from respondents.
q Facts are collected from a large number of people while
maintaining uniform responses.
o When dealing with a large audience, no other fact-finding technique
can tabulate the same facts as efficiently.
q Fixed-format questions
o Similar to a multiple choice exam question
o Must be able to anticipate potential answers to questions
o Easy to tabulate results
q Free-format questions
o Like an essay question – open-ended
o Response is unpredictable
o Harder to tabulate results

50

50

25
 2022-01-27

Questionnaires for Requirements Elicitation

strengths weaknesses
– Most can be answered
quickly (if properly
designed).
– Relatively inexpensive.
– Allow individuals to
maintain anonymity.
– Can be tabulated and
analyzed quickly (if
properly designed).
– Response is often low. How
to motivate participation?
– Incomplete questionnaires
returned – are these
worthless?
– Tend to be inflexible.
– Body language cannot be
observed.
– Cannot clarify a vague or
incomplete answer to any
question.
– Difficult to prepare a
successful questionnaire.

51

51

Observation
q Participate in or watch a person perform activities
to learn about the system
q Use when the validity of data collected using other
methods is in question.
q Use when the complexity of certain aspects of the
system prevents end-users from providing a clear
explanation

52

52

26

Observation for Requirements Elicitation
strengths
– Data gathered may be
highly reliable.
– Can see exactly what is
being done.
– Relatively inexpensive
(compared with other
fact-finding techniques).
– Can do work
measurements (if
needed).
53
Use Case Analysis
54
2022-01-27
weaknesses
– People may perform
differently when being
observed.
– Work may vary in
difficulty and volume.
– Some activities may take
place at odd times.
– The tasks being
observed are subject to
various types of
interruptions.
53
54
27
 2022-01-27

What is a Use Case?

q Use cases express and clarify user requirements.
q They define the expected interaction between user
and the system.
q Use that interaction to better describe functional
requirements
q Used extensively in the analysis phase.
q Text-based use cases are easy for the users to
understand.
q Flow easily into the creation of process models and
the data model.

55

55

Use Cases
q Represents how a system interacts with its
environment

q Illustrates the activities that are performed by

the users and the system’s responses.

q Each use case describes how an external user

triggers an event to which the system must
respond.

56

56

28
 2022-01-27

Elements of a Use Case

q Each use case has a name and number, and brief
description.
q The priority may be assigned to indicate the relative
significance.
q The actor refers to a person, another system, or a
hardware device that interacts with the system to
achieve a useful goal.
q The trigger for the use case – the event that causes
the use case to begin.
q Events triggers can be external or temporal

57

57

Request a
Chemical
Use Case

58

58

29
 2022-01-27

Use Case Basic Information

Normal Course
Ø The major steps that are performed to execute the response
to the event

59

59

Exceptions
Ø Error conditions encountered while performing use case
steps.
Ø NOT normal branches in decision logic.
Ø Lead to an unsuccessful result.

60

60

30
 2022-01-27

Use Cases in Sequence

Ø Uses cases often performed in sequence.
Ø No single use case should be too large.
Ø Important to define initial and ending states.

61

61

Preconditions and Postconditions

Ø Preconditions define what must be complete before beginning
this use case.

Ø Postconditions define what is complete when this use case

ends.

62

62

31
 2022-01-27

Use Case Practical Tips

q Use gradual refinement.
q Concentrate on describing the user’s objectives
with the system completely and accurately.
q Keep both audiences in mind – users and
developers.
q Create use cases only when needed to clarify what
the system must do from the user’s perspective.
Not needed for simple events.

63

63

Use Cases and the Functional

Requirements
q Use cases are useful tools to clarify user
requirements.
q Use cases convey only the user’s point of view.
q Transforming the user’s view into the
developer’s view through functional
requirements is one of the system analyst’s key
contributions.
q The derived functional requirements tell the
developers more about what the system must
do.

4-64

64

32
 2022-01-27

Detailed Functional Requirements

Use case content used to create more complete and descriptive functional requirements

65

65

Creating Use Cases

q Identify events the system must respond to –
develop Event-Response List
q Create use case form for the complex events
q For each use case:
Ø Identify the major steps
Ø Identify elements with each major step (inputs and
outputs)
Ø Confirm use case with users through role-playing
q Revise functional requirements as needed

66

66

33
 2022-01-27

Process Modeling

67

67

Key Definitions
q Process model
Ø A formal way of representing how a business process
operates
Ø Illustrate activities that are performed and how data
moves between them
Ø Logical process models describe processes without
suggesting how they are conducted.
Ø Physical process models include process implementation
information
q Data flow diagramming
Ø A popular technique for creating process models

68

68

34
 2022-01-27

Data Flow Diagram (DFD)

69

69

DFD Elements
q Process
Ø An activity or function performed for a
specific business reason
Ø Can be manual or computerized
Ø Includes the following:
• A number
• A name (verb phrase)
• A description
• At least one output data flow
• At least one input data flow

70

70

35
 2022-01-27

DFD Elements, con’t.

q Process, con’t.
Ø Logical process models omit any processes
that simply move or route data and leave
the data unchanged.
Ø You do include logical processes that:
• Perform computations (e.g., calculate grade
point average)
• Make decisions (e.g., determine availability of
ordered products)
• Sort, filter or otherwise summarize data (e.g.,
identify overdue invoices)
• Organize data into useful information (e.g.,
generate a report or answer a question)
• Trigger other processes (e.g., turn on the furnace
or instruct a robot)
• Use stored data (create, read, update or delete a
record)
71

71

DFD Elements, con’t.

q Data flow
Ø A single piece of data or a logical collection
of data
Ø Data Flow names describe the content of
the data flow but not how it is
implemented
Ø Always starts or ends at a process
Ø Includes the following:
• A name (noun)
• Description
• One or more connections to a process

72

72

36
 2022-01-27

DFD Elements, con’t.

q Data flow, con’t.
Ø A data flow is data in motion.
• an input of data to a process, or the output of
data (or information) from a process.
• the creation, deletion, or update of data in a
file or database (called a data store on the
DFD).
• A data flow is depicted as a solid-line with
arrow.

73

73

DFD Elements, con’t.

q Data Store
Ø Most information systems capture data
for later use.
Ø A data store is a collection of data that
is stored in some way
Ø Include the following:
• A number
• A name (noun)
• Description
• One or more input data flows
(somewhere in process model)
• One or more output data flows
(somewhere in process model)

74

74

37
 2022-01-27

DFD Elements, con’t.

q Data Store, con’t.
Ø If data flows are data in motion, think
of data stores as data at rest.
Ø Data stores should describe “things”
about which the business wants to
store data.
Ø Data flows leaving the data store are
data retrievals
Ø Data flows entering the data store are
updates or new data added

75

75

DFD Elements, con’t.

q External entity
Ø A person, organization, or system that
is external to the system
Ø Has interactions with the system (adds
data to system or receives data from
system)
Ø Include the following:
• A name (noun)
• Description

76

76

38
 2022-01-27

Depicting Business Processes with

DFDs
q Business processes are too complex to be shown
on a single DFD
q A deliberate hierarchy is created with multiple
“levels” of DFDs
q To build the hierarchy, use Decomposition
Ø Child diagrams show a portion of the parent diagram in
greater detail

77

DFD Hierarchy

o Context Diagram
decomposes into Level 0
diagram

78

78

39
 2022-01-27

DFD Hierarchy
o Processes on Level 0 diagram
each decompose into
separate Level 1 diagrams
o Processes on Level 1
diagrams may or may not be
decomposed into separate
Level 2 diagrams.
o Processes are decomposed
until each process is a single-
purpose, primitive process.

79

79

Balancing
q Ensures that information presented at one level
of a DFD is accurately represented in the next
level DFD.
q Data flows on parent diagram are carried down
to child diagram.
q Child diagram adds new processes and new data
flows

80

80

40
 2022-01-27

Steps in Building DFDs

q Build the context diagram
o Identify the external entities and the major inflows they
supply and the outflows they receive
q Identify all major processes encompassed by the
Context Diagram
o Each major event / use case is “handled” by a process
q Create DFD “fragments” for each event / use case
o Each DFD fragment is a mini-diagram showing the
process and the external entities and data stores with
which it interacts.

81

81

Steps in Building DFDs, con’t.

q Organize DFD fragments into level 0 diagram

q Decompose each level 0 process into a level 1
diagram; decompose level 1 processes into
level 2 diagrams as needed; etc.
q Validate DFDs with user to ensure
completeness and correctness

82

82

41
 2022-01-27

Integrating Use Cases

q DFDs start with events, use cases and the
requirements definition
q The DFDs often flow directly from the use cases
Ø Names of use cases become major processes on the Level
0 diagram
Ø Steps in the use case become processes on the Level 1
diagram
Ø Inputs and outputs become data flows on the Level 1
diagram (and below)

83

83

Data Modeling

84

84

42
 2022-01-27

Key Definitions
q Data model
Ø A formal way of representing the data that are used
and created by a business system
Ø Shows the people, places and things about which
data is captured and the relationships among them.
Ø Logical data model shows the organization of data
without indicating how it is stored, created, or
manipulated
Ø Physical data model shows how the data will
actually be stored in databases or files.

85

85

Key Definitions

q Entity Relationship Diagram (ERD)

Ø A popular way to depict the data model
q Normalization is the process analysts use to
validate data models.
q Data models should balance with process models

86

86

43
 2022-01-27

Using the ERD to Show Business Rules

q Business rules are constraints that are followed
when the system is in operation.
q ERD symbols can show when one instance of an
entity must exist for an instance of another to exist.
q ERD symbols can show when one instance of an
entity can be related to only one or to many
instances of another entity.
q ERD symbols show when the existence of an entity
instance is optional for a related entity instance.

87

87

An ERD Example
Entities

CUSTOMER has placed ORDER

Customer ID Order ID
Name Order Date
Address Order Total Cost
Telephone
Relationship

Attributes

88

88

44
 2022-01-27

Identifier Types
q One or more attributes can serve as the entity
identifier, uniquely identifying each entity instance
q Concatenated identifier consists of several
attributes
q An identifier may be ‘artificial,’ such as creating an
ID number
q Final decision on identifiers may postponed to the
Design Phase

89

89

Cardinality
q The number of times instances in one entity can
be related to instances in another entity
Ø One instance in an entity refers to one and only one
instance in the related entity (1:1)
Ø One instance in an entity refers to one or more
instances in the related entity (1:N)
Ø One or more instances in an entity refer to one or more
instances in the related entity (M:N)

90

90

45
 2022-01-27

91

91

Primary and Foreign Keys

q A primary key is an attribute or combination of
attributes that uniquely identifies one and only
one instance of an entity.

q The primary key becomes a foreign key in any

entity type to which it is related through a
relationship.

92

92

46
 2022-01-27

Primary and Foreign Keys

q A relationship implies that instances of one
entity are related to instances of another entity

q A foreign key is is used to identify instances of a

relationship. A foreign key always matches the
primary key (in a parent entity).

93

93

Foreign Keys

Parking ID - PK
Emp ID - PK is assigned
EMPLOYEE PARKING Emp ID - FK
Emp Name
PLACE Location
Emp Address is assigned to
one-to-one

Prod Line ID - PK Product ID - PK

includes Prod Line ID - FK
Prod Line Descrip PRODUCT
PRODUCT PRODUCT
PRODUCT Prod Description
LINE
LINE is included in
one-to-many

Student ID – PK Course ID – PK
?? FK ?? STUDENT registers for COURSE ?? FK ??
Student Name Course Name
registers
Student Address Course Descrip
many-to-many

94

94

47
 2022-01-27

Creating ERDs
q ERDs can become quite complex
q Steps in building ERDs…
Ø Identify the entities
Ø Add appropriate attributes for each entity
Ø Draw the relationships that connect associated entities

95

95

Identify the Entities

q Identify major categories of information
Ø If available, check the process models for data stores,
external entities, and data flows
Ø Check the major inputs and outputs from the use cases
q Verify that there is more than one instance of the
entity that occurs in the system

96

96

48
 2022-01-27

Add Appropriate Attributes

q Identify attributes of the entity that are relevant to
the system under development
Ø Check the process model repository entries for details on
data flows and data stores
Ø Check the data requirements of the requirements
definition
Ø Interview knowledgeable users
Ø Perform document analysis on existing forms and reports
q Select the entity’s candidate identifier (final decision
may be postponed until Design phase)

97

97

Draw the Relationships

q Start with an entity and identify all entities with
which it shares relationships
q Describe the relationship with the appropriate verb
phrase
q Determine the cardinality and modality by
discussing the business rules with knowledgeable
users

98

98

49
 2022-01-27

ERD Building Tips

q Data stores in DFD generally correspond to entities

q Don’t include entities associated with

implementation of the system (e.g., archive files of
older data). They will be added later.

99

99

Intersection Entities
q A new entity is created to store information about
two entities sharing an M:N relationship
Ø Remove the M:N relationship between two entities
and insert new entity between them
Ø Create two 1:N relationships: original entities are
parents to the new child intersection entity
Ø Name the intersection entity
Ø Migrate parent entity primary keys to new entity as
foreign keys (possibly also concatenated primary key)

100

100

50
 2022-01-27

Resolving M:N with an Intersection Entity

Student ID – PK Course ID – PK
?? FK ?? STUDENT registers for COURSE ?? FK ??
Student Name Course Name
registers
Student Address Course Descrip
many-to-many

registers for COURSE registers

STUDENT REGIS- COURSE
TRATION

Student ID (PK FK) Course ID - PK

Student ID - PK
Course ID (PK FK) Course Name
Student Name
Semester (PK) Course Descrip
Student Address
Final Grade

101

101

ERD Guidelines and Best practices

q Entities should have many occurrences
q Avoid unnecessary attributes
q Apply correct cardinality and modality
q Break attributes into lowest level needed
q Assumptions should be clearly stated

102

102

51
 2022-01-27

Balancing ERDs with DFDs

q All analysis activities are interrelated
q The DFD data components need to balance the
ERD’s data stores (entities) and data elements
(attributes)
q Check that all data stores and elements
correspond between models. Data that is not
used is unnecessary

103

103

CRUD Matrix
q The CRUD (create, read, update, delete) matrix is
a table that depicts how the system’s processes
use the data within the system.

q CRUD matrix is a useful tool to clearly depict the

interrelationship between process and data
models.

104

104

52
 2022-01-27

Using
CRUD
Matrix

105

105

Normalization

q Techniques used to validate data models

q Series of rules applied to logical data model to
improve its organization
q Three normalization rules are common

It is important that a database is normalized to minimize redundancy

(duplicate data) and to ensure only related data is stored in each table. It
also prevents any issues stemming from database modifications such as
insertions, deletions, and updates.

106

106

53
 2022-01-27

First Normal Form (1NF)

qContains no repeating elements
Ø Any entity that contains one or more multivalued
attributes must be transformed
Ø In other word, do any attributes (or groups of attributes)
occur more than once for a single occurrence of the
entity? If yes it is not 1NF.

107

107

108

108

54
 2022-01-27

Second Normal Form (2NF)

qA relation is in 1NF, and the key attributes determine
all non-key attributes.

qA violation of 2NF occurs when there is a composite

key, and part of the key determines some non-key
attributes. This is when the entity identifier contains
two or more attributes, and the non-key attribute
depends on part of the entity identifier.

109

109

110

110

55
 2022-01-27

Third Normal Form (3NF)

qA relation is in 2NF, and no non-key attributes can be
derived from one or more other non-key attributes
(i.e., the non-key attributes should be independent).

q3NF is violated when there exists a dependency

among non-key attributes (transitive dependency).
Transitive dependency is resolved by moving the
dependency attributes to a new entity with one-to-
many relationship. In the new entity the determinant
of the dependency becomes the entity identifier.
111

111

112

112

56
 2022-01-27

Summary of
Normalization
Steps

113

113

System Design Phase

114

114

57
 2022-01-27

Transition from Requirements to Design

q In Systems Analysis we figure out…

o What the business needs
q In System Design we figure out…
o How to build the system that fulfills those needs
q All of the “logical” work from Systems
Analysis is converted to the “physical”

115

115

From Requirements to Specification

q Design phase
o Decide how to build the system
o Create system requirements that describe all
technical details for building the system
q System specification
o Final deliverable from design phase
o Conveys exactly what system the development team
will implement during the implementation phase

116

116

58
 2022-01-27

Design Phase Steps

q Determine system acquisition strategy (make, buy, or
outsource)
q Determine the technical architecture for the system
q Address security concerns and globalization issues
q Make hardware and software selections
q Determine the way that users will interact with the
system (interface, inputs, and outputs)
q Design the programs for the underlying processes
q Design the way data will be stored
q Create final deliverable - the system specification

117

117

System Acquisition Strategies

118

118

59
 2022-01-27

Ways to Acquire a New System

q Custom development (build from scratch) in-house
q Purchase software (and possibly customize it)
o Install on our own computers, or
o Obtain access from a software provider (host)
q Outsource development to third party, who might
o Build system from scratch for us, or
o Purchase software for us, customize and install it

119

119

Custom Development
pros
§ Get exactly what we want
§ New system built consistently
with existing technology and
standards
§ Build and retain technical
skills and function knowledge
in-house
§ Allows team flexibility and
creativity
§ Unique solutions created for
strategic advantage
cons
§ Requires significant time and
effort
§ May add to existing backlogs
§ May require skills we do not
have
§ Often costs more
§ Often takes more calendar
time
§ Risk of project failure

120

120

60
 2022-01-27

Purchased Software
Pros
§ No need to “reinvent the
wheel” for common business
needs
§ Tested, proven product
§ Cost savings
§ Time savings
§ Utilize vendors’ expertise
§ Some customization may be
possible
cons
§ Rarely a perfect fit
§ Organizational processes
must adapt to software
§ Reliance on vendor for
maintenance and future
enhancements
§ Won’t develop in-house
functional and technical skills
§ Unique needs may go unmet
§ May require system
integration

121

121

Purchased Software
q Application service providers (ASP) supply
access to software on a pay-as-you-go basis
q Many applications today are “in the cloud”…
o ASP – provider hosts someone else’s software
o SaaS – software vendor hosts its own software
o Considerable savings – no hosting infrastructure
needed; host provides everything
q Risks include
o Fear of losing confidential information
o Performance

122

122

61
 2022-01-27

Purchased Software
q Analyze the vendor as well as the software
functionality
q Verify vendor claims with others
q Look carefully at vendor support
q Assess long-term viability of vendor as an on-
going business
o A new software company may have a great idea, but
can they survive as a business over the long haul?
o If the vendor is an acquisition target, what will
happen to the product?

123

123

Systems Integration
q Building systems by combining packages,
existing (legacy) systems, and custom software
written for integration
q Integrating data between various parts of the
system is the key challenge
q Many consultants specialize in systems
integration

124

124

62
 2022-01-27

Outsourced Development
pros
§ Hire expertise we don’t have
§ May save time and money
§ Lower risk
cons
§ No opportunity to build in-
house expertise
§ Reliance on vendor
§ Future options limited
§ Security – potential loss of
confidential information
§ Performance based on
contract terms

125

125

Outsourcing
q Hiring an external vendor, developer, or service
provider to supply the system
q Can also obtain custom system created by
outsourcer
q Can reduce costs and/or add value (resources,
experience)
q Risks include
o Losing confidential information
o Losing control over future development
o Losing learning opportunities

126

126

63
 2022-01-27

Architecture Design

127

127

Key Definitions
q Architecture design
o Plans for how the system will be distributed across
computers and what hardware and software will be
used for each computer.
q Hardware and software specification
o Describes the hardware/software components in
detail to aid those responsible for purchasing those
products.

128

128

64
 2022-01-27

Objective of Architecture Design

q Assign the software components of the
information system to the hardware devices
of the system in the most advantageous way.
q The major architectural components of any
system are the software and the hardware.

129

129

Architectural Components
q Software systems can be divided into four
basic functions:
o Data storage.
o Data access logic: the processing required to access
stored data.
o Application logic: the logic documented in the
DFDs, use cases, and functional requirements.
o Presentation logic: the display of information to the
user and the acceptance of the user’s commands.

130

130

65
 2022-01-27

Architectural Components (cont’d)

q The three primary hardware components:

o Client computers: Input-output devices employed
by users (e.g., PCs, laptops, handheld and mobile
devices, smart phones)
o Servers: Larger multi-user computers used to
store software and data.
o Network: Connects the computers.

131

131

Client-Server Architectures
q Client-server architectures balance the
processing between client devices and one
or more server devices.
q Generally, clients are responsible for the
presentation logic, and
q the server(s) are responsible for the data
access logic and data storage.
q Application logic location varies depending
on the C-S configuration chosen.

132

132

66
 2022-01-27

Benefits of Client-Server

q Scalable
q Can support different types of clients and
servers through middleware.
q The presentation logic, the application logic,
and the data processing logic can be
independent.
q If a server fails, only the applications requiring
that server are affected – highly reliable.

133

133

Client-Server Tiers
q There are many ways in which the application
logic can be partitioned between the client side
and the server side.
q The arrangement in Figure 8-1 is called two-
tiered architecture.

8-134

134

67
 2022-01-27

Two-Tiered Client-Server Architecture

Ø Thick client – most of application logic on the client side
(shown here)
Ø Thin client – little application logic on the client side; most
shifted to server side

135

135

Three-Tiered Client-Server Architecture

Ø Adds “specialized” servers – one for application logic;
one for data base tasks

136

136

68
 2022-01-27

n-Tiered Client-Server Architecture

Ø Adds “specialized” servers – one for Web-related
business logic; one for application logic; one for data
base tasks

137

137

Adding “Tiers” in the Architecture

advantages
§ Modular business logic
components are shareable
across applications
§ Separating the processing
among multiple servers
makes it possible to balance
the server loads efficiently.
disadvantages
§ More tiers place a higher load
on the network.
§ More difficult to implement
since the servers must
communicate effectively.

138

138

69
 2022-01-27

Server-Based Architecture
Ø Zero-client used today in Virtual Desktop Infrastructure
(VDI)

139

139

Mobile Application Architecture

q Rich client – involves processing on the mobile
device using its resources. Presentation logic,
business logic, and data access logic on the
client side.
q Thin Web-based client – business and data
access logic on the server side; always
connected to server.
q Rich Internet application – browser-based; uses
some technologies on client device to provide a
rich user interface (e.g., JavaScript).

140

140

70
 2022-01-27

Mobile Application Options

q Native app – written to run on specific device
with specific operating system.
q Mobile Web app – browser-based; platform
independent. Limited user experience.
q Cross-platform frameworks and Progressive
Web Applications (PWAs) – develop in web-
based technologies and use framework to
deploy to multiple devices.

141

141

Cloud-Based Systems
q Server virtualization involves partitioning a
physical server into smaller virtual servers.

q Storage virtualization involves combining multiple

network storage devices into what appears to be
single storage unit.

q Examples of virtualization system tools are

VMware, Xen, and Hyper-V.

142

142

71
 2022-01-27

Source: “Virtualization-support Cases in Engineering Education” by José Soler

143

143

Cloud Computing
q Cloud computing – everything from computing
power to computing infrastructure, applications,
and business processes can be delivered as a
service wherever and whenever needed.

q The “cloud” can be defined as the set of

hardware, networks, storage, devices, and
interfaces that combine to deliver aspects of
computing as a service.

144

144

72
 2022-01-27

A cloud is a virtualized dynamically scalable pool of shared resources

accessed over a network

145

145

Advantages of Cloud Computing

q Customers are billed for resources as they are used.
q Cloud services typically have standardized APIs
(application program interfaces).
q Reduced Costs
q Efficient Resource Sharing
q Elasticity , Scalability, and ease of Expansion
q More Mobility
q Consumption based costs
q Instant software updates

146

146

73
 2022-01-27

Scalable and Elastic:

• Elasticity: The resources are dynamically

allocated and can be increased or decreased
quickly, based on demand.
• Fully automated

147

147

Metered by Use:
• Services are metered, like a utility
• Users pay only for services used
• Services can be cancelled at any time

148

148

74
 2022-01-27

Designing the Architecture

q Business requirements -> technical environment

requirements -> application architecture

q If not, other nonfunctional requirements become

important.

149

149

Selecting an Architecture Design

q Lower costs often used to justify choice of client-
server
q Recommended selection process:
o Expand nonfunctional requirement details
o Base architecture selection on the detailed
nonfunctional requirements
§ Operational,
§ Performance,
§ Security, and
§ Cultural/political

150

150

75
 2022-01-27

Operational Requirements
Requirement Definition Example
Technical Special hardware, software, All office locations have
Environment and network requirements always-on network
imposed by business connection permitting real-
requirements time database updates
System The extent to which the The system will read and
Integration system will operate with write to the main inventory
other systems database
Portability The extent to which the The system must operate
system will need to operate in with mobile devices (Android
other environments and iOS)
Maintainability Expected business changes to The system must
which the system should be accommodate new
able to adapt manufacturing plants

151

151

Performance Requirements
Requirement Definition Example

Speed Time within which the system Network transaction

must perform its function response time <= 4
seconds

Capacity Total and peak number of users Maximum of 2000

and the volume of data expected simultaneous users at
peak use times

Availability and Extent to which the system will 99% uptime performance
Reliability be available to the users and the
permissible failure rate due to
errors

152

76
 2022-01-27

Security Requirements
Requirement Definition Example

System Value Estimated business value of A complete loss of all system

Estimates the system and its data data would cost $20 million

Access Control Limitations on who can access Inventory item changes can
what data be made only by managers for
items in their own
department
Encryption and Defines what data will be Data will be encrypted from
Authentication encrypted where and whether the user’s computer to the
authentication will be needed Web site to provide secure
for user access ordering
Virus Control Controls to limit viruses All uploaded files will be
checked for viruses before
being saved in the system

153

153

Cultural/Political Requirements
Requirement Definition Example

Multilingual The language(s) the The system will operate in

system users will need English, French, and Spanish
Customization Specification of what Country managers will be able to
aspects of the system can define new fields in the product
be changed by local users database to capture country-
specific information
Making Unstated Explicitly stating All weights will be stated in
Norms Explicit assumptions that differ pounds and in kilograms
from country to country

Legal The laws and regulations Personal customer information

that impose system cannot be transferred from
requirements European Union countries to US

154

154

77
 2022-01-27

Nonfunctional
Requirements and the
Architecture Design

155

155

User Interface Design

156

156

78
 2022-01-27

Key Definitions
qSystem Interface: “connections” with other systems
to exchange information.
qUser Interface: “connections” with users.
ØThe navigation mechanism provides the way for users
to tell the system what to do
ØThe input mechanism defines the way the system
captures information
ØThe output mechanism defines the way the system
provides information to users or other systems
qGraphical user interface (GUI): most common type of
interface in use today.
157

157

Usability Concept
qThe system is easy to use and easy to learn
qTasks are completed more efficiently and with more
accuracy
qMistakes with system are reduced
qUser satisfaction with new system is increased
qAdoption of system is more likely

158

158

79
 2022-01-27

Principles for User Interface Design

qLayout
qContent awareness
qAesthetics
qUsage level
qConsistency
qMinimize user effort

159

159

Layout Concepts
• The screen is often divided into three boxes
– Navigation area (top)
– Status area (bottom)
– Work area (middle)
• Information can be presented in multiple
areas
• Similar areas should be grouped together

160

160

80
 2022-01-27

More Layout Concepts

• Areas and information should minimize user
movement from one to another
• Ideally, areas will remain consistent in
– Size
– Shape
– Placement for entering data
– Reports presenting retrieved data

161

161

Model Layout for Web Page

162

162

81
 2022-01-27

Content Awareness
qAll interfaces should have titles
qMenus should show where you are and where you
came from to get there
qIt should be clear what information is within each
area

163

163

Aesthetics

q Interfaces need to be functional and inviting to use

q Avoid squeezing in too much, particularly for novice
users
q Design text carefully
Ø Be aware of font and size
Ø Avoid using all capital letters
q Colors and patterns should be used carefully
Ø Test quality of colors by trying the interface on a
black/white monitor
Ø Use colors to separate or categorize items
164

164

82
 2022-01-27

Usage Level
• Some people will be frequent, heavy users of
the system
• Frequent users desire ease of use – quick and
easy completion of job tasks
• Other people may use the system infrequently
• Infrequent users desire ease of learning –
quick and easy ways to figure out what to do.

165

165

Usage Level
• User interface design should anticipate the types
of users expected.
• For systems primarily used by frequent users,
include ways to perform tasks directly (hot keys,
short-cut keys, etc.).
• For systems primarily used by infrequent users,
include careful menu designs, tool tips, and
extensive help systems.
• For systems with both user types, incorporate
both user preferences in design as much as
possible
166

166

83
 2022-01-27

Consistency
• Elements are the same throughout the
application
• Enables users to predict what will happen
• Reduces learning curve
• Considers elements within an application and
across applications
• Pertains to many different levels
– Navigation controls
– Terminology
– Report and form design

167

167

Example of
Inconsistent Elements
Note the different button styles,
colors, and font styles.

168

168

84
 2022-01-27

Minimize Effort
• Three clicks rule
– Users should be able to go from the start or main
menu of a system to the information or action
they want in no more than three mouse clicks or
three keystrokes

169

169

Special Issues of Touch Screen Design

qIdeal for information display but not data entry.
qPlace content at top and navigation controls at
bottom so finger does not obscure content area.
qPlace labels on top of navigation controls.
qSize objects correctly for “fat fingers.”
qInclude adequate spacing between objects.
qConsider needs of left-handed/right-handed users.

170

170

85
 2022-01-27

User experience (UX) design is the process of enhancing user satisfaction by improving
the usability, accessibility, and pleasure provided in the interaction between the user
and the product.
171

171

System Implementation Phase

172

172

86
 2022-01-27

System Implementation
• Implementation is the development of all parts of the
system: the software itself, documentation, and new
operating procedures.

173

173

The Programmer Paradox

• More is not always better than less!

• After the “right” number of people are assigned to a

programming task, adding more people slows down rather
than speeds up completion of the project.

• Brooks's law: Adding manpower to a late software project

makes it later.

• Projects requiring a large team should be broken into a series

of independent, smaller parts.

174

174

87
 2022-01-27

Project Manager’s Tasks During

Programming
• Assigning the programmers
o Match programming tasks with programmer capabilities
o When skills are deficient, apply mentoring and training

• Coordinating the activities

– Weekly meetings
– Create and follow standards
– Implement change control mechanisms
– Use program log to monitor program changes

• Managing the schedule

– Use initial time estimates as a baseline
– Revise time estimates as construction proceeds

175

175

Version Control
Version control is a system that records changes to a file
or set of files over time so that you can recall specific
versions later.

Version control allows you to revert files back to a

previous state, revert the entire project back to a
previous state, compare changes over time, see who last
modified something that might be causing a problem,
who introduced an issue and when, and more.

When using a VC system you take snapshots of the state

of your project (commits) at regular intervals. If you make
a mistake you can easily go back to a previous snapshot.

176

88
 2022-01-27

Why Version Control?

– Revert files back to a previous state
– Compare changes over time
– See who last modified something
– Generally, if you screw things up or lose files, you
can easily recover

177

Version control is essential

– when you have multiple developers working on
the same code base.
– when you are supporting multiple versions of a
software over time.
– when a bug is reported in one version of the
product you have to rebuild that version of the
product, fix the bug and ship an updated version.

178

89
 2022-01-27

The two main categories of version control systems are

centralized (e.g. subversion or svn) and decentralized
or distributed (e.g. git). With a centralized system the
repository is located in one place. With a distributed
system each user has a copy of the repository.

Centralized Distributed
Centralized: A single server contains all the versioned files, and clients check out files
from that central place. Disadvantage: single point of failure. If the centralized
repository is down, no one can do work that requires version control.

Distributed: Clients fully mirror the repository and can commit changes when off-line.

179

Git vs. GitHub

• Git
– Distributed source-control system
– Work with local and remote repositories
– Git Bash – command line interface for Git
– Free, open-source

• GitHub (The Social Network for Developers)

– The world's #1 source code hosting site
– Free for open-source projects
– Paid plans for private projects

180

180

90
 2022-01-27

Git: How It Works?

Local computer Remote repository
(your laptop) (e.g. GitHub.com)

181

181

Git and GitHub Terminology

• Repository (repo)
– Keeps your project files (local and remote repo)
• Clone a remote repository
– Download a working copy from GitHub to your
computer
• Commit changes
– Save your changed files to the local repository (not in
GitHub!)
• Sync (synchronize changes)
1. Pull from GitHub – download (fetch) latest changes & merge them
2. Push to remote repository – upload the changes to GitHub

182

182

91
 2022-01-27

Commit The fundamental unit of a revision control system. A

snapshot of a repository at a specific time, annotated with a
log entry ("commit message") that describes the changes
made since the last commit.

Branch A timeline or series of commits. The mainline branch

is usually called the "master" or "trunk." Branches can diverge
from the trunk, creating an alternate timeline to develop a
new feature without touching the stable code. These changes
can later be merged into the main branch.

Workspace The project’s working directory. The files in the

workspace reflect the state of the current branch as of the last
commit, plus any changes since then. Untracked files are not
associated with a particular branch, and show up in all of
them.

183

Files tracked by git are in one of three states: committed,

modified, or staged.

This leads us to the three main sections of a Git project: the

.git directory, the working directory, and the staging area.

184

92
 2022-01-27

Untracked Tracked

Each file in your working directory can be in one of two states: tracked or
untracked. Tracked files are files that are recognized by git. They are under
version control. Tracked files can be unmodified, modified, or staged.

185

revision history
master
branches

Create project
Feature A
Add function A Add feature A

Fix bug #1 commits

Add help text

Merge feature A Fix bug in feature A

into master

186

93
 2022-01-27

Testing
• Testing helps ensure that the system performs as
outlined in the specifications.
• It may be difficult to reproduce sequence of events
causing an error
• Testing must be done systematically and results
documented carefully

187

187

Test Plan

188

188

94
 2022-01-27

Categories of Testing
• Stub testing
– Tests control structures before all modules are written
• Unit testing
– Tests each module – Does it performs its function?
• Integration testing
– Tests the interaction of modules - do they work together?
• System testing
– Tests to assure that the software works well as part of the overall
system
• Acceptance testing
– Tests to assure that the system serves organizational needs

189

189

Stub Testing

190

190

95
 2022-01-27

Unit Testing
qBlack Box Testing
Ø Focuses on whether the unit meets requirements stated in
specification
qWhite-Box Testing
Ø Looks inside the module at actual code

191

191

Integration Testing
• User interface testing
– Tests each interface function
• Use-scenario testing
– Ensures that each use scenario works correctly
• Data flow testing
– Tests each process in a step-by-step fashion
• System interface testing
– Ensures data transfer between systems

192

192

96
 2022-01-27

System Testing
• Requirements Testing
– Ensures that integration did not cause new errors
• Usability Testing
– Tests how easy and error-free the system is in use
• Security Testing
– Assures that security functions are handled properly
• Performance Testing
– Assures that the system works under high volumes of
activity (e.g., simultaneous users, peak transaction volume)
• Documentation Testing
– Analysts check the accuracy of documentation

193

193

Acceptance Testing
• Alpha Testing
– Performed by users to assure they accept the
system; frequently repeats earlier tests
• Beta Testing
– Uses real data, not test data. Actual users monitor
for errors or needed improvements.
• User sign-off following Acceptance Testing indicates the system
is ready to be placed into production.

194

194

97