Basics of System Development

Basics of System Development (Embedding)
Basics of System Development (Embedded)
Chapter 1 Development of Software
« Learning Goals »
 Learn lifecycle process and each process of software.
 Learn sub-process that is related to the whole development process.
 Learn process models of software development.
 Learn types of orientation in software analysis and design.
 Learn analysis methods.
 Learn design methods.
1 ©emBex Education Inc.

1.1 Flow of software development
Flow of software development

 Software development flow before receiving orders to start of operation is as shown in the
diagram below.
(proposal/quotation)
Start of operation
Receiving order
Delivery of the
Development
software
Planning
Development
 Process that a software developer takes charges
 Cutover, service-in, release

These terms mean to start operation of a newly developed system.
It is also called release because software is “released” from a software engineer.
 Agreement
NDA: Non-Disclosure Agreement, service agreement
 Methods of quotation
Various methods are used to estimate cost to create a quotation. Please refer to the appendix for major methods of
quotation.

1.2 Lifecycle process
Lifecycle process
 A set of process from requirement definition to maintenance is called a lifecycle process of
software.
Process
 Each task unit of the lifecycle process is called “Process.”
Lifecycle process Process
Order Requirement Detailed

Basic design
placement Definition design
Disposal Maintenance Test Implementation
 Sub-process
Operation that has to be done regularly during the whole development project is called sub-process or
supplementary process.
(details will be explained in “1.3 Sub-process”)
 Standards for lifecycle process

Domestic and international standards such as SDEM, JIS, ISO, and IEEE are stipulated for a lifecycle process.
In Japan, JIS X 0170 is the most known standard.
 What you have to keep in mind for a lifecycle process

“Next process is a customer”

1.2.1 Requirement Definition
What is a requirement definition?

 In the requirement definition, functions and performance required in the system are
identified.
Purposes of the requirement definition

 To define requirement (of functions) of customer clearly to arrive at mutual understanding
of the software between the customer and developer.
 To confirm feasibility and non-functional requirements.
Outcome
 Requirement Definition Document: summarizes items to be realized in the system based on
requirement from customer
Requirement Detailed
Basic design
Definition design
Maintenance Test Implementation
 Request Definition Document

Before defining requirements, Request Definition Document may be created.
Request Definition Document: a document created through communication with the customer on what is required
 Non-Functional Requirements
Requirements other than actual functions such as performance and security.

1.2.2 Basic design
What is basic design?

 Determines external functions and configuration of a system (from a viewpoint of the user)
based on Requirement Definition Document.
Purposes of basic design

 To divide the whole system into modules before determining external specifications such as
functions, data, and screens/forms of each module.
 To identify interface specifications between the system and external systems or devices.
Outcome
 Basic Design Document (External Design Document)
System
Design
external
system
functions
Basic design
Definition design
*Inside behavior and

implementation methods
are not included
 Different terms for “Basic Design”

Some organizations or projects use terms like “External Design” or “Summary Design.”
 Module
A module is a part that has a certain function, constituting a system.

1.2.3 Detailed design
What is detailed design?

 Determines internal data of program, procedures, etc., based on Basic Design Document.
Purposes of detailed design

 To identify how the system functions internally for each function unit.
 To identify hierarchical structure inside the system before modularization.
 To identify set of data flow of each function unit.
Outcome
 Basic Design Document (Internal Design Document)
System
Designs how
the system
Basic design
Definition design functions
internally
 Other term for “Detailed Design”

When Basic Design is called External Design, Detailed Design would be called Internal Design.

1.2.3.1 Independence of modules
Independence of modules
 If each module is highly independent, maintainability and expandability of the system is
improved.
Index to measure independence of modules

 Module strength and degree of module coupling

1.2.3.1.1 Module strength
Module strength
 An index to measure independence of modules based on strength of relationship between
components, i.e. functions and data the system deals with, within the module.
 When strength of modules is stronger, it is regarded as better.
 Strength of a module with simple functions tends to be stronger.
 When versatility is required to a module, strength of the module tends to become weaker.
> A module with logical strength is highly versatile.
Strong Functional strength A module that executes a single function

(good)
Informational strength A set of several functions that deal with the same data structure
Communicational strength A set of function is executed with communicating data
Procedural strength A set of function is executed according to the order
A set of functions that needs to be implemented simultaneously

Temporal strength
Initialization and finalization are the typical processes
A module that has multiple functions and executes one of the
Logical strength functions according to conditions
W eak
(bad) Cipher strength A combination of functions that are not related with each other
 Module strength
It is also called “degree of cohesion.”

1.2.3.1.2 Degree of module coupling
Degree of module coupling

 An index to measure independence of a module based on strength of coupling determined
by data transfer between modules, etc.
 Degree of coupling is expressed as “strong/weak” or “tight/loose.”
 If degree of coupling is loose, it is regarded as “better.”
 If you improve independence of data between multiple modules (capsulation), degree of module
coupling tends to become loose.
Loose Data coupling A coupling where simple data is transferred not using common area or argument
(weak)
A coupling where data structure is transferred not using common area or argument
Stamp coupling
Transferred data may include unused data
A coupling where switches are transferred as parameters, and changes its process
Control coupling according to the value
A coupling where only necessary data that exist in common area are used by more
External coupling than one module
A coupling where same data that exist in common area are used by more than one
Common coupling module
Tight
(strong) Content coupling A coupling where part of content of other module is shared
 External coupling
External coupling is sometimes regarded as a coupling where data having a data format that are externally provided
is shared.

1.2.4 Implementation
What is implementation?
 After an executable module is created through coding with specified programming
language, it is placed in working condition into the target hardware or software.
 If there is anything wrong with it, modify the software (debug).
Purpose of implementation
 Code a software according to design documents so that it can be operated before
transferring it to test process.
Outcome
 Source code
 Execution module
Basic design
Definition design
10
 Other terms for “Implementation process”

It is also called “Programming” or “Production.”
 Programming languages for implementation

C language, C++, Java, Assembly language, etc.
 Reverse engineering
Creating an outcome through a backward procedure, taking steps from the end to the beginning of a software
development process, e.g. creating a source code based on implementation modules or creating a program design
document based on source code is called reverse engineering.

1.2.5 Test
What is test?
 Runs a created program to check if it is implemented according to the specifications.
Purpose of testing
 To evaluate quality of created program and improve the quality.
 To detect a bug.
Outcome
 Test specifications
 Test results/test results report
Delivery of the software

 Software will be delivered when it passes “Acceptance Test” carried out at the end of test
process.
Basic design
Definition design
11
 About a test
Refer to “Chapter 4 Software test” for details.

1.2.6 Maintenance
What is maintenance?
 Monitors a product that is actually used by a user whether it is functioning properly.
 Respond properly when business operation is hindered due to problems of the software
and/or when operation efficiency degrades by wrong usage of the software because proper
usage is not clearly described.
Purpose of maintenance
 To improve customer satisfaction through assuring software quality as part of the service.
 Malfunctions of software not revealed during test process may come to light afterwards or the
software may not be easy to use for users.
Basic design
Definition design
12
 Operation
Operating delivered software according to its operation rules and/or designing operation rules themselves is called
“Operation work” that is usually carried out in combination with maintenance work.
They may be called collectively as “Operation and maintenance work.”
 Bathtub curve
A graph showing time dependence of number of bugs that occurred after maintenance.
At first, malfunctions that could not be detected with test occur. After that, occurrence of bugs gradually decreases
before starting to increase after a certain period of time.
Number of
bugs occurred Wear out
Stable
period
Infant
mortality
failure
Time
Bathtub curve

1.3 Sub-process
Sub-process
 Some operations are carried out regularly other than operations directly related to the
development process with system development. This is called a “Sub-process” or a
“Supplementary process.”
Configuration of sub-process
Sub-process name Description
Schedule management (progress management),
Project management Review/meeting management, Member management
Test plan management, Regulations management,
Quality control Metrics management, Quality factor management, Bug
tracking
Configuration management, Version/Revision
Version management management
Development environment Hardware management, Software management,
management Communication tool management
Prevents invasion by a malicious program from outside
Security management
and leakage of confidential information stored within
Risk management Countermeasures for assumed risks
13
 Risk management
It refers to a process managing risks at an organization level to prevent or mitigate hazard (origin and cause of
damage) or loss.
 PMBOK (Project Management Body Of Knowledge)

Basic body of knowledge on project management that Project Management Institute (PMI) developed.
Techniques and methods of project management are summarized.
The first edition was published in 1987, and in 2017 the sixth edition was released.

1.3.1 Project management
Project management
 To manage the whole system development that many people are engaged so as to
proceed with the project as planned is called “Project management.”
 Four items of person, material goods, and money as well as information are regarded as
the resources of project management and supply of the resources is controlled as
necessary.
 Schedule management
 To manage if a task proceeds as planned.
 Usually a progress management table called Gantt chart is used for management.
 Member management
 Management of number of personnel engaged in a development project, working hours, motivation,
education, etc.
 Manager motivates each member so that they can perform with highest productivity.
 Review/meeting management
 Proper reviews and meetings need to take place in an organization to realize a successful project.
14
 Review
Review tends to be carried out without identifying its objectives. Moderator (facilitator of the review) must clearly
declare purposes of the review and lead the discussion so as not to deviate from the topic.
Please refer to the appendix for details of review.

1.3.2 Quality control -1-
Quality Control (QC)

 An idea to evaluate quality characteristics to measure quality objectively both from the view
points of developer and user was developed. Quality characteristics are items and factors
that constitute quality.
 Test plan management

 Manages planning and implementation of a test.
 Defines test levels according to V model to plan and implement each test level.
 Regulations management
 Define description rules for standardizing formats and improvement of readability of project
documents.
 Coding rules, Design document rules (template)
 Metrics management
 Measures and manages productivity such as number of lines or pages written per unit time, and
number of bugs found per unit time to identify best practice and rules for all operations related to the
development.
 It is necessary to take the metrics data several times on a regular basis, not just once, to find out
tendency and measures.
15
 Quality characteristics of software

Quality characteristics of software are the items to be considered separately, for example, in terms of efficiency or
safety of the software.
Please refer to the appendix for concrete examples.

1.3.2 Quality control -2-
Quality Control (QC)

 Quality factor control
 There are various aspects as to the quality necessary for a system.
 Identify the requirements for the system to be developed, and manage the realization process of such
requirements.
 Bug tracking
 Continuous recording and sharing of information on malfunctions from identification and modification
of bugs found on the software.
 System for bug tracking is called a bug tracking system.
> Redmine
> Bugzilla
> Trac
> Mantis
> JIRA
> ･･･
16
 Column: Bug fix

When finding a bug, you must conform to strict rules stipulated within the project to deal with it.
Generally, at component test (unit test) level, the programmer can modify the program freely without
following approval process or the likes.
However, at the integration test step or later, you need to seek approval from the head of the project for a
bug fix.
With a conventional procedure, a form called “Bug tracking slip” was circulated for a bug fix. As a “Bug
tracking system” is widely used recently to manage flow starting from bug detection to approval for a bug
fix, and testing the modification.

1.3.3 Version management
Version management
 A system to manage modification history of edited files.
 In software development, it mainly refers to a source code management.
 Software for version management is called a “Version management system.”

 CVS (Concurrent Versions System)
 SVN (SubVersioN ) Master data of all the
 VSS (microsoft Visual SourceSafe ) Check out developing software
asset exist in a server
 Git
Development PC
 ･･･
Check in
Development PC
Repository server
Development PC
Configuration of version management system

 Configuration management
 Version management system manages configuration of software asset at the same time.
17
 Types of versions
There are four different types of versions
• Major version: changes when applying fundamental modifications to a product.
• Minor version: changes when applying large specification changes and/or adding functions to a product.
• Revision: changes when applying specification changes and/or adding functions to a product.
• Build version: changes for each modification patch of a product.
A complete set of version numbers consist of these four types of version number divided by periods i.e., "(major
version number).(minor version number).(revision number).(build version number)."
Ex.) ver. 1.2.2.15

1.3.4 Development environment management
Development environment management

 Manages equipment and software so that members engaged with the development can
work productively.
 It is also called an infrastructure management.
 Object of the management

<Hardware> <Software>
Development PC OS (W indows, Linus, MacOS, etc.)
Development servers Integrated development environment
(repository servers, groupware servers, etc.) Development languages
Test environment servers DBMS
Target W eb server software/servlet container
Version management tools
Project management tools
<Communication tools> Antivirus security software
E-mail Bug tracking tools
Telephone Document creation tools (MS-Office etc.)
Groupware Other tools
Video conference environment
18

1.3.5 Security management
Security management
 Prevents invasion by a malicious program from outside and leakage of confidential
information such as customer information stored within.
 Prevent invasion by a malicious program from outside

 Restrict carrying in external storage devices such as CD-Rs, DVD-Rs, HDDs, USB flash drives,
laptop PCs by hand.
 Install an antivirus security software to client machines and servers.
 Restrict domains to access on the internet.
 Monitor invalid access from outside.
 Prevent leakage of confidential information stored within

 Restrict carrying out external storage devices such as CD-Rs, DVD-Rs, HDDs, USB flash drives,
laptop PCs by hand.
 Conclude a non-disclosure agreement with members engaged in the development.
 Monitor files exchanged by e-mails and groupware.
 Restrict access to confidential information.
19
 Non-disclosure agreement
Also called NDA (Non-Disclosure Agreement).
It is an agreement to close before transactions not to leak undisclosed information such as trade secret or personal
information.

1.4 Development process models
What are development process models?

 There are several general patterns for software development method. They are called
“Software development process models (referred to as development process models
hereinafter).”
Typical development process models

 Waterfall model
 Prototyping model
 Spiral model
20
 Other terms for Development Process Model

Development Process Model is also called "Development Process," "Development Model," or "Process Model."

1.4.1 Waterfall model
Waterfall model
 A software development model proposed for the first time.
 As shown in the diagram below, it is characterized with a linear sequential process that are
carried out from the top to the bottom like a waterfall.
 Outcomes generated at each process step to be transferred to the next process step are
called products.
Requirement Requirement Definition Document

Definition Process
Basic design Basic Design Document
Product
Detailed Design Document
Detailed design
Implementation Execution module
Test Product
Maintenance
21
 Upstream process/downstream process

With waterfall model, process steps from requirement definition to basic design are usually called "upstream
process," and process steps afterwards are usually called "downstream process."
 Advantages and disadvantages of waterfall model

<Advantages>
• Since classification of processes is clear, progress management is easy
• Unless such problem as specification change takes place, development cost is minimum
<Disadvantages>
• All the requirements and design need to be determined before implementation
• Reworking due to specification change and other tasks would cause a large loss of man-hour
• User cannot use the system not even partly until all the development process is over
 Column: Waterfall model is the basic

Waterfall model is a classic development process model.
Various development process models have been developed and evolved based on this model through
amending its deficiencies.
Development process models introduced in the later pages succeed the lifecycle of waterfall model.

1.4.2 Prototyping model

Prototyping model
 Create a simple prototype at requirement definition step, and obtain evaluations and
feedback from customer to identify customer’s requirement to proceed with the
development.
 Customer will grasp the idea of the system through iteration of prototyping and feedback
from the customer thereby eliminating a gap between customer’s requirement and
understanding of the developer.
Order
placement Product development
Prototyping
Process
Customer Requirement
feedback Analysis Requirement Definition
Document
Product
Definition
Prototype Basic Design
Basic design Document
Create a prototype Detailed Design
Detailed design Document
Execution
Implementation module
Test Product
Maintenance
22

1.4.3 Spiral model
Spiral model
 Iterate lifecycle process of development to reach completion of development.
 In spiral model, software meeting all complex requirements will not be created from the
beginning.
 Analyze whole requirements first to extract and limit items that are more essential than
others or simple enough so that it can be easily implemented before starting development.
Analysis Requirement
Product specification
document
Basic design
Test
Execution module
Basic Design
Document
Detailed
Implementation design
Process
Detailed Design
Document
Product
23
 Iterative and incremental development

Development model proceeding with iteration of lifecycle process just like spiral model is called an "Iterative and
Incremental Development."

1.4.4 Agile development model

Agile model
 “Agile” does not refer to a specific development model, but is a general term of group of
lightweight development methods for agile and face-to-face software development.
Process flow of agile model

 With agile model, you iterate analysis, design, implementation, and test at short cycle time.
 While conventional development models bring a system to completion and functions when
final process ends, in agile model, each necessary function is added to the system one by
one.
W aterfall model Function Agile model

Function
Implementation
Analysis
Design
Test
Analysis
Implementation
Analysis
Design
Test
Design
Implementation
Analysis
Design
Test
Implementation
Implementation
Analysis
Design
Test
Implementation
Test
Analysis
Design
Test
Time Time
24
 About agile model

In the middle of 1990s, planning-focused development process represented by waterfall model was criticized as
slow, demeaning, and heavy, leading to development of an agile model.
Customer and development team, conventionally working separately at both ends of a transaction, cooperate
together in this model. Identifying and prioritizing necessary functions for the system before developing and
releasing each function one by one enables rapid response to users' business and market demands.
 Types of agile model

• EXtreme Programming (XP)
• Agile Unified Process (AUP)
• Feature Driven Development (FDD)
• Scrum
 Scrum
Scrum is one of the agile development models. Rules are stipulated in "Scrum guide™."
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

1.5 Type of orientation in analysis/design
What is a type of orientation?

 It stands for a method used at each process step in software development.
Major type of orientation

 Procedure-oriented
 It was used as a mainstream method from 70s through 90s.
 A standard method where data design and program flow design are separated.
 It can handle system with certain complexity using structured design and structured programming.
 Object-oriented
 It went mainstream in the 2000s chiefly with business application development.
 Based on the idea where data design and program flow are handled as a single “object” to meet
function requirements through their message collaboration (requirement relationship).
 It is highly superior to procedure-oriented method in managing complexity.
25
 Embedded system development and object-oriented

As a system becomes complex, object-oriented development is increasingly utilized to embedded system
development.
 Column: a term "Procedure-oriented"

This is a newly invented term which refers to conventional development methods as opposed to object-
oriented method that has been generalized.
Conventional procedure which focused development methods were then called procedure-oriented, in
contrast, with object-focused methods is called object-oriented.

1.5.1 Analysis method
Necessity of analysis method

 Specification document, either based on customer’s requests or in-house requirements, is
the only material available at the earliest stages of a system development project. It is
difficult to start system design from this point.
 Analyzing issues at hand, the target business flows, and/or status of existing systems help
to understand the foundation and structure of a system to be developed.
Requirement analysis
 It denotes examination and defining of a new system or system revisions in system
engineering and software engineering.
 Identifies a fundamental question of “What is necessary with the system?”
 Target will be modularized from the fundamental viewpoint of “function.”
Major analysis method

 Structured analysis
 Object-Oriented Analysis (OOA)
26
 Structured analysis
An analysis method based on procedure-oriented method.
 Object-oriented analysis (OOA)

Creating a conceptual model to identify and improve issues based on the concept of object-oriented method is the
objective. Issues will be analyzed specifically on function requirements.

1.5.2 Design method
Design method
 Analysis result will be created as an outcome of system analysis.
 The analysis results show summary of a system to be developed from user’s point of view
while it does not state how it should be realized and is deliberately not questioned for such
process.
 On the other hand, design method is a tool to give a concrete method to realize the system
according to what the analysis result indicates.
Major design methods

 Structured design
 State transition design
 Object-Oriented Design (OOD)
27
 Structured design
Design method based on procedure-oriented method.
 State transition design

This method is useful when designing a system where the system and/or device take a various states, and the
states change with events in a complex manner.
 Object-oriented design
Analysis models obtained with object-oriented analysis will be converted to models considering various kinds of
limitations.

End-of-chapter test -1.1-

Choose the most appropriate term used in software development which
corresponds to the description.
[ 1 ]: A set of process steps of software lifecycle
[ 2 ]: Identifies functions or performance required for the system
[ 3 ]: Identifies interface specifications between the system and an external
system
[ 4 ]: Identifies the behavior of internal system for each function unit
[ 5 ]: Enables function through coding according to a design document
[ 6 ]: Identifies malfunctions to improve quality
[ 7 ]: Monitors system usage to respond properly in case of an abnormality
<Alternatives>
a. Implementation b. Test c. Lifecycle process
d. Requirement definition e. Detailed design f. Basic design
g. Lifecycle mode h. Maintenance i. Order placement
28
Answer Column
Correct
Question Answer
Answer
1


In detailed design, program will be modularized.
If divided modules are highly [ 1 ], maintainability and expandability of the
system will be improved.
Module strength and module [ 2 ] can be used to measure [ 1 ] of a module.
If module strength is [ 3 ], it is regarded as better.
If [ 2 ] of a module is loose, it is regarded as better.
<Alternatives>
a. granularity b. degree of coupling c. for general purposes
d. density e. dependence f. degree of condensation
g. tight h. weak i. independent

j. strong
29
Answer Column
Correct
Question Answer
Answer
1


Choose the most appropriate term used in sub-process which corresponds to
the description.
[ 1 ]: Schedule management, members management, etc.
[ 2 ]: Test management, Regulations management, Metrics management,
Quality factor management, etc.
[ 3 ]: Management of revision history of edited files
[ 4 ]: Management of equipment and software used in the development
[ 5 ]: Management to prevent invasion from outside by malicious programs and
other threats
[ 6 ]: Continuous recording and sharing of information of bug fixing from
identification to modification of software malfunctions
<Alternatives>
a. Security management b. Quality control c. Project management

e. Development environment
d. Version management f. Bug tracking
management
30
Answer Column
Correct
Question Answer
Answer
1


There are several types of development process models.
First of such models proposed was [ 1 ] model where process is implemented
from upstream to downstream. In [ 2 ], [ 3 ] is created at requirement definition
stage to obtain evaluations and feedback from the customer identifying
customer’s requirement to proceed with the development.
In [ 4 ], iterate development lifecycle process until the completion of system.
Through criticisms to these development process models, [ 5 ] development
model was introduced for rapid and interactive software development.
<Alternatives>
a. object-oriented type b. all the programs c. agile model
d. prototype e. spiral model f. Process
g. waterfall model h. model i. prototyping model
31
Answer Column
Correct
Question Answer
Answer
1

Summary
 What should be done in requirement definition?

 What should be done in basic design?
 What should be done in detailed design?
 What should be done in implementation?
 What should be done during the tests?
 What are the types of sub-process?
 Explain each characteristic of waterfall model, prototyping model, and spiral
model.
 What is procedure-oriented analysis/design?
 What is object-oriented analysis/design?
 What are the different kinds of analysis methods?
 What are the different kinds of design methods?
32

Chapter 2 Structured analysis/structured design

method (embedded)
Understand concrete procedures of requirement analysis.
Understand concrete procedures of basic design.
Understand concrete procedures of detailed design.
33

2.1 Requirement analysis
Choice of method
 There are several methods to analyze requirements of the target system. You should
choose one that fits for embedded systems.
 Apply event list analysis as an effective requirement modeling method to proceed with
structured analysis and structured design.
Event list
 An event list is a collection of events which occurs outside the system and to which system
needs to provide some values.
I want to
drink coffee
Event
Stimulus
Target system
I can drink Response

coffee Action
Effect
Components of event list of a coffee maker
34

2.1.1 Event list analysis
Event list analysis

 Identify function requirements of the system through listing up all the items from event to
effect.
Components of event list

 Event
 Stimulus
 Action
 Response
 Effect User
Event Causality
Effect
Stimulus Response
Syste
m
Action
Event Stimulus Action Response Effect
Relationship between user and system with even list components

35
 Event
Occurs outside a system and the system is not capable of controlling the occurrence.
It refers to an action that someone outside the system (user) can feel.
 Stimulus
Information input to give stimulus to a system by an occurred event.
System interface (input interface) that operates between a system and a user.
Input switch is one of the examples.
 Action
What a system brings about when an event occurred.
Overview of processing within the system.
However, it is the overview seen from outside only, which has nothing to do with internal process.
 Response
Reaction against an action system brought about.
System interface (output interface) that operates between a system and a user.
Rotating propeller is one of the examples.
 Effect
Impact given to outside of a system in response to the system.
A valuable result that is given to the users outside the system.

2.1.2 Preparation for creating an event list
External view
 When considering an event list, you would have a clear image of it if you specify external
view, user interface, and physical input/output.
Water
Coffee drain lock

(key)
LED indicating
errors etc.
External view of a coffee maker
36
 Appearance is more important than you think

If you rely only on abstract theories in analyzing requirement, important discrepancies in recognition or omission of
definition that you may not notice may happen. One of the effective measures for this is, at the stage of requirement
analysis, to define appearance or user interfaces such as image of a screen design and/or placement of buttons to a
certain degree before reaching an agreement with the customer.
However, visual analysis is only supplementary to the whole analysis, and visual analysis alone cannot lead to an
ideal structure as a system analysis.

2.1.3 Create an event list
Create an event list

 List all the possible events before describing flows to their effects.
(i) First list up all the events (ii) List up actions (iii) List up effects

Request for brewing Button input Brew coffee Brew coffee I can drink coffee
coffee
Runs out of coffee Sensor Notify lack of coffee beans LED lights up Notices lack of coffee beans
beans indicating lack of
coffee beans
Water temperature Sensor Operation of water heater Heater Increase the water
goes down temperature
Coffee brewer lock Button input Lock coffee brewer T.B.D. Prevent coffee brewing
command operation
Release coffee Button input Release coffee brewer lock T.B.D. Enable coffee brewing
brewer lock operation
Water overflows Water level sensor (Hi) Stop operation of water heater Notification of error Avoid dangerous situation
Notify abnormality of the system to outside
Runs out of water Water level sensor (Lo) Stop operation of water heater Notification of error Avoid dangerous situation
Water temperature Time Stop operation of water heater Notification of error Notices error of the water
does not rise Temperature sensor Notify abnormality of the system to outside heater
(iv) Fill in stimulus and response (if difficult to make a table, it can be described later (T.B.D))
Example of an event list for a coffee maker

37
 How to handle non-functional requirements

Making a list of non-functional requirements may ease your concern if you have any and is persistent.
Anyway, because it is difficult to define non-functional requirements and working on them may waste man-hour at
this stage, the most rational attitude is to put them aside for the moment.
 What is TBD (To Be Determined/To Be Decided)?

As will be mentioned later in synchronization of design documents, design documents are gradually detailed and
embodied. During such process, some parts may be newly discovered or may become necessary.
Of course it is ideal to understand everything from the beginning, but there are things that you cannot foresee or
notice at the initial stage. It is more productive to leave such things that may surface later behind and go a step
forward than wasting time on worrying.

2.2 Basic design

What is basic design?
 Identifies functions in basic design.
 Structured analysis method is used.
 Functions will be identified through data-centered approach to event list created at
requirement analysis.
 Generally, DFD is used as a data-centered function design approach.
Procedures of the basic design

i. Extract terminator
ii. Describe DFD
iii. Design process
iv. Design data
38

2.2.1 What is DFD?

DFD
 DFD shows behavior of the system mainly with data flow.
Components of DFD
 Process
 Process input data for certain modification to output resultant data.
 Data flow
 Shows data transfer path between other components
 Data store
 Shows place of data storage.
 Terminator
 There are two types of terminators i.e., input terminator and output terminator.
 Exists outside the software system to be modeled.
 Shows input information source from outside or output destination of the information.
System boundary
Input terminator Process Output terminator

Data flow
Input Processing Output

Input data Output data
Conversion
Data Data
Data store
39
 What is included in the outside scope of software system?

Outside of the software system is not boundary of product package of the whole system but outside boundary of
microcomputers.
To be concrete, LED soldered inside the system is not inside but is outside of the system.
When the system is connected to a PC through a serial port, serial port is outside of the system, and, therefore, PC
connected to the port is not within scope of the design.
 Data flow and process

With DFD, basically, a terminator or a data store works as input/output to a process.
When data flow takes place between processes, it means a data flow through function parameters (arguments), and
is handled as STS division or at the division level during implementation, consequently not to be described in DFD.

2.2.2 Hierarchy of DFD

DFD has a hierarchical structure as shown below.
 Context diagram
 A diagram showing the whole system with one process
 Zeroth layer of DFD (DFD0)
 A diagram showing the whole system with multiple processes
 First layer of DFD (DFD1)
 A diagram showing a process of DFD0 with multiple processes
 N-th layer of DFD (DFDn)
 A diagram showing a process of DFD(n-1) with multiple processes
First layer of DFD

(DFD1) Zeroth layer of
DFD (DFD0)
Input Output
terminator terminator
Input flow Output flow
Context diagram
40

2.2.3 Procedures of terminator extraction
Extract input and output terminators separately.

 Analyze “event” and “stimulus” of event list to extract input terminator.
 Analyze “response” and “effect” of event list to extract output terminator.
Extract terminator
i. Extract input terminator
ii. Extract output terminator
41

2.2.3.1 Extract input terminator
Extract terminator from event and stimulus in the event list.

coffee
coffee beans
Water temperature Sensor Operation of water heater Heater Increase the water
goes down temperature
command operation
Same items will be grouped together

Terminator
User I/F
Bean sensor
Water level sensor
Thermistor
42

2.2.3.2 Extract output terminator

Extract terminator from response and effect of the event list.

coffee
coffee beans
Water temperature Sensor Operation of water heater Heater Heat the water
goes down
command operation
Same items will be grouped together

Terminator
Pump
LED indicating lack of
coffee beans
Heater
Error LED
43

2.2.4 Procedures of describing DFD
Describe a DFD diagram with larger granularity first.
Describe DFD.
i. Describe a context diagram
ii. Describe DFD0
iii. Describe DFD1
44
 DFD level
With the example in this explanation, DFD1 is enough while more complex system requires description of DFD2 or
more.

2.2.4.1 Create a context diagram
Procedures of creating a context diagram

 Examination of process
 With a context diagram, the whole system will be the process.
 Name the process representing the whole system.
 Placement of a terminator
 Place a terminator.
 Describe an event to input data flow.
 Describe an effect to output data flow.
User I/F
Pump
Request for brewing coffee
Coffee brewer lock command
Release coffee brewer lock I can drink coffee
LED indicating lack
Coffee beans sensor Runs out of coffee beans of coffee beans
Notifies lack of coffee beans
Water overflows Coffee maker

Runs out of water Error LED
Avoid dangerous situation
W ater level sensor Notices error of the water heater
Increase the water

temperature
Water temperature goes down Heater
Temperature sensor
Water temperature does not rise
Water temperature does not fall
45
 Analysis of complex systems

With complex systems, considering input and output at the same time may lead to omissions or oversight in the
analysis.
In that case, you should disregard output terminators to describe only input terminators to a context diagram.

2.2.4.2 Create DFD0

Procedures to create DFD0
 Fragment process of a context diagram to describe the data flow with related terminator.
 Process division
 Extract system functions (process) from an event list.
 Append data flow
 Refer to responses of the event list.
 More than one data flow may fall into a common process.
 Add/modify information
 Add terminators that are found to be necessary during design process.
 If information needs to be modified during design process, modify accordingly.
Lock
User input I/F Release the lock
Coffee beans User output I/F
sensor Request for
brewing 2. Notification of
Remaining Coffee brewer lock status
coffee
number of
coffee beans lock control
Pump Error status
1. LED indicating lack
Brewing coffee
Brewing of coffee beans
Remaining Error status
water level coffee
W ater level sensor
4.
Remaining Water Error LED
Water
water level supply
3.
temperature
Temperature
Error status
W ater temperature sensor control
Run/stop
Heater
46
 Positioning of process of DFD0

Process of DFD0 can be called a function, and is managed by numbers for convenience while their order has
nothing to do with time.
 How to divide DFD

First, divide a process in view of static function division in DFD0.

2.2.4.3 Create DFD1

Procedures to create DFD1
 Describe details of DFD about each process in DFD0.
 Process division
 Certain process can be divided into more than one process if you consider a set of time series procedures.
 Add a terminator at this point if you find a new one.
 Fill in data store
 Present data that needs to be retained across processes as a data store.
 Data store will be implemented for module synchronization or for permanently retaining data (file, global variables,
etc.) in the future.
LED indicating lack
[1. DFD1 of coffee brewing process] of coffee beans
Coffee beans Lack of

Filter sensor
sensor coffee Water level sensor
beans
Coffee beans supply
Filter setting machine
User input I/F machine Pump
Remaining Remaining
quantity of
User output I/F
number of filters coffee
Request for Set a filter beans Brewing Remaining
brewing coffee Supply of coffee water level Result
coffee beans
1.1 1.3
Receive 1.2 Supply coffee 1.4 1.5
coffee brewing Set a filter beans to the Brew coffee Dispose a filter
request filter
Dispose filter
Filter disposal
: New terminator machine
Coffee brewing Abnormal status

status
47
 Modification noticed while making a diagram

A data flow for “Error LED” is clearly described in DFD0, but it turned out to be unnecessary while creating DFD1
and was deleted.
 Is DFD2 or more necessary?

In this example, describing up to DFD1 was enough to obtain a model as a basic design.
However, if hierarchical structure of the system is multifold or the system is highly complex, DFD2 or more may be
necessary to obtain a model with enough details describing the system.
 Describe only data flows in DFD

When refining DFD, timeline transition of a process appears. As a result, you may end up describing information
other than data flows in DFD.
However, each diagram has a semantic domain, and information located outside the scope of the semantic domain
should not be included.
 Process number of DFD1

The process number of DFD1 is different from that of DFD0, and was chosen to be time related number. There is no
grammatical rules for this.
 New terminator
There are terminators that cannot be noticed when defining an event list.
In this example, it was found out that a mechanism to set or dispose a filter was necessary when creating DFD1.
In such case, you can add a terminator at this point. Consistency with upstream design documents will be
considered separately.

2.2.5 Procedures for defining process
Each process in DFD1 will be defined.
Describe process name, function overview, input, and output as process definition.
Define process.
i. Extract processes from DFD1
ii. Define process
48

2.2.5.1 Process definition
What is process definition?

 Treat each process unit appeared in DFD1 as one function.
 During implementation, there is an advantage for structure management in treating a
process on a per-file basis.
Example of process definition with coffee brewing process
[Receive coffee brewing request: process definition] [Set a filter: process definition]
<Process name> <Process name>
Receive coffee brewing request Set a filter
<Function overview> <Function overview>
Receive request from a user to change Set a filter to filter machine
coffee brewing status <Input>
<Input> Coffee brewing status
User input I/F Filter sensor
<Output> <Output>
Coffee brewing status Coffee brewing status
Filter setting machine
Abnormal status
49

2.2.6 Procedures for data definition
Identify data structure and overview of data store appeared in DFD1.

 Data store will be implemented for module synchronization or for permanently retaining
data (file, global variables, etc.) in the future.
 Concrete determination of items at implementation level such as data type and
structure/array, should be carried out at detailed design. Therefore, that will no be
prescribed here.
If system is highly complex, data design should be much more complicated.
 If maintainability and expandability are required with a system, it may result in a complex
system.
If DBMS is introduced in a system, table design through data normalization would
be necessary.
Define data.
i. Extract data store from DFD1
ii. Describe data structure of each data store
50
 DBMS (Database Management System)

2.2.6.1 Data design
Data design of coffee brewing process
i. Coffee brewing status : shows what status the coffee brewing machine is in
 Coffee brewing status : a flag showing whether or not the machine is brewing coffee
ii. Abnormal status : shows what status the system is currently in

 Abnormal status : code showing the system in an abnormal status
51
 Carry out to all the DFD1

Design data to all the data store from DFD1.
 Accessor to a data store

While, in many cases, a data store will finally be implemented with global variables, you should make it a rule to
read/write through function or accessor for a data store, not to directly use other functions by extern. This will be
described later in modularization.

2.3 Detailed design
Usage of structured design

 In this textbook, modularization according to structured design will be carried out in the
detailed design.
 Design module functions and input/output interface specifications to each properly divided
module.
Procedures of detailed design

i. Modularization
 In structured design, program will be modularized with implementation in mind before defining each
module.
 There are several different methods for modularization. We will extract modules directly from DFD.
 Define module structure diagram as a result of modularization.
ii. Module design
 Define functions given to each module in view of “what is the purpose of this module?”
iii. Detailed data design
 Design data structure with implementation in mind.
52
 Awareness of implementation languages

You cannot avoid being aware of implementation language once you reach detailed design stage.
It was assumed that implementation language has nothing to do with the design up to basic design; however, with
detailed design you need to identify implementation language to go into the concrete implementation method.

2.3.1 Procedures of modularization -1-
Modularization will be carried out using STS division method in this textbook.
Modularization
i. Choose a process from DFD1
ii. Carry out STS division
iii. Describe a module structure diagram
iv. Commonalize common modules
53

2.3.1 Procedures of modularization -2-
Extract modules from DFD according to the guidelines shown below.

 Define each process of DFD1 as a module
 Define the data flow from a terminator to each process of DFD1 as a module
 Define the data flow from each process to a terminator or a data store as a module
“1. Coffee brewing process” in the example has following processes that can be defined as
modules.
 1.1 Receive coffee brewing request
 1.2 Set a filter
 1.3 Supply coffee beans to the filter
 1.4 Brew coffee
 1.5 Dispose a filter
A data flow between each process and a terminator or a data store can be defined as a
detailed module.
 Ex.) Module between terminators of “1.2 Set a filter”
 Filter machine controller (output module)
 Filter sensor controller (input module)
 Obtain coffee brewing status (input module)
 Change coffee brewing status (output module)
 Obtain abnormal status (input module)
 Change abnormal status (output module)
54
 A module that receives data flow from a terminator

Such module is generally called an “Interface (I/F).”
 A module that outputs data flow to a mechanism or terminator of a machine.

Such module is generally called a “Machine control.”

2.3.1.1 Modularization method
STS division will be used for modularization.

STS division
 Modularize a process with STS division.
 A data flow will be divided into three modules of Source, Transform, and Sink with STS
division.
Process
STS division
Input Source Transform Sink Output
Maximum abstract Maximum abstract

input point output point
Module
Process
Structure of a divided module
Source Transform Sink
55

2.3.1.2 Procedures of STS division
Carry out the operations shown below to the target process subject to
modularization:
i. Extract a terminator and/or a data store that are related to object process from DFD1,
and then describe input element to the left hand side and output element to the right hand
side.
ii. Define source module to each input element.
 If input object is a terminator, source should be “XXX machine control/sensor control.”
 If input object is a data store, source should be “obtain XXX.”
iii. Define a unique transform from the source and give it a general name of “XXX
management.”
iv. Define a sink equivalent to an output terminator from the transform.
 If output object is a terminator, sink should be “XXX machine control.”
 If output object is a data store, sink should be “change XXX.”
Process
XXX machine control XXX
Input terminator or machine Output terminator
XXX sensor control
XXX control
management
(management
of XXX) Change
Data store Obtain Data store
XXX XXX
56
 STS division as an operation

When you draw up DFDs, the foundation of design is determined.
STS division is not something you create in your head, but is something you modify the diagram according to a
procedure.
 Definition of a sink
The above slide states that “if output object is a terminator, a sink should be “XXX machine control,” which may
not be always the case, maybe unnatural in terms of process flow. If that happens, you may change the name.
Ex.) A case where an output terminator is an LED indicating lack of coffee beans
 Lack of coffee beans LED machine control
 Lack of coffee beans notifying machine control
Ex.) A case where an output terminator is a coffee beans grinder

 Coffee beans grinder machine control
 Coffee powder supply machine control

2.3.1.3 STS division (process 1)
Extract detailed processes and check the relationship.
[1. Detailed process of coffee brewing process - 1.1 Receive coffee brewing request]
1.1 Receive coffee brewing request
1.1.1 User 1.1.2

1.1.3 Change
input I/F Management Coffee brewing
User I/F coffee brewing
Request machine of request for status
status
for control brewing coffee
brewing
coffee Source Transform Sink
57

A process with more than one input and output has multiple STS within the same
process.
[1. Detailed process of coffee brewing process - 1.2 Set a filter]
1.2 Set a filter

Remaining
number of filters
1.2.5 Change Coffee brewing

Filter sensor 1.2.1 Filter
coffee brewing status
sensor control
status
Source Sink
Coffee brewing 1.2.2 Obtain 1.2.4 1.2.6 Filter

coffee brewing Management of machine Filter setting machine
status
status filter setting control
Set filter
Source Transform Sink
Abnormal 1.2.3 Obtain 1.2.7 Change Abnormal

status abnormal abnormal status
status status
Source Sink
58

[1. Detailed process of coffee brewing process - 1.3 Supply coffee beans to the filter]
1.3 Supply coffee beans to the filter

Remaining number Coffee
of coffee beans
brewing status
Coffee beans
sensor Sink
Source Coffee beans supply

machine
Coffee brewing Sink Supply of

coffee beans
status
LED indicating lack
of coffee beans
Source Transform
Sink
Abnormal
status Abnormal
status
Source
Sink
[Questions] Fill in modules by dividing a process by STS division
59

[1. Detailed process of coffee brewing process - 1.4 Brew coffee]
1.4 Brew coffee
[Question] Fill in modules, terminators, and data stores by dividing process by STS division.
60

[1. Detailed process of coffee brewing process - 1.5 Dispose a filter]
1.5 Dispose a filter
[Question] Fill in modules, terminators, and data stores by dividing process by STS division.
61

2.3.1.8 Module structure diagram

Create a structure diagram for each DFD1 process through defining each process
as a module.
 A structure diagram before grouping common modules shows call relationship between
modules called collaboration.
Generally, it is simply a module
to start up a program
Coffee brewing process
[1. Coffee brewing process]
Receive coffee brewing Supply coffee beans to the

Set a filter Brew coffee Dispose a filter
request filter
User input I/F Filter sensor Coffee beans Water level User output I/F
machine control control sensor control sensor control machine control
Change coffee Filter machine Coffee beans Pump machine Filter disposal
brewing status control machine control control machine control
Obtain coffee Obtain coffee Obtain coffee Obtain abnormal

brewing status brewing status brewing status status
Change
Change coffee Change coffee Brewing coffee abnormal status
brewing status brewing status Change status
Obtain abnormal Obtain abnormal Obtain abnormal

status status status
Change Change Change

abnormal status abnormal status abnormal status
LED indicating
lack of coffee Process
beans control
62
 Intermediate outcome of module structure diagram

The module structure diagram shown above is an intermediate outcome, clearly showing what module came from
which process.
If common module is commonalized, above information will be lost and replaced by input information for describing
list of used functions in Function Definition Documents.

2.3.1.9 Module grouping

Module grouping
 Since machine control programs should not depend on the process, they should be
grouped together in a machine control program category (common module).
 Group together by newly developed unit.
 The module will be implemented as a unit called function.
 Group will be implemented as a unit called file.
Coffee brewing process

[1. Coffee brewing process]
Receive coffee brewing Supply coffee beans to the

Set a filter Brew coffee Dispose a filter
request filter
process
<Machine operation related modules> <Machine control related modules>
Obtain abnormal User I/F input Filter sensor Filter machine LED indicating
Obtain coffee lack of coffee
brewing status status machine control control control
beans control
Group Change User I/F output Water level Coffee beans

Change coffee abnormal status machine control sensor control sensor control
brewing status
Coffee beans Pump machine Filter disposal
machine control control machine control
cmn mcnCtl
63
 Handle a group as a file

If you name a group as mentioned above, you should make it a file name of the source code.
Ex.)
process.c
cmn.c
mcnCtl.c
 Considering performance and memory resource

Obtaining or modifying parameters through data operation related modules may degrade performance and/or waste
memory resource.
Although there are cases where data operation is to be carried out at each module directly at final design stage,
performance (non-functional requirement) should not be considered at analysis stage.

2.3.2 Procedures of module design
Design each divided module.
Module design
i. Select arbitrary module in the module structure diagram
ii. Describe functions and overview of the module
iii. Describe module input/output specifications
*Carry out above (i) through (iii) to all modules
64

2.3.2.1 About module design
Unit of a module is function

 Modules will be handled by unit of function at implementation.
 Module and function mean the same thing hereinafter.
Be aware of module strength.

 Strength of unit of modularization designed by structured design should already be strong.
If weak modules exists, there may be a mistake in the process of analysis/design.
Be aware of module coupling.

 Data transfer at module boundary should be carried out with parameters (arguments).
 If it is necessary to be handled as global variables, the reason should be clear.
 Even if it is defined in a data store, it is better to define local variable of main function to transfer the
data as a parameter where possible.
65
 Definition of terms
A term “module” is not what will not be stipulated with implementation, but is what designers use.
A term “function” is what is stipulated with implementation, and is what implementers use.

2.3.2.2 Module Design Document
Module Design Document is described as a Function Define Document.
[Function define document to receive [Function define document for setting

coffee brewing request] a filter]
<Function declaration> <Function declaration>

void MainCatchCoffOut(void) char McnSetFilter(void)
<Specifications> <Specifications>
Receive request from a user to change Set a filter to the filter machine using a machine
coffee brewing status. control program of the filter machine.
<Input> <Input>
• Input parameters • Input parameters
None None
• Input global variables • Input global variables
None Coffee brewing status
<Output> Abnormal status
• Returned value <Output>
None • Returned value: error code
• Output parameters 0: filter set successful
None -1: filter set failure
• Output global variables • Output parameters
Coffee brewing status None
<List of used functions> • Output global variables
User I/F input machine control Coffee brewing status
Abnormal status
<List of used functions>
Filter sensor control
Filter machine control
66
 Positioning of Function Definition Document

Function Definition Document will be coded as a function header comment of each function at implementation
process.

2.3.3 Detailed data design
Detailed data design

 Data design carried out at the basic design will be further refined keeping implementation in
mind.
 If a data store consists of two or three dimensional data, it should be handled by
multidimensional arrays.
 If there are more than one attributes in a data store, it should be handled as structures.
 If data stand for a status, its meaning should be defined by values.
[Data design of coffee brewing status] [Data design of abnormal status]
Logical name: coffee brewing status Logical name: system abnormal status
Name of the variable: statCoffOut Variable name: errCodeSystem
Type : char Type : char
Description: shows current status from a set of Description: shows type of abnormality when
status related to coffee brewing. the system is in abnormal status.
Definition: Definition:
0: standby status 0: Normal
1: setting a filter -1: Runs out of filters
2: Supplying coffee beans -2: Runs out of coffee beans
3: Brewing coffee -3: Runs out of water
4: Disposing a filter -4: Other abnormality
67
 Definition of status names

It is dangerous to handle a value that has been assigned to a status directly at implementation stage.
For example, designer may assign 1 to “setting a filter” while implementer cannot associate what 1 refers to.
Give each status a variable name that is easy to understand, and define values that stand for status in #define as
status names to use the name in source code instead of the value.

2.4 Maintain consistency of design documents
Discrepancies in design documents

 Design documents will be added/changed as the process proceeds.
 Discrepancies in design documents are unavoidable since there are items, processes, and/or data
that are found to be necessary or unnecessary later as the design progresses.
Maintenance of design documents

 Design documents that have discrepancies or that are clearly contradictory with source
code should be rectified to become consistent.
 This is called “synchronization of design documents and source codes.”
 It is desirable to synchronize design documents with source codes when discrepancy
occurred.
 At least before proceeding to implementation step, review design documents to rectify all
the discrepancies or contradictions that exist.
68

2.5 Process after design/analysis
Implementation process
 At the implementation process, algorithm design (flowchart, structured chart) and data
design for each module are carried out before coding with a programming language.
 While there are various styles or convention on procedures and methods of
implementation, how a function works and input/output interface specifications are
determined at the design process, and they cannot be modified at implementer’s own will.
 Algorithm design
 Flowchart is highly flexible, and is capable of describing any algorithm of languages.
 In principle, when you use structured language, it is advisable to use structured chart for algorithm
design.
 Data design (internal)

 Design data used inside functions.
 Structures or arrays should be designed according to a plan. On the other hand, it is acceptable to
prepare simple counters or flags when they become necessary.
Test process
 Verify quality at test process step-by-step (details of the test process will be explained
later).
69


There are several different methods for requirement analysis. From various [ 1 ] that
occurs outside the system, ones to which system needs to provide some values are
extracted and grouped together to form an [ 1 ] list. There are five elements of an [ 1 ] list.
Function requirements will be identified when all the items from [ 1 ] to [ 2 ] are listed up.
Causality happens to a user outside the system is [ 1 ] and [ 2 ]. [ 1 ] is what user can
directly feel such as actions. [ 2 ] is valuable result that user can directly obtain.
When function requirements of the system is identified, design behavior of the system
corresponding to each requirement with focusing on data. [ 3 ] is generally used to show
behavior of a system focusing on the data flow.
<Alternatives>
a. degree of coupling b. granularity c. strength
d. density e. DFD g. PAD
f. FDD g. context diagram h. semantic diagram
i. action j. stimulus k. response
l. event m. effect n. function
70
Answer Column
Correct
Question Answer
Answer
1


First [ 3 ] is called [ 4 ]. [ 4 ] handles system as a whole process.
After designing [ 4 ], it will be refined step-by-step. When designing [ 3 ]
completes, modularize the process. Module will be implemented as [ 5 ]. There
are two aspects of a module, i.e., [ 6 ] and [ 7 ]. When [ 6 ] is stronger, it is
regarded as better, while [ 7 ] is regarded as better when it is loose.
Module Design Document is described as a Function Define Document. Basic
data design carried out at [ 3 ] will be further refined keeping implementation in
mind.
<Alternatives>
a. degree of coupling b. granularity c. strength
d. density e. DFD G. PAD
f. FDD g. context diagram h. semantic diagram
i. action j. stimulus k. response
l. event m. effect n. function
71
Answer Column
Correct
Question Answer
Answer
4

Summary
 What is even list analysis?

 What is a DFD?
 Explain the elements of DFD.
 What is process definition?
 What should be done with data definition?
 Explain procedures of modularization.
 Explain procedures of module design.
 What are module strength and degree of module coupling?
 What will be described in a Screen Design Document?
 How do you design detailed data?
 How should you deal with discrepancies of design documents that happen as
process advances?
 What are the processes after design/analysis?
72

Chapter 3 State transition design
Understand state transition design.
Understand how to write a state transition diagram and a state transition

table.
Understand flow of state transition design.
73

3.1 What is state transition design?

State transition design is useful when designing a system where system and/or
device take a various states, and the states change with events in a complex
manner.
Design method using state transition diagrams and state transition tables
 This is a model with a combination of finite number of “state,” “transition,” and “action.”
 Next state will be determined by “event” and the current state.
 Described with state transition diagrams or state transition tables where diagrams and
tables showing the same meaning domain with different representation.
State 0
S State 0 State 1
Event 1 E 0 1
Event 0
/Process 3 1 －
/Process 1 Event 2 Event 0 0
/Process 4 Process 1 Process 2
0
Interconvertible Event 1 1 Process 3
State 1 Event 2 2
0
Process 4
Event 0
/Process 2
State transition diagram State transition table

74

3.2 Using state transition design
In embedded systems, state transition design (state transition diagram/state

transition table) is frequently used.
Using
Partly using Not using
extensively
Flowchart
State transition diagram
State transition table
Task relationship diagram
Timing chart
Others
Fact-finding survey on embedded software industry for development project managers (multiple answers
accepted), 2009, Ministry of Economy, Trade and Industry (METI)
75

3.3 Representation of state transition diagram
State Initial state (omissible)

(in this case initial state is State 0)
State 0
Event Event 1
Event 0
/Process 3
/Process 1 Event 2
/Process
4
Action
Transition
State 1
Transition condition
Event 0 [condition]/Process 2
An example of state transition diagram
State An object with continuity occupies a certain period of time
Event Stimulus from outside
Action Function or process implemented when specified event occurred under specified internal state
Transition condition Necessary conditions for a transition to occur
Transition Change from one state to another state or its own state
76

3.4 Representation of state transition table
Disregard Initial state
S State 1 State 2 State
E 0 1
Transition condition 1 else Transition condition
Event Event 1 0 State 1 － Disregard
Action 1 Action 2
State 2
Event 2 1
Action 1
Unacceptable
Action Transition target
An example of state transition table
77
 Initial state
Triangle showing the initial state can be solid (no particular meaning, triangle can be omitted).

3.5 Example of state transition design
Specifications of a CD player
 Initially, the CD player is stopped
 When PLAY button is pressed, it plays a CD
 When playing a CD, only STOP and PAUSE buttons are operable
 When STOP button is pressed while playing a CD, the player stops playing
 When PAUSE button is pressed while playing a CD, player stops temporarily, and when the
button is pressed again, restart the play
S Stop state Playing state Pausing state
E 0 1 2
Press down 1 1
0
PLAY button Start playing Restart playing
Press down 0 0
1
STOP button Stop playing Stop playing
Press down 2 1
2
PAUSE button Pause playing Restart playing
78

3.6 Benefit of state transition tables
S State 0 State 1 State 2
E 0 1 2
1 －－
Event 0 0
Process 1 Process 2 Process 5
1
Event 1 1 Process 6
2 0
Event 2 3 Process 4 Process 7
Omission is clearly
You can describe disregard
shown
You can describe unacceptable
State transition diagram State transition table

 Suitable for understanding the overview (analysis  Hard to understand the overview
phase)
 Hard to describe abnormal or exceptional cases  Can include abnormal or exceptional cases
 Omission and oversight tends to happen  Can prevent omission and oversight
79
 Relationship with tests

Test cases can be easily created if you use state transition tables.

3.7 Positioning of state transition design
State transition means change of state of an object through change of parameters

(data) values of whole or part of the system.
State transition design is a design method for designing a system of which behavior
changes with the change of state of an object.
Since embedded systems usually have such characteristics, state transition design
is suitable for designing an embedded system.
While process steps that uses state transition design are often downstream
process steps such as detailed design or programming design at implementation
stage, it may be used to analyze upstream process steps as well.
80

3.8 Check items of state transition tables
Does the state transition table meet the flow of requirement specifications?
 Is the transition of states with event occurrence properly realized?
No deadlock states?

 Are there any states that cannot escape from it once inside?
 Are there any states that will never be entered?
 Is there any case that an expected event will not occur?
Are there any useless states?

 Are there any states that can be commonalize?
81

3.9 State transition design/exercise
Specifications
 System name: Fan
 When you turn on the power, a motor begins to rotate to produce wind.
 You can change wind strength from weak to medium and then to strong by turning switch,
before going back to weak when you turn the switch once again.
 You can turn it off at any state.
 When you turn it on, wind strength is always weak.
Question 1
 Write a state transition diagram of the fan.
Question 2
 Write a state transition table of the fan.
82


State transition design consists of finite number of “[ 1 ]”, “transition” and “action,” and
next [ 1 ] is a model determined by [ 2 ] and current [ 1 ]. When an object with continuity
occupies a certain period of time, it is called [ 1 ]. [ 2 ] is stimulus from outside. Action is a
function to be implemented when specific [ 2 ] occurred at specific [ 1 ].
[ 3 ] and [ 4 ] are different way of representation while having the same meaning.
[ 3 ] is suitable for understanding the overview while it is difficult to describe abnormality
and exceptional cases, and omissions and oversight tend to occur. It is hard to
understand the overview with [ 4 ] while it is easy to describe abnormality and exceptional
cases and enables preventing omissions and oversight from occurring.
In [ 4 ], oblique strokes indicate [ 5 ] and x means [ 6 ].
<Alternatives>
a. state transition diagram b. state transition table c. interaction diagram
d. complex transition table e. disregard f. state
g. event h. position i. characteristics
j. condition k. unacceptable l. reservation
83
Answer Column
Correct
Question Answer
Answer
1

Summary
 What is the characteristics of state transition design?

 What is state?
 What is an event?
 What is an action?
 Explain the difference between state transition tables and state transition
diagrams.
 What are the items to be checked with state transition tables.
84

Chapter 4 Software test
Understand overview of the test as a whole.
Understand different types of test.
Understand characteristics of test level by V model and each test level.
Understand typical test techniques.
85

4.1 What is a test?
Test
 An operation to maintain product quality above a certain criteria.
 It is also called “testing.”
Dynamic test
 A test where a product is actually put into operation.
 Tests carried out at the test process are mainly dynamic tests.
Static test
 A test where a product will not be put into operation.
 Static test is mainly carried out at a review.
86

4.2 Test level
Test level
 Granularity classifying object of the test is called a test level.
 A test will be carried out at each test level.
 Types of test levels
Test level Other naming Test base

Standalone test Detailed Design Document, Design
Component test
Unit test document at implementation, source code
Basic Design Document, Detailed Design
Integration test Combination test
Document
Requirement Definition Document, Basic
System test Comprehensive test
Design Document
Acceptance test (user inspection) Request Definition Document,
Receiving test
Operation test Requirement Definition Document, etc.
Test base
 Development documents to infer requirements for the test.
87
 Operation test
A test after the acceptance test may be called an “operation test.”
 Names of test levels

In this textbook, test level names complying JSTQB is used.
 JSTQB (Japan Software Testing Qualifications Board)

An organization that certifies Software Testing Qualification.

4.2.1 V model
Relationship between test and process
 Each test level has a corresponding process.
 Test level is shown on the ordinate in the V model.
Validity check
Requirement
Acceptance test
Definition
Acceptance test
specification document
Requirement Definition Document
Basic design System test
Test level
System test specification
document
Basic Design Document
Detailed design Integration test

Integration test
Detailed Design Document
Implementation Component test

Component test
Source code and design Verification

documents at implementation
Source: Drawn based on the Figure 3.1 Review point of V model in Chapter 3 “Static technique” of “JSTQB Textbook/JSTQB certification test for
an engineer, Foundation Level test” 88
 Verification (if software is properly developed)

Verifies if software is properly developed in accordance with specifications specified at upstream.
Example Answer) Is not created correctly complying with specifications.
 Validation (if software is properly developed)

Validate if the software complies with user’s demand.
Example Answer) It had been created complying with requirement definitions, but was useless at actual business.

4.2.2 Component test
What is a component test?

 A test carried out for each module.
 To confirm the module is created according to the design document.
How to carry out a component test?

 Basically, separate the module from other parts of program.
 If the module does not function all by itself, a simplified alternative module (stub and driver)
will be created for the test.
Test base
 Detailed Design Document, Design document at implementation, source code
Test items
 Create test items focusing on internal structure of the module and functions the module
should have.
Responsible person for a component test

 Generally, a person who created the program carries out the test.
89
 Component
Component is a minimum unit of software that can be tested independently.

4.2.2.1 Stub/driver
Stub and driver

 A module created for a test.
 Has minimum functions necessary for the test.
Stub
 An alternative module that has input/output interface of lower module that calls the test
object module.
Driver
 An alternative module of upper module that calls the test object module.
Programmer Programmer
Stub
Object Object
of the Driver of the
Test test test
Test
Stub
Example of a stub Example of a driver
90

4.2.3 Integration test
What is an integration test?

 A test carried out by integrating modules.
 Flaws of interfaces between integrated modules and deficiencies caused by interaction of
modules will be checked.
How to carry out integration test?

 Integrate modules according to a specified method of integration test to carry out the test.
Test base
 Basic Design Document, Detailed Design Document
Test items
 Create test items focusing on the interaction between modules.
Responsible person for an integration test

 A program creator or dedicated members for the test will carry out the test.
91

4.2.3.1 How to carry out an integration test? -1-
Top-down test
 Start the test from the top module and then advance to Module A Module A
lower modules with integrating each module.
 Characteristics
Stub of
 Enables early detection of serious malfunctions such as Module B
module A
discrepancies in the understanding of specifications
between modules and interface errors.
 It is difficult to break down the test operation Stub of
module B
 Use stubs
Top-down test
Bottom-up test
 Start the test from the bottom module and then Driver of
advance to higher modules with integrating each module B
module.
 Characteristics Driver of
Module B
 It is easy to carry out the test and development module C
simultaneously
 If serious problems are found at later half of the test, lower
modules that have been tested are also affected. Module C Module C
 Use drivers
Bottom-up test
92

4.2.3.2 How to carry out an integration test? -2-
Sandwich test (compromised test)

 Top-down and bottom-up tests are carried out simultaneously.
 Characteristics
 Advantages and disadvantages of both the top-down test and bottom-up test coexist.
 Use stubs and drivers
Big bang test

 Regardless of hierarchical structure, component tests of all the modules are carried out
using stubs and drivers before integrating all the modules for an integration test.
 Characteristics
 Operation efficiency is better with a small-scale system
 Pinpoint the cause of failure is difficult when an error takes place.
 Use stubs and drivers
93

4.2.4 System test
What is a system test?

 A test to evaluate quality of the product at the final stage of development.
 Check if requirements are satisfied regarding functional/non-functional aspects of the
system.
How to carry out a system test?

 Function the system according to the situation/procedure with which a user uses the
system.
 It is ideal to test the system in an environment as close as the production environment.
Test base
 Requirement Definition Document, Basic Design Document
Responsible person for a system test

 In many cases, a team of specialist for the test will carry out the test.
94
 Examples of system test execution

• Business systems should be tested with a scenario simulating the actual operation flow in the company using data
quantity, transactions, and system environment that are same as the actual operation.
• Check the software by connecting to devices such as network, peripheral devices, and hardware subject to control
that are used in actual operation, to test security aspects of the software and response after system failures.

4.2.5 Acceptance test
What is an acceptance test

 The final test carried out just prior to accepting the product.
 Check if system requirements and usage meet user’s needs.
How to carry out an acceptance test?

 Production environment or simulation of the production environment is used to test in the
way a user actually operates.
Test base
 Request Definition Document, Requirement Definition Document, User Document,
regulations/standards/agreements, etc.
Responsible person for an acceptance test

 User or an independent test personnel will carry out the test.
95
 Beta test
For commercial software, a beta test may be carried out to seek feedback. A user use the software tentatively for
the whole or part of the system with certain restricted functions.
 Column: When bugs are found at an acceptance test

An acceptance test will be carried out assuming that bugs are fixed at earlier process, and therefore,
purpose of an acceptance test is not to find a bug.
Even though bugs are found at the acceptance test, never fix it without permission no matter how simple
the bugs are since modification may create another bug.
Modification will be carried out only against critical ones with deliberate decision of the responsible person
of the project.

4.3 Static test
What is a static test?

 A test carried out when a product (program) is not in use.
 Check if there are any errors in design documents or source code by reading them.
 Review is the typical method of the static test.
 A test with static analysis tools is also included in the static test.
Advantages of a static test

 Malfunctions can be found at an early stage.
 If reworking occurs at the upper stream, its impact is larger. Therefore, it is important to find out
malfunctions with review at each process step.
 In a static test, it is possible to find out a potential bug that are difficult to identify with a
dynamic test.
96
 Causes for reworks (by METI): from “Introduction to software” Gijutsu-Hyohron Co., Ltd.
Inadequate
development
environment
Improper 0.3%
standalone test Others
1.7% 1.0%
Not known
Incomplete test specifications 5.3%
2.8%
Improper integration test
4.8% Incomplete requirement
Coding mistakes specifications
5.0% 29.9%
Specifications change and/or

malfunction of hardware
6.7%
Improper
production test
8.8%
Erroneous
software design
Incomplete 18.6%
specifications
17.4%

4.4 Test cases
Test cases (test items)

 Determine test cases in advance to carry out each test case one-by-one before checking
the results.
 Create a test specifications when test cases are determined.
Extract test cases

 Since number of test cases are infinite in principle, you need to choose some of the cases.
 Discovery rate of malfunctions depends on the choice of test cases.
 Test cases with high discovery rate of malfunctions are said to be “having higher quality,” and one
with low discovery rate “having lower quality.”
 Test technique refers to a technique to extract test cases.
Normal test/abnormal test

 Test cases can be classified whether they are “testing actual functions?”
 Normal test
 Check if it functions normally (according to the specifications).
 Abnormal test
 Tests behavior when abnormal incident happens.
97
 Number of test cases

As number of test cases increase, man-hour increases. Therefore, the fewer test cases the better (for less cost).
However, if you neglect necessary test cases, you cannot guarantee the quality. The important thing is to extract
effective test cases.
 Semi-normal test
A test to check if the target software handles an abnormal event according to what is specified in the specifications.
 Test specifications
Please refer to appendix for examples of test specification documents.

4.5 Test technique
White box test

 Carry out a test focusing on internal structure of test object.
 It is usually used at component tests.
 Extract test cases in accordance with specified coverage criteria.
 Command coverage, branch coverage, condition coverage, and multi-condition coverage
Black box test

 Carry out a test without being aware of internal structure of the test object.
 Extract test cases through analyzing external specifications of the test object.
 There are several test techniques such as equivalence partitioning, boundary-value
analysis, and decision table.
Flowchart
Check if the flow goes through
path 1 when value of A is x,
Specification
Path 2 and it goes through path 2
when the value is y. Document
Path 1 A B
Input A will
result in
output B
White box test Black box test

98
 Coverage criteria with white box test

<C0>
Command coverage (statement coverage):
All the statements in the code will be executed at least once.
<C1>
Branch coverage:
All the branches in the code will be executed at least once.
<C2>
Condition coverage:
All the conditions in the code will be executed at least once.
*In some standards, C2 is regarded as multi-condition coverage.
*Multi-condition coverage: All the combinations of conditions within the code will be executed at least once.
 Relationship between a black box test and a white box test

A white box test only guarantees structural behavior, and does not guarantee if the software meets specifications
externally.
Therefore, a black box test is a must while a white box is not, and the other way around never happens.

4.5.1 Equivalence partitioning
Equivalence partitioning
 A test technique where group (equivalence class) values together, which give the same
output for certain inputs before selecting a representative value from each group.
 Group that gives valid inputs is called “valid equivalence class,” and group that gives invalid
inputs is called “invalid equivalence class.”
 Testing with representative values of “equivalence class” is regarded as covering all the
tests for input values under that condition.
 This way you can reduce the number of test cases.
 Example: consider test cases of the situation below

Admission fee from seven years old to 17 years old is 1,000 yen
Invalid Valid equivalence Invalid

equivalence class class equivalence class
…6 7 8 … 16 17 18 …
Choose representative values from three classes to make them test cases
99

4.5.2 Boundary value analysis

Boundary value analysis
 A test technique to use boundary values as representative values of equivalence
partitioning.
 For a certain independent equivalence class,
four values of two boundary values (on point), upper limit +1, and lower limit -1 (off point)
are used.
 Example: consider test cases of the situation below
Admission fee for six years or younger is free, that for younger than 18 years is 1,000 yen, and that for 18 years or
older is 1,500 yen.
Object age: test case

-------------------------------------------------------------------------------------------------------------------------------------------------------
0 to 6 yrs. old -1 0 6 7
7 to 17 yrs. old 6 7 17 18
18 yrs. or older 17 18 MAX MAX+1
-1 0 6 7 17 18 MAX MAX+1
There are eight test cases
100

4.5.2.1 Boundary analysis Exercise 1
Problem
 Date input screen is as shown below.
2002 Year 7 Month 30 Day
Execution
 Regarding input interface,

 There are input fields of year/month/day in the screen.
 Input to all these fields are required.
 Only integral numbers are acceptable.
Question
 What are the boundary values to be tested for month field?
 What are the boundary values to be tested for day field in January?
101

4.5.2.2 Boundary analysis Exercise 2
Problem
 Specifications as explained below are stipulated by automobile loan contract of company A
as “contract conditions with a customer.”
 Annual income of borrower of the contract should be 4 million yen or more and 20 million yen or less
 Purchase amount of borrower of the contract should be 1 million yen or more and 10 million yen or
less
 Unit of the annual income and purchase amount is 10 thousand yen.
Question
 What are the boundary values to judge eligibility of the automobile loan contract?
 Create a graph with its ordinate showing purchase amount and abscissa showing annual income.
 What are the test cases to be tested?

 Manage the test cases as matrixes of annual income, purchase amount, and result. (*)
* Remove redundancy with abnormal tests where it is possible.
102
 Contract object is a person with annual income of 4 million yen or more and 20 million yen or less
• A person with annual income of less than 4 million yen is considered to be incapable of paying it back.
• For a person with annual income of more than 20 million yen, such loan is considered to be unnecessary.

4.5.3 Decision table test
Decision table test

 A test technique to check if output changes with combination of input conditions.
 Input values are specified separately by equivalence partitioning method, boundary
analysis, etc.
 If listing all the combinations, some are impossible or meaningless. Such combinations will
be omitted.
 Example of decision table test Test cases
TC1 TC2 TC3 TC4
Input registered user name T T F F

Input conditions
Input correct password T F T F
T: True
Output conditions Login accepted T F F F F: False
[Number of test cases where impossible or meaningless combinations are not omitted]
(number of test cases) = two to the (number of input conditions)th power
In the above case, (number of test cases) = two to the second power = 4
103

4.5.3.1 Decision table test Exercise 1
Problem
 Input screen is as shown below.
Name Age
Occupation
Registration
 Regarding the input interface,

 There are input fields of name/age/occupation in the screen.
 Input of all the fields are required.
 Name has to be input with double-byte characters.
 Age has to be numbers.
Question
 Create a decision table to judge acceptance of the registration depending on combination
of the input values where validity of input values for name, age, and occupation is shown as
“True” when valid and “False” when invalid.
 Acceptance of the registration will be shown by “True” when acceptable, and “False” when
inacceptable. 104

4.5.3.2 Decision table test Exercise 2
Problem
 Specifications of a file updating program
 When input a file name as a file updating command parameter, the first character is either “J” or “E,”
and the characters that come after it should be numeric.
 When the first character is “J,” the file will be updated with S-JIS while the file will be updated with
EUC when the first character is “E.”
 If the first character of the file name is not as specified, show “Error 1” and if characters for second or
later is not correct, show “Error 2,” and the file will not be updated.
Question
 Create a decision table with patterns of parameter inputs and results, and list combinations
that can be test cases.
[Example of the display]
>updatefile J1234 <- will be updated
>update success!
>updatefile 1211 <- Error 1

>error1
>updatefile E33B4 <- Error 2

>error2
>updatefile AC <- Error 1+2

>error1 error2
*Omit impossible or meaningless combinations
105

4.6 Test plan
Test plan
 Test will be carried out based on the test plan.
 Determine how to proceed with the test policy and create a test plan document.
Types of test plan

 Master test plan
 A test plan for the whole project is called a master test plan.
 Create a master test plan document.
 Individual test plan
 Plan a test for each test level.
 Create component test plan document, integration test plan document, system test plan document,
acceptance test plan document for each test level.
Criteria for completing the test

 Define the criteria when the test will be completed in test plan.
 Test will be completed when the test is carried out and then the criteria is satisfied.
106
 Example of criteria for completing the test

• All the test cases planned have been executed,
• Coverage criteria configured were cleared,
• Number of unsolved malfunctions has become less than specified, etc.

4.7 Relationship between test and the quality
Return on investment
 Quality may improve as you spend more money on it indefinitely while improvement gets
smaller and smaller as the total cost increases.
 Identify criteria for test completion in the test plan considering how much you can spend on
the product or how malfunction may impact the market.
Quality may approach

perfect, but can never be
Quality perfect.
Perfect in its quality
Criteria where a
mission critical
system should
exceed
Criteria where a
system that is not
mission critical
should exceed
Cost
Change of quality by tests

107
 Mission critical
A backbone system or a computer system that interruption or stop of the system is not permitted.
Transportation and financial institutions have many such mission critical systems. Errors may cause a critical
consequences such as loss of large amount of money or loss of credibility.
If a system error may end up with a fatal incident, it is a mission critical system.

4.8 Something you should be aware of when

conducting a test
What is a complete test?
 All the test cases are covered.
 No deficiencies are overlooked after the test.
Difficulties of a complete tests

 In principle, there are infinite number of test cases made up of combinations of inputs and
results.
 Covering this infinite number of test cases is impossible.
Purpose of testing
 Purpose of testing is to identify malfunctions of software.
 It is not to prove the software is free of malfunctions.
Attitude a developer should take

 To say the least, you should guarantee that theoretically it is a bug free system at the
design stage.
 If you think “It may not be correct in theory, but I can rectify it by checking how it functions,”
you will never be able to create a program with high quality.
108
 Proverbs for testing

• Testing shows the presence, not the absence of bugs.
(By Dijkstra)
• Man-hour increase drastically if you try to identify 95% or more of all defects.
(By McConnell)
• There are two ways of designing a software:
One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so
complicated that there are no obvious deficiencies.
(by C.A.R.Hoare)


Test is an operation to maintain [ 1 ] of product above a certain level of criteria.
[ 2 ] is a granularity to classify test objects, and each [ 2 ] has corresponding
steps of lifecycle process.
Corresponding process steps for [ 3 ], [ 4 ], [ 5 ] and [ 6 ] are requirement
definition, basic design, detailed design, and implementation respectively.
Model showing this relationship is called [ 7 ].
<Alternatives>
a. component test b. review c. quality
d. test cases e. function f. receiving test

g. system test h. V model i. management
j. S model k. integration test l. test level
109
Answer Column
Correct
Question Answer
Answer
1


Classifications of tests with respect to their methods are [ 1 ] and [ 2 ]. [ 1 ] is a
test where the product is actually put into operation, while the product will be
checked through reading design documents, source codes, etc. without actually
being functioned with [ 2 ]. Typical method of [ 2 ] is [ 3 ].
Extract [ 4 ] when implementing a test.
Idea that classifies [ 4 ] considering if they are “testing actual functions?” as
explained below exist.
[ 5 ]: Tests to check if it functions normally (according to the specifications)
[ 6 ]: Tests to check the behavior when abnormal incident happens
<Alternatives>
a. test cases b. test bases c. dynamic test

d. test what is beyond expectation e. static test f. normal test
g. intermediate test h. abnormal test i. review
110
Answer Column
Correct
Question Answer
Answer
1


Choose one from below, which best explains each term of test technique
[ 1 ]: Test carried out focusing on internal structure of a program
[ 2 ]: Test where test cases are extracted through analyzing external
specifications of the test object
• [ 3 ]: Test carried out with representative values of equivalence class
• [ 4 ]: Test where boundary values are used as representative values of [ 3 ].
[ 5 ]: Alternative modules that are called by test object module and have
functions of lower modules
[ 6 ]: Alternative modules that call test object module and have functions of
upper modules
<Alternatives>
a. driver b. top-down test c. equivalence partitioning

d. white box test e. command coverage f. stub
g. black box test h. boundary value analysis i. bottom-up test
111
Answer Column
Correct
Question Answer
Answer
1

Summary
 What is test levels?

 In the V model, two different kinds of items have one to one correspondence.
What are they?
 What is a component test?
 What is a stub?
 What is a driver?
 What is an integration test?
 How do you proceed with an integration test?
 What is a system test?
 What is an acceptance test?
 List up characteristics of a static test.
 What is a white box test?
 What is a black box test?
 What is equivalence partitioning?
 What is boundary analysis?
 What is a decision table?
112

Basics of System Development

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Basics of System Development

Uploaded by

Copyright:

Available Formats

Basics of System Development (Embedding)

Basics of System Development (Embedded)

Chapter 1 Development of Software

 Learn lifecycle process and each process of software.

 Learn sub-process that is related to the whole development process.

 Learn process models of software development.

 Learn types of orientation in software analysis and design.

 Learn analysis methods.

 Learn design methods.

1 ©emBex Education Inc.

1.1 Flow of software development

Flow of software development

 Cutover, service-in, release

2 ©emBex Education Inc.

1.2 Lifecycle process

Lifecycle process Process

Order Requirement Detailed

Disposal Maintenance Test Implementation

 Standards for lifecycle process

 What you have to keep in mind for a lifecycle process

3 ©emBex Education Inc.

1.2.1 Requirement Definition

What is a requirement definition?

Purposes of the requirement definition

Maintenance Test Implementation

 Request Definition Document

4 ©emBex Education Inc.

1.2.2 Basic design

What is basic design?

Purposes of basic design

*Inside behavior and

 Different terms for “Basic Design”

5 ©emBex Education Inc.

1.2.3 Detailed design

What is detailed design?

Purposes of detailed design

Maintenance Test Implementation

 Other term for “Detailed Design”

6 ©emBex Education Inc.

1.2.3.1 Independence of modules

Index to measure independence of modules

7 ©emBex Education Inc.

1.2.3.1.1 Module strength

Strong Functional strength A module that executes a single function

Communicational strength A set of function is executed with communicating data

Procedural strength A set of function is executed according to the order

A set of functions that needs to be implemented simultaneously

8 ©emBex Education Inc.

1.2.3.1.2 Degree of module coupling

Degree of module coupling

9 ©emBex Education Inc.

Maintenance Test Implementation

 Other terms for “Implementation process”

 Programming languages for implementation

10 ©emBex Education Inc.

Delivery of the software

Maintenance Test Implementation

11 ©emBex Education Inc.

Maintenance Test Implementation

12 ©emBex Education Inc.

 PMBOK (Project Management Body Of Knowledge)

13 ©emBex Education Inc.

1.3.1 Project management

14 ©emBex Education Inc.