Ilovepdf Merged

9/6/21
SOICT
School of Information and Communication Technology
1
9/6/21
IT3180 – Introduction to
Software Engineering
1 – Introduction to Software Engineering
FYI
• Teacher: Dr. Bui Thi Mai Anh
• Research domains:
• Software Engineering
• Applied AI in Software Engineering:
Software Defect Prediction,
Fault/Bug Localization
• Search-based Software Engineering:
evolutionary computing,
reinforcement learning, deep
learning
• Lab: Intelligent Software Engineering –
BK AI Center
2
9/6/21
What is Software Engineering?
• Systematic approach for developing software
• Methods and techniques to develop and maintain quality software to

solve problems
• Study of the principles and methodologies for developing and

maintaining software systems
Questions addressed by Software Engineering?
• How do we ensure the quality of the software that we produce?
• How do we meet growing demand and still maintain budget

control?
• How do we avoid disastrous time delays?
3
9/6/21
Why apply Software Engineering to Systems?
• Provide an understandable process for system development
• Develop systems and software that are maintainable and easily

changed
• Develop robust software system
• Allow the process of creating computing based systems to be

repeatable and manageable
Historical Perspective
• 1940s: computers invented
• 1950s: assembly language, Fortran
• 1960s: COBOL, ALGOL, PL/1, Operating System

1969: First Conference on Software Engineering
• 1970s: multi-user systems, databases, structured programming
4
9/6/21
Historical Perspective (cont.)
• 1980s: networking, personal computing, embedded systems, parallel

architectures
• 1990s: information superhighway, distributed systems, OO in

widespread use
• 2000s: virtual reality, voice recognition, video conferencing, global

computing, pervasive computing,...
• 2010s: autonomos vehicles, new security awareness
• 2020s: AI everywhere
9
Hardware costs vs Software costs (% of overall cost)
10
10
5
9/6/21
Why is software so expensive?
Hardware has made great advances
But software too...
11
11
We need softwares because they help us save money...
Imagine: a software system could save a company $10,000/year
So, why couldn’t it charge $9,000?
• Most popular software suites out are software solutions that

companies cannot go without
• Productivity software, marketing, logistics, finance ...
12
12
6
9/6/21
Software is Expensive to Produce
• Labor costs to host hundreds of talented people

• Utilities have to be paid
• Software for software development costs money
• Extensive Q&A process
• Engage in makerting after release
• ... and the most important thing:
Software has to be supported 24/7
Software needs to be updated
13
13
Variety of Software Products
• 2 big categories: Application Software vs System Software

• Web sites
• Operating systems, compilers
• Routers, telephone switchers : communication software
• Telephone billings, Financial Market Predictions: data processing
• Air trafic control, autonomous vehicles: Real time apps
• Device drivers, controllers: Embedded Software
• Digital camera, GPS, sensors: mobile devices
• Information systems: database management, digital libraries
• Offices: word processing, spreadsheet, video conferences
• Scientific: simulations, weather forecasting...
14
14
7
9/6/21
The craft of software development
• Client requirements are very different
• There is no standard process for software engineering
• There is no best language, operating system, platform, database

system, development environment...
• The craft of software development is

to select appropriate methods for each project
and to apply them effectively
15
15
1. Introduction to Software Engineering

(end of lecture)
16
16
8
9/6/21
SOICT
1
9/6/21
3 – Software Development in Practice
Clients - Customers - Users
• Client: a person (or a group of people) for whom the software

development team creates the software
• The client provides resources such as money and expect some product in
return
• The client’s job success may depend on the success of the software
project
Client satisfaction is a primary measure of success

in a software project
4
2
9/6/21
Clients - Customers - Users
• Customer is the person who buys the software or selects it for use by
an organization
• User is a person who actually uses the software

• With personal software, the user and the customer may be the same
• In organizations, the customers and the users are usually different
• Example: Many people in our university use Microsoft Team

Who is the customer? Who are the users?
Risk
• Many (probably most) software development projects run into

difficulties
• Problems
• Does not work as expected (FUNCTION)
• Over budget (COST)
• Late delivery (TIME)
• Competing goals
• Every software project has a trade-off between function/cost/time
• Extra functions add extra costs for development, testing, maintainance etc.
3
9/6/21
What is important to the person who is paying?
Risk (cont.)
• Much of software is wasted (perhaps 50% is never used)

• Many software projects fail because the software developers build the
wrong software
The software development team must:

• Understand what the client expects of the software
• Understand what the client’s organization expects of the client
• Understand what the customers and the users expect of the software
The software development team will often add technical insights and
suggestions, but...
8
4
9/6/21
Client satisaction is a primary measurement of success in a

software project
Minimizing Risk: Communication with Client
• Feasibility studies (should we begin the project?)
• Separation of requirements (what the client wants) from design (how

the developers meet the requirements)
• Milestones (how the developers report or demonstrate progress to

the clients) and releases
• Acceptance (how the client tests that the software meets the
requirements) and user testing
• Handover (ensuring that the client receives a package that can be
operated and supported over a long time period)
10
10
5
9/6/21
Minimizing Risk: Visibility
• Visibility : The people who take the responsibility must know what is
happening
• The problem (as seen by a manager) must rely on others for reports
of progress or difficulties
However, software developers:

• Have difficulty evaluating progress
• Are usually optimistic about progress
• Consider reporting a waste time
• etc.
11
11
You will make regular progress reports on your projects
12
12
6
9/6/21
Minimizing Risk: Short Development Cycle
Risk is minimized by frequent delivery of working software (weeks rather

than months)
• Client, customers, and users can evaluate the developers’ work
• Opportunities to adapt to changing circumstances
This is one of the basic principles of agile software development
13
13
Software Project Scale
• Large and very large systems have different needs

• A big project may be of 100 to 10000+ person per years
• Every large system is developed by many people, who are constantly

changing
• Before a big project is completed the requirements have changed
many times
• No large system is ever complete
• Nobody comprehends more than a fraction of the project
14
14
7
9/6/21
Teams
Most software development is by teams

• Effectiveness of team determines success
Most large projects are built on older ones
• Building on the work of others is a fundamental skill of software
development
• Much software is built in increments, with different teams responsible
for the increments
15
15
Managing Large Projects
Large software projects need skilled management

• Project management
• Personel management
• Resources management
• ...
We need a development process to effectively manage

the software project
16
16
8
9/6/21
Software Development Processes
Fundamental assumptions:
• Good processes lead to good software
• Good processes reduce risk
• Good processes enhance visibility
• Good processes enable teamwork
17
17
Variety of Software Processes
Software products are very varied...
... Therefore, there is no standard process for all software development

projects
BUT successful software development projects all need to address

similar issues
• This creates a number of process steps that should be part of all
software projects
18
18
9
9/6/21
Process Steps in all Software Development
Feasibility Study
Requirements
User Interface Design
These steps may be
repeated many times
System Design
during the development
Program Development (detail design
cycle
and coding)
Acceptance and release
Operation and Maintenance
It is essential to distinguish among these steps and to be clear

which you are doing at any given moment
19
19
Feasibility
A feasibility study precedes the decision to begin a project

• What is the scope of the proposed project?
• Is the project technically feasible?
• What are the project benefits?
• What are the costs, timetable?
• Are the resources available?
• What are the risks and how can they be managed?
A feasibility study leads to a decision: go or no-go

Lecture 6 is about Feasibility Study
20
20
10
9/6/21
Requirements
• Requirements define the function of the system from the client’s

viewpoint
• The requirements establish the system’s functionality, constraints, and

goals by consultation with the client, customers and users
• The requirements may be developed in a self-contained study or may

emerge incrementally
• Failure to agree on the requirements and define them adequately is

one of the biggest cause of software projects failing
21
21
Requirements
This step is sometimes divided into:

• Requirements analysis
• Requirements definition
• Requirements specification
Lectures 8-9-10 are about Requirements
22
22
11
9/6/21
User Interface Design
• Usability is of great importance in many modern applications and

software systems. That requires good user interface design
• User interfaces need to be evaluated with users
• This requires iterative development:

• Design the user interface
• Test with users
• Revise the user interface
• Repeat
Lectures 11-12-13 are about User Experience
23
23
System Design
Design describes the system from the software developers’ viewpoint

System Design:
• Establish a system architecture, both hardware and software that
matches the requirements
• Security and performance are parts of the system design
Models:
• Models are often used to represent the requirements, system design
and program design
• This course teaches the basic concepts of the Unified Modeling
Language (UML)
Lecture 14-15-16-17 focuses on System Design
24
24
12
9/6/21
Program Development
Program development:
• Takes the system design and user interface design and builds
programs that meet the requirements
Program development is sometimes divided into two parts:

• Program design (often refered as Detail/Module design)
• Implementation (coding)
Often these two parts overlap or are combined
Lectures 18-19-20 are about Program Development
25
25
Acceptance and Release
Acceptance testing
• The system is tested against the requirements by the client, often with
selected customers and users
Delivery and release
• After successful acceptance testing, the system is delivered to the
client and released into production or marketed to customers
26
26
13
9/6/21
Operation and Maintenance
Operation
• The system is put into practical use
Maintenance
• Errors and problems are identified and fixed
Evolution
• The system evolves overtime as requirements change, to add new
functions or adapt to a changing technical environment
Phase out
• The system is withdrawn from service
This is sometimes called the Software Life Cycle
27
27
Quality Control in all Software Development
• Validating the requirements

• Validating the system and program design These steps may be
• Usability testing repeated many times
• Program testing during the development
• Acceptance testing cycle
• Bug fixing and maintenance
Lectures 21-22-23 are about Software Testing
28
28
14
9/6/21
Categories of Testing
The term testing is used in several different contexts which are easily
confused:
User Testing
• Versions of the user interface are tested by users
• Their experience may lead to changes in the requirements or the
design
Program Testing
• The development team tests components individually (unit testing) or
in combination (system testing) against the design to find bugs
Acceptance Testing
• The client tests the final version of the system or parts of the system
against the requirements
29
29
3. Software development in Practice

(end of lecture)
30
30
15
9/8/21
SOICT
1
9/8/21
4 – Introduction to Software Projects 20211
Major Objectives
• This course is about Software Engineering with focusing on how to

develop a software project by applying principles of SE
• Major component: software development project – The objective is

to develop a product for a client who intends to use it in regular
production
• During this course, the project team will work together through a full
development cycle
2
9/8/21
Project Teams
• You will work by team to develop your software project
• A project team is formed by a group of 6 to 8 students
• Evaluation over the team work as well as on individual contribution
Note: After week 1, as soon as possible, you have to form your group
and choose project
Choosing Project
• The project can be an application, system software, or even a toolkit, a

plugin or a library
• Software Engineering covers everything from smartphones to
supercomputers
• The only conditions are that there must be a real client who has to
participate to our course to evaluate assigments’ reports and
project progress
• The idea of your project comes from client, not your own
• In this semester, your teacher plays the role of your project client
• A list of suggested projects are available for 15 groups of 120 students
3
9/8/21
Milestones
The project is divided into 4 parts, each of which ends in a

milestone
• The first milestone is a feasibility report
• The second and third milestones, the team makes a presentation

and submits a progress report to the client
• At the fourth milestone, the team demonstrates the working

software and makes a presentation to the client, followed by a final
report and handover of the completed project
7
Overview about Software Development Project
Software development is more than writing code

Every project includes all aspects of software development:
• feasibility study
• requirements
• system and program design
• coding
• reliability and testing
• delivery
• documentation for future maintenance
• etc.
8
4
9/8/21
Sprint
• The project is small, about the size of an agile sprint in most

production
Sprint
• In agile terminology, a sprint is a fixed period of time during which a
team completes part of a software project
• Every sprint ends with code that is ready to put into production
• A typical sprint might have a team of 4 to 9 people working for 2 to 4
weeks
• It should be fully tested, with documentation for maintenance
Time box
Time box
• A time box is a set of period of time during which a development team
completets part of a software project
Our course:
• Time: one semester of 16 weeks (including the pausing mid-semester
week)
• Resources: The team size is fixed (6-8 students)
• Scope: The scope of the project should be determined during feasibility
study period to match with the time and resources
10
10
5
9/8/21
Team Organization
• An effective team organization makes the success of the project

• Every project should have:
• Regular meetings with the client (at least during assigment work
weeks)
• Regular team meetings
• A project plan which is kept up to date (e.g., Gantt chart)
• A project management system for code and documentation (e.g.,
Github)
11
11
Within the time box
You NEED a systematic process for developing your software project
Most projects use one of the following processes:

• Iterative refinement
• Modified waterfall model
Some projects may use

• An agile process with a sequence of short sprints
12
12
6
9/8/21
List of available projects for Semester 20211
• Refers to projects20211.pdf for more details

• After forming team, each group should choose the appropriate project
13
13
4. Introduction to Software Projects 20211

(end of lecture)
14
14
7
10/4/21
SOICT
1
10/4/21
IT3180 – Introduction to Software

Engineering
5 – Software Development Processes
Sequence of Processes
Lecture 3 introduced several process steps:

• Requirements
• User Interface Design
• System Design
• Program development (design and coding)
• Acceptance and release
Every software project will include these basic steps, in some shape or
form, but:
• The steps may be formal or informal
• The steps may be carried out in various sequences
4
2
10/4/21
A software development process or methodology is a systematic way of

combining these steps to build a software system
Software Development Process

In this lecture, we look at four categories of software development
processes:
• Waterfall
• Complete each process step before beginning the next
• Iterative refinement
• Go quickly through all the steps to create a rough system, then repeat them to
improve the system
• Spiral
• A variant of iterative refinement in which new and updated components are
added to the developing system as they are completed
• Agile development:
• Small increments of software are developed in a sequence of sprints, each of
which creates deployable code
6
3
10/4/21
Heavyweight and Lightweight Software Development
• Heavyweight Process
• Fully complete each step and have minimal changes and revisions later
• Each step is fully documented before beginning the next
• Example: waterfall or modified waterfall
Heavyweight and Lightweight Software Development
• Lightweight Process
• Expectation that changes will be made based on experience
• Minimal intermediate documentation
• Only the final system will be documented
• Example: Agile Software Development
4
10/4/21
Heavyweight vs. Lightweight Methodologies
Heavyweight Lightweight
Slower process Speedy process
Release at the final stage Released as increments
Client negotiation Client collaboration
Following a plan Responding to change
History
Software engineering became a discipline, dated from the early 1970s

At that time:
• Most computer systems were conversions of systems that had
previously been done manually (billing, airline reservation etc.)
• The requirements were well understood
• Many system followed the same architecture, Master File Update
• The system design was well understood
• Coding was tedious with none of the modern languages and tools
• It was important to have a good program design before coding
The factors led to the Waterfall Model of software development

10
10
5
10/4/21
The Waterfall Model
11
11
Discussion of the Waterfall Model
The waterfall model is a heavyweight process with full documentation

of each process step
Avantages:
• Separation of tasks
• Process visibility
• Quality Control at each step
• Cost monitoring at each step
Disadvantages:
• In practice, each stage in the process reveals new understanding of the
previous stages, which often requires the earlier stages to be revised
12
12
6
10/4/21
The Waterfall model is not flexible enough!
13
13

• A pure sequential model is not possible
• The plan must allow for some form of iteration
Examples:
• Does the Feasibility Study can create a proposed budget and

schedule?
• Detailed design and implementation reveal gaps in the requirements

specification
• What if the client changes requirements or what if the development

team decides to change the technology?
14
14
7
10/4/21
Modified Waterfall Model
15
15
When to use the Modified Waterfall model
The Modified Waterfall Model works best when the requirements are
well understood and the design is straightforward
For example:
• Converting a manual data processing systems where the requirements
were well understood
• New version of a system where the functionality is closely derived

from an earlier product
• Portions of a large system where some components have clearly

defined requirements and are clearly separated from the rest of the
system
16
16
8
10/4/21
Discussion
Consider the following case study:

• A web-based banking application has been developed for two groups
of users: personal user and enterprise user of the bank X. Now, the
bank desired to develop a mobile application for personal user. They
apply the modified waterfall model.
• Give at least 3 reasons why the modified waterfall model is appropriate
in this case study.
17
17
Iterative Refinement
Concept:
• Requirements are hard to understand until there is an operational
system, particularly with user interfaces.
• System and program design may benefit from prototypes
Process:
• Create a prototype system early in the development process
• Review the prototype with clients and test it with users, to
• improve the understanding of the requirements
• clarify the design
• Refine the prototype in a series of iterations.
18
18
9
10/4/21
Iterative refinement: an example (1)
Problem: Add graphics package to a programming environment

Requirements:
• The client was unsure of several important requirements
• E.g., syntax for how to manage coordinates across different objects
Process
• Build a prototype version with a preprocessor and preliminary run-time
package
• Have several iterations of development
• The final iteration is the complete version of package
19
19
Iterative refinement: an example (2)
Problem: Add graphics package to a programming environment

Requirements:
• The client was unsure of several important requirements
• E.g., syntax for how to manage coordinates across different objects
Process
• For each iteration:
• Test the system with users
• Make modifications
• Repeat until users are pleased with function
20
20
10
10/4/21
Iterative Refinement - Schema
21
21
Discussion of Iterative Refinement
This is a medium weight process with documentation created during the

process
Iterative refinement uses various techniques that enable the client to

review the planned system early during development:
• User interface mock-ups
• Throw-away software components
• Rapid prototyping
• Successive refinement
22
22
11
10/4/21
User interface mock-up
23
23
Throw-away
Prototyping
24
24
12
10/4/21
Evolutionary
Prototyping
25
25
Get something working as quickly as possible, for client and user evaluation
...but do not release it
26
26
13
10/4/21
Incremental Development
27
27
Incremental Development - Example
Ecommerce website
• Search, Product Information, Shopping Basket, Checkout, Favourites,
Customer Review
1 increment = 1 release
28
28
14
10/4/21
3 incrementals:
• 1st:
1st release
29
29
3 incrementals:
• 2nd:
2nd release
30
30
15
10/4/21
3 incrementals:
• 3rd:
3rd release
31
31
Incremental Development - Discussion
Is incremental model also an iterative one?
32
32
16
10/4/21
Incremental
vs. Iterative
Can you see the difference?
33
Spiral Development
• Iterative and incremental model with more emphasis placed on risk

analysis
• 4 main phases: Planning – Design – Construct – Evaluation
• An iteration = A spiral
34
34
17
10/4/21
Spiral Development - Schema
• 1st quadrant: Requirements are

gathered and analyzed at the start
of every spiral
• 2nd quadrant: All proposed

solutions for identified problems
are evaluated. Risks are identified
for the selected solution, then are
resolved using the best possible
strategy.
Prototype is built for the best possible
solution
35
35
Spiral Development - Schema
• 3rd quadrant: identified features

are developed and verified through
testing
Next version of the system is available
• 4th quadrant: customers evaluate

the so far developed version
Planning for the next phase then is
started
36
36
18
10/4/21
Spiral Development – Risk Handling
Risk: any situation that might affect the successful completion of the
project
• Spiral model emphasizes risk handling by developing a prototype
• After some iterations, most of risks are studied and resolved
• For example: What is the risk involved in accessing data from a remote
database system?
• What if the data access might be too slow?
• Risk solution: Building a prototype of the data access subsystem
37
37
Spiral model viewed as a Meta-model
The spiral model subsumes all the other models

• Single loop represents the waterfall model
• Prototyping approach is used to first draft the solution before

embarking on the actual product
• Iterations along the spiral model can be considered as the evolutionary

levels through which the complete system is built
• At the end of each spiral, the result will typically be incorporated with
the large base system
38
38
19
10/4/21
Agile Methodology
Spring 2000, in Oregon, US, big question:
How could speed up development times in order to bring new software to

market faster?
Critical milestone in the history of Agile with 3 key ideas:

• Speed to market
• Rapid feedback
• Continuous improvement
39
39
Agile Methodology - History
• Oregon 2001, Manifesto for Agile Software Development:
12 principals
40
40
20
10/4/21
Agile Approach: Iterative and Incremental
41
41
Agile Approach: Iterative and Incremental
• A large project is divided into

small increments called sprints
• The development is carried out by
small teams of 4 to 9 people
• The schedule is divided into fixed
time boxes, perhaps 2 to 4 weeks
• Each sprint is a time box during
• Single sprint: requirements, which the team completes part of
design, coding and testing a software project
• Each sprint ends with fully tested
code, ready to put into
production 42
42
21
10/4/21
Agile Development - Sprint
After each sprint the code may be:

• Released (original agile method)
• Combined with code from other sprints for subsequent release
• Incorporated into a larger code base (spiral development)
43
43
Scrum – The most widely used agile method for software development
44
44
22
10/4/21
Scrum roles
Scrum Master
• Understand the theory, practices, rules and values of Scrum
• Help others improve interactions to maximize the value by the Scrum
team
Product Owner
• The bridge between the business part and the technical part of the
project
• Responsible for writing user stories and for keeping the Product
backlog up to date
Development Team
• Transform the expressed needs into usable functionalities
• Developers, software architects, functional analyist, graphic designers
45
45
Product Backlog
46
46
23
10/4/21
Product Backlog
• Contains all the userstories which

will be turned into tasks so that the
scrum team can select and plan in
upcoming sprints
• PO is in charge of managing and

keeping the product backlog up to
date
47
47
Sprint Backlog
48
48
24
10/4/21
Epics – Userstories – Tasks
Epic
• A functionality of the product to be developed
• A multiple sets of userstories grouped by categories or themes
User Story
• Not a task, neither a specification
• A statement of a user expectation
Task
• Technical activities that helps respond to user stories
• Tasks should be same sized but may be of different nature: design,
development, test, etc.
49
49
Epics – Userstories – Tasks
50
50
25
10/4/21
Scrum Meetings
51
51
Sprint Planning – Sprint Retrospective – Daily Scrum
Sprint Planning Meeting

• Goal: The development team selects the priority elements of the
Product Backlog to complete in the current sprint
Daily Stand-up Meeting

• Daily synchronizing meeting
• Goal: to enable team members to gather on a daily basis
• to discuss tasks and work progress as well as potential problems
• to overcome possible blockages
• to promote mutual support
52
52
26
10/4/21
Sprint Planning – Sprint Retrospective – Daily Scrum
Sprint Retrospective Meeting

• Toward continuous improvement
• Take place at the end of the sprint
• Goal: discussing and taking a step back from the latest sprint
• to optimize interactions between individuals,
• to raise product quality
• to improve productivity
• Tools:
• Burnup chart
• Burndown chart
• Velocity
53
53
Scrum Development - Example
54
54
27
10/4/21
Mixed Processes
In practice, many large projects use processes that mix aspects of the
four types of software process
Example:
• A project with well-understood requirements might use a modified
waterfall approach to specify the requirements and system design,
followed by a series of agile sprints
• A project with vague requirements might use iterative refinement to
clarify the requirements, followed by a modified waterfall model to
build the final version
• With spiral development, new components may be developed as a
series of sprints
55
55
The most important:
User Interface should be tested with users...
è Iterative development, whatever process is used for the rest of

the system
56
56
28
10/4/21
IT3180 Project: Iterative Refinement
57
57
IT3180 Project: Modified Waterfall Model
58
58
29
10/4/21
IT3180 Project: Agile Development
59
59
5. Software development processes

(end of lecture)
60
60
30
10/4/21
SOICT
1
10/4/21

Engineering
6 – Feasibility Study
Overview
Lecture 5 introduced several processes:

• Waterfall Model and Modified Waterfall Model
• Iterative Refinement – Prototype Model and its variants
• Spiral Development
• Agile Development
Before applying a process to develop a software system, the project shoud

be studied – Feasibility Study
2
10/4/21
Feasibility Study
A feasibility study is a study made before committing to a project
A feasibility study leads to a decision:

• Go ahead
• Do not go ahead
• Think again
In introduction projects, the feasibility study often leads to a budget

request
A feasibility study may be in the form of a proposal

5
Feasibility Study - A general step
Feasibility study can be observed in our life
• A housewife inspects the quality of the product she is purchasing from a

grocery store è It’s actually a material quality feasibility test
• Due to increasing fuel rates and air pollution, young students perform technical,
resource and economic feasibility tests in order to launch an electric vehicle
3
10/4/21
Why are Feasibility Studies Difficult?
Uncertainty
• Clients may be unsure of the scope of the project
• Benefits are usually very hard to quantify
• Approach is usually unclear or vague è Estimates of resources and
timetable are very rough
• Organization changes may be needed
Feasibility Studies rely heavily on the judgement of experienced people
Mistakes made at the beginning of a project are

the most difficult to correct
4
10/4/21
Feasibility Study is about Decision Making

The feasibility study makes recommendations
• Client: Who is this project for?
• Scope: What are the boundaries of the project?
• Benefits: What are the benefits? Can they be quantified? If the
software is a product, what are the forecasts or likely sales?
• Technical: Is the project possible? Is there at least one technical way to
carry out the project?
• Resources: What are the estimates of staff, time, equipment, etc.?
• Alternatives: What are the options if the project is not done?
Where are the Risks?
Technical Risks
• There must be an outline plan with a rough timetable and staff
allocation
• The plan must have a large margin for contingencies
External Risks
• Every system interacts with others. Are the others committed to the
necessary efforts?
• Where are the external pressures and obstacles?
10
10
5
10/4/21
Example 1: A case study - Decision made before feasibility study
Outline Description
A governmental agency (X) has to manage huge numbers of documents

and other records, wishes to move from a paper based approach to a
system that can manage digital documents
11
11
Example 1: Problems (1)
Context:
• A team at University B developed a prototype system to demonstrate
technology for Agency X
• Funds were approved
• An external feasibility study was commissioned to report on the
technical approach to be followed (technical feasibility).
Problems:
• The decision to go ahead was made and the budget was approved
before the feasibility study was begun
• The feasibility study looked at only the technical aspects
12
12
6
10/4/21

Organizational:
• Agency X manager lacked the experience to lead a very large project
that will completely change the agency
• No thought was given to the workflow and job changes that would
affect almost every member of staff.
Preparation:
• No preliminary study was made of volumes or kinds of data; nor of the
complex policies for access (e.g., privacy, classified information).
Requirements:
• The requirements were complex and only partially understood.
• Major changes were inevitable even after the system went into
production with real users.
13
13
• A successful implementation needed fundamental changes at the

Agency management level
• A phased approach, using iterative refinement over many years, might
possibly work
BUT…
• The agency did not want to abandon the project (money needs to be
returned to the government)
• The agency adopted a pure waterfall model to initialize the project
This is how disasters are made
14
14
7
10/4/21
Feasibility Study: Scope
Scope expresses the boundaries of the system:

• It will have a list of included functions
• It will have a list of excluded functions
• It will have a list of dependencies
• It will have a list of current systems to be replaced
Confusion over scope is a common reason for clients to be dissatisfied with

a system
15
15
In Reality
Is that all you

planned to
do?
…
But I assumed I can’t use the
that you were system
going to do without ABC.
XYZ!
16
16
8
10/4/21
Example 2: Confusion over Scope

Context:
• A government organization L required a “repository system” to store
and make accessible very large amounts of highly varied material over
long periods of time
• An outside organization, C, built a repository system to store and
manipulate complex digital material
BUT…
• Nobody built the sub-systems needed to organize, validate, and to load
material into the repository.
• L expected the repository system to include these sub-systems. C
considered the sub-systems separate from the repository system.
A good feasibility study would have seen this confusion
17
17
Benefits of Feasibility Study
Why is this project proposed? Can you quantify the benefits?

Organization benefits
• Create a marketable product
• Improve the efficiency of an organization (e.g., save staff)
• Control a system that is too complex to control manually
• New or improved service (e.g., faster response to customers)
• Safety or security
Professional benefits are not the reason for doing a project
18
18
9
10/4/21
Feasibility Study: Technical

A feasibility study needs to demonstrate that the proposed system is
technically feasible. This requires:
• an outline of the requirements
• a possible system design (e.g., database, distributed, etc.)
• possible choices of software to be acquired or developed
• estimates of numbers of users, data, transactions, etc.
These rough numbers are part of the provisional plan that is used to
estimate the staffing, timetable, equipment needs, etc.
The technical approach actually followed may be very different.

19
19
Feasibility Study: Planning and Resources
The feasibility study must include an outline plan:

• Estimate the staffing and equipment needs, and the preliminary
timetable
• Identify major milestones and decision points
• Identify interactions with and dependences on external systems
• Provide a preliminary list of deliverables and delivery dates
20
20
10
10/4/21
Feasibility Study: Alternatives and Risks
A feasibility study should identify risks and alternatives:

Risks
• What can go wrong?
• How will progress be monitored and problems identified (visibility)?
• What are the fall back options?
Alternatives
• Continue with current system, enhance it, or create new one?
• Develop in-house, or contract out? (How will a contract be managed?)
• Phases of delivery and possible points for revising plan
21
21
Techniques for Feasibility Studies
The highest priority is to ensure that the client and development team have
the same understanding of the goals of the system
22
22
11
10/4/21
For the development team to understand the goals:

• Interviews with client and the staff of the client’s organization
• Review of existing systems (including competitors’)
For the client to appreciate the proposed system:

• Demonstration of key features or similar systems
• Mock-up of user interfaces
• Walk through typical transactions or interactions
23
23
Outline budget:
• n people for m months at $x per month
• equipment, buildings, etc.
• contingency (at least 50% is needed)
Phases/milestones:
• specify deliverables and approximate dates
• planned releases
24
24
12
10/4/21
Feasibility Study: Report
A feasibility study should have a written report

It should be a well written, well presented document:
• For a general audience: client, financial management, technical
management, etc.
• Short enough that everybody reads it.
• Long enough that no important topics are skipped.
• Details can be included in supporting documents.
A report that is not read and understood is useless
25
25
IT31380 Project: Feasibility Report
Specific Requirements for the Feasibility Report:

• Outline plan, showing principal activities and milestones (see the
lecture on Project Management)
• Risk analysis. What can go wrong? What is your fall back plan?
26
26
13
10/4/21
IT3180 Project: Challenges
• Team: How many hours per week? What skills do people have?
• Time: Must be completed by end of semester, including operational
system, documentation, presentation
• Equipment and software: What special needs are there?
• Client: Will the client be sufficiently available and able to help?
• Start-up time: Creating a team, scheduling meetings, acquiring
software, learning new systems, ...
• Business considerations: Licenses, trade-secrets, ...
• Too ambitious: Nothing to show at the end of the semester...
• What else?
27
27
Good processes lead to good software

Good processes reduce risks
28
28
14
10/4/21
IT3180 Project: Feasibility Report – Common problems
• The purpose of a feasible study is to establish if a project is feasible, at

reasonable cost, within the planned period
• The report should conclude with recommendations about whether to
proceed, but the final decision is made jointly by the client and the
development team
• In previous years, many reports have had the following problems:
• The report is vague about the scope. Without a clear definition of scope, it is
not clear that the project is feasible
• The plan does not describe the activities in enough detail to estimate the effort
convincingly.
• The projects is too ambitious. The report needs to describe how will you
monitor the progress and adjust the scope if necessary.
29
29
6 – Feasibility Study
(end of lecture)
30
30
15
10/11/21
SOICT
1
10/11/21

Engineering
7 – Project Management
The Aim of Project Management
To complete a project:
• On time
• On budget
• With required functionality
• To the satisfaction of the client
• Without exhausting the team
To provide visibility about the progress of a project
To give early warning of problems so that corrections can be made
2
10/11/21
The challenge of Project Management (1)
What do clients want to know?

• Will the system do what was promised? (Function)
• When will it be delivered? If late, how late? (Time)
• How does the cost compare with the budget? (Cost)

Often, the software is a part of larger activity:
• If the system is a product, marketing and development must be

combined (e.g., Microsoft Office)
• If the system has to work with other systems, developments must be

coordinated (e.g., embedded systems in an automobile)
3
10/11/21

BUT:
• Every software system is different.
• Most systems are not well specified, or the requirements change

during development.
• Estimate time and effort is full of errors, even when the system is well
understood.
Aspects of Project Management (1)
• Planning
• Outline schedule during feasibility study
• Full schedule for each part of a project (e.g., each process step, iteration, or
sprint)
• Contingency planning
• Anticipate possible problems (risk management)
4
10/11/21
Aspects of Project Management (2)
• Progress tracking
• Regular comparison of progress against plan
• Regular modification of the plan
• Changes of scope, etc. made jointly by client and developers
• Final analysis
• Analysis of project for improvements during next project
Terminology (1)
• Deliverable
• Work product that is provided to the client (mock-up, demonstration,

prototype, report, presentation, documentation, code, etc.)
• Release of a system or subsystem to customers and users
• Milestone
• Completion of a specified set of activities (e.g., delivery of a deliverable,
completion of a process step, end of a sprint)
10
10
5
10/11/21
Terminology (2)
• Activity
• Part of a project that takes place over time (also known as a task)
• Release of a system or subsystem to customers and users
• Event
• The end of a group of activities, e.g., agreement by all parties on the budget and
plan
• Dependency
• An activity that cannot begin until some event is reached
• Resource
• Staff time, equipment, or other limited resource required by an activity
11
11
Standard approach to Project Management
• The scope of the project is defined early in the process.

• The development is divided into tasks and milestones.
• Estimates are made of the time and resources needed for each task.
• The estimates are combined to create a schedule and a plan.
• Progress is continually reviewed against the plan, perhaps weekly.
• The plan is modified by changes to scope, time, resources, etc.
Typically the plan is managed by a separate project management team,

not by the software developers.
Used with the Modified Waterfall Model and Iterative Refinement.
12
12
6
10/11/21
Agile Approach to Project Management
• Planning is divided into high level release forecasting and low level
detailed planning.
• Release planning is a best guess, high level view of what can be
achieved in a sequence of time-boxes.
• Release plans are continually modified, perhaps daily.
• Clients and developers take joint control of the release plans and
choice of sprints.
• For each time-box, the team plans what it can achieve.
The team may use Gantt charts or other conventional planning tools.
13
13
Project Planning Tools
Critical Path Method, Gantt Charts

• Build a work-plan from activity data
• Display work-plan in graphical or tabular form.
Project planning software (e.g., Microsoft Project)

• Maintain a database of activities and related data
• Calculate and display schedules
• Manage progress reports
14
14
7
10/11/21
A Simple Gantt Chart
15
15
Gantt Chart (1)
Used for small projects, single 1me-boxes, and sprints

• Dates run along the top (days, weeks, or months).
• Each row represents an activity.
• Activities may be sequential, in parallel or overlapping.
• The schedule for an activity is a horizontal bar.
• The left end marks the planned beginning of the task.
• The right end marks the expected end date.
• The chart is updated by filling in each activity to a length proportional
to the work accomplished. This is often difficult.
• Progress to date can be compared with the plan by drawing a vertical
line through the chart at the current date.
16
16
8
10/11/21
Activity Graph
A group of scheduling techniques that emphasizes dependencies:
17
17
Example: AcDvity Graph for first Part of a Distance

Example: Activity Graph Learning Course
Suggest projects
Plan
projects
Dra( 1 Slides 1 Approve
projects
Plan 1 Audio 1 Mount

START dependency
Plan 2 Audio 2 Release
Dra( 2 Slides 2
Write test
instrucDons
Plan test Print test
dependency
Dra( test
18
18
9
10/11/21
Scheduling using Activity Graphs: History
PERT
• Program Evaluation and Review Technique introduced by the U.S.
Navy in 1957 to support the development of its Polaris submarine
missile program.
PERT/Time
• Activity graph with three time estimates (shortest, most probable,
longest) on each activity to compute schedules.
• Because of the difficulty of obtaining good time estimates, usually only
one esDmate is made. This is called the Critical Path Method.
PERT/Cost
• Added scheduling of resources (e.g., facilities, skilled people, etc.)
19
19
Time Estimates for Activities (weeks)
20
20
10
10/11/21
Example: Building a house
Project activities:
• install landscaping
• pour foundations
• frame walls
• install plumbing systems
• get permits
• install electrical systems
• move in
21
21
Activities in order, Durations, Labels, Dependencies

Project tasks Durations Labels Preds. Post
Get permits
Pour foundations
Frame walls
Install plumbing systems
Install electrical systems

Install landscaping
Move in
22
22
11
10/11/21

Get permits 2
Pour foundations 6
Frame walls 5
Install plumbing systems 4
Install electrical systems 6

Install landscaping 9
Move in 3
23
23

Get permits 2 A
Pour foundations 6 B
Frame walls 5 C
Install plumbing systems 4 D
Install electrical systems 6 E

Install landscaping 9 F
Move in 3 G
24
24
12
10/11/21

Get permits 2 A -- B
Pour foundations 6 B -- C, F
Frame walls 5 C B D
Install plumbing systems 4 D A, C E
Install electrical systems 6 E D G

Install landscaping 9 F B G
Move in 3 G E, F --
25
25
Create a precedency diagram
A
D E
C
start
G finish
B
26
26
13
10/11/21
Add duration to each node in the diagram
A
2
D E
4 6
C
start
5
G
finish
B 3
6
F
9
27
27
Critical Path Method
• Uses an Activity Graph with single time estimate for each activity
• A standard method for managing large construction projects
• On big projects, activity graphs with more than 10,000 activities are
common
• Based on the estimated duration, calculate the theoretical Early Start ,

Early Finish, Late Start and Late Finish for each activity
28
28
14
10/11/21
ES, EF, LF, LS
• Earliest start date (ES): the earliest date that it is possible to start an
activity, given that its precedent activities must be completed first
• Earliest finish date (EF): the date that all the activities ending at that
node will be completed, assuming that every activity begins at its
earliest start date
• Equal to the earliest start time for the activity plus the time required to
complete the activity
• Latest finish time (LF): the latest time at which the activity can be
completed without delaying the project
• Latest start time (LS): equal to the latest finish time minus the time
required to complete the activity
29
29
Identify Critical Path
• The critical path is the longest-duration path through the network

• Determining the following four parameters for each activity
• Slack time (float time): how much extra time you have available for a
particular activity?
30
30
15
10/11/21
How many paths are there in this network?
A A-D-E-G = 15
2
D E B-C-D-E-G = 24
4 6
B-F-G = 18
C
start 5
G
finish
B 3
6
F
9
31
31
Which is the longest path?
A A-D-E-G = 15
2
D E B-C-D-E-G = 24
4 6
B-F-G = 18
C
start 5
G
finish
B 3
6
F
9
32
32
16
10/11/21
Calculate Slack time
For each activity, calculate ES, EF, LS, LF and slack time
ES Duration EF
Activity
LS Slack LF
33
33
Calculate Slack time (2)
• The float is how long an activity’s duration can extend before it

lengthens the project duration
• The float for any activity on the critical path is zero
• The float for non-critical activities is the critical path duration minus
the duration of the activity’s path
• If an activity is on multiple paths, its float is the one that is least
34
34
17
10/11/21
• The critical path has a duration of 24

• The Slack time of activities B, C, D, E, G are all 0.
A
2
D E
4 6
A-D-E-G = 15
B-C-D-E-G = 24
B-F-G = 18
C
start 5
G
finish
B 3
6
F
9
35
35
• With path B-F-G has a duration of 18, the Slack time of

F (non-critical path activities) is 24–18 = 6
• What’s about the activity A?
A
2 A-D-E-G = 15
D E
4 6 B-C-D-E-G = 24
B-F-G = 18
C
start 5
G
finish
B 3
6
F
9
36
36
18
10/11/21
D 6
2
0 E
A
0
9
start 5 3
C G finish
0 0
9
6 F
B 6
37
37
Calculate ES and EF (1)
• ES and EF are calculated by doing a forward pass through the diagram
• The ES of activities after the start node is 1
• The EF of an activity is its ES plus its duration minus 1
• The ES is the EF of the predecessor activity plus 1
• If there are multiple predecessor activities, use the greatest EF
38
38
19
10/11/21
Calculate ES and EF (2)
12 4 15
D 16 6 21
1 2 2
0 E
A
0
9
start 7 5 11 22 3 24
C G finish
0 0
7 9 15
1 6 6 F
B 6
39
39
Calculating LS and LF (1)
• Late start is the latest time that an activity can start

• If an activity is on a path that’s much shorter than the critical path, then it can
start very late without delaying the project
• Late finish is the latest time that an activity can finish

• If an activity is on a shorter path than the critical path and all of the other
activities on that path start and finish early, then it can finish very late without
delaying the project
40
40
20
10/11/21
• LS and LF are calculated by doing a backward pass through the

diagram
• Start with the longest path and work your way from the end node to
the start node
• Do the same thing for the next longest path, and so on
• Don’t recalculate the LS or LF for an activity that’s already been calculated on
a prior backward pass.
41
41
• The LS and LF of the last activity in the critical path will be the same as
its ES and EF
• The LF of non-critical activities with the end node as their successor will
be the LF of the last critical path activity
• The LF of an activity is the LS of its successor minus 1

• If there are multiple successor activities, use the least LS
• The LS is the LF of the activity minus its duration plus 1
42
42
21
10/11/21
12 4 15
D 16 6 21
1 2 2
12 0 15 E
A
16 0 21
10 9 11
start 7 5 11 22 3 24
C G finish
7 0 11 22 0 24
7 9 15
1 6 6 F
B 13 6 21
1 0 6
43
43
Discussion
• What are the critical activities?
• How long will it take to complete this project?
• Can activity D be delayed without delaying the entire project? If so,

how many weeks?
• Can activity F be delayed without delaying the entire project? If so,

how many weeks
• What is the schedule for activity C?

44
44
22
10/11/21
7. Project Management
(end of lecture)
45
45
23
10/11/21
SOICT
1
10/11/21

Engineering
8 – Requirement Analysis
Requirements
Requirements describe the function of the system from the client's

viewpoint.
• The requirements establish the system's functionality, constraints, and
goals.
• The requirements must be understandable by both the client and the

development staff.
• The development team and the client need to work together closely to
define the requirements.
2
10/11/21
Why are Requirements Important?
Causes of failed software projects
Failures to understand the requirements led the developers to build the

wrong system
5
Steps in Defining the Requirements

Defining the requirements can be divided into several steps:
• Analysis to establish the functionality by consultation with client,
customers, and users
• Modeling to organize the requirements in a systematic and

comprehensible manner
• Define, record, and communicate the requirements.

Heavyweight processes go through these steps for the entire system
before beginning the design
With lightweight processes, these steps are done separately for each
sprint.
6
3
10/11/21
Requirement Steps
Requirement Dilemma
You cannot build a system unless you know what it is required to do

BUT...
Clients may have only a partial understanding of requirements
4
10/11/21
Challenges
For clients:
• When they see the system, they ask for new features
• Frequently, they ask for major changes
• These changes may force you to rework large parts of the system
• These are problems for both heavyweight and lightweight processes.
Heavyweight Processes: Modified Waterfall Model
10
10
5
10/11/21
Requirements in Heavyweight Processes
Heavyweight processes expect detailed specification:

• Written document that specifies each requirement in detail
• Carefully checked by client and developers
• May be a contractual document
• Will be used for acceptance testing
Difficulties:
• Specification is time consuming and difficult to create
• Specification is hard to maintain
• Checking a detailed specification is tedious
• Clients rarely understand the implications
11
11
The difficulty of creating and maintaining a detailed requirements

specification is one of the reasons that many organizations prefer
lightweight development processes
12
12
6
10/11/21
Lightweight Processes: Agile Development
Each sprint has its own set of requirements
13
13
Requirements in Lightweight Processes (1)
Lightweight processes develop the requirements one sprint at a time:

• Working code is used for checking the requirements
• Client and developers work jointly on the requirements
• Minimal documentation is created during the sprint
• Fuller documentation is needed for future maintainers, but details are

provided in the code
14
14
7
10/11/21
Requirements in Lightweight Processes (2)
Difficulties:
• Some requirements are system-wide and cannot be defined within a
single sprint
• e.g., data bases, security architectures, overall user interface design
• The requirements of future sprints may lead to major rework of earlier

sprint
15
15
Middleweight Processes: Iterative Refinement
The requirements are revised for each iteration
16
16
8
10/11/21
Requirements in Middleweight Processes
Middleweight processes develop the requirements iteratively:

• The first iteration has an outline of the main requirements
• Each iteration refines the outline and add details
• Documentation is needed for future maintainers, but details are
provided in the code
Difficulties:
• Each iteration may require major rework of previous work
• Developers often patch new requirements onto previous iterations
17
17
Discussion
• For a large system, you have to be flexible
• Both heavyweight processes and lightweight process have problems
BUT...
Both types of process work well, if used sensibly
• When using a heavyweight process, such as the modified waterfall
model, specify the requirements in moderate detail, but be prepared
for revisions. Some details can be left until later in the process
• When using a lightweight process, such as agile, develop system-wide

requirements and the overall system architecture early in the process,
perhaps before beginning the regular sprints
18
18
9
10/11/21
Requirement Goals
• Understand the requirements in appropriate detail
• Ensure that the client and developers understand the requirements

and their implications
• Define the requirements in a manner that is clear to the client

• This may be a written specification, prototype system, or other form of
communication
• Define the requirements in a manner that is clear to the people who

will design, implement, and maintain the system
19
19
Requirement Analysis: Interviews with Clients

Client interviews are the heart of the requirements analysis
Clients may have only a vague concept of requirements
• Allow plenty of time
• Prepare before you meet with the client
• Keep full notes
• If you do not understand, discuss and detail with client, again and again
• Repeat what you hear
20
20
10
10/11/21
Requirement Analysis: Understand the Requirements
Understand the requirements in depth

• Domain understanding
• Understanding the terminology
• Clients often use specialized terminology. If you do not understand it, ask for an
explanation
• Understanding of the real requirements of all stakeholders
• Clients may not have clear ideas about what they require, or they may not
express requirements clearly
21
21
Requirement Analysis: New and Old Systems
Clients often have an old system that is so familiar that they do not
realize that it has functions that are not needed in a new system:
• A replacement system is when a system is built to replace an existing
system
• A legacy system is an existing system that is not being replaced, but is
being extended or must interface to a new system
In requirements analysis it is important to distinguish:

• features of the old system that are needed in the new system
• features of the old system that are not needed in the new system
• proposed new features
22
22
11
10/11/21
Requirement Analysis: Unspoken Requirements
Discovering the unspoken requirements is often the most difficult part

of developing the requirements
Examples:
• Departmental friction, e.g., transfer of staff
23
23
Stakeholder Analysis
Identify the stakeholders

Who is affected by this system?
• Client
• Customers
• Users
• Senior management
• Administrators
• Computing staff
Example:
Web shopping site (shoppers, administration, finance, warehouse)
24
24
12
10/11/21
Viewpoint Analysis
Viewpoint Analysis
• Analyze the requirements as seen by each group of stakeholders
• Example: University Admissions System
• Applicants
• University administration
• Admission office
• Financial aid office
• Special offices
• Academic departments
• Computing staff
• Operations and maintenance
25
25
Specifying Requirements: Realism and Verifiability
Requirements must be realistic, i.e., it must be possible to meet them

• Wrong: The system must be capable of x (if no known computer
system can do x at a reasonable cost)
Requirements must be verifiable, i.e., since the requirements are the

basis for acceptance testing, it must be possible to test whether a
requirement has been met
• Wrong: the system must be easy to use
• Right: After one day’s training, an operator should be able to process
50 transactions per hour
26
26
13
10/11/21
Specifying Requirements: Communication
• With heavyweight processes, the requirements are defined by a full

specification.
• With lightweight processes, the specification covers selected parts
where there might be uncertainty
Objectives:
• Provide a basis for acceptance testing
• Provide visibility
• Be a foundation for system and program design
• Communicate with other teams who may work on or rely on this
system or subsystem
• Inform future maintainers
27
27
Lightweight Processes (1)
With lightweight processes, experience and judgment are needed to

distinguish between:
• details that can be left for later in the development process
• key requirements that must be agreed with the client early in the
process
• A common fault is to miss crucial details

• This results in misunderstandings between client and the developers
The whole intent of lightweight processes is to have minimal intermediate

documentation, but you need some
28
28
14
10/11/21
Lightweight Processes (2)
Lightweight processes use a outline specification + other tools

• Documentation describing key requirements in appropriate detail.
• Reviewed by client and developers.
Details provided by supplementary tools, e.g.,
• User interface mock-up or demonstration.
• Models, e.g., data base schema, state machine, etc.
Clients understand prototypes and models beger than specification
• Iterative or incremental (agile) development processes allows the client
to appreciate what the final system will do.
29
29
Functional requirements
Functional requirements describe the functions that the system must

perform.
They include topics such as:

• Transactions
• Data
• User interfaces
30
30
15
10/11/21
Non-Functional requirements
Requirements that are not directly related to the functions that the
system must perform
Product requirements
• performance, reliability, portability, etc...
Organizational requirements
• delivery, training, standards, etc...
External requirements
• legal, interoperability, etc...
Marketing and public relations
31
31
Non Functional Requirements - Examples
Example: Library Management System

Use technology that the client's staff are familiar with:
• Hardware and software systems (IBM/Unix)
• Database systems (Oracle)
• Programming languages (C and C++)
32
32
16
10/11/21
Requirement Analysis: Negotiation with Clients
Sometimes the client will request functionality that is very expensive or

impossible to implement. Or two requirements may contradict each
other.
This requires negotiation:
• Talk through the requirement with the client. Why is it wanted? Is
there an alternative that is equivalent?
• Explain the reasoning behind your concern.
• Explain the technical, organizational, and cost implications.
• Be open to suggestions. Is there a gap in your understanding? Perhaps
a second opinion might suggest other approaches.
The client and development team must resolve these questions.
33
33
Requirements vs. System Design
Technical decisions
• Requirements analysis should make minimal assumptions about the
system design
• But the requirements definition must be consistent with computing
technology and the resources available
In practice, analysis and design are interwoven. However:

• Do not allow assumptions about the design to influence the
requirement analysis
34
34
17
10/11/21
8 – Requirement Analysis
(end of lecture)
35
35
18
10/18/21
SOICT
1
10/18/21

Engineering
9 – Scenarios and Usecases
Requirement Steps
2
10/18/21
Requirement as a Scenario
A functional requirement is often represented as a scenario

In which
We define interactions between a user and the system
Scenarios
Definition:
• A scenario is a scene that illustrates some interaction with a proposed

system
• A scenario is a tool used during requirements analysis to describe a

specific use of a proposed system
• Scenarios capture the system, as viewed from the outside

• By a user
3
10/18/21
Scenario - Terminology
In some document:
• Scenario refers to a user’s total interaction with the system
• Example: An admin of the store can manage all the products of his
store
• Including: add new product, delete/update existing products
• Scenario can also be used to refer to parts of interactions

• Example: An admin of the store can: Add new product, Delete a
product, Update a product
• In this course, the term scenario is used with both meanings

7
Describe a Scenario
At the very least, the description of a scenario should include:

• A statement of the purpose of the scenario
• The individual user or transaction that is being followed through the

scenario
• Assumptions about software or equipment
• The steps of the scenario
4
10/18/21
Example of How to develop a scenario with a client
Requirement’s goal:
The requirements are being developed for a system that will enable
university students to take exams online from their own rooms using a
web browser
Create a scenario for how a typical student interacts with the system
In the next few slides, the questions in blue are typical of the questions to ask
the client while developing the scenario
Example (2)
Purpose
• Scenario describes the use of an online Exam system by a
representative student
User
• [Who is a typical student?] Student A, senior at HUST, major in
computer science
• [Where can the student be located?] At his/her own room
Equipment
• Any computer with a supported browser
• [Is there a list of supported browsers? Are there any network restrictions?]
10
10
5
10/18/21
Example (3)
Scenario
1. Student A authenticates. [How does a HUST student authenticate?]
2. Student A starts browser and types URL of Exam system. [How does
the student know the URL?]
3. Exam system displays list of options. [Is the list tailored to the
individual user?]
4. Student A selects IT3180 Exam 1.
5. A list of questions is displayed, each marked to indicate whether
completed or not. [Can the questions be answered in any order?]
6. Student A selects a question and chooses whether to submit a new
answer or edit a previous answer [Is it always possible to edit a
previous answer? Are there other options?]
11
11
Example (3)
Scenario
7. [What types of questions are there: text, multiple choice, etc.?] The first
question requires a written answer. Student A is submitting a new
answer. The student has a choice whether to type the solution into
the browser or to attach a separate file. Student A decides to attach
a file. [What types of file are accepted?]
8. For the second question, the student chooses to edit a previous
answer. Student A chooses to delete a solution previously typed into
the browser and to replace it with an attached file. [Can the student
edit a previous answer, or must it always be replaced with a new
answer?]
9. As an alternative to completing the entire exam in a single session,
Student A decides to saves the completed questions to continue
later. [Is this always permitted?] 12
12
6
10/18/21
Example (4)
Scenario
10. Student A logs off.
11. Later Student A logs in, finishes the exam, submits the answers, and
logs out. [Is this process any different from the initial work on this exam?]
12. The student A has now completed the exam. The student selects an
option that submits the exam to the grading system. [What if the student
has not attempted every question? Is the grader notified?]
13
13
Developing a Scenario with a client
• Developing a scenario with a client clarifies many functional

requirements that must be agreed before a system can be built
• Policies
• Procedures
• Etc.
• The scenario will often clarify the requirements for the user interface,
but the design of the user interface should not be part of the scenario
14
14
7
10/18/21
Scenarios for error recovery
Murphy’s Law: “If anything can go wrong, it will”
Create a scenario for everything that can go wrong and how the system
is expected to handle it
15
15
Modeling Scenarios as Use Cases
Scenarios are useful in discussing a proposed system with a client, but

requirements need to be made more precise before a system is fully
understood.
This is the purpose of requirement modeling
• A use case provides such a model
16
16
8
10/18/21
Two simple Use Cases
17
17
Actor and Use Case Diagram
18
18
9
10/18/21
Use Cases and Actors
• Actor is role, not an individual

• E.g., A staff in a hotel can have many roles
• Receptionist
• Security Staff
• Etc.
• Actor must be a beneficiary of the use case
• When naming actors, choose names that describe the role, not generic
names, such as “user” or “client”
19
19
Use Cases for Exam System
20
20
10
10/18/21
Use cases for Exam System (2)
21
21
Describe a Use Case
Metadata
• The name of the use case
• Goal of the use case
• The actor or actors
• Trigger
• Entry conditions at beginning
• Post conditions at end
Flow of events
• The basic flow of events
• Alternative flows of events
• Exceptions
22
22
11
10/18/21
Take Exam Use Case: Metadata
Name of Use Case: Take Exam

Goal: Enables a student to take an exam online with a web browser
Actor(s): ExamTaker
Trigger: ExamTaker is notified that the exam is ready to be taken
Entry conditions: ExamTaker must be registered for course. ExamTaker
must have authentication credentials
Post conditions: Completed exam is ready to be graded
23
23
Take Exam Use Case: Basic Flow

Basic flow of events:
1. ExamTaker connects to the server
2. The server checks whether ExamTaker is already authenticated and
runs authentication process if necessary
3. ExamTaker selects an exam from a list of options
4. ExamTaker repeatedly selects a question and either types in a
solution, attaches a file with a solution or edit a solution
5. ExamTaker either submits completed exams or saves current state
6. When a completed exam is submitted, the server checks that all
questions have been attempted and send acknowledgement to
ExamTaker
7. ExamTaker logs out.
24
24
12
10/18/21
Take Exam Use Case: Alternative Flow

Alternative flows and exceptions model paths through the use case
other than the basic flow
In the following list, each flow is linked to a step of the basic flow.
Alternative flows are alternative paths to successful completion of the
use case
3. ExamTaker has previously entered part of the exam, but not
submitted it.
4. Solution file not accepted by system
6. Incomplete submission
Exceptions lead to failure of the use case
2. Authentication failure
25
25
Association between Actor and Use case
• A direct relationship between an actor and a use case, to denote the

interaction of this actor with the system through the use case
• An actor must be associated with at least one use case
• An actor can be associated with multiple use cases
• Multiple actors can be associated with a single use case
• Primary actor
• Secondary actors
26
26
13
10/18/21
Association (2)
Which statement is correct?

• Actor 1 and Actor 2 can interact
the system through UC1
• Both Actor 1 and Actor 2 are
needed to start UC1
• Actor 1 starts UC1 first then
Actor 2 does something later or
vice versa
27
27
Association (3)
Two actors Sales Clerk and Sales Manager

are required to execute the use case Sell
an Item
• But only one primary actor, who starts
the UC, supposing Sales Clerk
• Every sale is performed by a clerk
• But it should be approved by a sales
manager
• Sales Manager is the secondary actor
who is involved in the execution
28
28
14
10/18/21
Association (4)
Both the Sales Manager and the Sales

Clerk can sell an item (i.e., start the Sell
an Item use case)
• Both actors Sales Manager and Sales
Clerk can act as the seller (Seller)
• Using the inheritance relationship
between Actor to denote that actors
share the same use case
29
29
Association (5)
Same situation as UC1, but a minor

difference
• The arrows indicate clearly who is the
primary and the secondary actors
• However, these arrows are not
standardized in UML
• But they are used as private notation
of the organization
There is no differentiation between

primary and secondary actors
30
30
15
10/18/21
Generalization between Actors
• One actor can inherit the role

of the other actor
• The descendant inherits all the
use cases of the ancestor
• The descendant can have one
or more use cases that are
specific to that role
31
31
Relationship between Use Cases
There are three kinds of relationship between Use cases:

• Generalization
• Extension
• Inclusion
32
32
16
10/18/21
The <<extend>> Relationship
The <<extend>> relationship

Use cases can make use of other use cases
• Base use case: extended use case
• Extending use case: provides optional behavior
Base Use Case Extending Use Case
33
33
The <<extend>> Relationship (2)
Extension Point
• A feature of a use case that identifies a point where the behavior of
this use case can be augmented with elements of another (extending)
use case.
• If an alternative flow or an exception needs extra detail, it can be
modeled as a separate use case using the <<extend>> relationship
34
34
17
10/18/21
Take Exam extensions
35
35
The <<include>> relationship
A directed relationship between two use cases which is used to show

that behavior of the included use case (the addition) is inserted into the
behavior of the including (the base) use case
The <<include>> relationship could be used:
• To simplify large use case by splitting it into several use cases
• To extract common parts of the behaviors of two or more use cases
36
36
18
10/18/21
The <<include>> relationship (2)
A large use case is split into several use cases
Use case B is extracted from larger use case A into a separate use case
Use cases B and C are extracted from larger use case A into separate use cases
37
37
Example
38
38
19
10/18/21
The <<include>> relationship (3)
Extract common parts of the behaviors of a some use cases
Use case C is extracted from use case A and B to be reused by both use cases A, B
There is no “inclusion points” to specify location or condition of
inclusion for the <<include>> relationship
39
39
Example
40
40
20
10/18/21
Exam System - <<include>>
41
41
The Generalization relationship between two Use cases
The Generalization relationship between two Use Cases has the same
meaning as in the case of Actors
• The behavior of the ancestor is inherited by the descendant
• This is used when there is common behavior between two use cases
and also specialized behavior specific to each use case
42
42
21
10/18/21
Example
When checkout, a customer has to make a payment. He or she can

select one of three payment methods:
• Pay via Paypal
• Pay via Credit Card
• Pay via EFT
43
43
Example (2)
44
44
22
10/18/21
Example (3)
45
45
Scenario and Use Cases in the Development cycle
Scenarios and Use cases are both intuitive – easy to discuss with clients
Scenarios are a tool for requirement analysis
• They are useful to validate use cases and in checking the design of a
system
• They can be used as test cases for acceptance testing
Use cases are a tool for modeling requirements

• A set of use cases can provide a framework for the requirement
specification
• Use cases are the basis for system and program design, but are often
hard to translate into class models
46
46
23
10/18/21
Use Case Diagrams
• A use case diagram shows the relationships between actors and their
interactions with a system
• It does not show the logic of those interactions
• In practice, a use case diagram is often used together with Scenario

description to specify the business logic of interactions
47
47
System Boundary
• An actor is defined as an entity outside of the system boundary in a

Use case diagram
• An actor therefore can be either a user or an external system or a
component in the large system
• A system boundary is a rectangle around a use case diagram to
separate this use case diagram and the actors who interact with
48
48
24
10/18/21
Exercise 1 – Old Exam Question
49
49
Exercise 1 – Correct Solution
50
50
25
10/18/21
Exercise 1
51
51
Exercise 2
• Modeling the following situation using use cases

• A general customer can come to the Bank X and ask for open an
account. He or she will complete a form and the bank employee will
validate the form to open his/her account.
• A customer can deposit funds, when the amount is over 10,000$ or
his/her age is over 55, a bonus will be calculated and offered to the
customer
• A NRFC customer can also open account, deposit funds but he or she
can also convert currency
52
52
26
10/18/21
9 – Scenarios and Use Cases

(end of lecture)
54
54
27
IT3180 - Introduction to Software Engineering
Exercises: Use Case Diagram Quiz
Bui Thi Mai Anh1

anhbtm@soict.hust.edu.vn
1 School
of Information and Communication Technology
Ha Noi University of Science and Technology
18 octobre 2021
Bui Thi Mai Anh SE - Introduction 18 octobre 2021 1 / 31

Question 1

Question 2

Question 3

Question 4

Question 5

Question 6

Question 7

Question 8

Question 9

Question 10

Question 11

Question 12

Question 13

Question 14

Question 15

Question 16

Question 17

Question 18

Question 19

Question 20

Question 21

Question 22

Question 23

Question 24

Question 25

Question 26

Question 27

Question 28

Question 29

Question 30

11/1/21
SOICT
1
11/1/21

Engineering
10 – Models for requirements
Models for requirements
Requirement analysis and specification includes selecting the appropriate

tool for the particular task
• Models provide a bridge between the client’s understanding and the
developers’
• A variety of tools and techniques
• There is no correct technique that fits all situations
2
11/1/21
Models
A model is a simplification of reality
• We build models so that we can better understand the system we are

developing
• We build models of complex system because we cannot comprehend

such a system in its entirely
Example: Model
Approach: as a Blueprint
Floorplan
2. Design
1. Requirements
• Shall fit on given 3. System

http://wikimedia.org (CC nc-sa 3.0, Ottoklages)
piece of land.
• Each room shall
have a door.
• Furniture shall fit
into living room.
• Bathroom shall
have a window.
• Cost shall be in http://wikimedia.org
budget. (CC nc-sa 3.0,
Bobthebuilder82)
– 1 – 2013-10-21 – Smodel –
6 Observation: Floorplan abstracts from, e.g., . . .

• kind, number, and placement of bricks, • water pipes/wiring, and
• subsystem details (e.g., window style),
6/40
3
11/1/21
Example (2): Model as a Blueprint
Floorplan as an Abstraction
Floorplan
γ
all houses
F
F •
•
• •
H
α
α
7
Floorplan F
•• Floorplan F denotes
denotes a set γ(F ) of houses (concretisations of F ),
7
Smodel ––
which differ,
which differ, e.g.
e.g. in
in colour
colour of bricks, or making of windows.
2013-10-21 –– Smodel
Floorplan F
•• Floorplan F represents
represents house H according to abstraction α.
–– 11 –– 2013-10-21
By adding
•• By adding information
information to F (such as making of windows),
Principles we
of can
we Modeling
can narrow down
narrow down γ(F ).
7/40
• The choice of what model to be created has a profound influence on

how to resolve a problem
• No single model is sufficient
• Every model can be expressed at different levels of precision
• Good models are connected to reality
• Every nontrivial system is best approached through a small set of nealy

independent models
4
11/1/21
The Unified Modeling Language
• UML is a standard language for modeling software systems
• Serves as a bridge between the requirements and the implementation
• Provides a means to specify and document the design of a software system
• It is intended to be processed and programming language independent, but is

particularly suited to object-oriented program development
Data Flow Models (Data Flow Diagrams – DFDs)
• Goal
• Represent the flow of information through the system and the activities that
process this information
• DFDs provide a graphical representation of the system that aims to be

accessible to computer specialist and non-specialist users
• The models enable software engineers, customers and users to work

together effectively during the analysis and specification of
requirements
10
10
5
11/1/21
DFD notations
• Processes
• The activities carried out by the system which use and transform information
• Process is denoted as a rounded rectangle
• Data-flows
• The data inputs to and outputs from to these activities (processes)
• Data flows are notated as named arrows
• External entities
• The sources from which information flows into the system and the recipients of
information leaving the system
• External entities are notated as ovals
• Data stores
• Where information is stored within the system
• Notated as rectangles
11
11
DFD symbols
12
12
6
11/1/21
Example: University Admissions
13
13
Example (2): Assemble Application
14
14
7
11/1/21
Example (3): Process Completed Application
15
15
Decision Table Model
16
16
8
11/1/21
Flowchart Models
An informal modeling technique to show the logic part of a system and

paths that data takes through a system
17
17
Example: University Admission Assemble Application
18
18
9
11/1/21
Transition Diagrams
19
19
52
Flight booking system

Example: Flight Booking System
The customer provides some information and makes a booking. He then
has a certain amount of time to make the reservation.
Finite State Machine
Event
giveInfo/ Booking
startPayTimer Made payMoney
Action Transition Paid
Entry point
State 20
20
10
11/1/21
54
Flight booking system complete

Example (2) Finite State Machine for Flight Booking System
payMoney
giveInfo/ Booking
startPayTimer Made checkIn
Paid
cancel
cancel/refund
time Ticketed
Expires Cancelled/
Customer
Cancelled
/Unpaid fly
Used
21
21
Entity Relation Model
A requirement and design methodology for relational databases

• A database of entities and relations
• Tools for displaying and manipulating entity-relation diagrams
• Tools for manipulating the database
Entity Relationship Models can be used both for requirement

specification and for the design specification
22
22
11
11/1/21
Entity Relationship Diagram
23
23
Example: IT3180 Project
IT 3180
Student
24
24
12
11/1/21
Example: Database Schema for Web Data
25
25
Prototyping Requirements
Rapid prototyping is the most comprehensive of all modeling methods
• A method for specifying requirements by building a system that

demonstrates the functionality of key parts of the required system
• Particularly valuable for user interfaces
26
26
13
11/1/21
Discussion
• Class and object models are used as a tool for program design, not for
modeling requirements
• Some documents recommend class and object models for

requirements definition, but it is difficult to use them without
constraining the system design
• Flow charts, finite state machines, entity relationship diagrams are

supported by UML as design models but are equally useful for
requirement modeling.
27
27
10. Models for Requirements

(end of lecture)
28
28
14
11/1/21
SOICT
1
11/1/21

Engineering
11 – User Experience
The importance of User Experience
A computer sytem is only as good as the experience it provides to its

users
• If a system is hard to use:
• Users may fail to find important results
• They may give up
• Developing good user interfaces needs skill and time
2
11/1/21
Terminology
User Experience (UX)

• The user experience is the total of all factors that contribute to the
usability of a computer and its systems
Human Computer Interaction (HCI)

• HCI is the academic discipline that studies how people interact with
computers
Development Processes for User Interfaces

It is almost impossible to specify an interactive or graphical interface in
a written document
• Requirements benefit from sketches, comparison with existing system
• Designs should include graphical elements and benefit from various
forms of prototype
• User interfaces must be tested with users.
• Expect to change the requirements and design as the result of testing
• Schedules should include user testing and time to make changes
3
11/1/21
Prototypes
A prototype is a preliminary version that can be used to iterate rapidly

between requirements and design
• Paper prototype
• Quick sketches
• Wireframe
• Online layout
• Mock-up
• Graphical designs to show details of layout, colors, etc.
• Operational prototype
• Include controls to test interaction and navigation
Paper Prototype
• Little effort has been spent

on drawing the paper
prototype
• People do not hesitate to
propose major changes
• Changes can be made at
low cost
4
11/1/21
Wireframe
• A wireframe shows the layout of information and controls on a display

• This wireframe is created with Balsamiq
Mock-up
• A mock-up shows
suggested layout and
graphical design elements,
such as icons, colors, fonts,
etc.
• This mock-up was drawn
with Photoshop
10
10
5
11/1/21
Mental Model and Computer Model
11
11
Mental Model and Computer Model (2)
• The mental model is the user’s model of what the system provides
• The computer model may be quite different from the user’s mental
model
Example: A board game, e.g., chess
• Mental model: pieces on a board
• Computer model: data and logic that describe the game
Example: The desktop metaphor, e.g., Windows and Mac OS

• Mental model: files and folders on a desktop
• Computer model: file system and metadata about the items visible on
screen
12
12
6
11/1/21
Mental Model vs. Computer Model
13
13
Mental Models and User Experience
14
7
11/1/21
The Model View Control
15
15
The Model View Controller
• The term Model View Control (MVC) is used with a wide variety of
slightly different meanings
• In this lecture, we use MVC as a computer model for designing the user
experience
• In other lectures, we may see it as:

• a system architecture (system design)
• a design pattern (program design)
• a framework for program development
16
16
8
11/1/21
Model: Content and Data
17
17
Model: Separation of Content from the View
18
18
9
11/1/21
Model: Separation of Content from View
19
19
Navigation
The controller manages the flow of the application

• Controls the navigation through the various displays that a system
provides (forms, panels, pages of a web site, etc.)
• Manages the information that is saved when leaving a display and

makes it available to other displays
• Invokes user interface functions that convey information between the

model and the user interface
Different versions of MVC have different roles for the controller

20
20
10
11/1/21
View: User Interface
The user interface is the appearance on the screen and the manipulation
by the user
• Graphical elements, e.g., fonts, colors, logos, icons

• Controls, e.g., mouse, touch screen, keyboard
• Input, e.g., forms, text boxes, menus, buttons
For user interface design, a team needs somebody who has skills in
graphic design
21
21
Principles of User Interface Design
User interface design is partly an art, but there are general principles
• Consistency – in appearance, controls, and function
• Feedback – what is the computer system doing? Why does the user
see certain results?
• Users should be able to interrupt or reverse actions
• Error handling should be simple and easy to comprehend
22
22
11
11/1/21
Navigation: Menus
Advantages
• Easy for users to learn and use
• Certain categories of error are avoided
Major difficulty is structure of large number of choices

• Scrolling menus
• Hierarchical
• Associated control panels
• Menus plus command line
23
23
Simple is good
24
24
12
11/1/21
Choices in User Interface Design
25
25
Design choices: Information Presentation
• Text
• Precise, unambiguous
• Fast to compute and transmit
• Graphics
• Simple to comprehend / learn
• Uses of color
• Variations show different cases
26
26
13
11/1/21
Simple is good: Command line interfaces
Problems with graphical interfaces

• Not suitable for some complex interactions
• Only suitable for human users
Command line interfaces: users interact with computer by typing

commands (e.g., Linux shell script)
• Allows complex instructions to be given to computer
• Can be adapted for people with disabilities
• Can be used for formal methods of specification and implementation
• Usually requires learning or training
27
27
10. Models for Requirements

(end of lecture)
28
28
14
SOICT
Engineering
12 – System Architecture
3
Design Phase
For a given set of requirements, the software development team must

design a system that will meet those requirements
The design of a system has many aspects:

• System architecture
• Program design
• Security
• Performance
• In practice, requirements and design are interrelated, working on the

design often clarifies the requirements.
4
Creativity and Design
Creativity
• System and program design are a particular part of creativity in the
software development, as user interfaces
Software development as a craft

• Software developers have a variety of tools that can be used in design
• We have to select the appropriate tool for a given implementation
5
System architecture
System architecture is the overall design of a system:
• Computers and networks (e.g., LAN, Internet, cloud services)
• Interfaces and protocols (e.g., HTTP, IMAP, ODBC)
• Databases (e.g., relational, distributed)
• Security
• Operations (e.g., backup, archiving, audit trails)
At this stage of the development process, we should select:

• Software environment (e.g., language, database system, framework)
• Testing framework
6
Models for System Architecture
Our models for system architecture are based on UML

• For every system, there is a choice of models
• The goal is to choose models that best model the system, which are
also clear to everybody
In UML, every model must have both a diagram and a supporting

specification
• The lectures provide diagrams that give an outline of the system,
without supporting specifications
• The diagrams show the relationship among parts of the system, but
much more details are needed to specify the system
7
Subsystems
Subsystem is a group of elements that form part of a system

• Coupling is a measure of the dependencies between two subsystems
• If two systems are strongly coupled, it is hard to modify one without modifying
the other
• Cohesion is a measure of dependencies within a subsystem

• If a subsystem contains many closely related functions, its cohesion is high
• An ideal division of a complex system into subsystems has low

coupling between subsystems and high cohesion within subsystems
8
Example: Low cohesion (blue), High coupling (red)
9
Example: High cohesion (blue), Low coupling (red)
BETTER!
10
Component
• A component is a replaceable part of a system that conforms to and

provides the realization of a set of interfaces
• A component can be thought of as an implementation of a subsystem
• UML definition of a component
• A distributable piece of implementation of a system, including software code
(source, binary, executable) but also including business documents
11
Components as Replaceable Elements
Components allow systems to be

assembled from binary replaceable
elements
• A component can be replaced by
any other component(s) that
conforms to the interfaces
• A component is part of a system
• A component provides the
realization of a set of interfaces
12
Components and Classes
• Classes represent logical abstractions

• They have attributes (data) and operations (methods)
• Classes can be combined to form programs
• Components represent physical things that live in the world of bits

• Components may be at different levels of abstraction
• Components have operations that are reachable only through
interfaces
• Components can be combined to form systems
13
Kinds of Components
• Three kinds of components may be distinguished

• Deployment components
• Components are necessary and sufficient to form an executable system
• Dynamic libraries (.dll) or executable files (.exe) are two examples of
deployment components
• Work product components
• These components are generally the residue of the development process
• Source code files, data files are examples of work product components from
which deployment components are created
• Execution components
• These components are created as a consequence of an executing system, such
as .obj, .class files
14
Package
A package is a general purpose mechanism for organizing elements into

groups
15
Node
• A node is a physical element that exists at a run time and provides a

computational resource, e.g., a computer, a smartphone, a router etc.
• Components may live on nodes
16
Example: Simple Web System
• Static pages from server

• All interactions require communication with the server
17
Deployment Diagram
• One of the two kinds of diagrams used in modeling the physical aspects
of an object-oriented system
• Show the configuration of run time processing nodes and the
components that live on them
• We use deployment diagrams to model the static deployment view of a
system
• A deployment diagram commonly contains
• Nodes
• Dependency and association relationships
18
Deployment Diagram (2)
19
Deployment Diagram (3) – Common Uses
When modeling the static deployment view of a system, we’ll typically

use deployment diagrams in one of the three ways
• To model embedded systems
• To model client/server systems
• To model fully distributed systems
20
Model embedded system
• Identify the devices and nodes

that are unique to your system
• Model the relationships
among these processors and
devices
21
Model client/server system
• Identify the nodes that represent your system’s client and server
processors
• Highlight those devices that are relevant to the behavior of the system
• Model the topology of these nodes in a deployment diagram
22
Model a fully distributed system
23
Component Diagram
• Component diagrams are one
of the two kinds of diagrams
for modeling the physical
aspects of object-oriented
software system
• Show the organization and
dependencies among a set of
components
• We use component diagrams
to model the static
implementation view of a
software system
24
Component diagram - content
Component diagram commonly contains:
• Components
• Interfaces
• Dependency, generalization, association and realization relationships
25
Component Diagram: Interfaces
An interface is a collection of
operations that are used to
specify a service of a class or a
component
• Relationship between a
component and its interface
can be in two ways
• Iconic form of realization
• Expanded form (reveal
operations) of realization
• The component that accesses
the services of the other
component through the
interfaces using dependency
26
Application Programming Interface (API)
An API is an interface that is realized by one or more components
27
Component diagaram to Model an API
28
Component Diagram to Model Source Code
29
Component Diagram to Model an executable release
30
Component Diagram to Model Tables, Files, Documents
31
Component Diagram to Model a physical database
32
Architectural Styles
• An architectural style is system architecture that recurs in many

different applications
• See:
• Mary Shaw and David Garlan, Software architecture: perspective on an emerging
discipline. Prentice Hall, 1996.
33
Architecture Style: Pipe
• Example: A three-pass compiler
34
Architectural Style: Client/Server
• Example: A mail system

• The control flows in the client and the server are independent
• Communication between client and server follows a protocol
• Because components are binary replaceable elements, either the client
or the server can be replaced by another component that implements
the protocol
• In a peer-to-peer architecture, the same components act as both client
and server
35
Architectural Style: Repository
36
Architectural Style: Repository with Storage Access Layer
37
Exercise (Old Exam Question)
• A company that makes sport equipments decides to create a system

for selling online. The company already has a product database with
description, marketing information, and prices of the equipment that it
manufactures
• To sell equipment online the company will need to create: a customer
database and an ordering system for online customers
• The plan is to develop the system in two phases. During phase 1,
simple versions of the customer database and ordering system will be
brought into production. In Phase 2, major enhancements will be made
to these components
38
Solution for Phase 1
39
40
• (b) For Phase 2:

• What architectural style would you use for the customer database?
Repository with Storage Access Layer
• Why would you choose this style?
It allows the database to be replaced without changing the

applications that use the database
41
• (b) For Phase 2:

• Draw an UML diagram for this architectural style showing its use in this
application
42
12. System Architecture
(end of lecture)
43
11/25/21
SOICT
1
11/25/21

Engineering
13 – System architecture (2)
Three popular architectural styles
• Three tier Architecture

• Master File Update
• Model/View/Control
2
11/25/21
Three Tier Architecture
• This architecture is an extension of the client/server model

• It is the standard architecture for small and medium sized web sites
• The basic web system has a client / server architecture
Web Server with Data Store
The basic client/server web site returns only fixed HTML pages
• Attach the server to a data store, so that it can respond to requests
from the client and return suitable content
• Advantage: Server-side code can respond to user requests by

accessing data, configuring pages, validating information, etc.
6
3
11/25/21
Web Server with Data Store – Component Diagram
• Since components are replaceable binary elements:

• Any web browser can access the web site
• The database server can be replaced by another database that supports the
same interface
Architectural Style: Three tier architecture
Each of the tiers can be replaced by other components that implement

the same interfaces
4
11/25/21
Web Browser with JavaScript
The Presentation Tier has become more complex. Since it still supports
the same interface it is still a replaceable binary component.
Tier vs. Layer
• A ‘layer’ refers to a functional division of the software

• Presentation Layer
• Business Logic Layer
• A ‘tier’ refers to a functional division of the software too, but a tier
runs on infrastructure separate from the other divisions
• For example:
• The Contacts app on your phone is a three-layer application but a single-tier
application because all three layers run on your phone
10
10
5
11/25/21
Benefits of three-tier architecture
A separation of logical functionality and physical functionality

• Each tier can run on a separate operating system and server platform
• Presentation tier, Application tier, Database tier – that best fits its
functional requirements
• Each tier runs on at least one dedicated server hardware or virtual
server
• Services of each tier can be customized and optimized without impact
the other tiers
11
11
Master File Update
• This architecture is an alternative to the repository model

• Information is kept on files needing to be modified as changes. The
process is called updating and the files that are being updated are
called master files
• It is very widely used in data processing systems
• Inputs
• Processing
• Outputs
12
12
6
11/25/21
Updating
• Updating a file can involve the following:

• Adding records to the file
• Changing records on the file
• Deleting records from the file
• Actions: add, change, delete transactions that will be used to update
the master file are saved on a transaction file
• Transaction file will be processed with the master file to update the file
• 2 kinds of business updating:
• Maintenance updating
• Production updating
13
13
Master File with Batch Processing: Dataflow Model
• Input and validation process runs throughout the day

• It processes transactions when they arrive
• Master file update program runs once per day (usually at night)
• Output process is run after the master file update finishes
14
14
7
11/25/21
Batch Processing: Input and Validation
• Because the input and validation process is able to read the master file,
it can check that the transaction is compatible with the master file
• Example: whether or not the file has a record for the customer
15
15
Benefits of Batch processing with Master File Update
Advantages:
• Backup and recovery has fixed checkpoints
• Better management control of operations
• Efficient use of staff and hardware
• Error detection and correction is simplified
Disadvantages:
• Information in master file is not updated immediately
• No good way to answer customer inquiries
16
16
8
11/25/21
Online Inquiry
• Customer calls the organization and speaks to a customer service

representative
• The representative can read the master file and the pending file, but
cannot change them
• If the representative wishes to change information in the master file, a
new transaction is created and sent to the input and validation process
17
17
Model/View/Control (MVC) Architecture
• This architecture is used to control a complex user interface

• It is the standard architecture for web/mobile apps and widely used in
robotics
• The definition of MVC is in a state of flux – The term is used to
describe a range of architectures and designs
• Some are system architectures, where the model, view and controller are
separate components
• Some are program design, with classes called model, view and controller
18
18
9
11/25/21
Model/View/Controller as a System Architecture
19
19
View
The view presents the state of the interface to the user. It subscribes to
the model, which notifies it of events that change the state
• Renders data from the model for the user interface
• Provides editors for properties, such as text fields, etc.
• Receives updates from the model
• Sends user input to the controller
• A given model may support a choice of alternative views
20
20
10
11/25/21
Model
The model records the state of the application and notifies subscribers. It
does not depend on the controller or the view
• Stores the state of the application in suitable data structures or
databases
• Responds to instructions to change the state information
• Notifies subscribers of events that change the state
• May be responsible for validation of information
21
21
Controller
The controller is the part of the system that manages user input and
navigation within the application
• Defines the application behavior
• Maps user actions to changes in the state of the model
• Interacts with external services via APIs
• May be responsible for validation of information
• Different frameworks handle controllers in different ways. In
particular, there are several ways to divide responsibilities between
the model and the controller, e.g., data validation, external APIs
22
22
11
11/25/21
Model/View/Controller as a Program Design
• For mobile apps, the MVC is a single component. The model, view,
controller are classes
• The programs often use cloud-based external services, each with an
API (e.g., location, validation). These are usually managed by the
controller
23
23
Web’s Version of Model/View/Controller
• The MVC is a program design (not a system architecture)

• The model, view, controller are classes (not components)
• All messages pass through the controller
• A multi-screen app will have several views and controllers sharing the
same model
24
24
12
11/25/21
Architectural Styles and Design Patterns
• There are many variants of the common architectural styles

• We distinguish carefully between architectural styles and design
patterns
• Architectural styles are part of system design. They are defined in terms of
subsystems, components and deployment
• Design pattern are part of program design. They are defined in terms of classes
25
25
13. System Architecture (2)

(end of lecture)
26
26
13
11/25/21
SOICT
1
11/25/21

Engineering
Preparation of Presentation for IT3180
Project
Presentations
Presentations are an important part of software projects

• Marketing to potential clients
• Reporting of progress
• Reports and demonstrations to clients
• Communication with members of development team
Not everybody is a great presenter, but everybody can be well-prepared
2
11/25/21
The IT3180 Presentations
There are three presentations during the semester:

• Everybody must be the presenter for at least one part of one
presentation during the course
• Inexperienced presenters are usually most comfortable describing
material where they did the work
• Avoid technical details that are not appropriate for the audience
Planning for a presentation
Objectives
• What is the purpose of the presentation? What do you want to
achieve?
• Who will be there?
• How much time will you have? How will you use the time?
IT 3180 Presentations:
• Lecturer, Teaching Assistant, may be clients (if available)
• Plan 15 minutes for the presentation and 5 minutes for questions
• Expect interruptions
3
11/25/21
Topics for Software Presentations
Every project is different, but here are some suggestions:

General topics for every project
• A description of what you have agreed to deliver to your client
• Summary of progress since last presentation or report
• Test plan and test cases
• Discussion of unexpected events and risks
• Overview of plan to complete and deliver the project
Topics for Software Presentations
Topics that apply to many projects

• Results of user testing
A demonstration is always welcome
• If you have a mock-up, demonstration, prototype, etc, it is usually
better to show it first before talking about it.
4
11/25/21
Topics for the first IT3180 Presentation
• Client and team agreement on scope and goals

• Progress to date:
• Summary of requirements, preliminary designs, etc.
• Mock-ups, Prototypes (if available), designs, etc.
• Schedule and plan
• What has been done since feasibility study?
• What has been learned?
• Changes in plans?
• Problems
• Solutions
Demonstrations
Demonstrations are always useful, but they need preparation and

practice to do well
• If you need test data create it in advance before demonstration
• If you have to type complex commands to run a demonstration, do so
before the presentation
• Prepare a text that list all the things you want to demonstrate, the
examples that will be shown, who will do which tasks
• Tell the audience what they are seeing: operating system, mock-up,
prototype, etc.
10
10
5
11/25/21
Final Presentation
• What do you want to achieve?

• Personal and team satisfaction in handing over a good piece of work to the
client
• Complete the course in good style with good grade
• A clean handover without loose ends
• A good basis for future involvement with the client, team or this
project
11
11
Final Presentation (2)
Who is the audience? What do they want?

• Clients/Lecturer – Teaching Assistant
• Is it ready for production?
• What has been accomplished? What has been learned?
• Is the client satisfied?
• Are you handing over a maintainable system?
• How much can you cover?
• Show the system in operation
• Be honest about gaps, weaknesses, etc.
• Brief review of goals
• Summary of what is being delivered?
12
12
6
11/25/21
Preparation of Presentation
for IT3180 Project
(end of lecture)
13
13
7
11/26/21
SOICT
1
11/26/21

Engineering
14 – Models for Program Design
Approaches for Program Development
Heavyweight Approach
• Program design and coding are separated
• The design uses class models and other models to specify the program in
detail, before beginning the code
Lightweight Approach
• Program design and coding are intertwinned
• The development is iterative
Mixed Approach
• Outline design is created using models, with details worked out
iteratively during work
2
11/26/21
Program Design
The task of Program Design is to represent the software architecture in

the form that can be implemented as one or more executable programs
Given a system architecture, the program design specifies:

• Programs, components, packages, classes, class hierarchies, etc.
• Interfaces, protocols (which may be not part of system architecture)
• Algorithms, data structures, security mechanism, operational
procedures
UML Models
Models used for requirements
• Use case diagram shows a set of use cases and actors and their
relationships
Models used for system architecture:
• Component diagram shows the organization and dependencies among
a set of components
• Deployment diagram shows the configuration of processing nodes and
the components living on them
Models used for program design
• Class diagram shows a set of classes, interfaces, and collaborations
with their relationships
• Object Diagram or Sequence Diagram show a set of objects and their
relationships 6
3
11/26/21
Class Diagram
A class is a description of a set of objects that share the same attributes

methods, relationships and semantics
Example: The “Hello World” Applet
4
11/26/21
Example (2) – The Hello World Class
Notation: Relationships
10
10
5
11/26/21
Example (3) – The Hello World Class Diagram
11
11
Notation: Association
An association is a structural relationship that describes a set of links,

a link being a connection among objects
Employer Employee
12
12
6
11/26/21
Notation: Association
A Parking Lot associates to one or many Parking Spaces
13
13
Which classes to be used?
• Given a case study, how do you decide what classes to use?

Step 1: Identify a set of candidate classes that represent the system
design
• What terms do the users and developers use to describe the system?
These terms are candidates for classes
• Is each candidate class crispy defined?
• For each class, what is its set of responsibilities? Are the
responsibilities evenly balanced among the classes?
• What attributes and methods does each class need to carry out its
responsibilities?
14
14
7
11/26/21
Which classes to be used? (2)
Step 2: Modify the set of classes

Goals:
• Improve the clarity of design
• If the purpose of each class is clear, with easily understood methods and
relationships, developers are likely to write simple code, which future
maintainers can understand and modify
• Increase the coherence within classes and lower the coupling
between classes
• Aim for high cohesion within classes and weak coupling between them
15
15
Application Classes and Solution Classes
A good design is often a combination of application classes and solution

classes
• Application classes represent application concepts
• Noun identification is an effective technique to generate candidate application
classes
• Solution classes represent system concepts
• For example, user interface objects, databases, etc.
16
16
8
11/26/21
Noun Identification
Case study: A library example

• The library contains books and journals. It may have several copies of a
given book. Some of the books are reserved for short-term loans only. All
others may be borrowed by any library member for three weeks. Members
of the library can normally borrow up to six items at a 5me, but members of
staff may borrow up to 12 items at one 5me. Only members of staff may
borrow journals.
• The system must keep track of when books and journals are borrowed and
returned, to enforce the rules.
17
17
Noun Identification
Case study: A library example

• The library contains books and journals. It may have several copies of a
given book. Some of the books are reserved for short-term loans only. All
others may be borrowed by any library member for three weeks. Members
of the library can normally borrow up to six items at a 5me, but members
of staff may borrow up to 12 items at one 5me. Only members of staff may
borrow journals.
• The system must keep track of when books and journals are borrowed and
returned, to enforce the rules.
18
18
9
11/26/21
Candidate Classes
19
19
Relation between classes
20
20
10
11/26/21
Methods
21
21
Class Diagram (1)
22
22
11
11/26/21
From Candidate Classes to Completed Design
Methods used to move to final design

• Reuse
• Wherever possible use existing components, or class libraries. They may need
extensions.
• Restructuring
• Change the design to improve understandability, maintainability, etc.
• Techniques include merging similar classes, splitting complex classes, etc.
• Optimization
• Ensure that the system meets anticipated performance requirements, e.g., by
changed algorithms or restructuring
• Completion
• Fill all gaps, specify interfaces, etc.
23
23
Modelling dynamic aspects of the system
• Interaction diagrams
• Show set of objects and their relationships including messages that
may be dispatched among them
• Sequence diagram: time ordering of messages
24
24
12
11/26/21
Interaction
Example: execution of an HTTP get command
25
25
UML Notations for Class and Object
26
26
13
11/26/21
Actions on Objects
27
27
Sequence Diagram: Borrow a copy of a book
28
28
14
11/26/21
Exercise: Sequence Diagram for Online Shopping
Use Case Meta-data for Online Shopping

1. Customer browses through catalog and select items to buy
2. Customer goes to checkout
3. Customer fills out shipping information
4. System presents full pricing information, including shipping
information
5. Customer fills in credit card information
6. System authorizes purchase
7. System confirms sale immediately
8. System sends confirming email to customer
29
29
Exercise (2): Identify candidate classes for this scenario
• Application classes:
• Customer
• Catalog
• Item/Product
• Order
• Purchased Item
• System classes:
• User Interface
• Purchase Interface
• Browse Interface
• Check Out
• Credit Card Authorization
• Item, Purchased Item
30
30
15
11/26/21
Class Diagram
31
31
Sequence Diagram
32
32
16
11/26/21
14 – Models for Program Design

(end of lecture)
33
33
17
12/13/21
SOICT
1
12/13/21

Engineering
15 – Reuse and Design Patterns
Software Reuse
It is good to design a program to reuse existing components. This can lead

to better software at lower cost.
Potential benefits of reuse
• Reduced development time and cost
• Improved reliability of mature components
• Shared maintenance cost
Potential disadvantages of reuse
• Difficulty in finding appropriate components
• Components may be a poor fit for application
• Quality control and security may be unknown
2
12/13/21
Evaluating Software
• It is impossible to remove all bugs from software, even a well-

established software
• Maintenance
• Is the software supported by an organization that will continue maintenance
over the long term?
Design For Change: Replacement of Components (1)

The software design should anticipate possible changes in the system
over its life-cycle
New vendor or new technology
• Components are replaced because its supplier goes out of business
• Components from other source provide better functionality, support,
pricing, etc.
• This can apply to either open source or vendor-supplied components
3
12/13/21

over its life-cycle
New Implementation
• The original implementation may be problematic
• Poor performance
• Inadequate backup and recovery
• Unable to support growth and new features added to the system

over its life-cycle
Additions to the requirements
• When the system goes into production, it is usual to reveal both
weakness and opportunities for extra functionality and enhancement
to the user interface design
• For example, in data-driven application, it is almost certain that there
will be requests for extra reports and ways of analyzing the data
Request for enhancements are often the sign of a successful system.

Clients recognize latent possibilities
4
12/13/21

over its life-cycle
Changes in the application domain
• Most application domains change continually
• Because of business opportunities
• External changes (such as new laws)
• New group of users
• New technology
• It is rarely feasible to implement a completely new system when the
application domain changes
èExisting system must be modified
èThis may involve extensive restructuring, but it is important to reuse
existing code as much as possible
9
Design Patterns
• Design Patterns are template designs that can be used in a variety of

systems
• They are particularly appropriate in situations where classes are likely
to be reused in a system that evolves over time
Sources:
• E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994
• Wikipedia has good discussion of many design patterns, using UML
and other notation, with code samples.
10
10
5
12/13/21
Inheritance and Abstract Class
• Design patterns make extensive use of inheritance and abstract

classes
• Classes can be defined in terms of other classes through inheritance
• Generalization classes – super classes
• Specialization classes – subclasses
• Abstract classes
• Super classes which contain abstract methods and are defined such that
concrete subclasses extend them by implementing the abstract methods
• May have not abstract methods, in this case, the intention is to prevent the
creation of instances
• Interface classes are abstract classes but for multi-inheritances and for
specifying a standard protocols for all classes that realize them
11
11
Inheritance and Abstract Class (2) - Example
12
12
6
12/13/21
Delegation
• A class is said to delegate to another class if it implements an operation

by resending a message to another class.
• Delegation is an alternative to inheritance that can be used when reuse
is anticipated.
13
13
Delegation (2)
Delegation is like inheritance done manually through object composition
14
14
7
12/13/21
Delegation (3) - Example
• Case study: a cat’s sound behavior - ”meow” and “roar”
• How to compose the behavior of Cat at runtime?

Inheritance or Delegation?
15
15
Delegation (4) - Example
• Delegation makes it easy to compose behaviors at runtime
16
16
8
12/13/21
Delegation (5) – Example Source Code
17
17
Delegation (6) – Example Source Code
18
18
9
12/13/21
Notation
19
19
Strategy Pattern
Encapsulating Algorithms
20
20
10
12/13/21
Problematic
• To solve a specific
problem, there may be a
family of algorithms
• Each algorithm is
separated in a class called
strategy
• The client will decide
which strategy will be
selected
21
21
Strategy Pattern - Structure
22
22
11
12/13/21
Strategy Pattern - Components
• The Context maintains a reference to one of the concrete strategies

through the strategy interface
• The Strategy interface is common to all concrete strategies. It declares
the methods which are used by the Context
• Concrete Strategies implement different variations of an algorithm the
Context uses
• The Client creates a specific strategy object and passes it to the
Context
23
23
Case Study in many software projects
• Payment method in an e-commerce application

• There are various payment methods in an e-commerce application.
After selecting a product to purchase, a customer picks a payment
method: either Paypal or Credit Card.
• MoMo and ZaloPay are considered in the future
24
24
12
12/13/21
25
25
Observer
Pattern
Subscriber-Publisher
26
26
13
12/13/21
Problematic
• To define a subscription
mechanism to notify
multiple objects about any
events that happen to the
object they are observing
• Event-Subscriber
• Listener
27
27

• The customer want to be
notified about a new coming
product
• Notify a set of customers
about new events, new
vouchers
• An admin want to associate a
discount/coupon with
multiple product. Any
changes in discount/coupon
must be notified to its
associated products
28
28
14
12/13/21
Observer Pattern Structure
• Add a subscription mechanism to the publisher so individual object can

subscribe to or unsubscribe from a stream of events coming
• subscribers: a list of subscribers of the publisher
29
29
Observer Pattern Structure (2)
• notifySubscribers(): the notification

mechanism of publisher to inform
subscribers about new events
30
30
15
12/13/21
Observer
Pattern
Structure (3)
31
Case study: ecommerce
• Whenever an user make a new purchase, he or she will receive a

notification about the order.
• Notification mechanisms: email, SMS, PhoneCall
• What plays the role of Publisher?

• What are Observers?
32
32
16
12/13/21
Solution
33
33
State Pattern
34
34
17
12/13/21
Problematic
• State is a behavior pattern
• Allow an object to alter its
behavior when its internal
state changes
• Closely related to the
concept of Finite State
Machine
35
35
Case study in many projects
• When a new order is created, the users should view the state of the
order
• When the state of an order is changed, some actions will be fired!
36
36
18
12/13/21
State Structure
• Context: the object which has a

reference to one of its state and
a mechanism to prceess
whenever there is a change of
its state (changeState)
• abstract State: state specific
methods
• concrete States: specific
implementation for state
methods, has a reference back
to the context
37
37
Case study
• Order states follow a finite-state

machine diagram
• Which is the Context object?

• What are states objects?
38
38
19
12/13/21
Solution
39
39
15 – Reuse and Design Pattern

(end of lecture)
40
40
20
12/20/21
SOICT
1
12/20/21

Engineering
16 – Verification and Testing
Testing
• A software test executes a program to determine whether a property of

the program holds or doesn’t hold
• A test passes [fails] if the property holds [doesn’t hold] on that run
• “[T]he means by which the presence, quality, or genuineness of anything is

determined; a means of trial.” –dictionary.com
2
12/20/21
Software Quality Assurance
• Static analysis (assessing code without executing it)

• Proofs of correctness (theorems about program properties)
• Code reviews (people reviewing others’ code)
• Software process (placing structure on the development lifecycle)
• …and many more ways to find problems and to increase confidence
V Model – Different levels of Test

• Unit test: ONE module at a time
• Integration test: The linking modules
• System test: The whole (entire) system
• Acceptance test: test from the user point of view
3
12/20/21
Test Levels – Unit Testing

• Unit Testing: Does each unit (class, method, etc.) do what it supposed
to do?
• Smallest programming units
• Approaches: Black box and white box testing
• Techniques, Tools
Test Levels – Integration Testing
• Integration Testing: do you get the expected results when the parts are
put together?
• Approaches: Bottom-up, top-down testing
• Acceptance Testing: does it match to user needs?
4
12/20/21
Test Levels – System Testing
• System Testing: does it work within the overall system?

• Approaches: Black box testing
Terms
10
10
5
12/20/21
Terms (2)
• Test case
• a set of conditions/variables to determine whether a system under
test satisfies requirements or works correctly
• Test suite
• a collection of test cases related to the same test work
• Test plan
• a document which describes testing approach and methodologies
being used for testing the project, risks, scope of testing, specific
tools
11
11
Test suite
• Example of test suite

• Test case 1: Login
• Test case 2: Add New Products
• Test case 3: Checkout
• Test case 4: Logout
12
12
6
12/20/21
Integration Testing (1)
Examine the interface between modules as well as the input and output
• Stub/Driver:
• A program that simulates functions of a lower-level/upper-level module
13
13
Integration Testing (2) – Top-down Approach
• Defects based on misunderstanding of specification can be detected

early
• Effective in newly developed systems
• Need test stubs (can be simply
returning a value)
14
14
7
12/20/21
Integration Testing (2) – Bottom-up Approach
• Lower modules are independent => test independently and on a

parallel
• Effective in developing systems by modifying existing systems
• Need test drivers (more complex with controlling)
15
15
Other integration test techniques
• Big-bang test
• Wherein all the modules that have completed the unit tests are linked all
at once and tested
• Reducing the number of testing procedures in small-scale program; but
not easy to locate errors
• Sandwich test
• Where lower-level modules are tested bottom-up and higher-level
modules are tested top-down
16
16
8
12/20/21
Regression test
“When you fix one bug, you introduce several new bugs”
• Re-testing an application after its code has been modified to verify that
it still functions correctly
• Re-running existing test cases
• Checking that code changes did not break any previously working functions
(side-effect)
• Run as often as possible
• With an automated regression testing tool
17
17
Test-case Design Techniques
A. Choose input data (“test inputs”)

B. Define the expected outcome (“soict”)
C. Run the unit (“SUT” or “software under test”) on the input and
record the results
D. Examine results against the expected outcome (“soict”)
Specification
Precondition Postcondition
Implementation
Black box White box
Must choose inputs without Can choose inputs with
knowledge of the knowledge of the
implementation implementation
18
18
9
12/20/21
Black-box vs. White box
White box
Black box
Can choose inputs with knowledge of the
Must choose inputs without knowledge of the
implementation
implementation
• Has to focus on the • Common use: coverage

behavior of the SUT • Basic idea: if your test
• Needs an “soict” suite never causes a
• Or at least an statement to be executed,
expectation of then that statement might
whether or not an be buggy
exception is thrown
19
19
Unit & System Testing Techniques
For test case design

• Test Techniques for Black Box Test
• Equivalence Partitioning Analysis
• Boundary-value Analysis
• Decision Table
• Use Case-based Test
• Test Techniques for White Box Test
• Control Flow Test
• Data flow testing
• Predicate testing
20
20
10
12/20/21
White-box
Testing
21
21
Whitebox testing techniques
• Control Flow Testing

• All-paths testing
• Statement testing
• Branch testing
• Data Flow Testing
• All-defs coverage
• All-uses coverage
22
22
11
12/20/21
Control Flow Graph
• Represent the graphical structure of a program unit

CFG symbols
• A sequence of statements from entry point to exit point of the unit
4.3 CONTROL FLOW GRAPH 91
True False
Computation Decision
Sequential computation Decision point Merge point
Figure 4.2 Symbols in a CFG.
computation. A maximal sequential computation can be represented either by23a

single rectangle or by many rectangles, each corresponding to one statement in the
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
23 source code.
We label each computation and decision box with a unique integer. The two
branches of a decision box are labeled with T and F to represent the true and false
evaluations, respectively, of the condition within the box. We will not label a merge
node, because one can easily identify the paths in a CFG even without explicitly
Control Flow Testing
considering the merge nodes. Moreover, not mentioning the merge nodes in a path
will make a path description shorter.
We consider the openfiles() function shown in Figure 4.3 to illustrate the
• Main idea: select a few
process pathsain
of drawing a program
CFG. The functionunit andstatements:
has three observeanwhether or
assignment state-
not the selected paths produce the expected outcome
ment int i = 0;, a conditional statement if(), and a return(i) statement. The reader
may note that irrespective of the evaluation of the if(), the function performs the
• Executing a fewsame
paths while
action, trying
namely, toFigure
null. In assess
4.4, the behavior
we show of the
a high-level entire of
representation
White-Box Testing (Ch 4, 5)
program unit
Exhaustive Testing
FILE *fptr1, *fptr2, *fptr3; /* These are global variables. */
If-then-else There are many possible paths!
int openfiles(){
/* 520 (~1014 ) different paths
This function tries to open files "file1", "file2", and
"file3" for read access, and returns the number of files
successfully opened. The file pointers of the opened files
are put in loop the
< 20x global variables.
*/
int i = 0;
if( Selective Testing
((( fptr1 = fopen("file1", "r")) != NULL) && (i++)
&& (0)) ||
((( fptr2 = fopen("file2", "r")) != NULL) && (i++) 24
&& (0)) ||
24 ((( fptr3 = fopen("file3", "r")) != NULL) && (i++))
);
return(i);
}
Figure 4.3 Function to open three files. 12

12/20/21
Outline of Control Flow Testing

90 CHAPTER 4 CONTROL FLOW TESTING
• Inputs Path
selection
• Source code of unit
Work criteria
• Path selection criteria

process
• Generate CFG: draw Program
unit
Draw a
control flow Control
flow graph
Select
paths
Selected
paths
graph
CFG from source code
of the unit Inputs
Generate
• Selection of paths: test input
data
selected paths to
satisfy path selection Are
criteria No the selected

paths
feasible?
• Generation of test Yes
input data Process of generating test input data
Fig 4.1 Output Test input

data 25
25 Figure 4.1 Process of generating test input data for control flow testing.
Selection of Paths: Paths are selected from the CFG to satisfy the path selec-
tion criteria, and it is done by considering the structure of the CFG.
Generation of Test Input Data: A path can be executed if and only if a
certain instance of the inputs to the program unit causes all the conditional
Path selection criteria statements along the path to evaluate to true or false as dictated by the
control flow. Such a path is called a feasible path. Otherwise, the path is
said to be infeasible. It is essential to identify certain values of the inputs
from a given path for the path to execute.
• Example: Feasibility Test of a Path: The idea behind checking the feasibility of a
selected path is to meet the path selection criteria. If some chosen paths
• Given the source code of the function AccClient
are found to be infeasible, then new paths are selected to meet the criteria.
• Draw the CFG
4.3 CONTROL FLOW GRAPH
Life Insurance Example
A CFG is a graphical representation
1
of a program unit. Three symbols are used
Age, Gender
to construct a CFG, as shown in Figure 4.2. A rectangle represents a sequential
2
bool AccClient(agetype T if(female) F
age; gndrtype gender) T 3 F

Age <85
bool accept T 4
Age <80
F
if(gender=female)
accept := age < 85;
Accept = true 5 Accept = false 6
else
accept := age < 80;
Return accept 7
return accept
26
26
13
12/20/21
All path coverage
• Objective: Design all possible test cases so that all paths of the
program are executed
• 4 test cases satisfy the all paths coverage criterion
All paths
Female Age < 85 Age < 80
Age, Gender 1
Yes Yes Yes
Yes Yes No
2
Yes No Yes T if(female) F
Yes No No
T 3 F
No Yes Yes Age <85
4
T F
No Yes No Age <80
No No Yes
No No No
<Yes,Yes,*> 1-2(T)-3(T)-5-7
<Yes,No,No> 1-2(T)-3(F)-6-7 Return accept 7
<No,Yes,Yes> 1-2(F)-4(T)-5-7
<No,*,No> 1-2(F)-4(F)-6-7
27
27
Statement Coverage
• Main idea: Execute each statement at least once

• A possible concern may be:
Statement Coverage
• dead code
bool AccClient(agetype
1
age; gndrtype gender) Age, Gender
bool accept 2
T if(female) F
if(gender=female)
3
accept := age < 85; T
Age <85
F
4
F
else T
Age <80
accept := age < 80;

6
return accept Accept = true
5
Accept = false
AccClient(83, female)->accept Return accept

7
AccClient(83, male) ->reject

28
28
14
12/20/21
Branch coverage
• Also called Decision Coverage

• A branch is an outgoing edge from a node
• A rectangle node has at most one out going branch
• All diamond nodes have 2 outgoint branches
• A decision element in a program may be one of
• If – then
• Switch – case
• Loop
• Main idea: selecting paths such that every branch is included in at least
one path
29
29
Example
AccClient(83,
Branch Coverage /1 female)->accept
Age, Gender 1
age; gndrtype gender) 2
T if(female) F
bool accept
if(gender=female) T 3
Age <85
F
4 F
Age <80
true
else
accept := age < 80; Accept = true 5 Accept = false6
return accept
Return accept 7
30
30
15
12/20/21
Example
AccClient(83, male)
Branch Coverage /2 ->reject
Age, Gender 1
age; gndrtype gender)
T if(female) 2 F
bool accept
Age <85
F
T 4 F
accept := age < 85; Age <80
else
accept := age < 80; Accept = true 5 Accept = false 6
false
return accept
Return accept 7
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group 31
31
Example
AccClient(78, male)-
Branch Coverage /3 >accept
bool AccClient(agetype Age, Gender 1
age; gndrtype gender)

T if(female) 2 F
bool accept
Age <85
F
4 F
Age <80
true
else
accept := age < 80;
true
return accept
Return accept 7
32
32
16
12/20/21
Example
AccClient(88,
Branch Coverage /4 female) ->reject
bool AccClient(agetype Age, Gender 1
age; gndrtype gender) 2

bool accept T if(female) F
if(gender=female) T 3 F
Age <85
accept := age < 85; T 4
Age <80
F
false
else
accept := age < 80;
false Accept = true 5 Accept = false 6
return accept
Return accept 7
33
33
Comparing 3 criteria
• (1) All path coverage: assure 100% paths executed

• (2) Statement coverage: pick enough paths to assure that every source
statement is executed at least once
• (3) Branch coverage: assure that every branch has been exercised at
least once under some test
• (1) implies (3), (3) implies (2)
• These 3 criteria are also called as Path Testing Techniques
34
34
17
12/20/21
Example 2: Exponential Function
35
35
Limitations of path testing
• Path Testing is applicable to new unit

• Limitations
• Interface mismatches and mistakes are not taken
• Not all initialization mistakes are caught by path testing
• Specification mistakes are not caught
36
36
18
12/20/21
Black-box
Testing
37
37
Black-box Techniques
• Equivalence Partitioning
• Boundary Analysis
• Table Decision
38
38
19
12/20/21
Equivalence Partitioning
• Create the encompassing test cases by analyzing the input data space
and dividing into equivalence classes
• Input condition space is partitioned into equivalence classes
• Every input taken from a equivalence class produces the same result
39
39
Example: Examination Judgment Program
• Program Title: “Examination Judgment Program”

• Subject: Two subjects as Mathematics, and Physics Judgment
• Specification:
• Passed if
• scores of both mathematics and physics are greater than or equal to 70 out of 100
or,
• average of mathematics and physics is greater than or equal to 80 out of 100
• Failed => Otherwise
40
40
20
12/20/21
Example: Examination Judgment Program (2)
• How many equivalent classes?

Score of Average Score
Physics. is 80.
100
(2)
(5)
(1)
Score Math. Physics Result

80
(4)
70
(3) (1) 55 85 Failed
60
Average (2) 67 97 Passed
(3) 96 68 Passed
Score
is 80.
40
(7) (6) (4) 77 80 Passed
(5) 85 92 Passed
20 (6) 79 58 Failed
Score of (7) 52 58 Failed
Math.
0 20 40 60 70 80 100
41
41
Equivalence Partitioning - Discussion
• What’s about invalid data of the input?
• (8) Math = -15, Physics = 120 Both score are invalid.

• (9) Math = 68, Physics = -66 Physics score is invalid.
• (10) Math = 118, Physics = 85 Math score is invalid.
42
42
21
12/20/21
(8) Average Score

is 80.
Some invalid data are added.
100
(2)
Score of
Physics.
(1)
(5) (10) Score Math. Physics Result
80 (1) 55 85 Failed
(4)
70 (2) 67 97 Passed
(3)
60 (3) 96 68 Passed
Average
Score (4) 77 80 Passed
(5) 85 92 Passed
is 80.
40
(6) 79 58 Failed
(7) (6)
(7) 52 58 Failed
(8) -15 120 Invalid
20
Score of
Math. (9) 68 -66 Invalid
0 20 40 60 70 80 100
(10) 118 85 Invalid
(9)
43
43
Table Decision
• Relations between the conditions for and the contents of the

processing are expressed in the form of a table
• A decision table is a tabular form tool used when complex conditions
are combined
• Example: The conditions for creating reports from employee files
Under age 30 Y Y N N
Male Y N Y N
Married N Y Y N
Output Report 1 - X - -
Output Report 2 - - - X
Output Report 3 X - - -
Output Report 4 - - X -
44
44
22
12/20/21
• Condition1: Mathematics score=>70

• Condition2: Physics score=>70
• Condition3: Average of Mathematics, and Physics =>80
----------------- TC5------TC4------TC3------ TC6------TC2------TC1-------TCNG------------TC7
Condition1 True True True True False False False False
Condition2 True True False False True True False False
Condition3 True False True False True False True(none) False
--------------------------------------------------------------------------------------------------------------------------------------
-
“Passed” Yes Yes Yes --- Yes --- N/A --
“Failed” --- --- --- Yes --- Yes N/A Yes
45
45
• Invalid input data (integer)

• Condition4: Mathematics score = valid that means “0=< the score =< 100”
• Condition5: Physics score = valid that means “0=< the score =< 100”
--------------------------------TCI1----------TCI2--------TCI3----------TCI4--------
Condition4 Valid Invalid Valid. Invalid
Condition5 Valid Valid Invalid Invalid
-------------------------------------------------------------------------------------------
“Normal results” Yes --- --- ---
“Error message math” --- Yes --- Yes
“Error message phys” --- --- Yes Yes
If both of mathematics score and physics score are invalid è Two messages are expected to be
output. Is it correct specifications?
46
46
23
12/20/21
Create Test case from Use case
• Identify all of the scenarios for the given use case

• Alternative scenarios should be drawn in a graph fo each action
• Create scenarios for
• a basic flow,
• one scenario covering each alternative flow,
• and some reasonable combinations of alternative flows
• Create infinite loops
47
47
Test case for UC “Login”
• “Thành công”
• Mã PIN đúng
• “Thất bại”
• Mã PIN sai và số lần sai < 3
• “Khoá tài khoản”
• Mã PIN sai và số lần sai >= 3
Mã PIN đúng Y Y N N
Số lần sai < 3 Y N Y N
“Thành công” x N/A - -
“Thất bại” - N/A x -
“Khoá tài khoản” - N/A - x
48
48
24
12/20/21

(end of lecture)
49
49
25
SOICT
Engineering
17 – Configuration Management
Content
1. Changes and Software Configuration

2. Software Configuration Management
3. SCM Process
4. Version Control
4
5
Changes and Software Configuration
The “First Law”
No matter where you are in the system

life cycle, the system will change, and the
desire to change it will persist throughout
the life cycle.
Bersoff, et al, 1980
Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
6
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
user requirements other
documents
software models
Project
Plan
data
Test
code
7
The Software Configuration
programs documents
The pieces
data
8
• The IEEE (IEEE Std. No. 610.12-1990) defines a

baseline as:
A specification or product that has been formally
reviewed and agreed upon, that thereafter serves as
the basis for further development, and that can be
changed only through formal change control
procedures.
• a baseline is a milestone in the development of
software that is marked by the delivery of one or
more software configuration items and the
approval of these SCIs that is obtained through a
formal technical review
9
Baselines
10
Software Configuration Objects
11
Software Configuration Management
SCM Repository
• The SCM repository is the set of mechanisms
and data structures that allow a software team to
manage change in an effective manner
• The repository performs or precipitates the
following functions [For89]:
• Data integrity
• Information sharing
• Tool integration
• Data integration
• Methodology enforcement
• Document standardization
12
Repository Content
13
Repository Features
• Versioning.
• saves all of these versions to enable effective management of product
releases and to permit developers to go back to previous versions
• Dependency tracking and change management.
• The repository manages a wide variety of relationships among the data
elements stored in it.
• Requirements tracing.
• Provides the ability to track all the design and construction components
and deliverables that result from a specific requirement specification
• Configuration management.
• Keeps track of a series of configurations representing specific project
milestones or production releases. Version management provides the
needed versions, and link management keeps track of interdependencies.
• Audit trails.
• establishes additional information about when, why, and by whom
changes are made.
SCM Elements
Component elements—a set of tools coupled within a file management system (e.g.,
a database) that enables access to and management of each software configuration
item.
Process elements—a collection of procedures and tasks that define an effective
approach to change management (and related activities) for all constituencies
involved in the management, engineering and use of computer software.
Construction elements—a set of tools that automate the construction of software by
ensuring that the proper set of validated components (i.e., the correct version) have
been assembled.
Human elements—to implement effective SCM, the software team uses a set of tools
and process features (encompassing other CM elements)
15
SCM Process
Addresses the following questions …

• How does a software team identify the discrete elements of a
software configuration?
• How does an organization manage the many existing versions of a
program (and its documentation) in a manner that will enable
change to be accommodated efficiently?
• How does an organization control changes before and after software
is released to a customer?
• Who has responsibility for approving and ranking changes?
• How can we ensure that changes have been made properly?
• What mechanism is used to appraise others of changes that are
made?
16
17
SCM Process
Change Control
STOP
18
SCM Process
Change Control Process—I

need for change is recognized
change request from user
developer evaluates
change report is generated
change control authority decides
request is queued for action

change request is denied
user is informed
change control process—II
19
SCM Process
Change Control Process-II
assign people to SCIs
check-out SCIs
make the change
review/audit the change
establish a “baseline” for testing
change control process—III
20
SCM Process
Change Control Process-III

perform SQA and testing activities
check-in the changed SCIs
promote SCI for inclusion in next release
rebuild appropriate version
review/audit the change
include all changes in release
SCM Process
Version Control
• Version control combines procedures and tools to manage different versions
of configuration objects that are created during the software process
• A version control system implements or is directly integrated with four
major capabilities:
• a project database (repository) that stores all relevant configuration objects
• a version management capability that stores all versions of a configuration object (or
enables any version to be constructed using differences from past versions);
• a make facility that enables the software engineer to collect all relevant
configuration objects and construct a specific version of the software.
• an issues tracking (also called bug tracking) capability that enables the team to
record and track the status of all outstanding issues associated with each
configuration object.
22
SCM Process
Configuration Auditing
Change
Requests SQA
Plan
SCIs
SCM Audit
23
SCM Process
Status Accounting
Change
Change
Reports
Requests ECOs
SCIs
Status Accounting
Reporting
24
SCM Process
SCM for Web Engineering-I

• Content
• A typical WebApp contains a vast array of content—text, graphics,
applets, scripts, audio/video files, forms, active page elements, tables,
streaming data, and many others.
• The challenge is to organize this sea of content into a rational set of
configuration objects (Section 27.1.4) and then establish appropriate
configuration control mechanisms for these objects.
• People
• Because a significant percentage of WebApp development continues to
be conducted in an ad hoc manner, any person involved in the WebApp
can (and often does) create content.
25
SCM Process
SCM for Web Engineering-II

• Content
• As size and complexity grow, small changes can have far-reaching
and unintended affects that can be problematic. Therefore, the
rigor of configuration control mechanisms should be directly
proportional to application scale.
• Politics
• Who ‘owns’ a WebApp?
• Who assumes responsibility for the accuracy of the information on
the Web site?
• Who assures that quality control processes have been followed
before information is published to the site?
• Who is responsible for making changes?
• Who assumes the cost of change?
26
Content Management-I
• The collection subsystem encompasses all actions required to create and/or
acquire content, and the technical functions that are necessary to
• convert content into a form that can be represented by a mark-up language
(e.g., HTML, XML
• organize content into packets that can be displayed effectively on the client-
side.
• The management subsystem implements a repository that encompasses the
following elements:
• Content database—the information structure that has been established to
store all content objects
• Database capabilities—functions that enable the CMS to search for specific
content objects (or categories of objects), store and retrieve objects, and
manage the file structure that has been established for the content
• Configuration management functions—the functional elements and
associated workflow that support content object identification, version
control, change management, change auditing, and reporting.
27
Content Management-II
• The publishing subsystem extracts from the repository, converts it to a

form that is amenable to publication, and formats it so that it can be
transmitted to client-side browsers. The publishing subsystem
accomplishes these tasks using a series of templates.
• Each template is a function that builds a publication using one of three
different components [BOI02]:
• Static elements—text, graphics, media, and scripts that require no
further processing are transmitted directly to the client-side
• Publication services—function calls to specific retrieval and formatting
services that personalize content (using predefined rules), perform data
conversion, and build appropriate navigation links.
• External services—provide access to external corporate information
infrastructure such as enterprise data or “back-room” applications.
28
Content Management
29
Change Management for WebApps-I
30
Change Management for WebApps-II
31
4. Version Control
32
4.1. Why version control?
• Scenario 1:
• Your program is working
• You change “just one thing”
• Your program breaks
• You change it back
• Your program is still broken--
why?
• Has this ever happened to

you?
33
Why version control?
• Your program worked well

enough yesterday
• You made a lot of
improvements last night...
• ...but you haven't gotten them
to work yet
• You need to turn in your
program now
• Has this ever happened to

you?
34
Version control for teams
•Scenario:
• You change one part of a
program--it works
• Your co-worker changes
another part--it works
• You put them together--it
doesn’t work
• Some change in one part
must have broken
something in the other part
• What were all the changes?
35
Version control for teams
• Scenario:
• You make a number of
improvements to a class
• Your co-worker makes a
number of different
improvements to the same class
• How can you merge these
changes?
36
Tools: diff
• There are a number of tools
that help you spot changes
(differences) between two
files
• Tools include diff, rcsdiff,
jDiff, etc.
• Of course, they won't help
unless you kept a copy of the
older version
• Differencing tools are useful
for finding a small number of
differences in a few files
37
Tools: jDiff
• jDiff is a plugin for the jEdit editor

• Advantages:
• Everything is color coded
• Uses synchronized scrolling
• It's inside an editor--you can make changes directly
• Disadvantages:
• Not stand-alone, but must be used within jDiff
• Just a diff tool, not a complete solution
38
Tools: jDiff
39
Version control systems

• A version control system (often called a source code control
system) does these things:
• Keeps multiple (older and newer) versions of everything (not just
source code)
• Requests comments regarding every change
• Allows “check in” and “check out” of files so you know which files
someone else is working on
• Displays differences between versions
40
4.2. Versioning Models
•Lock-Modify-Unlock
•Copy-Modify-Merge
41
a. The Lock-Modify-Unlock Model
The Lock-Modify-Unlock Model (1)

Andy and Bobby
check-out file A.
Repository
The check-out is done
without locking. They A
just get a local copy. Check-out
Check-out
A
Bobby
Andy
3
42
a. The Lock-Modify-Unlock Model (2)
Andy locks file A and Repository

begins modifying it.
A
Lock
A
Аndy
(Local Edit)
Bobby
Andy
33
43
Bobby tries to lock the

file too, but she can’t. Repository
Bobby waits for Andy to

A
finish and unlock the file. Wait
Andy
Bobby
Andy
34
44

Andy commits his changes Repository

and unlocks the file. Andy
Commit
A
Andy
Bobby
Andy
35
45
Now Bobby can take the

modified file and lock it. Repository
Bobby edits her local Andy
copy of the file. Lock
Andy
Andy
(Local Edit)
Bobby
Andy
36
46

e Lock-Modify-Unlock Model (6)
Bobby finishes,
Repository
commits her changes
and unlocks the file. Andy
Bobby
Commit
Andy
Bobby
Andy
Bobby
Andy
47
a. The Lock-Modify-Unlock
e Lock-Modify-Unlock Model Model
(7) (7)
Andy updates the

Repository
changes from the
repository. Andy
Bobby
Update Andy
Bobby
Andy
Bobby
Bobby
Andy
48
b. The Copy-Modify-Merge Model

he Copy-Modify-Merge Model (1)
Andy and Bobby
check-out a file A.
Repository
The check-out is
done without A
locking. Check-out
Check-out
A
Bobby
Andy
49
b. The Copy-Modify-Merge Model (2)

e Copy-Modify-Merge Model (2)
Both of them
edit the local
Repository
copies of the
file (in the A
same time).
Bobby
Andy
(Local Edit)
(Local Edit)
Bobby
Andy
50

Bobby commits Repository

her changes to
the repository. Bobby Commit
Bobby
Andy
Bobby
Andy
51

Andy tries to
commit his Repository
changes.
Bobby
A conflict occurs.
Commit Bobby
Bobby
Andy
Andy
(Local
Conflict) Bobby
Andy
52
The Copy-Modify-Merge Model (5)

Andy updates his
changes with the ones
from the repository. Repository
The changes merge
into his local copy. Bobby
A merge conflict can

occur. Bobby
Andy
&
Bobby
(Local
Merge) Bobby
Andy
53

Andy commits the
merged changes to
the repository. Repository
A common version Andy
with the changes of &
Andy and Bobby is Bobby
inserted. Commit Bobby
Andy
&
Bobby
Bobby
Andy
54

Bobby updates the
changes from the
repository. Repository
She gets the common Andy
version with both & Update
changes from Andy Bobby
Andy
and Bobby. &
Bobby
Andy
&
Bobby
Bobby
Andy
46
55
4.3. Central vs. Distributed version control
• version control
• Only one repository
Centralized Version Control
Source: http://homes.cs.washington.edu/~mernst/advice/version-control.html 22
56
Distributed Version Control
Distributed Version Control
Source: http://homes.cs.washington.edu/~mernst/advice/version-control.html 23
57
Distributed Version Control (1)

Andy and Bobby
clone the remote
repository locally. Remote
Repository
They both have the (Server)
A
same files in their
local repositories.
Clone Clone
A A
Local Local
Repository Repository
(Andy) (Bobby)
Andy
Bobby
58

stributed Version Control (2)
Andy and Bobby Remote

work locally on a Repository
(Server)
certain file A. A
(Local Edit)
(Local Edit) Andy Bobby
A A
Local Local
(Andy) (Bobby)
Andy
Bobby
59

Andy and Bobby
commit locally the Remote
modified file A Repository
(Server)
into their local A
repositories.
Commit (locally) Commit (locally)
Andy Andy Bobby Bobby
Local Local
(Andy) (Bobby)
Andy
Bobby
60

Andy pushes the
file A to the remote Remote
repository. Repository
(Server)
Still no conflicts Andy
occur.
Push
Local Local
(Andy) (Bobby)
Andy
Bobby
61

istributed Version Control (5)
Bobby tries to push

her changes. Remote
Repository
A versioning conflict (Server)
Andy
occurs.
Push (conflict)
Local Local
(Andy) (Bobby)
Andy
Bobby
62

Bobby merges the
her local files with
the files from the Remote
Repository
remote repository. (Server)
Andy
Conflicts are locally
resolved.
Pull (Fetch + Merge)

+Andy +Andy
Local Local
(Andy) (Bobby)
Andy
Bobby
63

Bobby commits her Remote

merged changes. Repository
(Server)
No version conflict. Bobby
Andy
+Andy
Push (no conflict)

+Andy +Andy
Local Local
(Andy) (Bobby)
Andy
Bobby
64

Andy pulls
(updates) the Remote
changed files Repository
(Server)
from the remote Bobby
Andy
+Andy
repository.
Pull
Bobby Bobby Bobby Bobby

+Andy +Andy +Andy +Andy
Local Local
(Andy) (Bobby)
Andy
Bobby
65
4.3. Vocabulary
• Repository (source control repository)
• A server that stores the files (documents)
• Keeps a change log
• Revision, Version
• Individual version (state) of a document
that is a result of multiple changes
• Check-Out, Clone
• Retrieves a working copy of the files from a
remote repository into a local directory
• It is possible to lock the files
66
Vocabulary
• Change
• A modification to a local file (document) that is under version
control
• Change Set / Change List
• A set of changes to multiple files that are going to be committed
at the same time
• Commit, Check-In
• Submits the changes made from the local working copy to the
repository
• Automatically creates a new version
• Conflicts may occur!
67
Vocabulary
• Conflict
• The simultaneous change to a certain file by multiple users
• Can be solved automatically and manually
• Update, Get Latest Version, Fetch / Pull
• Download the latest version of the files from the repository to
a local working directory + merge conflicting files
• Undo Check-Out, Revert / Undo Changes
• Cancels the local changes
68
Vocabulary
• Merge
• Combines the changes to a file changed locally and
simultaneously in the repository
• Can be automated in most cases
• Label / Tag
• Labels mark with a name a group of files in a given version
• For example a release
• Branch / Branching
• Division of the repositories in a number of separate
workflows
69
Version Control: Typical Scenario
on Control: Typical Scenario

Users Repository
Main
development Version A Branch
User X line (trunk)
Version A.1 Branch

Check Out
Check In
C A
User Y
B Version B Branch
Check Out
D
Merge E
Check In
70
4.4. Tools
13
• Central version control

• SVN (Subversion)
• TFS
• Source safe (commercial)
• Distributed version control
• Git
• Mercurial
71
What is Git?
• Git
• Distributed source-control system
• Work with local and remote repositories
• Git bash – command line interface for Git
• Free, open-source
• Has Windows version (msysGit)
• http://msysgit.github.io
• https://www.atlassian.com/git/tutorials/setting-up-a-repository
72
Installing Git
• msysGit Installation on Windows

• Download Git for Windows from: http://msysgit.github.io
• “Next, Next, Next” does the trick
• Options to select (they should be selected by default)
• “Use Git Bash only”
• “Checkout Windows-style, commit Unix-style endings”
• Git installation on Linux:
sudo apt-get install git
73
Basic Git Commands
• Cloning an existing Git repository

git clone [remote url]
• Fetch and merge the latest changes from the remote
repository
git pull
• Preparing (adding / selecting) files for a commit
git add [filename] ("git add ."adds everything)
• Committing to the local repository
git commit –m "[your message here]"
74
Basic Git Commands
• Check the status of your local repository (see the local changes)
git status
• Creating a new local repository (in the current directory)
git init
• Creating a remote (assign a short name for remote Git URL)
git remote add [remote name] [remote url]
• Pushing to a remote (send changes to the remote repository)
git push [remote name] [local name]
75
Using Git: Example
mkdir work
cd work
git clone https://github.com/SoftUni/test.git dir
cd test
dir
git status
(edit some file)
git status
git add .
git commit -m "changes"
git push
76
Project Hosting Sites

• GitHub – https://github.com
• The #1 project hosting site in the world
• Free for open-source projects
• Paid plans for private projects
• GitHub provides own Windows client
• GitHub for Windows
• http://windows.github.com
• Dramatically simplifies Git
• For beginners only
77
• Google Code –
http://code.google.com/projecthosting/
• Source control (SVN), file release, wiki, tracker
• Very simple, basic functions only, not feature-
rich
• Free, all projects are public and open source
• 1-minute signup, without heavy approval
process
• SourceForge – http://www.sourceforge.net
• Source control (SVN, Git, ...), web hosting,
tracker, wiki, blog, mailing lists, file release,
statistics, etc
78
• CodePlex – http://www.codeplex.com
• Microsoft's open source projects site
• Team Foundation Server (TFS) infrastructure
• Source control (TFS), issue tracker, downloads, discussions,
wiki, etc.
• Free, all projects are public and open source
• Bitbucket – http://bitbucket.org
• Source control (Mercurial), issue tracker, wiki, management
tools
• Private projects, free and paid editions
79
Bitbucket demo
• Introduction to version control

• https://www.youtube.com/watch?v=gY2JwRfi
n1M
• See Episode 1-> 5
• Bitbucket
• https://www.youtube.com/watch?v=BtEvnE7
9jxY&list=PL57RkP_325rLuT3EmFTf3lkoLw93I
w1_8

(end of lecture)
80
Open questions
1. Here is an activity graph with time estimates for each activity in weeks
(a) For each activity in the graph, calculate the slack

(b) What is the critical path?
(c) Suppose that an extra member of staff is available who can work on
either activity BE or activity BC but not both
i. If she works on activity BE, the time estimate for BE is reduced
from 5 weeks to 3 weeks. How much would the elapsed time to
complete the project be reduced?
ii. If she works on activity BC, the time estimate for BC is reduced
from 9 weeks to 6 weeks. How much would the elapsed time to
complete the project be reduced?

Ilovepdf Merged

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

Ilovepdf Merged

Uploaded by

Copyright:

Available Formats

9/6/21

What is Software Engineering?

• Systematic approach for developing software

• Methods and techniques to develop and maintain quality software to

• Study of the principles and methodologies for developing and

Questions addressed by Software Engineering?

• How do we ensure the quality of the software that we produce?

• How do we meet growing demand and still maintain budget

• How do we avoid disastrous time delays?

Why apply Software Engineering to Systems?

• Provide an understandable process for system development

• Develop systems and software that are maintainable and easily

• Develop robust software system

• Allow the process of creating computing based systems to be

• 1940s: computers invented

• 1950s: assembly language, Fortran

• 1960s: COBOL, ALGOL, PL/1, Operating System

• 1970s: multi-user systems, databases, structured programming

Historical Perspective (cont.)

• 1980s: networking, personal computing, embedded systems, parallel

• 1990s: information superhighway, distributed systems, OO in

• 2000s: virtual reality, voice recognition, video conferencing, global

• 2010s: autonomos vehicles, new security awareness

Hardware costs vs Software costs (% of overall cost)

Why is software so expensive?

Hardware has made great advances

But software too...

Why is software so expensive?

We need softwares because they help us save money...

Imagine: a software system could save a company $10,000/year

So, why couldn’t it charge $9,000?

• Most popular software suites out are software solutions that

Why is software so expensive?

Software is Expensive to Produce

• Labor costs to host hundreds of talented people

Variety of Software Products

• 2 big categories: Application Software vs System Software

The craft of software development

• Client requirements are very different

• There is no standard process for software engineering

• There is no best language, operating system, platform, database

• The craft of software development is

1. Introduction to Software Engineering

Clients - Customers - Users

• Client: a person (or a group of people) for whom the software

Client satisfaction is a primary measure of success

Clients - Customers - Users

• User is a person who actually uses the software

• Example: Many people in our university use Microsoft Team

• Many (probably most) software development projects run into

What is important to the person who is paying?

• Much of software is wasted (perhaps 50% is never used)

The software development team must:

Client satisaction is a primary measurement of success in a

Minimizing Risk: Communication with Client

• Feasibility studies (should we begin the project?)

• Separation of requirements (what the client wants) from design (how

• Milestones (how the developers report or demonstrate progress to

Minimizing Risk: Visibility

However, software developers:

You will make regular progress reports on your projects

Minimizing Risk: Short Development Cycle

Risk is minimized by frequent delivery of working software (weeks rather

This is one of the basic principles of agile software development