Ky nghe phan mem
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
1
Introduction to Software Engineering
ThS Luong M?nh Bá
Acknowledgments: Many thanks to Prof. Ian
Sommerville, Prof. Roger S. Pressman and Prof Nguy?n
Ng?c Bình for providing the materials for this course
HÀ N?I, March 2008
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
2
Reference Books
1. R. Pressman, Software Engineering: A Practioner's Approach. 6th
Ed., McGraw-Hill, 2004
2 Sommerville, Software Engineering. 7th Ed., Addison-Wesley, 2006
Others:
slides for HUT Students at SE Dept>
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
3
Week One: Introduction to Computer Software
1. Computer Software
1.1 What's the Computer Software?
• Computer Software or Software - SW is a concept that is inverse to
Hardware - HW
• In the past, SW was free or sold enclosed with the HW
• By the time, the price of SW becomes expensive and now it is more
expensive than HW
• Characteristic of SW and HW
HW
- The thing "hard"
- Metal
- Material
- Produced by Manufactory
- Quantitative
- Failures, amortization
SW
- The thing "soft"
- Technique used
- Immaterial
- Produced by People
- Qualitative
- Never amortization
? Definition 1- SW:
- Instructions (computer program) give the functions and desired results when
they are executed.
- Data structures that make program operate correctly over input information.
- Documents that describe how to operate and use the programs.
? Definition 2
- In a computer system, SW is the rest when the drive and the material
components are out.
- Narrow sense: SW are the service programs that develop the capability of
treatment of computer hardware. (like - OS)
- Broad sense: SW are all the techniques used to execute the functional
services for one purpose by hardware.
=> SE is
Group of
methods
and
techniques
Programs Documents
Know-how of SE
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
4
i) Methods and techniques
- The concepts and the process to develop a system
- Approach methods for problem solving
- Standards for design and develop
- The methods for SR specification, system design, program design, SW
testing and all the process developing a SW.
Ii) Programs
• Is the interface with HW which is made from the instructions indicating
the computer how to and in which sequence it must treat the data.
• Basis SW:
- Give the easy environment working to the users, users easily
exploit the system and develop the treatment capacity of HW
- For example: OS is a system program
• Application SW: used to treat
- a specific business (manage, accounting, . . .),
- packaged SW,...
iii) Documents
• Useful documents have a good quality and are necessary to develop,
exploit and maintain the SW.
• To make the SW with a high reliability degree ? need edit the high
quality documents:
- SW requirements,
- SW design,
- Test,
- Operate and guidance maintenance.
iv) Other elements
• SW production depends much on people (SW engineer):
- Capability abstraction,
- Programming,
- Technique skills and
- Experiment working,
- ...
? too different from the others.
• SW depends much on the idea and the know-how of developers or group
of developers.
1.2 Two views about Software Architecture
1.2.1 SW viewed from Hierarchical Structure
• SW architecture is an hierarchical structure:
- top: system,
- next levels below: subsystems,
- below subsystems: programs,
- last levels are the modules or subroutines with the arguments.
• SE structure expresses:
- all the functions that SW must have
- the conditions to decompose the functions (architecture design)
• Functional design:
- Vertically: more deep, more complex SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
5
- Horizontally: more wide, more functions and broader scope
1.2.2 SW viewed from procedural structure
• relations among different components of SW
• algorithms with the control flow: sequence, condition and iteration
• logical structures expressing every function in the SW and its operation
sequence.
• At first, structure design and then the function design.
1.3 Characteristics of Software
• Is an immaterial product, invisible
• Quality of SW: never amortized and has a better tendency after error /bug
is detected and corrected.
• There are the potential errors in the SW: the broader scope, the higher
capability of errors
• Error of SW is easily detected by people outside.
• The function of SW is always evolved by the time and by the location)
• Propagative effect in the SW change
System
Subsystem Subsystem
Program Program
Module Module Subroutine
Master files
Temporary
files
Arguments Arguments
Job unit
Jobstep unit
Common Module
?
?
Function A
Function B Function C
Function D Function E Function F
Horizontal structure
Vertical structure
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
6
• SW depends on know-how of the developer /group of developer.
• Easily copied
2. Software Quality
2.1 Basic criteria
• Effectiveness: response to the user requirements
• Few potential errors
• The cost: does not excess the estimated cost
• Easy to operate and use
• High reliability and safety
2.2 Performance
• Efficiency on time execution:
• Efficiency on material: CPU, RAM, HDD, Internet resources, . . .
2.3 Easy understood
• Understood architecture and structure
• Easy to test and to verify
• Easy to maintain
• High quality documents (requirement, condition testing, operate and
maintenance).
?Easy understood: more important today
3. Classification of SE
• System SW
• Real-time SW
• Business SW
• Eng.&Scie. SW
• Embedded SW
• Personal computer SW
• Web-based SW
Performance
Basis criteria
Easy understood
Time
Concept
elements
What's a good SW ?
Recent
characteristics
Time SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
7
• AI SW
4. Software Crisis
4.1 What's SW crisis ?
• 10/1968 - NATO meeting, SW specialists introduced the word "Software
crisis".
• To present, the word is still used with more pressure
Webster's Dict:
- A turning point in the course of any thing, decisive or crucial time,
stage or event.
• In the SW: slow, evolutionary change, chronic affiliation more than three
decades ( by Prof. Tiechrow, Geneva, Arp. 1989)
What do?
• How to do while the SW quality is diminished by the potential errors in
SW?
• How to maintain the SW after it is delivered?
• How to resolve when there are not enough SW technicians?
• How to manufacture the SW when the demands changed due to new
process ?
• How to manage when the SW failures cause social problems?
? Cost comparison between HW and SW
4.2 The difficulties in the SW develop
(1) There are not appreciable methods to describe user's requirements
? any trouble could occur after delivering the SW
(2) With big SW, the specified documents are made in long periods of time
? too difficult to adapt with the user's changes on time.
(3) If there is not any consistent design methods, ? the quality of SW
depends on the know-how of developer, and then, like a causal relation, will
be decreased.
Time
%
100
80
60
40
20
0
-
-
-
-
+
1955
+
1970
+
2000
+
1985
Hardware
Develop
Maintenance
Software SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
8
(4) If there are not any standards to write documents for the SW production
process
? unclear specification could make the SW quality diminution.
(5) If test for the correctness of SW is not made in each stage instead of the
last one, the delivery of the product will never be on time
(6) If we focus only on the programming stage but not the design stage
? the diminution of SW quality will occur
(7) If we do not focus on the SW-reuse
? the productivity will be diminutive too.
(8) In the SW development process, there are too many tasks made by people
? the productivity is always diminutive.
(9) If the correctness of SW is not verified
? the SW will too diminutive.
(10) The standard to measure the SW quality, in general, isn't quantitative
?the system evaluation is difficult and can not confirm its correctness.
(11) If maintenance takes a lot of man power ? productivity of team
decreases (12) If maintenance lasts long ? quality of documents reduces
and badly affects to other activities
(13) Loose project management leads to unclear schedule management
(14) There is no criteria to estimate manpower and estimation ? lengthen
the duration and exceed the budget of the project
These are problems reflecting aspects of SW crisis. ? Need effort to
overcome them!
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
9
Week Two Software Engineering
1. Software Engineering
? Bauer [1969]: The establishment and use of sound engineering principles
in order to obtain economical software that is reliable and works
efficiently on real machines
? Parnas [1987]: multi-person construction of multi-version software
? Ghezzi [1991]: SE is a field of computer science related to the
construction of big and complex software system by individual or a group
of engineers.
? Sommerville [1995]: SE is an engineering discipline that is concerned
with all aspects of software production from the early stages of system
specification to maintaining the system after it has gone into use.
? IEEE [1993]: SE is
1. The application of a systematic, disciplined, quantifiable approach
to the development, operation and maintenance of software. That
is, the application of engineering to software.
2 The study of approaches as in (1)
Software Engineering is a scientific field to deal with methodologies,
techniques and tools integrated in software production-maintenance process to
obtain software with desired qualities.
Morphology for SE Production
Present the techniques and methodologies
Apply in each process
Improve and apply in each product and tool
(computerize partially)
Synthesize and systematize for each tool
(computesize al the SW production process)
Will be automatic SW production
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
10
Technology in SE ?
1) Like other technologies, SE also takes the sciencetific methodologies as the
basis.
(2) The techniques for design, manufacture, test and maintenance are systematic
and become the methodologies and forming the SE.
(3) All the process to the SW development is related to the concept "software life
cycle" and modeled by the techniques and methodologies and creates different
topics in the SE.
(4) In the software life cycle, there are not only manufacture but also design,
operation and maintenance (the importance of design and maintenance )
(5) In the SW, not only the program but also the documents used for design and
maintenance.
(6) Technological approaches assist in increasing the SW productivity, reliability
and the diminution of cost.
Software life-cycle
• Software life cycle is a period of time from the moment when the
requirement is occurred to the one when SW dies (no one uses it).
• SW process (software life cycle) is divided into main stages : analysis,
design, production, testing and maintenance.
=> These stages, perhaps are different by people.
System
Requirement
Analysis
Verification
Software
Requirement
Analysis
Verification
Basic Design
Verification
Detailed Design
Verification
Programming
Debug
Programming
Debug
Testing
Running
Operation &
Maintenance
ReVerification
System
Requirement
Analysis
Verification
System
Requirement
Analysis
Verification
Software
Requirement
Analysis
Verification
Software
Requirement
Analysis
Verification
Basic Design
Verification
Basic Design
Verification
Detailed Design
Verification
Detailed Design
Verification
Programming
Debug
Programming
Debug
Programming
Debug
Programming
Debug
Testing
Running
Testing
Running
Operation &
Maintenance
ReVerification
Operation &
Maintenance
ReVerification
Waterfall
model of
Boehm
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
11
2. Software Development Process Models
3. Waterfall model
4. CMM/CMMI
4.1 Brief History
• Nov '86: the Software Engineering Institute-SEI (USA) gave the
framework and corresponding concepts helping improve the SW
development process.
• Sep '87: SEI published a specification for this framework.
• '91: specification ? Capability Maturity Model (CMM):
- CMM 1.0: 1991-1992.
- This slide: CMM 1.1.
4.2 The main Concepts
a. Process:
• A SW process is a collection of activities, methods, practices and changes
that are used to maintain and develop SW as well as related components
- Ex: project planning, design, programming, testing, guidance
documents
b. Software Process Capability
• The concept gives information about the desired result of a SW process.
• SPC can help in predicting the capability of carrying out the next project.
c. Software Process Performance
• Execute the SW development reveals its actual result.
? focus on the achieved result
? SPC: desired result.
• Due to the characteristics of each project as well as factual situations, the
real results do not often reflect SPC of company.
d. Software process maturity
Umbrella activities
Framework activities
Task sets
Tasks
Milestones,
deliverables
SQA points -
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
12
• Indicate a clear way to specify, manage, evaluate, and control the
software to take the most effect.
• Indicate the capability of development, worth of SW process and solid of
the project.
The components of CMMI
5 levels of CMMI
18 KPA of CMMI
Maturity
Levels
Key Process
Areas
Common
Features
Key
Practices
Process
maturity
Targets
Execute or ...
Institutionalize
Infrastructure or
activities
receive from
organized by
indicate
achieve
map
describe
Key
pratices
Repeatable
(2)
Defined
(3)
Managed
(4)
Optimizing
(5)
Initial
(1)
Disciplined
process
Standard,
consistent
process
Predictable
process
Continuously improving
process
Infrastruture
or activities SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
13
Capability of acknowledge at each level
• When PC increases:
- Differences between achieved results and estimated one decrease.
- Differences between actual results and desired one reduce.
- Improvements are achieved: reduced cost, shorter duration, higher
quality and productivity
LEVEL 5: Optimizing
LEVEL 4: Managed
16. Process
change
manageme
17.
Technology
change
manageme
18. Defect
prevention
14. SW
quality
Management
15.
Quantitative
process
management
LEVEL 3: Defined
7. Peer reviews
8. Intergroup
coordination
9. SW product
10. Integrated
SW
management
11. Training
program
12. Organization
process
definition
13. Organization
process
focus
LEVEL 2:
Repeatable
1. SW
configuration
management
2. SW quality
assurance
3. SW subcontract
management
4. SW project
tracking
and oversight
5. SW project
planning
6. Requirements
management
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
14
5. Linear Sequential model
• (System / Information engineering and modeling): set up requirements,
map some subsets of requirements to SW through interacting between
HW, people and DB
• Requirements analysis:
- understand aspects of information, function, behavior, properties
and GUI of the SW
- build documents and drafts to customers, users
• Design: a multiple steps process that has 4 separate properties of a
program:
- data structure,
- SW architecture,
- GUI,
- procedures-algorithms.
? Need clear and detailed documents, an important part of SW
configuration.
• Code generation / programming: transform the design into computer
program by any programming language. If the design is detailed enough
then the code generation is mechanically.
• Testing: verify internal logic and functions of programs/modules to
discover fault and assure appropriate output to input
• Support / Maintenance: to change, adapt and update developed SW due to
changes of environment and requirements
Disadvantage of Linear model
• Actual projects seldom follow the sequential flow of the model, iterations
often occur (Boehm's model)
• Requirements from customers seem not to come to an end
• Patient form customers are required because of time for development. If a
serious bug is discovered ? catastrophe
Analysis Design Coding Testing
Info System
Technology
Classic life cycle: waterfall model-most used SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
15
Week Three
Software Development Models (next)
6. RAD model
• Incremental SW development process
• Increase step-by-step, with short cycle: 60-90 days
• Component-based construction and reusability
• Include some teams, each team builds 1 RAD for each phase:
- Business Model
- Data Model
- Process Model
- Application Model
- Generation Model
- Test Model
Business modeling
Flow of information is modeled to answer questions:
- Which information controls business processing ?
- What information is created?
- Who activates?
- Where is information come from?
- Who processes this information?
Data and Process modeling
• Data modeling:
Rapid
application
model Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
60 - 90 days
Business
Modeling
Data
Modeling
Process
Modeling
Applicatio
Generati
Testing
&
Turnove
Busines
Modelin
Data
Modeling
Process
Modelin
Withdraw
raw Testing
&
Turnov
Team #1
Team #2
Team #3 SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
16
- Data objects are used for supporting business
- Properties of objects are defined
- Relations among these objects are set up
• Process modeling:
- Data objects are switched to information flow to realize business
functions
- Process business for each of them are created for updating (add,
edit, remove and recover)
Appl. Generation and Testing
• Application Generation:
- Use 4th generation techniques to build SW from built-in
components or create reusable component
- Use automatic tools to build SW
• Testing and Turnover:
- Test new components
- Verify all GUI (built-in components are tested and reused)
Disavantage ?
• Need much manpower to build main functions
• Require 2 parts of the contract to complete the SW in a short time
? lack of responsibility of one side ? project fails
• Is not appropriate for every SW, especially applications that can not
modulized or are high-level requirements
• Can not use when risk of high tech is found
6. Prototyping model
When?
• Only general aims of SW are known, but not details of input or
processing or output's requirements
• Used as "survey means" to collect users' requirements via rapid design
• Template algorithms, techniques are used to get requirements, not for
performance or optimization
Customers give
requirements
Create / edit
Templates
Customers
test templates SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
17
8. Incremental Models: Incremental, spiral and concurrent models
• Most of complex SW evolutes by the time: changed environment, new
requirements, new functions
• Evolutionary models are repeated: SW engineers builds many versions:
the latter, the better
• Models: incremental, spiral, WINWIN spiral, concurrent development
model
Incremental model
• Combine sequential model and repeated of templates
• Develop the most fundamental requirements of core-products in the
system first
• Develop other functions and requirements later
• Repeat the process to be more perfect
Spiral model
Analys
Design Coding Testin
System/info.
Engineering
Calendar time
Analysi
Design Coding Testing
Analysi
Design Coding Testing
Analysi
Desing Coding Testing
Increment 1
Increment 2
Increment 3
Increment 4
Deliver 2
Deliver 1
Deliver 3
Customer
Discussion
Planning
Risk Analysis
Engineering
Build and
delivery
Customer's
Estimation
Maintain
Update
New
Concept
Deliver 4 SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
18
• Customer discussion: between developer-customer to find out
requirements, suggestion
• Planning: set up resources, duration and other information
• Risk Analysis: evaluate risks of technique and management
• Engineering: build one or many presentations of applications
• Build and delivery: code, test, install and support users (documents,
training, . . .)
• Customers' estimation: receive feedback from users about SW's
operations in aspects of engineering and installation
Strengths vs Weaknesses?
• Appropriate for large scale SW
• Easily to control risk in each level of evolution
• Hard to convince customers that Spiral model is able to take under the
control
• Is not as popular as other evolutionary models
Concurrent development model
• Network of concurrent activities are identified
• Events occur under conditions of state movement in each activity
• Appropriate for all kinds of applications
• Give a quite precise view of current status of the project
• Most suitable for client/server applications: system and components are
developed concurrently
9. Other models: 4th generation technique model, formal methods model
Component-based model
• Go with Object-oriented technologies through initalizing classes with data
and data processing algorithms
• Have many similarities to Spiral Model
• Because of the ability of reusing components via library: save 70%
developing time, 80% budget, Production Index: 26.2/16.9
• UML is confirmed as industry standard
Customers
Discussion
Planning
Risk analysis
Engineering
Build
Delivery
Customers'
Estimation
Identify
candidate
components
Find
Components
from library
Use
component
(if has)
Build
component
If do not have
Put
component
into library
Build the nth
iteration
of the system SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
19
Fourth generation techniques
• Collect tools that are used to identify SW's properties at high level,
• Automatically generate code based on specification
• Symbolic 4th generation tools-4GT:
- Un-procedure language to create query for DB
- Data processing
- GUI
- Code generation
- High level graphics
- Spreadsheet
- Web Interface
- ...
How ?
• Between customers and developers is the most important from
requirements collection and products
• Can not skip design phase. 4GT is applied only to implement design via
4GL
• Strength: reduce time of developing, increase productivity
• Weakness: 4GT is harder to use than programming language, to optimize
code and to maintain large system ? require skill of SW engineers
• Future: 4GT and component-based model
10. Product and process
• Weak process ? nearly impossible to receive good product
• Neither focus much on process nor product
• Product and process need to be focused at the same level of importance
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
20
Week Fourth
SW Requirement
1. Software Requirement
1.1 SW Requirements ?
• Are all requirements about the SW which are requested by customers-SW
users, include requirements of:
- SW's functions
- Performance
- Design and interface
- Special requirements
• SWR are often divided into 4 categories:
- Requirements about Software
- Requirements about Hardware
- Requirements about Data
- Requirements about People and Users
• Aim: response to customers' demands e.g SW users.
1.2 Why must define SR?
• Customers often have indefinite ideas about the software they need
? developers must be ready and patient to be able to build SW with full
necessary functions from that unclear thought
• Cust enjoy changing their requirements
? catch changes, update description in a suitable way
2. SR Process
i) Requirements elicitation
ii) Requirements analysis and negotiation
iii) Requirements specification
iv) System modeling
v) Requirements validation
vi) Requirements management SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
21
Analysis Model
2.1. Requirements Elicitation
Problems of requirements elicitation
• Scope
• Understanding
• Volatility
Requirements Elicitation Methodology
• Identify methods used to discover SW requirements: interview,
team-work, meetings,... etc
• Seek staff (expert, users) who have deep and detailed knowledge
about the system ? find out requirements
t th he e p pr ro ob bl le em m
R Re eq qu ui ir re em me en nt ts s
e el li ic ci it ta at ti io on n
B Bu ui il ld d a a
p pr ro ot to ot ty yp pe e
C Cr re ea at te e
a an na al ly ys si is s
m mo od de el ls s
Develop
specification R Re ev vi ie ew w
Data Model
Functional
Model
Behavioral
Model SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
22
• Identify "technical environment"
• Identify "domain constraints"
• Attract participation of many experts, custs ? get different views
about the SW from the client-side
• Design scripts to use SW
Output of SWR elicitation
• Statements of:
- requests, functions of the SW
- Applied scope of the SW
- Collect use-case scripts
• Description technical environment of the SW
• Prototype for building, developing or using (if have)
• List of staffs joining in the process of requirement identification,
including staffs from the company-cust.
2.2. Requirements Analysis and Negotiation
• Categorize requirements, divide into related groups
• Detailed survey of each requirement in the relations with other
requirements
• Assess each requirement in properties:
- Suitability
- Completeness
- Clearance
- Identicalness
• Hierarchy of SW requirements is based on need and request of cust/users
S So of ft tw wa ar re e
E En ng gi in ne ee er ri in n
G Gr ro ou up p
C Cu us st to om me er r
G Gr ro ou up p
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
23
• Assess each requirement to identify the capability of realization in
technical environment or validation of requirements
• Assess possible risks for each SW requirements
• Raw estimation of cost, time to realize each requirement compared to
those of SW product
• Solve all divergence between developers-users
• Negotiate suggested requirements
2.3. Requirement Specification
• The task of building specifications
• Tools can be used:
- Modeling
- Formal mathematical model
- Collections of use-case scripts
- Prototypes
- Combinations of all above
• Quality of specification files is estimated by criteria:
- Clearance, precision
- Suitability
- Completeness
• Components of specification files:
- Informal specifications: written in natural languages
- Formal specifications: written by collections of symbols which
have strict regulations of syntax and semantic: graphic used
diagrams
- Operational specifications describe operations of SW system
being built:
i-Services will be provided
ii-Responses of system to particular input
iii-Behavior of system to special situations
- Descriptive specifications - specify properties, characteristics of SW:
i-Constraints of services or system functions (ex: time)
ii-Constraints of development process, standards,...
- Requirements about scope, originating from application domain of
system application and its specific characteristics.
Functional specifications
i) Describe functions of system, depend on PM and users' expectation
ii) Tools often used:
- Data Flow Diagrams
- Finite State Machines
- Petri nets,...
- Not obligatory
- Can use natural language
Non-Functional Specifications
i) Define system's properties, constraints: reliability, time to response, memory
capacity,...
ii) Requirements stipulated: process, document standards,...
iii) External requirements
? Non-functional specifications are hard to exactly state and test
• Tools popularly used SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
24
- Entity-Relationship Diagrams
- Logic Specifications
- Algebraic Specifications
Difficulties with NL?
Specification Documents
• Document of requirements: official statement about system developers'
requirements :
- Definition
- Requirement specification
• # design document:
- Should be a set of what to do
- Should not be how to do
( analysis # design)
Requirements of specification documents
• Specify system's external behaviours
• Specify constraints of installation
• Easy to change
• A referenced tool for maintenance
• Careful writings about system's life cycle ? predict changes
• Responses to unexpected troubles
Who use the Requirement's documents?
3. Structure Analysis
Apply 5 principles to analyze SR
• Principle I Data Modeling
- Identify data objects
- Identify attributes of data objects
- Set up relations among data objects
• Principle II. Functional Modeling
- Identify functions of transferring data object over
- Indicate the data flow moveing in the system
- Present parts that generate/use data
• Principle III Behavioral Modeling
- Indicate different states of system
- Specify events leading to state change
• Principle IV Partition the Models
- Refine each model to present lower levels of abstraction
- Filter data object
- Create functional hierarchy
- Present behavior at different detail levels
• Principle V Essence based
Begin by focusing on the essence of the problem without
regarding to implementation details.
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
25
Week Five
SW Requirement (Next)
1. Tools for functional Modeling
i) Business Functional Diagram -BFD
ii) Data Flow Diagram - DFD
iii) Finite State Machines -FSM
BFD gives us a statical image of one system:
? What are their components (subsystem) and whate are their
functions?
? The relation between them
? usefull to buil a dynamic system (DFD)
? Limitation: don't give the exchange info between their
components and the external world .
2. DFD: Data Flow Diagram
? System: Set of data will be processed by functions
? Notation used:
- Express a function
<Data name> - Express a data flow
Data store - Express a data store
- Input-Output Data and interaction
between the system and user
Function SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
26
Ex1: The execution of a Math Expression with DFD:
(a+b)*(c+a*d)
Ex2: A DFD for a library system DFD
Creating a Data Flow Model
+
*
* +
a
a d
c
Servicable
Books
Search by
topics
Borrower's
requirements
Book store
List of authors
List of titles
List of topics
Requested topics Give books
List of borrowers
Books'
information
Book
Topics
Author's name
name
Book's name
Show book's name
name
related to topics
Book's title
Borrower's name
Book
Book's name, author's name,
Borrower's name SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
27
• DFD enables the SE to develop models of the info domain and functional
domain at the same time.
• As the DFD is refined into the greater level of detail (4th principle), the
developer perform an implicit decomposition of the system.
• A few simple guidelines:
- At the level 0, system has only a single function
- Input/Output shoud be carefully noted
- Refinement should begin by isolating candidate processes, entities
and stores to be represented at the next level
- All the components (arrow, boubbles) should be labeled with
meaning full name.
- Info flow continuity must be maintained.
- One bubble at a time must be refined.
Ex: SafeHome
• Problem: people want to develop a system "SafeHome" that enables
the homewner to confuge the secutiry system. When it is installed,
monitors all sensord connected to the secutity and interact with the
homeowner through a keypad and function keys contained in the
SafeHome control Panel.
• The SE must have three main functions:
1- Configure system
2- Monitor sensor
3- Interact with user
The 2nd function has two functions:
i) poll for sensor event
ii) active alarm functions
Each function has also some functions,...
DFD at level 0
DFD at level 1
Exercise: decompose the system at any level: 1, 2,...
SafeHome
Software
Control
Panel
Sensor
Sensor status
Control
Panel Display
alarm
Telephone line
Telephone
number tone
Alarm type
Display Info
User Command
and Data SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
28
Give some ex.
Limitations of DFD
• Meanings of used symbols are identified by users' choice
• Example of search function:
If Users fill in author's name and book's title
Then search corresponding books,
if does not exist
then notify error
Else if only author's name
Then
show list of corresponding books whose author's name is received
and require Users to choose books
Elseif only book's title Then
. . .
Endif
• DFD does not identify clearly control aspects
This DFD does not specify the input/output for function D
- Function D may need:
• A, B C
• Only one in A, B and C
- Function D can send result:
• To one in E and F
• To both
• Separately to E and F
• DFD can not identify synchronization between functions/modules:
- B received data processed by A
- A and B are asynchronous activities
? need buffer to prevent from data loss
3. FSM: Finite State machine
FSM includes:
• Finite set of states Q
• Finite set of inputs I
• Switching functions
A
B
C
D
F
E
A B
Q I Q ? ? : ?SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
29
• Example: activities in a library:
- Borrow / return
- Add title / remove title
- Lists of titles in the order of authors' name or topics
- Search books due to users' requirements
- Find expired date books, . . .
• Characteristic requirements:
- Reader can not borrow excess a definite quantity in a specified
- Some books are not allowed to home borrow
- Some kinds of books are not allowed to borrow by some users, . . .
Objects -
Title
Book_code
Librarian
User
• Should have a set of titles, authors for each book, list of related
topics of each books
• A set of books (each title can have more than one book in the
library). Each can be in 1 of 5 status:
- (AV) - Available
- (CO) - (BR) - Check Out; Borrow),
- (L): Last, (R): Remove
• FSM specify states
CO BR
L R
AV
ON
OF
F
High pressure alarm
High temp. alarm
Restart SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
30
Week Six
No- functional Requirement
1. No - functional Requirement
Classifications
• Product requirements
- Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
• Organisational requirements
- Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.
• External requirements
- Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Non-functional requirement types
Examples
• Product requirement
- 4.C.8 It shall be possible for all necessary communication between
the APSE and the user to be expressed in the standard Ada
character set
• Organisational requirement
- 9.3.2 The system development process and deliverable documents
shall conform to the process and deliverables defined in XYZCo-
SP-STAN-95
• External requirement
Performance
requirements
Spac e
requir ements
Usability
requirements
Ef ficiency
r equir ements
Reliability
requirements
Por tability
requirements
Interoperability
requirements
Ethical
requirements
Legislative
requirements
Implementation
requirements
Standa rds
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirementsSE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
31
- 7.6.5 The system shall not disclose any personal information
about customers apart from their name and reference number to
the operators of the system
• A system goal
- The system should be easy to use by experienced controllers and
should be organised in such a way that user errors are minimised.
• A verifiable non-functional requirement
- Experienced controllers shall be able to use all the system
functions after a total of two hours training. After this training, the
average number of errors made by experienced users shall not
exceed two per day.
Requirements measures
Requirements interaction
• Conflicts between different non-functional requirements are common in
complex systems
• Spacecraft system
- To minimise weight, the number of separate chips in the system
should be minimised
- To minimise power consumption, lower power chips should be
used
- However, using low power chips may mean that more chips have
to be used. Which is the most critical requirement?
Domain requirements
• Derived from the application domain and describe system characterisics
and features that reflect the domain
• May be new functional requirements, constraints on existing requirements
or define specific computations
• If domain requirements are not satisfied, the system may be unworkable
=>We focus on Data Model
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systemsSE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
32
2. ERD- Entity Relationship Data Model
2.1 Basis elements of Entity Relationship Model
• Entity - set of related information need processing in SW
• Entity may have relations: - person owns car
• One entity is represented by a labeled rectangle. Ex: Person, Car are the
entities.
• The relationships are indicated with a labeled line connecting entities
(ex1).
• Some variations: the connecting line contain a diamond labeled with the
relationship (ex 2).
• Entity has attributes
• Attributes: Properties of an entity or a data object
- Name an instance of the data object
- Describe the instance
- Make reference to other instances
Set of attributes of a data object is identified through problem's context.
Relation - show references among data objects
? Cardinality : indicates quantification of the relation
1:1 one-to-one 1:N one-to-many M:N many-to-many
? Modality : 0 - relation may (not) exist
1 - relation is obligatory
Person
Owns
Car
Customer
Repair Action
is provided with
Ex1
Ex2
Car
Ford
Blue
ID
Automobile
Company
Ford
Bookstore Books
1 N
Orders SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
33
Ex: ERD describe a Library
2.2 How to create a ERD
1- Find out the entities:
- Criteria
i) need to manage
ii) distinguish
- Source: ? Men, meterials and structured documents,...
2- Determine the attributes: depend on the specific domain.
3- Analyse the relation between the entities
- 3 main relations:
i) one to one (1-1)
ii) one to many (1-n)
iii) many to many (m-n)
4- Construct the Entity Relationship Diagram
- Based on 3 steps above
2.3. Create a ERD for a specific system
As exercice
3. Data Specification
Pspec role
• Pspec is used to describe all flow model processes, apper at the final level
of refinement.
Customer
Is
provide
d
with
Repair Action
1 N
Area
Title
Author
Deals
with
Written
by
Belongs
Copy
holds
Was
held
by
Borrower
state
1 M
N N
N
Text
1
ER diagram for a library
limit SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
34
• Content: narrative text, PDL, diagrams or charts
• Ex: a software appl in which the dimensions of geometric objects are
analysed to identify the shape of object.
The analyse-triangle process accepts values A,B and C that represent the side
dimension of a trangle. The process tests the demension values to determine
whether all values are positive. If a negative value is encountered, an error
message is produced. The process evaluates valid input data to determine
whether the dimention define a valid triangle and if so, what typw of triangle -
equilateral, isosceles or scalene- is implied by the demention. The type is output.
Data dictionary
1-Why?
- In each representation, data and/or function play a role. Therefore, it is
necessary to provide an organized aproach for representing the charac-
teristics of each data and control item.
2-What?
- Data dictionary is a organize listing of all data elements that are
pertinent to the system, with precise, rigorous definition so that noth
users and developer will have a common understanding of input/output,
components of storeand intermediate calculations.
3-Format
Although the format varies from tool to tools, most contain the following
info:
- Name: name of the data item or function, data store,...
- alias: other names
- Where used / how used
- Content description
- Supplementary info
4.Criteria for good specification
• Easy for user to understand
• Little ambiguity
• Few conventions for describing, easy to create
• Top-down
• Easily implement for next phases in life cycle: system design, program
design and interface are easy to build and assured the consistent,...
In the analysis step, we can use structured method or object oriented method
(UML - week 10)
Analyse triangle
Triangle type
Error
message
Side dimension
of triangle
PSPEC: Processing narrative for Analyse
Triangle SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
35
Week Seven
Software design
1. System Architecture Design
1.1 Design concept and principles
What's the system design
• Is to design hardware configuration and software structure (both function
and data) to archive the system satisfying needed requirements
• Can be considered as Structure Design (WHAT), not Logic Design
(HOW).
Design process
• Divide analysis model into subsystems
• Find concurrency in the system
• Distribute subsystems to processors or tasks
• Develop interface design
• Select implementation strategy for data management
• Find shared resource and its control mechanism for accessing
• Design the suitable control mechanism for the system, even task
management
• Consider how to process boundary conditions
• Consider and review trade-offs
Remarks
(1) Can extract data flow from system: the content specifies requirements and
interface
(2) Consider optimize architecture resource in the system ? decide
architecture
(3) Follow process of data modification, how functions are architectured?
(4) From architecture of functions in (3): review and adjust; switch to
program architecture and detailed design
(5) Decide program units due to SW's functions, data flow and divide into
components
(6) Need to divide into smaller modules when the program structure is too
complicated
(7) Consider input-output data and shared files in program. Optimize file
accessing
(8) Which methodologies and techniques should be used to achieve the
above design?
System design
• System design
- Hardware system design [(1), (2)]
- Software system design [(3)-(7)]
• Sw Design SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
36
- File design) [(7)]
- System's functions design [(3)-(6)]
1.2 Concepts and Tools: module, Bubble chart, Hierarchical Structured
Chart - HSC
• Module
- Chain of statements to act a function
- Can compile independently
- Compiled modules can be invoked by others
- Interface between modules via arguments
Compare to Programming Language!
• Bubble chart
Present data processing flow
Notation:
• Hierarchical Structured Chart
? The hierarchy present dependent relation between modules and
interface
• Convention:
- Not related to sequence of calling modules. Default is from left
to right
- Each module appearing once in the structure can be called many
- Upper-lower relation: do not need to denote the number of calls
Function's
name
Data's name Data's name
(Input data) (Output Data) (Bubble) SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
37
- Module's name presents function ("What")
? synthesize lower modules' name will present full function of their
upper module
- Arguments present interface between module. Arguments in
invoking modules can be different form those in invoked ones
- Arrow that has white, round tag present data. One that has black
(pink), round tag presents flag
- Arrow's direction shows direction of argument transfer
1.3 Methods for system architecture design
Methods
Structured Design method (Constantine)
Other methods: Composite Design ( Myers)
Structured Design
? Having origin of modularity, top-down design and structured
programming.
? This is called as Data flow-oriented design.
? Process of 6 steps: (1) make the flow information; (2) determine
the flow's boundary; (3) Map DFD to HSC; (4) identify control
hierarchy; (5) refine structure; (6) select architecture specification.
Structured Design process
(1) Module and arguments
(2) Bubble chart and Hierarchical structured chart
- Bubble chart
- Hierarchical structured chart
(3) Method STS (Source/Transform/Sink) and TR (Transaction)
(4) Structured analysis
(5) Standard for module decomposition
Module A
Module B Module C Module D
Module E
1
Data flow
Flag flow
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
38
2. STS Method
Concept
? Method STS (Source/Transform/Sink)
? Method TR (Transaction)
8 stages to create a HSC
1) Divide the "Problem" into the functional component
Decision main flow
2) Find the main data flow go through all the functional component from Input to
Output.
Transform in Bubble chart
3) Follow main data flow : replace each function by bubble and clarify data
among bubbles
Transform from the Bubble chart to DFD
4) Identify the position of abstract (at the highest level) of input/output data
5) Construct a DFD
F2 F3 F4 F5 F1
Data1 Data2 Data3 Data4 Data5 Data6
INPUT
Abstract (at the
highest level) input
Abstract (at the
highest level) output
Source Module Transform Module
Sink Module
OUTPUT
Sink Module
F1
F2
F3
F4
F5
Problem
F1
F2
F3
F4
F5
INPUT
OUTPUT
Main data flow
F2 F3 F4 F5 F1
Data1 Data2 Data3 Data4 Data5 Data6
INPUT OUTPU
T SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
39
6) Determinate the parameters
7) Apply STS partition in each module (Source, Transform, Sink) from step 1 to
step 6. It can be partitioned into 2 not 3 modules.
8) Continue partitioning to the level of logic structure until corresponding
module to known algorithm.
? synthesize = hierarchical structure: each node is one module whose
branches are equal or less than 3
3. TS method
Concept
• When the main data flow does not exist and input data has different
features as different sources which can be considered as different
Transactions.
• Each transaction has its own processing module
• Divide module:
- By experience
- By module's independence
- By the maximum number of steps in one module (example < 50)
F2 F3 F4 F5 F1
Data1 Data2 Data3 Data4 Data5 Data6
INPUT OUTPUT
Abstract (at the
highest level) input
Abstract (at the
highest level) output
Source Module Transform Module Sink Module
Control
Module
Source
Module
Transform
Module
Sink
Module
0
1 2 3
Module 0
Module 1 Module 2 Module 3
0
1 2 3
3
3
5
5
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
40
- By standards.
TR process
i) Determine transaction's center which includes some category functions
and functions in processing process:
- In: functions transfer information from source and some functions
make raw processing.
- Out: functions give information out from processing event.
ii) Draw two highest level of structure diagram:
- one highest module (top): level 1
- 1 for input, 1 for processing each case, 1 for output: level 2.
Example
Functional diagram has 1 transaction centre
HSC at top level
4. Architecture design aptomization
- Identify data flow
- Apply STS partition in linear flow
A B D C
T1
T3
T2
x y
u1
u2
u3
v3
v2
v1
z
T1
Get y
T2 T3 Transfer z
Input Process transactions Output
Main SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
41
- Apply TR partition in branch flow
Standard for module decomposition
• Independent: coupling and strength
• 5 criteria of Myers
- Decomposability
- Composability
- Understandability
- Continuity
- Protection
Characteristics of structured design
• Easy to adapt to the Waterfall model due to high friendliness
• Design due to process does not fit batch system
• Use partition-synthesis to solve the system's complication
• Top-down in module partition
• Effect programming technique
Week Eight
Software design -2
1. Modules Design
What is Modules Design?
• Design internal structure details in SW: design characteristics in each
module and corresponding interface
• External structure in SW: system design
• Internal processing order: Algorithm; Logic.
Techniques for modules Design
• Do not have fuzzy state to assure true internal structure design
• Suitable programming language
• Accurately implement specification of module's functions and program
due to detailed design methodologies
• Use design process to easily standardize each step
• Design techniques for SW system model
- Process-oriented: technique of control structure design
- Data-oriented: technique of data structure design
- Object-oriented: technique of object-oriented design
2. Structure Design
? Fundamental concepts: sequence, branch (switch case), loop;
expanded structure, pre-processing, post-processing.
? Benefits in algorithm design:
o Module's independence: consider only input/output
o Program:
? Easy to understand
? Easy to monitor the way of executing SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
42
o Complicated system will be easy to understand due to
hierarchical approach
Eliminate GOTO
• What is GOTO used for?
- Allow to carry out jumps to a particular label
• Why need eliminate GOTO ?
- Break structure of structure programming
• Methods for eliminate GOTO
• Can eliminate GOTO in every case?
• What is "skill of structure programming"
Ex Spaghetti's program
Program structured
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
43
Recommendations
• Depend on skill and experience of designer.
• Need to standardize document of detailed design specification.
• Due to conventions of structure, designer's creativity may be limited or
depended on existed templates when design the control structure of
algorithm
3. Graphical design Notation
? Effect of flow chart
? Discipline
? Abstract procedures
? Structured diagram:
- Structure fundamental control
- Detail each step in algorithm
- Present the sequence of implementation control
NS chart by IBM
a- concatenation b- selection
Treatment
Treatment
Con Y
treatment treatment
Con
Treat-
ment 1
Treat
Ment 2
Treat 3
TT1
TT2 TT3
Cond
Treatment
Cond
Treatment
N
c- case d- repetition
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
44
PAD chart by Hitachi
4. Jackson's method
? JSP: Jackson Structured Programming
? Notations:
- elementary
- sequence
- repetition
- branch
JSD express the functions of an employee system
General design process
• Data Design steps
• Program Design steps
• Operation Design steps
• Text Description steps
a a- concatenation b- selection
concatenation b- selection
c- case d- repetition
- case d- repetition
WHILE
Cond
Treatment
Treatment
Treatment
Treatment
Treatment
Cond
Treat1
Treat 2
Treat 3
TT1
TT2
TT3
TT4
C
O
N
D
I
T
I
O
N
UNTIL
Cond
Treatment
Main
axis SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
45
5. Wanier's method
? General concepts
? Design order
- Output data design
- Input data design
- Program structure design
- Diagram design
- Procedures/statements design
- Detailed specification design
Week Nine
Software design -3
1. Object Oriented Concept
• Objects are entities in a software system which represent instances of
real-world and system entities.
• Object classes are templates for objects. They may be used to create
objects.
• Object classes may inherit attributes and services from other object
classes.
An object is an entity which has a state and a defined set of operations which
operate on that state. The state is represented as a set of object attributes. The
operations associated with the object provide services to other objects (clients)
which request these services when some computation is required.
Objects are created according to some object class definition. An object class
definition serves as a template for objects. It includes declarations of all the
attributes and services which should be associated with an object of that class.
Object communication
• Conceptually, objects communicate by message passing.
Employee
name: string
address: string
dateOfBirth: Date
employeeNo: integer
socialSecurityNo: string
department: Dept
manager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. . .
join ()
leave ()
changeDetails ()SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
46
• Messages
- The name of the service requested by the calling object.
- Copies of the information required to execute the service and the
name of a holder for the result of the service.
- In practice, messages are often implemented by procedure calls
- Name = procedure name.
- Information = parameter list.
Message examples
Call a method associated with a buffer
// object that returns the next value
// in the buffer
v = circularBuffer.Get () ;
// Call the method associated with a
// thermostat object that sets the
// temperature to be maintained
thermostat.setTemp (20) ;
Interacting objects
Generalisation and inheritance
• Objects are members of classes which define attribute types and
operations
• Classes may be arranged in a class hierarchy where one class (a super-
class) is a generalisation of one or more other classes (sub-classes)
• A sub-class inherits the attributes and operations from its super class and
may add new methods or attributes of its own
• Generalisation in the UML is implemented as inheritance in OO
programming languages
A generalisation hierarchy
state o3
o3:C3
state o4
o4: C4
state o1
o1: C1
state o6
o6: C1
state o5
o5:C5
state o2
o2: C3
ops1() ops3 () ops4 ()
ops3 () ops1 () ops5 ()SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
47
2. Encapsulation
Transparent to user:
- users do not care object's internal structure (attributes, methods)
internal changes do not affect user
- Prevent complication
- Any effect to object is done via message passing
Hidden implementation in OOP
• Two tasks in programming:
- Object class creators
- Client programmers
• Two causes to implicit execute in OOP:
- Allow client to access and use their corresponding items. Some
classes are hidden and not be accessed by clients.
- Allow designers to change or redefine classes without affecting
application
Employee
name: string
address: string
dateOfBirth: Date
employeeNo: integer
socialSecurityNo: string
department: Dept
manager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. . .
join ()
leave ()
changeDetails ()
Employee
Programmer
project
progLanguage
Manager
Project
Manager
budgetsControlled
dateAppointed
projects
Dept.
Manager
Strategic
Manager
dept responsibilitiesSE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
48
• Note:
- different programming languages have different implementations
- Eg, some methods for only some clients (friend), some for shared
(public) and the same to attributes (private, static, public,
protected)
3. Inheritance
There are different views as to whether
inheritance is fundamental to OOD.
View 1.
- Identifying the inheritance hierarchy or network is a fundamental
part of object-oriented design.
- Obviously, this can only be implemented using an OOPL.
View 2.
- Inheritance is a useful implementation concept which allows
reuse of attribute and operation definitions.
- Identifying an inheritance hierarchy at the design stage places
unnecessary restrictions on the implementation
• Inheritance introduces complexity and this is undesirable, especially
in critical systems
Reuse in OOP
• It costs manpower to build (code) classes. Reuse classes is one of
important characteristics of OOP
• The easiest way to reuse one class: reuse directly its objects as necessary
boundary to solve the problem
• 2nd, use class's object variables to build new class (object in new
classes). Composition principle is also called aggregation. This princinple
present has-a relationship
• 3rd, present in inheritance principle
• Help in building new classes based on existed ones. Just add non-existed
or inadequate items ? inheritance in OOP
• Fundamental class
• Inherited class
• Characteristics
• Relation "Be": objects in inherited class can be considered objects in
fundamental class.
• Relation "As": inherited classes redefine fundamental classes' behaviors
Polymorphism in OOP
• When building inherited classes in OOP, it can be: inherited classes
define the same behavior (function) as fundamental ones ? compiler can
not identify which behavior will be called
- early binding function
- late binding function
• Can be shown in principles:
- Function-override: similar functions' arguments are different in:
quantity or data type SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
49
- Operator-override: redefine existed operators in programming
languages on new data, objects in classes need to be built
UML associations
• Objects and object classes participate in relationships with other objects
and object classes
• In the UML, a generalised relationship is indicated by an association
• Associations may be annotated with information that describes the
association
• Associations are general but may indicate that an attribute of an object is
an associated object or that a method relies on an associated object
Week Ten
Software design -4
1. Object Oriented Analysis
An object-oriented design process
• Define the context and modes of using the system
• Design the system architecture
• Identify the principal system objects
• Develop design models
• Specify object interfaces
Characteristics of OOD
• Objects are abstraction of real-world or system entities and manage
themselves
• Objects are independent and encapsulate state and representation
information.
• System functionality is expressed in terms of object services
• Shared data areas are eliminated. Objects communicate by message
passing
• Objects may be distributed and may execute sequentially or in parallel
Advantages of OOD
Employee
Department
Manager
is-member-of
is-managed-by
managesSE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
50
? Easier maintenance. Objects may be understood as stand-alone entities
? Objects are appropriate reusable components
? For some systems, there may be an obvious mapping from real world
entities to system objects.
Object-oriented development
1) Object-oriented analysis (OOA), design and programming are related
but distinct
2) OOA is concerned with developing an object model of the application
domain
3) OOD is concerned with developing an object-oriented system model
to implement requirements
4) OOP is concerned with realising an OOD using an OO programming
language .
Object Oriented Analysis
• A brief introduction to UML
• 5 views in UML
• Use case, sequence chart,...
• Object Oriented Development with UML
5 views in UML
Basic elements in UML
• Package
• Subsystem
• Subsystem and Component
• Object
• Class
• Interface
• Component
• 4 main relations :
- Dependency
- Generalization SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
51
- Realization
- Association : Aggregation, Compostion
? 8 diagrams
- Use Case Diagram
- Class Diagram
- Component Diagram
- Deployment Diagram
- Statechart Diagram
- Activity Diagram
- Sequence Diagram
- Collaboration Diagram
Use - Case Diagram
Use-case diagram provides use cases, actor and association among them
Used to:
- Model a sequence of activities that the system will carry out, provide a
meaningful result for the external actors.
- Provide a general view for what the system will do and who will use
- Provide a basis to identify the human-computer interact in the system
- Model scenario for 1 UC
- Let end-user understand and interact with the system at the general level
- Help in drafting specifications for testing
Steps in building UC
• Find actor
• Find UC
• Describe UC
• Test whether those UC are adequate
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
52
Example
Abstract actor
Communication relation
Interact diagrams
• Definition: model dynamic aspects of the system
• Compose of object collection, relations and transferred message
Customer withdraw
Fast
withdraw
Customer
verification
<< uses >>
Understand existedSE
existedSE
staff
Hour staff Month staff
Contract
staff
Customer
Payment
system
Withdraw SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
53
Collaboration Diagram
• It is possible to identify classes, their relations, operations and each
class's responsibility
• It is included:
- Object
- Connection
- Message
- Comment (if needed)
Sequence Diagram: focus on controlling in timing order. Show objects arranged
in a continuous duration of time
Collaboration Diagram: focus on data flow but not in timing order
Class Diagram
• Show the existence of classes and relations among them under the logical
view
• Fundamental components in class diagram:
- Class
- Attribute
: Student
registration
form
registration
manager
math 101
1: fill in info
info
2:
ssubmit
submit 3: add course(joe, math 01)
4: are you open?
5: are you open?
6: add (joe)
7: add (joe)
math 101
section 1
course form :
CourseForm
theManager :
CurriculumManager
aCourse :
Course
1: set course info
2: process
3: add course
4: new course
3: add course SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
54
Class: a collection of objects, has common structure, common effect, common
relations and common semantics
Relationships
State Diagram
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
Student
name
major
CourseOffering
location
addStudent(StudentInfo)
Professor
name
tenureStatus
ScheduleAlgorithm
RegistrationForm
RegistrationManager
Cours
e Studen
CourseOffering
Professor
ScheduleAlgorithm
Initializatio
Open
entry: Register student
exit: Increment count
Closed
do: Initialize course
course
do: Finalize course
Canceled
do: Notify registered students
Add Student /
Set count =
0
Add student [ count <10 ]
[ count = 10
]
Cancel
Cancel
Cancel
Cours
name
numberCredits
) addStudent(Stude tInfo) SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
55
2. Object Oriented Design
USDP process
• Process of SW development in OO methodology
- Fundamental principles and development steps
- Techniques and models, diagrams
• Eg: develop application - tour management problem
- analysis
- design
• Development process to achieve requirements need to specify:
- What must be done
- How to do
- Who will do
• USDP is developed by the group that builds UML based on principles:
- Loop and increase development
- Component-oriented development
- Requirement-oriented
- Structured
- Visual modeling technique
The steps SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
56
• Collect and model requirements
• Analysis requirements
• System design
• Class design
• Interface design
• Data management design
• Build
• Implement, testing
Activity diagram for design process
Collect and model requirements
• Users' requirements
- Functions the system have to execute (functional requirement) or a
standard for system's activities (Non-functional requirement)
- Survey existed system and new requirements
- Techniques for real specification/investigation
• Use case
- Describe system's functions from the user's view
- Do not care about how the system goes SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
57
Requirement analysis
• Each use case is analyzed to recognize objects, their interaction via
interfaces as well as responsibility ? origin analysis diagram
• What does requirement model have to do?
• Techniques:
- UC realization
- Collaboration diagram
- Class diagram
- Class-Responsibility-Collaboration tag
- Synthesize analysis diagrams
Improve Requirement model
• Help in developing components which can be reused
• Abstract mechanism for this aim: class hierarchy system.
• Abstraction
• Generalization
- General factors
- Individual factors
• Aggregation
The relation between the whole and the part, Whole class composes many
components of Part class
? Interaction among objects: two kinds of interaction diagram and message
passing
? specification of operation and control
System design
? Name subsystems and basic components
? Identify subsystems to the processor
? Select data management strategy
? Identify standard for development
? Identify implementation requirement
• Cascade subsystem
Each layer is corresponding to one or more subsystems. They are distinct
by the level of abstract or their functions. SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
58
• Separate subsystem
Objects and data design
• Specify class.
- Attribute : name ':' type-expression '=' initial-value '{' property-
string '}'
- Operation: name '('parameter-list')' ':' return-type-expression
• Design standards (coupling và cohesion)
• Operation design
• Object reference
• Combination design
• Mapping class to table
• Mapping the level of inheritance to table
Combination design
Combination of multiple-multiple in 2 directions
E.x: tour management problem (as exercice)
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
59
Week Eleven
Software Testing
1. Software testing
1-1. The role of software testing
What's SE testing?
• A key part for SQA
• A process (and also an art) for detecting errors by reviewing the
specification, design and coding.
• A successful testing must detect error, otherwise, a bad testing (Sue
A.Conger- The New SE)
Difficulties in SE testing
• Increment the Quality of SE but don't exceed the quality in design:
it detects only potential errors and corrects them.
• Error detection is limited by manual process.
• Psychology is easy to be influent
• Completeness is difficult to ensure
6 remarks
(1) Quality of SE is determined by design
(2) Easy testing may depend on structure of program
(3) Tester and developer would be different
(4) Need the data to support error detection
(5) Not only input data but also the expected result
(6) When error is detected, it's better to repeat the latest test to avoid
influential propagation.
1-2. Techniques for software testing
i) Static testing
ii) Dynamic testing/Machine testing
• Static testing: papers, pencils to logic verify to follow all the details
once the programs are written. Techniques:
- walk through
- inspection
Machine testing
• Machine debug or dynamic testing: Execute programs on the
computer to review the status of programs.
• 9 steps for machine testing:
(1) Design test case following the static test
(2) Prepare the expected result
(3) Compile source module to obtain the object module
(4) While test case need the i/o file must identify the domain of the
file.
(5) Input the data for this test case
(6) Correct the executable environment SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
60
(7) Execute the object module to obtain the result
(8) Match the obtained result with the expectant result
(9) Repeat the steps (5)-(8)
• Technique based on external description of program - Black box test:
WHAT ?
• Technique based on internal description of program - White box test:
HOW ?
• Others: Top-Down and Bottom-Up test.
1-3. Compatibility between Software Life Cycle and Testing process
2. Black Box Test
• Equivalent partition
- Objective: diminution in the test numbers by selecting the
representative data
- Execution: divide data into partitions and execute the test on each
partition
- Advantage: Test on abstract level
- Ex:
• Boundary values analysis
- Is a specific case of equivalent partition
Objective and scope
Functional description/
Logical design
Physical
design
Module description
Acceptance test
System test
Integration test
Unit test
Regression
Coding
Black Box
Results Input
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
61
- Value taken: lower/upper boundary ± 1
- Used in module testing
• Error guess
- Based on experience and intuitiveness
- Ex: error divide by 0 => if there are some divisions in the module,
this test must be taken
- Disadvantage: don't detect all the errors
• And others
3. White Box test
Is a method based on structure control of the procedures to design test
case
• SE must ensures :
- Test all the independent basic paths inside the module at least one
- Test all the branches true/false of the if or case
- Test the execution of the loop in the lower/upper bound and the
inside
- Test all the data structures to verify the validation
• Techniques:
- Basis path testing
- Structure control
Basic path testing
• By Tom McCabe invented to enables the testers take some measures
about the logic complexity of the procedures and these measures are used
to define some basic paths in the program so that each statement must
have be verified at least one time
• Use the notation " graph programming":
- Each node represents one statement or a series of statement
- An edge represents a flux control (execution control).
Results
Input
? ?
? ?
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
62
Remarks
- An edge always terminates at a node (true node or predicate node) .
- Region is an area formed by the edges and nodes .
- Eg: the graph programming in the slide above has 4 regions (red number).
- With the complex condition (more than one comparison), so each
comparison is represented by a node.
- Ex: If a OR b then X else Y Endif SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
63
Cyclomatic Complexity-CC
• CC is a SE measure giving a quantitative measure about the logic
complexity of the program.
• In the basic path testing, this value gives a number of basic paths in the
program and it is considered as an upper bound of the number of tests
must be taken and ensures that all the statements are verified at least one
time.
• Basic path? One part of the program includes at least 1 set of statements
or a new condition.
• Graph of the slide above has 4 basic paths: 1-11; 1-2-3-4-5-10-1-11; 1-2-
3-6-8-9-10-1-11; 1-2-3-6-7-9-10-1-11
There are 3 methods to calculate the cyclomatic complexity, noted V(G):
1) V(G) = E - N +2, with E: number of edges, N: the number of
vertex (node) of G
2) V(G) = number of regions
3) V(G) = P +1, with P: number of Predicate nodes
Ex:
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
64
Solution
1- the number of basic paths = 6
1-2-10-11-13; 1-2-10-12-13
1-2-3-10-11-13; 1-2-3-4-5-8-9-2 ...
1-2-3-4-5-6-8-9-2...; 1-2-3-4-5-6-7-8-9-2...
...
2- The graph program?
3- The number of tests have to execute: 6
Week Twelve
Software Testing-2
1. Unit Testing
2. Integration Testing
3. System testing
4. Validation testing
Test purpose
Software development phase:
Classifying integration testing
- Requirements: "interfaces between units work correctly"
- Software characteristics: access to software at module level, not to units
themselves
- Purpose: integration testing, interface/cooperation errors
- Assumption: units have already been tested
Integration of software to be tested
• composition of units
• units have been already tested
• interfaces must be tested
- no concern yet for system-level behavior!
- procedure calls: construct call-graph
• to actually test, any included unit needs some representation of
- all its children in call-graph
- at least one parent in call-graph SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
65
1. What is an integration test?
input values + driver/stub/unit set-up
• in the composed program graph: unit-paths with call/return markers
m1 <Main calls C> c1 <C calls F> f1 <F
Integration Testing
- Bottom-up Test
- Top - down Test
- Big - bang Test
- Sandwich Test
Integration approaches: bottom-up
• start with the lowest-level unit: E
• replace unit calling E with a driver:
- dummy software
- makes calls as original unit would
- harder to program
• many drivers required
- Are usually fewer than #stubs for top-down
• many test sessions required
- 1 session per unit
Main
G F
A C
E
D
B
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
66
• easy to isolate errors
Integration approaches: top-down
• start with top unit: Main
• replace each unit called by Main with a stub:
- dummy software
- reacts as original unit would
- easy to program
• 1st session: test interfaces for Main
• second session: unit A
• ...
• many stubs required
• many test sessions required
- 1 session per unit
• easy to isolate errors
Integration approaches: big-bang
• put all units together as they are: 1 session
• rely on unit test results
• (relatively) few tests required
• very hard to isolate errors
Integration approaches: sandwich
• mixture of top-down and bottom-up
• some stubs, some drivers required
• test interfaces between portions already tested
• moderate #test sessions required
• harder to isolate errors
2. System testing
• Recovery testing
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
67
• Security testing
• Performance testing
3. Validation Testing/acceptance Test
• Objective: deliver SW to customer
• Object: Need present and participle of users
• Process: Based on SWR
Week Thirteen
Software Maintenance
1 What's maintenance?
• Definition: the work to modify and change the existed SE following the
different reasons d' être
• Type of maintenance
- Correction
- Adaptive
- Improving
- Prevention
Correction maintenance
• Maintenance for recovering faults in SW
• Main reasons:
- SW engineers misunderstand client and vice versa
- Implicit bugs due to carelessness in programming or
inadequate in testing
- SW's functions are not satisfied in memory, file,..., wrong
design, wrong compile. . .
- Lack of standardization in developing SW (in previous time).
• Technique: reverse engineering
Adaptive maintenance
• Adjust SW due to changes in external environment to maintain and
manage SW in its life cycle
• Change SW to adaptable to environment: HW engineering, SW
environment.
• Main causes:
- Changes in HW (peripherals, server,. . .)
- Changes in SW (environment): change OS
- Changes in file structure or expand database
Improving maintenance
• Adapt SW system due to requirements that are more perfect, more
adequate and more reasonable.
• Main reasons:
- Increase performance or improve method of accessing file
- Add new functions to system
- Improve management leads to improve in operation document and
task's order SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
68
- Change user/operation
• Also called re-engineering
• Target: provide a design with same function but better quality
• Steps:
- Build SW diagram
- Deduce Bool expression for each processing sequence
- Compile truth table B iên d?ch b?ng chân lí
- Re-structure SW
Prevention maintenance
• To adapt program with counting on how the program will be
expanded/changed
• It is counted on in SW development
? if the SW is well designed, prevention maintenance is hardly needed
• Target: change to adapt to changes in user requirement
• Implicit changes on design
• Understand internal activities in the program
• Redesign/reprogramming
• Use CASE tool
2 Maintenance process
• A process in SE life cycle follows steps of analysis, design,
implementation, testing since the problem occurs until resolved
problem.
• Operation: 2 types
- Correct the existence (type 1)
- Add new items (type 2)
Diagram
Understand existedSE
Type
Modify existed SE
Testing
Testing after Maintenance
Make a schedule
Develop a new SE
2
1 SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
69
Understand existed SE
• Study functions through documents
• Study the detail specification about the testing conditions,. . . through
documents
• Read source programs, understand the treatment process of this system
=> Manual processes
Correct the existence
• Maintain the source programs and make new module, then compile
• Execute unit testing and related items in the specification document.
• Consider the influence on other components in system.
Develop a new
• When add a new component, consider the concordance with the
requirement
• Must follow the development process: design, implementation, testing,...
• Add to the interface and the document, . .
Consistence testing by integrated testing
• Take the tested unit into unit the system
• Adapt compatibility among modules
• Test by used data in previous testing for consistency
• Care about wave-effect in adapting
Testing after maintenance
• Verify the content in the document
• Does writing document fit the specification for new environment?
3 Some suggestions to maintain
• Initiative in SW development process
(1) Standardize every step in SW development
(2) Key maintainer join in analysis and design phases
(3) Design for easy maintenance
• Initiative in SW maintenance process
(1) Use tools supporting SW development
(2) Standardize maintenance operations and environment
(3) Store historic information of maintenance
(4) A key member of the project will take the responsibility of
maintenance when development phase finishes
• Develop new techniques for maintenance
- Tools
- Database
- Manage document, data, source program, testing data,...
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
70
Week Fourteen
IT Project Management-1
Project management
=> Organising, planning and scheduling software projects
What's an IT project?
• The product is intangible
• The product is uniquely flexible
• Software engineering is not recognized as an engineering discipline with
the same status as mechanics, electrical engineering, etc.
• The software development process is not
standardised
• Many software projects are 'one-off' projects
Why need?
• Concern with activities involved in ensuring that software is delivered on
time and on schedule and in accordance with the requirements of the
organisations developing and procuring the software
• Project management is needed because software development is always
subject to budget and schedule constraints that are set by the organisation
developing the software
Why project must be unsuccessful?
What makes success of a project?
Management activities
• Proposal writing
• Project planning and scheduling
• Project costing
• Project monitoring and reviews
• Personnel selection and evaluation
• Report writing and presentations
Main domains of project management
1) People
• Players: senior, manager, customer,...
• Team leaders
• Software team
• Coordination and Communication issues
=> Problem of Project staffing
- May not be possible to appoint the ideal people to work on a
project (budget, not available, desire of organisation,...)
- Managers have to work within these constraints especially when
(as is currently the case) there is an international shortage of
skilled IT staff
2) Product
SW Scope
• Context
• Information objectives SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
71
• Function and Performance
3) Process
• Linear sequential Model
• Prototyping Model
• RAD Model
• Incremental Model
• Spiral Model
• Win-Win Spiral Model
• Component based Model
• Concurrent Development Model
• Formal method Model
• 4th generation Techniques Model
4) Project
A project is unsuccessful when: The aims of project are fallen and/or
exceed at least 30% budget
Causes of unsuccessful Projects
• Staffs don't understand the customer's requirement
• The scope is unclear
• Weak Change management
• Selected technology is changed
• Business requirements are changed
• Sponsors are changed
• Missing the technician,...
To avoid unsuccessful
Miss info: 21%
Unfamiliar scope and
complex: 17%
Unclear aims: 18%
18%
Bad management: 32%
others: 12%
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
72
Success factors of a Project
• Begin by right treat with the rights
• Frequently consider the project
• Monitor and make notes about process
• Make true, intelligent decisions
• Analysis, summarize lessons when finishing project
10 gold principles
• Successful project management depends on human factor and also
administration task
• Find supporting/preventing sources
• Presentation may tell lie - review hidden schedule
• Different people have different points of view
? be in their position
• Planning must be able to change easily
• Face each event as if it were there
• Use administration to support project's targets
• Aim duration for each task is not the same as in planning
• Reread project's scope and targets once a week
• Don't surprised!
Principle 5W2H (Boehm)
• Why is system developed?
• What is obtained when project will be finished?
• When is it finished?
• Who is charged for a function?
• Where is it implemented in the organization?
• How technical has the work been accomplished?
• How much does the resource spend?
Project planning
• Probably the most time-consuming project management activity
• Continuous activity from initial concept through to system delivery. Plans
must be regularly revised as new information becomes available
• Various types of plan may be developed to support the main software
project plan that is concerned with schedule and budget
Types of project
Plan Description
Quality plan Describes the quality procedures and
standards that will be used in a project.
Validation plan Describes the approach, resources and
schedule used for system validation.
Configuration
management plan
Describes the configuration management
procedures and structures to be used.
Maintenance plan Predicts the maintenance requirements of
the system, maintenance costs and effort
required.
Staff development plan. Describes how the skills and experience of
the project team members will be
developed.
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
73
Project planning process
The project scheduling process
Scheduling problems
• Estimating the difficulty of problems and hence the cost of developing a
solution is hard
• Productivity does not proportionate to the number of people working on a
task
• Adding people to a late project makes it later because of communication
overheads
• The unexpected matters always happen. Always allow contingency in
planning
Bar charts and activity networks
• Graphical notations used to illustrate the project schedule
• Show project breakdown into tasks. Tasks should not be too small. They
should take about one week or two
• Activity charts show task dependencies and the the critical path
• Bar charts show schedule against calendar time
Estima te resource s
for activities
Identify activity
dependencies
Identify
activities
Allocate people
to activities
Create project
charts
Softwa re
requirements
Activity charts
and bar charts
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
74
Task durations and dependencies
Activity network
start
T2
M3
T6
Finish
T10
M7
T5
T7
M2
T4
M5
T8
4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days
5/9/99
10 days
19/9/99
15 days
11/8/99
25 days
10 days
20 days
5 days
25/7/99
15 days
25/7/99
18/7/99
10 days
T1
M1 T3
T9
M6
T11
M8
T12
M4
Task Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
75
Activity timeline
Staff allocation
Practice skill
• Risk management
• Cost estimation and schedule
• Project management based on metrics
• Take care the incremental values
• Take care the effect influencing the quality
• Manage the program oriented people
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Start
FinishSE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
76
Week fifteen
IT project management-2
1. Risk management
1.1. What is the risk?
• Risk management is concerned with identifying risks and drawing up
plans to minimise their effect on a project.
• A risk is a probability that some adverse circumstances will occur.
- Project risks affect schedule or resources
- Product risks affect the quality or performance of the software being
developed
- Business risks affect the
organisation developing or procuring
the software
? Risk is manageable
Reasons
• All projects depend on risks.
• The process does not follow the plan in some steps of project
• Risk could not totally eliminate
The risk management process
• Risk identification
- Identify project, product and business risks
• Risk analysis
- Assess the likelihood and consequences of these risks
• Risk planning
- Draw up plans to avoid or minimise the effects of the risk
• Risk monitoring
- Monitor the risks throughout the project
Risk identification
• Technology risks
• People risks
• Organisational risks
• Requirements risks
• Estimation risks
Risk avoidance
and contingency
plans
Risk planning
Prioritised risk
list
Risk analysis
List of potential
risks
Risk
identification
Risk
assessment
Risk
monitor ingSE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
77
Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many
transactions per second as expected.
Software components which should be reused contain defects
which limit their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management
are responsible for the project.
Organisational financial problems force reductions in the
project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework
are proposed.
Customers fail to understand the impact of requirements
changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
Risk analysis
• Assess probability and seriousness of each risk
• Probability may be very low, low, moderate, high or very high
• Risk effects might be catastrophic, serious, tolerable or insignificant
Risk planning
• Consider each risk and develop a strategy to manage that risk
• Avoidance strategies
- The probability that the risk will arise is reduced
• Minimisation strategies
- The impact of the risk on the project or product will be reduced
• Contingency plans
- If the risk arises, contingency plans are plans to deal with that risk
Risk monitoring
• Regularly assess each identified risks to decide whether or not it is
becoming less or more probable
• Also assess whether the effects of the risk have changed
• Each key risk should be discussed at management progress meetings
2. Quality Management
Definition
1-Accordance with the objective
2- Waste diminution by correct execution at the 1st time
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
78
Balance of quality
Quality management process
3. Changeable Management
Why?
Two well-known reasons for unsuccessful projects:
• Don't see the changes and troubles
• Don't manage effectively these problems
Solution for changeable management
Definition:
All the activities that change:
• Scope
• Delivery result
• Basic architecture
• Cost
• Schedule
of a project
Inspection and solution
Factors of success:
• Risk diminution by the effectively process for change management and
problems SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
79
• All the members of the project well understand this problem
• Write carefully the changes and problems
Cost for changeable
3. Configuration management
Most think...
• There are problems of LANs, WANs, hardware,...
• There are activities purely technique
• Very few related to Project management
...execute two main functions
• Give a safe and simple access to the copy of all the delivery result.
• Inspect all the status of delivery result and the relations between these
results.
Technique and process
• Give a safe store to the delivered result.
• Allow to inspect and reveal in a principle way the delivered results in SE
life cycle. Ensure the right version and updated,...
• Inspect changes of the delivered results and ensure that these results are in
the right order.
• Always give reports on the status of change
SE- StudentNotes
Software Engineering - Vietnamo-Japanese programme- HUT 2008
80
Version inspection
Functions for configuration management
0.1 0.2 0.n
1.1 1.2 1.n
1.0
2.0
Approved
Bạn đang đọc truyện trên: AzTruyen.Top