Introduction to

Software
Engineering
Introduction

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Lecture Learning Objectives
 Professional software development
 What is meant by software engineering.
 Software engineering ethics
 A brief introduction to ethical issues that affect software
engineering.
 Case studies
 An introduction to three examples that are used in later chapters
in the book.
Software engineering
 The economies of ALL developed nations are
dependent on software.
 More and more systems are software controlled
 Software engineering is concerned with theories, methods
and tools for professional software development.
 Expenditure on software represents a
significant fraction of GNP in all developed countries.
Software costs
 Software costs often dominate computer system costs.
The costs of software on a PC are often greater than the
hardware cost.
 Software costs more to maintain than it does to develop.
For systems with a long life, maintenance costs may be
several times development costs.
 Software engineering is concerned with cost-effective
software development.
Software project failure
 Increasing system complexity
 As new software engineering techniques help us to build larger,
more complex systems, the demands change. Systems have to be
built and delivered more quickly; larger, even more complex
systems are required; systems have to have new capabilities that
were previously thought to be impossible.
 Failure to use software engineering methods
 It is fairly easy to write computer programs without using software
engineering methods and techniques. Many companies have
drifted into software development as their products and services
have evolved. They do not use software engineering methods in
their everyday work. Consequently, their software is often more
expensive and less reliable than it should be.
Professional Software Development
Frequently asked questions about
software engineering
Question Answer
What is software? Computer programs and associated documentation.
Software products may be developed for a particular
customer or may be developed for a general market.
What are the attributes of good Good software should deliver the required
software? functionality and performance to the user and should
be maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline
that is concerned with all aspects of software
production.
What are the fundamental software Software specification, software development,
engineering activities? software validation and software evolution.
What is the difference between Computer science focuses on theory and
software engineering and computer fundamentals; software engineering is concerned
science? with the practicalities of developing and delivering
useful software.
What is the difference between System engineering is concerned with all aspects of
software engineering and system computer-based systems development including
engineering? hardware, software and process engineering.
Software engineering is part of this more general
process.
Frequently asked questions about
software engineering
Question Answer
What are the key challenges facing Coping with increasing diversity, demands for
software engineering? reduced delivery times and developing trustworthy
software.
What are the costs of software Roughly 60% of software costs are development
engineering? costs, 40% are testing costs. For custom software,
evolution costs often exceed development costs.
What are the best software While all software projects have to be professionally
engineering techniques and managed and developed, different techniques are
methods? appropriate for different types of system. For
example, games should always be developed using a
series of prototypes whereas safety critical control
systems require a complete and analyzable
specification to be developed. You can’t, therefore,
say that one method is better than another.
What differences has the web made The web has led to the availability of software
to software engineering? services and the possibility of developing highly
distributed service-based systems. Web-based
systems development has led to important advances
in programming languages and software reuse.
Software products
 Generic products
 Stand-alone systems that are marketed and sold to any
customer who wishes to buy them.
 Examples – PC software such as graphics programs,
project management tools; CAD software; software for
specific markets such as appointments systems for
dentists.
 Customized products
 Software that is commissioned by a specific customer to
meet their own needs.
 Examples – embedded control systems, air traffic control
software, traffic monitoring systems.
Essential attributes of good
software
Product Description
characteristic
Maintainability Software should be written in such a way so that it can
evolve to meet the changing needs of customers. This is a
critical attribute because software change is an inevitable
requirement of a changing business environment.
Dependability and Software dependability includes a range of characteristics
security including reliability, security and safety. Dependable
(Độ tin cậy và bảo mật) software should not cause physical or economic damage in
the event of system failure. Malicious users should not be
able to access or damage the system.
Efficiency Software should not make wasteful use of system resources
(hiểu quả) such as memory and processor cycles. Efficiency therefore
includes responsiveness, processing time, memory
utilisation, etc.
Acceptability Software must be acceptable to the type of users for which it
(tính chấp nhận được) is designed. This means that it must be understandable,
usable and compatible with other systems that they use.
Software engineering
Software engineering is an engineering discipline
that is concerned with all aspects of software
production from the early stages of system
specification through to maintaining the system
after it has gone into use.
Engineering discipline
 Using appropriate theories and methods to solve
problems bearing in mind organizational and financial
constraints.
All aspects of software production
 Not just technical process of development. Also project
management and the development of tools, methods etc.
to support software production.
Software Engineer vs. Programmer
 Both software engineers and programmers work on software
projects.

 Programmers work on the task of writing code to produce

software applications.

 Software engineers focus on the entire software development

process by understanding how to support a business context
with relationships between marketing, sales, production,
installation, training, and operations; using methods to
integrate components into a large application or final product
that satisfies business needs.
Some Comparisons
Example: Product Development
Process
Computer Science Focus - 1
 Mathematical logic (Boolean logic and modeling logical queries)
 Number theory (Theory of proofs and heuristics in integers)
 Graph theory (Foundations for structures and searching algorithms)
 Type theory (Formal analysis of the types of data)
 Category theory (Math and computation synthesis)
 Computational geometry (The study of algorithms to solve problems
stated in terms of geometry)
 Numerical analysis (Foundations for algorithms in discrete
mathematics, as well as the study of the limitations of floating point
computation, including round-off errors)
Computer Science Focus - 2

 Automata theory (Different logical structures for solving problems)

 Computability theory (Calculable with the models of computers)

 Computational complexity theory (Time and storage space)

 Analysis of algorithms (Complexity of algorithms)

 Algorithms (Formal logical processes for computation)

 Data structures (The organization of and rules for the manipulation of

data)
Computer Science Focus - 3
 Compilers
 The translating of computer programs, usually from higher
level languages to lower level ones.
 Interpreters
 A program that takes a computer program in as input and
executes it.
 Programming languages
 Formal language for expressing algorithms, and the
properties of these languages.
• For example: Pascal, C, Java
Software Engineering
 Algorithm implementation (Using ideas from algorithms to
design solutions.)
 Computer programming (Using a programming language
to implement algorithms.)
 Formal methods (Mathematical approaches for describing
software designs.)
 Reverse engineering (The application of the scientific
method to the understanding of arbitrary existing software.)
 Software development process (The principles and
practice of obtaining requirements: architect, design,
develop, test, release, as well as proper engineering
practices to meet quality and business needs.)
Importance of software engineering
 More and more, individuals and society rely on advanced
software systems. We need to be able to produce reliable
and trustworthy systems economically and quickly.
 It is usually cheaper, in the long run, to use software
engineering methods and techniques for software systems
rather than just write the programs as if it was a personal
programming project. For most types of system, the majority
of costs are the costs of changing the software after it has
gone into use.
Software process activities
 Software specification, where customers and engineers
define the software that is to be produced and the
constraints on its operation.
 Software development, where the software is designed
and programmed.
 Software validation, where the software is checked to
ensure that it is what the customer requires.
 Software evolution, where the software is modified to
reflect changing customer and market requirements.
General issues that affect software

 Heterogeneity/Inconsistent
 Increasingly, systems are required to operate as distributed
systems across networks that include different types of
computer and mobile devices.
 Business and social change
 Business and society are changing incredibly quickly as
emerging economies develop and new technologies become
available. They need to be able to change their existing
software and to rapidly develop new software.
General issues that affect software

Security and trust

 As software is intertwined with all aspects of our lives,
it is essential that we can trust that software.
Scale
 Software has to be developed across a very wide
range of scales, from very small embedded systems
in portable or wearable devices through to Internet-
scale, cloud-based systems that serve a global
community.
Software engineering diversity
 There are many different types of software system
and there is no universal set of software techniques
that is applicable to all of these.
 The software engineering methods and tools used
depend on the type of application being developed,
the requirements of the customer and the background
of the development team.
Application types
 Stand-alone applications
 These are application systems that run on a local
computer, such as a PC. They include all necessary
functionality and do not need to be connected to a
network.
 Interactive transaction-based applications
 Applications that execute on a remote computer and are
accessed by users from their own PCs or terminals. These
include web applications such as e-commerce
applications.
 Embedded control systems
 These are software control systems that control and
manage hardware devices. Numerically, there are probably
more embedded systems than any other type of system.
Application types
 Batch processing systems
 These are business systems that are designed to process
data in large batches. They process large numbers of
individual inputs to create corresponding outputs.
 Entertainment systems
 These are systems that are primarily for personal use and
which are intended to entertain the user.
 Systems for modeling and simulation
 These are systems that are developed by scientists and
engineers to model physical processes or situations, which
include many, separate, interacting objects.
Application types
 Data collection systems
 These are systems that collect data from their environment
using a set of sensors and send that data to other systems
for processing.
 Systems of systems
 These are systems that are composed of a number of
other software systems.
Software engineering
fundamentals
 Some fundamental principles apply to all types of software
system, irrespective of the development techniques used:
 Systems should be developed using a managed and
understood development process. Of course, different
processes are used for different types of software.
 Dependability and performance are important for all types of
system.
 Understanding and managing the software specification and
requirements (what the software should do) are important.
 Where appropriate, you should reuse software that has already
been developed rather than write new software.
Internet software engineering
 The Web is now a platform for running application and
organizations are increasingly developing web-based
systems rather than local systems.
 Web services (discussed in Chapter 19) allow application
functionality to be accessed over the web.
 Cloud computing is an approach to the provision of
computer services where applications run remotely on the
‘cloud’.
 Users do not buy software buy pay according to use.
Web-based software engineering
 Web-based systems are complex distributed systems but
the fundamental principles of software engineering
discussed previously are as applicable to them as they are
to any other types of system.
 The fundamental ideas of software engineering apply to
web-based software in the same way that they apply to
other types of software system.
Web software engineering
 Software reuse
 Software reuse is the dominant approach for constructing web-
based systems. When building these systems, you think about
how you can assemble them from pre-existing software
components and systems.
 Incremental and agile development
 Web-based systems should be developed and delivered
incrementally. It is now generally recognized that it is impractical
to specify all the requirements for such systems in advance.
Web software engineering
 Service-oriented systems
 Software may be implemented using service-oriented software
engineering, where the software components are stand-alone
web services.
 Rich interfaces
 Interface development technologies such as AJAX and HTML5
have emerged that support the creation of rich interfaces within
a web browser.
Software engineering ethics
Software engineering ethics
 Software engineering involves wider responsibilities than
simply the application of technical skills.
 Software engineers must behave in an honest and
ethically responsible way if they are to be respected as
professionals.
 Ethical behaviour is more than simply upholding the law
but involves following a set of principles that are morally
correct.
Issues of professional
responsibility
 Confidentiality
 Engineers should normally respect the confidentiality of
their employers or clients irrespective of whether or not a
formal confidentiality agreement has been signed.
 Competence
 Engineers should not misrepresent their level of
competence. They should not knowingly accept work
which is outwith their competence.
Issues of professional
responsibility
 Intellectual property rights
 Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They should
be careful to ensure that the intellectual property of employers
and clients is protected.
 Computer misuse
 Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse ranges
from relatively trivial (game playing on an employer’s machine,
say) to extremely serious (dissemination of viruses).
ACM/IEEE Code of Ethics
 The professional societies in the US have cooperated to
produce a code of ethical practice.
 Members of these organisations sign up to the code of
practice when they join.
 The Code contains eight Principles related to the behaviour
of and decisions made by professional software engineers,
including practitioners, educators, managers, supervisors
and policy makers, as well as trainees and students of the
profession.
Rationale for the code of ethics
 Computers have a central and growing role in commerce,
industry, government, medicine, education, entertainment and
society at large. Software engineers are those who contribute by
direct participation or by teaching, to the analysis, specification,
design, development, certification, maintenance and testing of
software systems.
 Because of their roles in developing software systems, software
engineers have significant opportunities to do good or cause harm, to
enable others to do good or cause harm, or to influence others to do
good or cause harm. To ensure, as much as possible, that their
efforts will be used for good, software engineers must commit
themselves to making software engineering a beneficial and
respected profession.
Key Points
 Software engineering is an engineering discipline that is
concerned with all aspects of software production.
 Essential software product attributes are maintainability,
realability and security, efficiency and acceptability.
 The high-level activities of specification, development,
validation and evolution are part of all software
processes.
 The fundamental notions of software engineering are
universally applicable to all types of system development.
Key Points
 There are many different types of system and each requires
appropriate software engineering tools and techniques for
their development.
 The fundamental ideas of software engineering are
applicable to all types of software system.
 Software engineers have responsibilities to the engineering
profession and society. They should not simply be
concerned with technical issues.
 Professional societies publish codes of conduct which set
out the standards of behaviour expected of their members.
Introduction to
Software Engineering
Software Processes

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda

• Software process models

• Process activities
• Coping with change
The software process

• A structured set of activities required to develop a

software system
• Specification – defining what the system should do;
• Design and implementation – defining the organization of
the system and implementing the system;
• Validation – checking that it does what the customer wants;
• Evolution – changing the system in response to changing
customer needs.
• A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.
Software process descriptions

• Process descriptions may also include:

• Products, which are the outcomes of a process
activity;
• Roles, which reflect the responsibilities of the
people involved in the process;
• Pre- and post-conditions, which are statements that
are true before and after a process activity has been
enacted or a product produced.
Software process models
Software process models
• ETVX Model
• Each process unit requires an Entry condition (input), a Task to do
something (task can be a procedure, method), a Validation
(measurement), an Exit condition (Output)to define the results.
• The waterfall model
• Plan-driven model. Separate and distinct phases of specification and
development.
• Incremental development
• Specification, development and validation are interleaved. May be
plan-driven or agile.
• Integration and configuration
• The system is assembled from existing configurable components.
May be plan-driven or agile.
• In practice, most large systems are developed using a process
that incorporates elements from all of these models.
The ETVX Model
• The simplest process description is the ETVX notation
where:
• 'E' is the entry criteria which must be satisfied before a set
of tasks can be performed.
• 'T' is the set of tasks to be performed.
• 'V' stands for the verification & validation process to
ensure that the right tasks are performed.
• 'X' stands for the exit criteria or the output of the tasks.
• If an activity fails in the validation check, corrective action is
taken or a rework is ordered.
• This notation can be used in any development process. Each
phase in the process can be considered as an activity and
structured using the ETVX model. If required, the tasks can
be further subdivided and each subtask can be further
structured using the ETVX model.
Example Of Process Description
Example: Process For Code Review

Project Manager selects a Code review approach for the

Entry
software product being reviewed and states his objectives for the
review.

- Project Manager selects review participants and schedules a

Task meeting.
- Project Manager distributes the code to be reviewed prior to the
meeting.
- Project Manager describes the work to be reviewed, leads the
code review, discusses code with reviewers.
- Based on reviewer comments, Project Manager orders any
necessary rework of the code, errors fixes, add comments, etc.

No verification is needed, Project Manager conducts code

Verification
review and monitors any rework from his programmers.

Exit Programmers have made appropriate changes to the code.

The waterfall model
Waterfall model phases
• There are separate identified phases in the waterfall
model:
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
• The drawback of the waterfall model is the difficulty of
accommodating change after the process is underway
Waterfall model problems
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
• Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
• In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.
Incremental development
Incremental development

Requirements continue to be analyzed then allocated to a

series of incremental releases.
Incremental development benefits
• The cost of accommodating changing customer
requirements is reduced.
• The amount of analysis and documentation that has to be
redone is much less than is required with the waterfall
model.
• It is easier to get customer feedback on the
development work that has been done.
• Customers can comment on demonstrations of the software
and see how much has been implemented.
• More rapid delivery and deployment of useful software
to the customer is possible.
• Customers are able to use and gain value from the software
earlier than is possible with a waterfall process.
Incremental development problems
• The process is not visible.
• Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to
produce documents that reflect every version of the system.
• System structure tends to degrade as new increments
are added.
• Unless time and money is spent on refactoring to improve
the software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.
Process activities
Process activities
• The four basic process activities of specification,
development, validation and evolution are organized
differently in different development processes.
• For example, in the waterfall model, they are organized
in sequence, whereas in incremental development they
are interleaved.
The requirements engineering process
Software specification
• The process of establishing what services are required
and the constraints on the system’s operation and
development.
• Requirements engineering process
• Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
• Requirements specification
• Defining the requirements in detail
• Requirements validation
• Checking the validity of the requirements
Software design and implementation

• The process of converting the system specification into

an executable system.
• Software design
• Design a software structure that realises the specification;
• Implementation
• Translate this structure into an executable program;
• The activities of design and implementation are closely
related and may be inter-leaved.
A general model of the design process
Design activities
• Architectural design, where you identify the overall
structure of the system, the principal components
(subsystems or modules), their relationships and how
they are distributed.
• Database design, where you design the system data
structures and how these are to be represented in a
database.
• Interface design, where you define the interfaces
between system components.
• Component selection and design, where you search for
reusable components. If unavailable, you design how it
will operate.
System implementation
• The software is implemented either by developing
a program or programs or by configuring an
application system.
• Design and implementation are interleaved
activities for most types of software system.
• Programming is an individual activity with no
standard process.
• Debugging is the activity of finding program faults
and correcting these faults.
Software validation
• Verification and validation (V & V) is intended to
show that a system conforms to its specification
and meets the requirements of the system
customer.
• Involves checking and review processes and system
testing.
• System testing involves executing the system with
test cases that are derived from the specification of
the real data to be processed by the system.
• Testing is the most commonly used V & V activity.
Stages of testing

Component testing
• Individual components are tested independently;
• Components may be functions or objects or coherent
groupings of these entities.
System testing
Testing of the system as a whole. Testing of emergent
properties is particularly important.
Customer testing
Testing with customer data to check that the system meets
the customer’s needs.
Testing phases in a plan-driven software
process (V-model)
System evolution

• Software is inherently flexible and can change.

• As requirements change through changing business
circumstances, the software that supports the business
must also evolve and change.
• Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new.
Coping with change
Coping with change
• Change is inevitable in all large software projects.
• Business changes lead to new and changed system
requirements
• New technologies open up new possibilities for improving
implementations
• Changing platforms require application changes
• Change leads to rework so the costs of change include
both rework (e.g. re-analysing requirements) as well as
the costs of implementing new functionality
Reducing the costs of rework
• Change anticipation, where the software process
includes activities that can anticipate possible changes
before significant rework is required.
• For example, a prototype system may be developed to show
some key features of the system to customers.
• Change tolerance, where the process is designed so that
changes can be accommodated at relatively low cost.
• This normally involves some form of incremental
development. Proposed changes may be implemented in
increments that have not yet been developed. If this is
impossible, then only a single increment (a small part of the
system) may have be altered to incorporate the change.
Coping with changing requirements
• System prototyping, where a version of the system or part
of the system is developed quickly to check the
customer’s requirements and the feasibility of design
decisions. This approach supports change anticipation.
• Incremental delivery, where system increments are
delivered to the customer for comment and
experimentation. This supports both change avoidance
and change tolerance.
Software prototyping
• A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
• A prototype can be used in:
• The requirements engineering process to help with
requirements elicitation and validation;
• In design processes to explore options and develop a UI
design;
• In the testing process to run back-to-back tests.
Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
The process of prototype development
Prototype development
• May be based on rapid prototyping languages or
tools
• May involve leaving out functionality
• Prototype should focus on areas of the product that are
not well-understood;
• Error checking and recovery may not be included in the
prototype;
• Focus on functional rather than non-functional
requirements such as reliability and security
Throw-away prototypes
• Prototypes should be discarded after development
as they are not a good basis for a production
system:
• It may be impossible to tune the system to meet non-
functional requirements;
• Prototypes are normally undocumented;
• The prototype structure is usually degraded through
rapid change;
• The prototype probably will not meet normal
organisational quality standards.
Incremental delivery
• Rather than deliver the system as a single delivery,
the development and delivery is broken down into
increments with each increment delivering part of
the required functionality.
• User requirements are prioritised and the highest
priority requirements are included in early
increments.
• Once the development of an increment is started,
the requirements are frozen though requirements
for later increments can continue to evolve.
Incremental development and delivery
• Incremental development
• Develop the system in increments and evaluate each
increment before proceeding to the development of the next
increment;
• Normal approach used in agile methods;
• Evaluation done by user/customer proxy.
• Incremental delivery
• Deploy an increment for use by end-users;
• More realistic evaluation about practical use of software;
• Difficult to implement for replacement systems as increments
have less functionality than the system being replaced.
Incremental delivery
Incremental delivery advantages
• Customer value can be delivered with each
increment so system functionality is available
earlier.
• Early increments act as a prototype to help elicit
requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive
the most testing.
Incremental delivery problems

• Most systems require a set of basic facilities that are

used by different parts of the system.
• As requirements are not defined in detail until an
increment is to be implemented, it can be hard to identify
common facilities that are needed by all increments.
• The essence of iterative processes is that the
specification is developed in conjunction with the
software.
• However, this conflicts with the procurement model of
many organizations, where the complete system
specification is part of the system development contract.
Key points
• Software processes are the activities involved in
producing a software system. Software process
models are abstract representations of these
processes.
• General process models describe the organization
of software processes.
• Examples of these general models include the ‘waterfall’
model, incremental development, and reuse-oriented
development.
• Requirements engineering is the process of
developing a software specification.
Key points
• Design and implementation processes are concerned
with transforming a requirements specification into an
executable software system.
• Software validation is the process of checking that the
system conforms to its specification and that it meets
the real needs of the users of the system.
• Software evolution takes place when you change
existing software systems to meet new requirements.
The software must evolve to remain useful.
• Processes should include activities such as prototyping
and incremental delivery to cope with change.
Q & A?
Introduction to
Software Engineering
Agile Software Development

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Agile methods
• Agile development techniques
• Agile project management
• Scaling agile methods
Rapid software development
• Rapid development and delivery is now often the most
important requirement for software systems
• Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements
• Software has to evolve quickly to reflect changing business
needs.
• Plan-driven development is essential for some types of
system but does not meet these business needs.
• Agile development methods emerged in the late 1990s
whose aim was to radically reduce the delivery time for
working software systems
Agile development
• Program specification, design and implementation
are inter-leaved
• The system is developed as a series of versions or
increments with stakeholders involved in version
specification and evaluation
• Frequent delivery of new versions for evaluation
• Extensive tool support (e.g. automated testing
tools) used to support development.
• Minimal documentation – focus on working code
Plan-driven and agile development
Plan-driven and agile development
• Plan-driven development
• A plan-driven approach to software engineering is based
around separate development stages with the outputs to be
produced at each of these stages planned in advance.
• Not necessarily waterfall model – plan-driven, incremental
development is possible
• Iteration occurs within activities.
• Agile development
• Specification, design, implementation and testing are inter-
leaved and the outputs from the development process are
decided through a process of negotiation during the software
development process.
Agile methods
Agile methods
• Dissatisfaction with the overheads involved in software
design methods of the 1980s and 1990s led to the creation
of agile methods. These methods:
• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
• The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to be
able to respond quickly to changing requirements without
excessive rework.
Agile manifesto
• We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
• That is, while there is value in the items on the
right, we value the items on the left more.
The principles of agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
Agile method applicability
• Product development where a software company is
developing a small or medium-sized product for
sale.
• Virtually all software products and apps are now
developed using an agile approach
• Custom system development within an
organization, where there is a clear commitment
from the customer to become involved in the
development process and where there are few
external rules and regulations that affect the
software.
Agile development techniques
Extreme programming
• A very influential agile method, developed in the
late 1990s, that introduced a range of agile
development techniques.
• Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
• New versions may be built several times per day;
• Increments are delivered to customers every 2 weeks;
• All tests must be run for every build and the build is only
accepted if tests run successfully.
The extreme programming release
cycle
Extreme programming practices (a)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’. See Figures 3.5 and 3.6.

Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Extreme programming practices (b)
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of
the development team and is responsible for bringing system
requirements to the team for implementation.
XP and agile principles
• Incremental development is supported through small,
frequent system releases.
• Customer involvement means full-time customer
engagement with the team.
• People not process through pair programming, collective
ownership and a process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of code.
Influential XP practices
• Extreme programming has a technical focus and is
not easy to integrate with management practice in
most organizations.
• Consequently, while agile development uses
practices from XP, the method as originally defined
is not widely used.
• Key practices
• User stories for specification
• Refactoring
• Test-first development
• Pair programming
User stories for requirements
• In XP, a customer or user is part of the XP team and is
responsible for making decisions on requirements.
• User requirements are expressed as user stories or
scenarios.
• These are written on cards and the development team
break them down into implementation tasks. These
tasks are the basis of schedule and cost estimates.
• The customer chooses the stories for inclusion in the
next release based on their priorities and the schedule
estimates.
A ‘prescribing medication’ story
Examples of task cards for prescribing
medication
Refactoring
• Conventional wisdom in software engineering is to
design for change. It is worth spending time and
effort anticipating changes as this reduces costs
later in the life cycle.
• XP, however, maintains that this is not worthwhile
as changes cannot be reliably anticipated.
• Rather, it proposes constant code improvement
(refactoring) to make changes easier when they
have to be implemented.
Refactoring
• Programming team look for possible software
improvements and make these improvements even
where there is no immediate need for them.
• This improves the understandability of the software
and so reduces the need for documentation.
• Changes are easier to make because the code is
well-structured and clear.
• However, some changes requires architecture
refactoring and this is much more expensive.
Examples of refactoring
• Re-organization of a class hierarchy to remove
duplicate code.
• Tidying up and renaming attributes and methods to
make them easier to understand.
• The replacement of inline code with calls to
methods that have been included in a program
library.
Test-first development
• Testing is central to XP and XP has developed an
approach where the program is tested after every
change has been made.
• XP testing features:
• Test-first development.
• Incremental test development from scenarios.
• User involvement in test development and validation.
• Automated test harnesses are used to run all
component tests each time that a new release is built.
Test-driven development
• Writing tests before code clarifies the requirements
to be implemented.
• Tests are written as programs rather than data so
that they can be executed automatically. The test
includes a check that it has executed correctly.
• Usually relies on a testing framework such as Junit.
• All previous and new tests are run automatically
when new functionality is added, thus checking
that the new functionality has not introduced
errors.
Customer involvement
• The role of the customer in the testing process is to
help develop acceptance tests for the stories that are to
be implemented in the next release of the system.
• The customer who is part of the team writes tests as
development proceeds. All new code is therefore
validated to ensure that it is what the customer needs.
• However, people adopting the customer role have
limited time available and so cannot work full-time
with the development team. They may feel that
providing the requirements was enough of a
contribution and so may be reluctant to get involved in
the testing process.
Test case description for dose
checking
Test automation
• Test automation means that tests are written as
executable components before the task is implemented
• These testing components should be stand-alone, should
simulate the submission of input to be tested and should
check that the result meets the output specification. An
automated test framework (e.g. Junit) is a system that makes
it easy to write executable tests and submit a set of tests for
execution.
• As testing is automated, there is always a set of tests
that can be quickly and easily executed
• Whenever any functionality is added to the system, the tests
can be run and problems that the new code has introduced
can be caught immediately.
Problems with test-first development
• Programmers prefer programming to testing and
sometimes they take short cuts when writing tests. For
example, they may write incomplete tests that do not
check for all possible exceptions that may occur.
• Some tests can be very difficult to write incrementally.
For example, in a complex user interface, it is often
difficult to write unit tests for the code that implements
the ‘display logic’ and workflow between screens.
• It difficult to judge the completeness of a set of tests.
Although you may have a lot of system tests, your test
set may not provide complete coverage.
Pair programming
• Pair programming involves programmers working in
pairs, developing code together.
• This helps develop common ownership of code and spreads
knowledge across the team.
• It serves as an informal review process as each line of code
is looked at by more than 1 person.
• It encourages refactoring as the whole team can benefit
from improving the system code.
Pair programming
• In pair programming, programmers sit together at the
same computer to develop the software.
• Pairs are created dynamically so that all team members
work with each other during the development process.
• The sharing of knowledge that happens during pair
programming is very important as it reduces the overall
risks to a project when team members leave.
• Pair programming is not necessarily inefficient and
there is some evidence that suggests that a pair
working together is more efficient than 2 programmers
working separately.
Agile project management
Agile project management
• The principal responsibility of software project
managers is to manage the project so that the software
is delivered on time and within the planned budget for
the project.
• The standard approach to project management is plan-
driven. Managers draw up a plan for the project
showing what should be delivered, when it should be
delivered and who will work on the development of the
project deliverables.
• Agile project management requires a different
approach, which is adapted to incremental
development and the practices used in agile methods.
Scrum
• Scrum is an agile method that focuses on managing
iterative development rather than specific agile
practices.
• There are three phases in Scrum.
• The initial phase is an outline planning phase where you
establish the general objectives for the project and design the
software architecture.
• This is followed by a series of sprint cycles, where each cycle
develops an increment of the system.
• The project closure phase wraps up the project, completes
required documentation such as system help frames and user
manuals and assesses the lessons learned from the project.
•
Scrum terminology (a)
Scrum term Definition

Development team A self-organizing group of software developers, which should be no more than
7 people. They are responsible for developing the software and other
essential project documents.
Potentially shippable The software increment that is delivered from a sprint. The idea is that this
product increment should be ‘potentially shippable’ which means that it is in a finished state and
no further work, such as testing, is needed to incorporate it into the final
product. In practice, this is not always achievable.

Product backlog This is a list of ‘to do’ items which the Scrum team must tackle. They may be
feature definitions for the software, software requirements, user stories or
descriptions of supplementary tasks that are needed, such as architecture
definition or user documentation.

Product owner An individual (or possibly a small group) whose job is to identify product
features or requirements, prioritize these for development and continuously
review the product backlog to ensure that the project continues to meet critical
business needs. The Product Owner can be a customer but might also be a
product manager in a software company or other stakeholder representative.
Scrum terminology (b)
Scrum term Definition
Scrum A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting that includes the whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
responsible for interfacing with the rest of the company and for ensuring
that the Scrum team is not diverted by outside interference. The Scrum
developers are adamant that the ScrumMaster should not be thought of
as a project manager. Others, however, may not always find it easy to
see the difference.

Sprint A development iteration. Sprints are usually 2-4 weeks long.

Velocity An estimate of how much product backlog effort that a team can cover in
a single sprint. Understanding a team’s velocity helps them estimate
what can be covered in a sprint and provides a basis for measuring
improving performance.
Scrum sprint cycle
The Scrum sprint cycle
• Sprints are fixed length, normally 2–4 weeks.
• The starting point for planning is the product
backlog, which is the list of work to be done on the
project.
• The selection phase involves all of the project team
who work with the customer to select the features
and functionality from the product backlog to be
developed during the sprint.
The Sprint cycle
• Once these are agreed, the team organize
themselves to develop the software.
• During this stage the team is isolated from the
customer and the organization, with all
communications channelled through the so-called
‘Scrum master’.
• The role of the Scrum master is to protect the
development team from external distractions.
• At the end of the sprint, the work done is reviewed
and presented to stakeholders. The next sprint
cycle then begins.
Teamwork in Scrum
• The ‘Scrum master’ is a facilitator who arranges daily
meetings, tracks the backlog of work to be done,
records decisions, measures progress against the
backlog and communicates with customers and
management outside of the team.
• The whole team attends short daily meetings (Scrums)
where all team members share information, describe
their progress since the last meeting, problems that
have arisen and what is planned for the following day.
• This means that everyone on the team knows what is going
on and, if problems arise, can re-plan short-term work to
cope with them.
Scrum benefits
• The product is broken down into a set of
manageable and understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have visibility of everything and
consequently team communication is improved.
• Customers see on-time delivery of increments and
gain feedback on how the product works.
• Trust between customers and developers is
established and a positive culture is created in
which everyone expects the project to succeed.
Distributed Scrum
Scaling agile methods
Scaling agile methods
• Agile methods have proved to be successful for
small and medium sized projects that can be
developed by a small co-located team.
• It is sometimes argued that the success of these
methods comes because of improved
communications which is possible when everyone
is working together.
• Scaling up agile methods involves changing these to
cope with larger, longer projects where there are
multiple development teams, perhaps working in
different locations.
Scaling out and scaling up
• ‘Scaling up’ is concerned with using agile methods
for developing large software systems that cannot
be developed by a small team.
• ‘Scaling out’ is concerned with how agile methods
can be introduced across a large organization with
many years of software development experience.
• When scaling agile methods it is importaant to
maintain agile fundamentals:
• Flexible planning, frequent system releases, continuous
integration, test-driven development and good team
communications.
Practical problems with agile methods
• The informality of agile development is incompatible
with the legal approach to contract definition that is
commonly used in large companies.
• Agile methods are most appropriate for new software
development rather than software maintenance. Yet
the majority of software costs in large companies come
from maintaining their existing software systems.
• Agile methods are designed for small co-located teams
yet much software development now involves
worldwide distributed teams.
Contractual issues
• Most software contracts for custom systems are based
around a specification, which sets out what has to be
implemented by the system developer for the system
customer.
• However, this precludes interleaving specification and
development as is the norm in agile development.
• A contract that pays for developer time rather than
functionality is required.
• However, this is seen as a high risk my many legal
departments because what has to be delivered cannot be
guaranteed.
Agile methods and software
maintenance
• Most organizations spend more on maintaining existing
software than they do on new software development.
So, if agile methods are to be successful, they have to
support maintenance as well as original development.
• Two key issues:
• Are systems that are developed using an agile approach
maintainable, given the emphasis in the development process
of minimizing formal documentation?
• Can agile methods be used effectively for evolving a system in
response to customer change requests?
• Problems may arise if original development team
cannot be maintained.
Agile maintenance
• Key problems are:
• Lack of product documentation
• Keeping customers involved in the development process
• Maintaining the continuity of the development team
• Agile development relies on the development team
knowing and understanding what has to be done.
• For long-lifetime systems, this is a real problem as
the original developers will not always work on the
system.
Agile and plan-driven methods
• Most projects include elements of plan-driven and
agile processes. Deciding on the balance depends on:
• Is it important to have a very detailed specification and
design before moving to implementation? If so, you probably
need to use a plan-driven approach.
• Is an incremental delivery strategy, where you deliver the
software to customers and get rapid feedback from them,
realistic? If so, consider using agile methods.
• How large is the system that is being developed? Agile
methods are most effective when the system can be
developed with a small co-located team who can
communicate informally. This may not be possible for large
systems that require larger development teams so a plan-
driven approach may have to be used.
Agile principles and organizational
practice
Principle Practice
Customer involvement This depends on having a customer who is willing and able to
spend time with the development team and who can represent all
system stakeholders. Often, customer representatives have other
demands on their time and cannot play a full part in the software
development.
Where there are external stakeholders, such as regulators, it is
difficult to represent their views to the agile team.

Embrace change Prioritizing changes can be extremely difficult, especially in

systems for which there are many stakeholders. Typically, each
stakeholder gives different priorities to different changes.

Incremental delivery Rapid iterations and short-term planning for development does
not always fit in with the longer-term planning cycles of business
planning and marketing. Marketing managers may need to know
what product features several months in advance to prepare an
effective marketing campaign.
Agile principles and organizational
practice
Principle Practice
Maintain simplicity Under pressure from delivery schedules, team members may not have
time to carry out desirable system simplifications.

People not process Individual team members may not have suitable personalities for the
intense involvement that is typical of agile methods, and therefore may
not interact well with other team members.
Agile and plan-based factors
System issues
• How large is the system being developed?
• Agile methods are most effective a relatively small co-located team
who can communicate informally.
• What type of system is being developed?
• Systems that require a lot of analysis before implementation need
a fairly detailed design to carry out this analysis.
• What is the expected system lifetime?
• Long-lifetime systems require documentation to communicate the
intentions of the system developers to the support team.
• Is the system subject to external regulation?
• If a system is regulated you will probably be required to produce
detailed documentation as part of the system safety case.
People and teams
• How good are the designers and programmers in
the development team?
• It is sometimes argued that agile methods require
higher skill levels than plan-based approaches in which
programmers simply translate a detailed design into
code.
• How is the development team organized?
• Design documents may be required if the team is
dsitributed.
• What support technologies are available?
• IDE support for visualisation and program analysis is
essential if design documentation is not available.
Organizational issues
• Traditional engineering organizations have a culture
of plan-based development, as this is the norm in
engineering.
• Is it standard organizational practice to develop a
detailed system specification?
• Will customer representatives be available to
provide feedback of system increments?
• Can informal agile development fit into the
organizational culture of detailed documentation?
Agile methods for large systems
• Large systems are usually collections of separate, communicating
systems, where separate teams develop each system. Frequently,
these teams are working in different places, sometimes in
different time zones.
• Large systems are ‘brownfield systems’, that is they include and
interact with a number of existing systems. Many of the system
requirements are concerned with this interaction and so don’t
really lend themselves to flexibility and incremental development.
• Where several systems are integrated to create a system, a
significant fraction of the development is concerned with system
configuration rather than original code development.
Large system development
• Large systems and their development processes are
often constrained by external rules and regulations
limiting the way that they can be developed.
• Large systems have a long procurement and
development time. It is difficult to maintain coherent
teams who know about the system over that period as,
inevitably, people move on to other jobs and projects.
• Large systems usually have a diverse set of
stakeholders. It is practically impossible to involve all of
these different stakeholders in the development
process.
Factors in large systems
IBM’s agility at scale model
Scaling up to large systems
• A completely incremental approach to requirements engineering
is impossible.
• There cannot be a single product owner or customer
representative.
• For large systems development, it is not possible to focus only on
the code of the system.
• Cross-team communication mechanisms have to be designed and
used.
• Continuous integration is practically impossible. However, it is
essential to maintain frequent system builds and regular releases
of the system.
Multi-team Scrum
• Role replication
• Each team has a Product Owner for their work component
and ScrumMaster.
• Product architects
• Each team chooses a product architect and these architects
collaborate to design and evolve the overall system
architecture.
• Release alignment
• The dates of product releases from each team are aligned so
that a demonstrable and complete system is produced.
• Scrum of Scrums
• There is a daily Scrum of Scrums where representatives from
each team meet to discuss progressand plan work to be
done.
Agile methods across organizations
• Project managers who do not have experience of agile methods may
be reluctant to accept the risk of a new approach.
• Large organizations often have quality procedures and standards that
all projects are expected to follow and, because of their bureaucratic
nature, these are likely to be incompatible with agile methods.
• Agile methods seem to work best when team members have a
relatively high skill level. However, within large organizations, there
are likely to be a wide range of skills and abilities.
• There may be cultural resistance to agile methods, especially in those
organizations that have a long history of using conventional systems
engineering processes.
Key points
• Agile methods are incremental development methods
that focus on rapid software development, frequent
releases of the software, reducing process overheads by
minimizing documentation and producing high-quality
code.
• Agile development practices include
• User stories for system specification
• Frequent releases of the software,
• Continuous software improvement
• Test-first development
• Customer participation in the development team.
Key points
• Scrum is an agile method that provides a project
management framework.
• It is centred round a set of sprints, which are fixed time
periods when a system increment is developed.
• Many practical development methods are a
mixture of plan-based and agile development.
• Scaling agile methods for large systems is difficult.
• Large systems need up-front design and some
documentation and organizational practice may conflict
with the informality of agile approaches.
Q & A?
Introduction to
Software Engineering
Requirements Engineering

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Functional and non-functional requirements
• Requirements engineering processes
• Requirements elicitation
• Requirements specification
• Requirements validation
• Requirements change
Requirements engineering
• The process of establishing the services that a customer
requires from a system and the constraints under which
it operates and is developed.
• The system requirements are the descriptions of the
system services and constraints that are generated
during the requirements engineering process.
Why Requirements Engineering?

• Failure to develop good requirements is the

major cause for software project failures.
• Lack of knowledge of customer’s business
process contributes to the failure of
requirements engineering.
What is a requirement?
• It may range from a high-level abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification.
• This is inevitable as requirements may serve a dual
function
• May be the basis for a bid for a contract - therefore must
be open to interpretation;
• May be the basis for the contract itself - therefore must
be defined in detail;
• Both these statements may be called requirements.
Types of requirement
• User requirements
• Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers.
• System requirements
• A structured document setting out detailed descriptions
of the system’s functions, services and operational
constraints. Defines what should be implemented so
may be part of a contract between client and contractor.
User and system requirements
Readers of different types of
requirements specification
System stakeholders
• Any person or organization who is affected by the system
in some way and so who has a legitimate interest
• Stakeholder types
• End users
• System managers
• System owners
• External stakeholders
Functional and non-functional
requirements
Functional and non-functional
requirements
• Functional requirements
• Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
• Often apply to the system as a whole rather than
individual features or services.
• Domain requirements
• Constraints on the system from the domain of operation
Functional requirements
• Describe functionality or system services.
• Depend on the type of software, expected users
and the type of system where the software is used.
• Functional user requirements may be high-level
statements of what the system should do.
• Functional system requirements should describe
the system services in detail.
Non-functional requirements
• These define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
• Process requirements may also be specified
mandating a particular IDE, programming language
or development method.
• Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system may be useless.
Types of nonfunctional requirement
Non-functional requirements
implementation
• Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
• For example, to ensure that performance requirements are
met, you may have to organize the system to minimize
communications between components.
• A single non-functional requirement, such as a security
requirement, may generate a number of related
functional requirements that define system services
that are required.
• It may also generate requirements that restrict existing
requirements.
Non-functional classifications
• Product requirements
• Requirements which specify that the delivered
product must behave in a particular way e.g.
execution speed, reliability, etc.
• Organisational requirements
• Requirements which are a consequence of
organisational policies and procedures e.g. process
standards used, implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are
external to the system and its development process
e.g. interoperability requirements, legislative
requirements, etc.
Metrics for specifying nonfunctional
requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Requirements engineering processes
Requirements Development
Process
• The processes used for RE vary widely depending
on the application domain, the people involved and
the organisation developing the requirements.
Requirements Elicitation
• The process through which the stakeholders and the developers of a
software/system discover, review, articulate, and understand the stakeholders’
needs and the constraints on the software/system and the development activity.
Requirements Elicitation - Questions To Ask
• What is the problem to be solved?

• What are the constraints?

• Cost

• Deadlines

• Performance

• Platform, Technology…

• What are the needs?

• Successive refinement (Iterative)

• Technical feasibility

• Financial justification
Requirements Elicitation - Specific Skills
• Software Engineers who are involved in requirements
elicitation must be able to:
• Ask direct questions about who the stakeholders are.
• Ask what are the stakeholders’ expectations of you.
• State clearly what you want from the stakeholders.
• Ask directly for the stakeholders’ concerns about costs, quality and
time, and other issues.
• Reach agreement with stakeholders.
• Ask for feedback about control and commitment.
• Ask how you and stakeholders will know if you are successful.
• Ask for open communication channels.
• Get feedback early.
Requirements Elicitation - Understand Stakeholders’ Needs
• Draw pictures – stay in Problem space.
• Create scenarios – use cases.
• Tell stories about how you think it works.
• Process modeling and simulation.
• Prototype.
• Verify your assumptions with stakeholders.

When people talk, listen completely. Most people never listen!

Requirements Elicitation Techniques
Techniques or methods used by software engineers to
determine the needs of stakeholders, so that systems can be
built with a high probability of satisfying those needs.
Several techniques may be employed: Interviewing,
Questionnaires, Focus Groups, Direct Observation,
Apprenticing, Brainstorming, Joint Applications
Development; Prototyping, Use Case
Req. Elicitation Techniques: Interviews
• The most popular technique:
• Asking questions of stakeholders about the problem to be solved and their
needs. Listening to their response and documenting them for analysis.
• Very useful when stakeholders are subject matter experts, know the
problem well, are accessible and willing to spend time to be interviewed.
• Software Engineers have to be trained in interview techniques to be
effective.
• Interviewing is a good technique to gather information. However,
the experience, understanding, and bias of the stakeholder being
interviewed influence the information obtained.
• Software engineers should use questions that do not suggest a
particular response.
• For example: Who is the owner for this system? What is the reason for
wanting to solve this problem? What environment is this product likely to
encounter? What kind of product precision is required?
3 Phase of Interview Process
1. Before the Interview
2. During the Interview
1. BEGINNING

Pleasantries Introductions Purpose/Agenda

2. MIDDLE
Use Questions to
Active Listening Take Notes
drive the session

3. CLOSE
Thanking the
Summary Next Step
Participtants
3. After the Interview
Req. Elicitation Techniques:
Interviews
• What is the client’s problem?
• What, precisely, is the problem to be solved?
• When does the problem occur?
• What generates the problem?
• Are they new or old? Or Transient?
• Where does the problem occur?
• What are the problem domain boundaries?
• How is the problem handled now?
• Why does the problem exist?
Good Question, Bad Question

Question:
• When a car suddenly brakes in front of your car,
you have to slow down and not hit it, right?
Answer:
• Yes, of course.

• What is BAD in the question here?

 It gives absolutely nothing!
Good Question, Bad Question
• Question:
• What happens when a car suddenly brakes in front of your
car?
• Answer:
• If that car is too close, I have to do something or else a crash
may happen. I guess all cars need a warning light when
braking. If the car is far away, I may not have to do anything.
The only time brakes are used is when the closing speed is
too high for the distance and yet within the capabilities of the
system to slow down. But I guess if a collision is imminent, I
should brake very hard.
What is GOOD in the question here?
 It gives you more details
Example Interview Session
Req. Elicitation Techniques:
Questionnaire
• Distributing pre-defined questions to a sample of
stakeholders. Tallying the results as inputs for
further analysis.
• Very useful when stakeholders population is large
and geographically distributed.
• Assume that all questions can be predetermined,
and stakeholders understand them well.
• Work well to ascertain opinion trends about specific,
well-defined requirements.
Questionnaire’s Issues
Most Stakeholders:
• Focus on their own problems rather than the
whole system.
• Think in terms of their own operational needs
with many “unstated needs”.
• Have lots of assumptions.
• Unrealistic expectations.
• Contradictory statements.
Elicitation Techniques: Prototyping
• A technique for building a quick and rough
version of a desired system or parts of that
system.
• The prototype illustrates the capabilities of the
system to users and designers. It serves as a
communications mechanism to allow reviewers
to understand interactions with the system.
• Prototyping sometimes gives an impression that
developers are further along than is actually the
case, giving users an overly optimistic impression
of completion possibilities.
Elicitation Techniques: Prototyping
• Constructing a partial implementation of a system in a
quick manner, to gain feedback for the requirements
process, and then discard the prototype.
• Very effective to reduce the risk associated with
inadvertently building the wrong system.
• Good for “proof of concept”.
• Could convert poorly understood requirements into much
better understood requirements.
• Effective way of communication of requirements to
stakeholders.
• Time constraints.
• Sometimes prototype implementation became part of the
new system.
Requirements Elicitation Issues
• Stakeholders may not convey the true needs of the user’s
community.
• Not all stakeholders are participating in requirements
elicitation activities.
• Software Engineers are not familiar with business
processes and do not understand the application domain.
• Stakeholders are not familiar with the technical
requirements (written by the Software Engineer) which
focuses mostly on functions, performance factors and
design constraints, but not much information on operational
characteristics.
• Different views and definitions from multiple groups
participating in requirements elicitation.
Requirements change
Changing Requirements
• The business and technical environment of the system
always changes after installation.
• New hardware may be introduced, it may be necessary to
interface the system with other systems, business priorities
may change (with consequent changes in the system support
required), and new legislation and regulations may be
introduced that the system must necessarily abide by.
• The people who pay for a system and the users of that
system are rarely the same people.
• System customers impose requirements because of
organizational and budgetary constraints. These may conflict
with end-user requirements and, after delivery, new features
may have to be added for user support if the system is to
meet its goals.
Changing requirements
• Large systems usually have a diverse user
community, with many users having different
requirements and priorities that may be conflicting
or contradictory.
• The final system requirements are inevitably a
compromise between them and, with experience, it is
often discovered that the balance of support given to
different users has to be changed.
Requirements evolution
Requirements management
• Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development.
• New requirements emerge as a system is being
developed and after it has gone into use.
• You need to keep track of individual requirements
and maintain links between dependent
requirements so that you can assess the impact of
requirements changes. You need to establish a
formal process for making change proposals and
linking these to system requirements.
Requirements management planning
• Establishes the level of requirements management detail
that is required.
• Requirements management decisions:
• Requirements identification Each requirement must be
uniquely identified so that it can be cross-referenced with
other requirements.
• A change management process This is the set of activities that
assess the impact and cost of changes. I discuss this process in
more detail in the following section.
• Traceability policies These policies define the relationships
between each requirement and between the requirements
and the system design that should be recorded.
• Tool support Tools that may be used range from specialist
requirements management systems to spreadsheets and
simple database systems.
Requirements change management
• Deciding if a requirements change should be accepted
• Problem analysis and change specification
• During this stage, the problem or the change proposal is analyzed to
check that it is valid. This analysis is fed back to the change requestor
who may respond with a more specific requirements change proposal,
or decide to withdraw the request.
• Change analysis and costing
• The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements. Once
this analysis is completed, a decision is made whether or not to
proceed with the requirements change.
• Change implementation
• The requirements document and, where necessary, the system design
and implementation, are modified. Ideally, the document should be
organized so that changes can be easily implemented.
Requirements change management
Key points
• Requirements for a software system set out what the
system should do and define constraints on its
operation and implementation.
• Functional requirements are statements of the services
that the system must provide or are descriptions of
how some computations must be carried out.
• Non-functional requirements often constrain the
system being developed and the development process
being used.
• They often relate to the emergent properties of the
system and therefore apply to the system as a whole.
Key points

• The requirements engineering process is an iterative

process that includes requirements elicitation,
specification and validation.
• Requirements elicitation is an iterative process that
can be represented as a spiral of activities –
requirements discovery, requirements classification
and organization, requirements negotiation and
requirements documentation.
• You can use a range of techniques for requirements
elicitation including interviews and ethnography. User
stories and scenarios may be used to facilitate
discussions.
Key points
• Requirements specification is the process of
formally documenting the user and system
requirements and creating a software requirements
document.
• The software requirements document is an agreed
statement of the system requirements. It should be
organized so that both system customers and
software developers can use it.
Key points
• Requirements validation is the process of checking
the requirements for validity, consistency,
completeness, realism and verifiability.
• Business, organizational and technical changes
inevitably lead to changes to the requirements for a
software system. Requirements management is the
process of managing and controlling these changes.
Q & A?
Introduction to
Software Engineering
System Modeling

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Context models
• Interaction models
• Structural models
• Behavioral models
System Modeling
• System modeling is the process of developing abstract
models of a system, with each model presenting a
different view or perspective of that system.
• System modeling has now come to mean representing
a system using some kind of graphical notation, which
is now almost always based on notations in the Unified
Modeling Language (UML).
• System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers.
UML Diagram Types
• Activity Diagrams, which show the activities involved in
a process or in data processing .
• Use Case Diagrams, which show the interactions
between a system and its environment.
• Sequence Diagrams, which show interactions between
actors and the system and between system components.
• Class diagrams, which show the object classes in the
system and the associations between these classes.
• State Diagrams, which show how the system reacts to
internal and external events.
Use of Graphical Models
• As a means of facilitating discussion about an existing or
proposed system
• Incomplete and incorrect models are OK as their role is to
support discussion.
• As a way of documenting an existing system
• Models should be an accurate representation of the system but
need not be complete.
• As a detailed system description that can be used to
generate a system implementation
• Models have to be both correct and complete.
Context models
Context models
• Context models are used to illustrate the operational
context of a system - they show what lies outside the
system boundaries.
• Social and organisational concerns may affect the
decision on where to position system boundaries.
• Architectural models show the system and its
relationship with other systems.
Context models Example
Benefits of Context Model
• Helps stakeholders quickly and simply define the project scope
and to focus on what the system needs as input and output.

• Assists Software Engineers to identify actors, use cases and

other data models.

• Establishes scope and possible scope creep problems as new

external entities are added.

• Provides a starting point for understanding the data used by the

system.

• Verifies direct and indirect users identified in the stakeholder list.

System Boundaries
• System boundaries are established to define what is
inside and what is outside the system.
• They show other systems that are used or depend on the
system being developed.
• The position of the system boundary has a profound
effect on the system requirements.
• Defining a system boundary is a political judgment
• There may be pressures to develop system boundaries that
increase / decrease the influence or workload of different
parts of an organization.
System Boundaries Example
Interaction models
Interaction models
• Modeling user interaction is important as it helps to
identify user requirements.
• Modeling system-to-system interaction highlights the
communication problems that may arise.
• Modeling component interaction helps us understand
if a proposed system structure is likely to deliver the
required system performance and dependability.
• Use case diagrams and sequence diagrams may be
used for interaction modeling.
Use case
• Use case is a description of a system’s behavior as it
responds to a user request.
• Use cases describe the system and "who" can do "what"
with the system from the users’ point of view.
• Use cases describe the interaction between an actor and
the system, represented as a sequence of steps.
• Actor is a person, a hardware or another system that
interacts with the system to achieve a goal.
Use case Model
• Use Case Model (UCM) is a type of behavioral model
defined by and created from a Use-Case analysis.
• UCM present a graphical overview of the functionality
provided by a system in terms of actors, their goals
(represented as use cases), and any dependencies between
those use cases.
• The main purpose of a UCM is to show what system
functions are performed for which actors and the roles of the
actors in the system.
• UCM have 4 major elements: The actors that interact with
the system, the system itself, the use cases, or services
that the system perform, and the lines that represent
relationships between these elements.
Example Of Use Case Diagram
Sequence diagrams
• Sequence diagrams are part of the UML and are
used to model the interactions between the actors
and the objects within a system.
• A sequence diagram shows the sequence of
interactions that take place during a particular use
case or use case instance.
• The objects and actors involved are listed along the
top of the diagram, with a dotted line drawn
vertically from these.
• Interactions between objects are indicated by
annotated arrows.
 ATM Databas e

Card
Card number

Card OK
PIN request
PIN

Sequence Option menu

<<exception>>
Validate card

diagram invalid card

Withdraw reques t Balance request

example Amount reques t

Balance

Handle request
Amount
Debit (amount)

<<exception>> Debit res pons e

insufficient cas h

Card
Card removed
Complete
Cash trans action

Cash removed
Receipt
Structural models
Structural models
• Structural models of software display the organization of
a system in terms of the components that make up that
system and their relationships.
• Structural models may be static models, which show the
structure of the system design, or dynamic models, which
show the organization of the system when it is executing.
• You create structural models of a system when you are
discussing and designing the system architecture.
Class diagrams
• Class diagrams are used when developing an object-
oriented system model to show the classes in a system and
the associations between these classes.
• An object class can be thought of as a general definition of
one kind of system object.
• An association is a link between classes that indicates that
there is some relationship between these classes.
• When you are developing models during the early stages
of the software engineering process, objects represent
something in the real world, such as a patient, a
prescription, doctor, etc.
UML Notation for a Class
• The complete UML notation for a class is shown in
Figure.
• Attribute1 and Operation1 are private (denoted by the –
sign);
• Attribute2 and Operation2 are protected (denoted by the #
sign);
• Attribute3 and Operation3 are public (denoted by the +
sign).
• The -, #, and + signs are optional, depending upon the
level of detail of the design.
Class Diagram Example
Class Diagram Example
Behavioral models
Behavioral models
• Behavioural models are used to describe the overall
behaviour of a system
• Two types of behavioural model are shown here
• Data processing models that show how data is processed as it
moves through the system
• State machine models that show the systems response to
events
• Both of these models are required for a description of
the system’s behaviour
Data-driven modeling
• Data flow diagrams are used to model the system’s data
processing
• These show the processing steps as data flows through a
system
• Intrinsic part of many analysis methods
• Simple and intuitive notation that customers can
understand
• Show end-to-end processing of data
Data-driven modeling

Checked and
Completed Signed Signed Send to signed order
order form order form order form supplier + order
Or der
notification
details + Complete Valida te Record
blank order form order order
order form Adjust
Order available
Signed budget
details order form
Order
amount
+ account
details
Orders Budget
file file
State machine models
• These model the behaviour of the system in response to
external and internal events.
• They show the system’s responses to stimuli so are
often used for modelling real-time systems.
• State machine models show system states as nodes and
events as arcs between these nodes. When an event
occurs, the system moves from one state to another.
• Statecharts are an integral part of the UML and are used
to represent state machine models.
State machine models
Key points
• A model is an abstract view of a system that ignores system details.
Complementary system models can be developed to show the system’s
context, interactions, structure and behavior.
• Context models show how a system that is being modeled is positioned
in an environment with other systems and processes.
• Use case diagrams and sequence diagrams are used to describe the
interactions between users and systems in the system being designed.
Use cases describe interactions between a system and external actors;
sequence diagrams add more information to these by showing
interactions between system objects.
• Structural models show the organization and architecture of a system.
Class diagrams are used to define the static structure of classes in a
system and their associations.
Key points
• Behavioral models are used to describe the dynamic behavior of
an executing system. This behavior can be modeled from the
perspective of the data processed by the system, or by the events
that stimulate responses from a system.
• Activity diagrams may be used to model the processing of data,
where each activity represents one process step.
• State diagrams are used to model a system’s behavior in response
to internal or external events.
Q & A?
Introduction to
Software Engineering
Architectural Design

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Architectural design decisions
• Architectural views
• Architectural patterns
• Application architectures
Architectural design
• Architectural design is concerned with understanding
how a software system should be organized and
designing the overall structure of that system.
• Architectural design is the critical link between design
and requirements engineering, as it identifies the main
structural components in a system and the relationships
between them.
• The output of the architectural design process is an
architectural model that describes how the system is
organized as a set of communicating components.
Architectural abstraction
• Architecture in the small is concerned with the
architecture of individual programs. At this level,
we are concerned with the way that an individual
program is decomposed into components.
• Architecture in the large is concerned with the
architecture of complex enterprise systems that
include other systems, programs, and program
components. These enterprise systems are
distributed over different computers, which may be
owned and managed by different companies.
Advantages of explicit architecture
• Stakeholder communication
• Architecture may be used as a focus of
discussion by system stakeholders.
• System analysis
• Means that analysis of whether the system can
meet its non-functional requirements is
possible.
• Large-scale reuse
• The architecture may be reusable across a range
of systems
• Product-line architectures may be developed.
Use of architectural models
• As a way of facilitating discussion about the system
design
• A high-level architectural view of a system is useful for
communication with system stakeholders and project
planning because it is not cluttered with detail.
• Stakeholders can relate to it and understand an abstract view
of the system. They can then discuss the system as a whole
without being confused by detail.
• As a way of documenting an architecture that has been
designed
• The aim here is to produce a complete system model that
shows the different components in a system, their interfaces
and their connections.
Architectural design decisions
Architectural design decisions
• A number of common decisions span all design
processes and these decisions affect the non-functional
characteristics of the system.
Architecture and system characteristics
• Performance
• Localise critical operations and minimise communications.
Use large rather than fine-grain components.
• Security
• Use a layered architecture with critical assets in the inner
layers.
• Safety
• Localise safety-critical features in a small number of sub-
systems.
• Availability
• Include redundant components and mechanisms for fault
tolerance.
• Maintainability
• Use fine-grain, replaceable components.
Architectural views
Architectural views
• What views or perspectives are useful when designing
and documenting a system’s architecture?
• What notations should be used for describing
architectural models?
• Each architectural model only shows one view or
perspective of the system.
Architectural views
Architectural patterns
Architectural patterns
• Patterns are a means of representing, sharing and
reusing knowledge.
• An architectural pattern is a stylized description of
good design practice, which has been tried and
tested in different environments.
• Patterns should include information about when
they are and when the are not useful.
• Patterns may be represented using tabular and
graphical descriptions.
The organization of the Model-View-Controller
Web application architecture using the
MVC pattern
Client-server architecture
• Distributed system model which shows how data
and processing is distributed across a range of
components.
• Can be implemented on a single computer.
• Set of stand-alone servers which provide specific
services such as printing, data management, etc.
• Set of clients which call on these services.
• Network which allows clients to access servers.
A client–server architecture for a film library
Application architectures
Application architectures
• Application systems are designed to meet an
organisational need.
• As businesses have much in common, their
application systems also tend to have a common
architecture that reflects the application
requirements.
• A generic application architecture is an architecture
for a type of software system that may be
configured and adapted to create a system that
meets specific requirements.
Use of application architectures
• As a starting point for architectural design.
• As a design checklist.
• As a way of organising the work of the development
team.
• As a means of assessing components for reuse.
• As a vocabulary for talking about application types.
Examples of application types
• Data processing applications
• Data driven applications that process data in batches without
explicit user intervention during the processing.
• Transaction processing applications
• Data-centred applications that process user requests and
update information in a system database.
• Event processing systems
• Applications where system actions depend on interpreting
events from the system’s environment.
• Language processing systems
• Applications where the users’ intentions are specified in a
formal language that is processed and interpreted by the
system.
Application type examples
• Two very widely used generic application architectures
are transaction processing systems and language
processing systems.
• Transaction processing systems
• E-commerce systems;
• Reservation systems.
• Language processing systems
• Compilers;
• Command interpreters.
Information systems architecture
• Information systems have a generic architecture
that can be organised as a layered architecture.
• These are transaction-based systems as interaction
with these systems generally involves database
transactions.
• Layers include:
• The user interface
• User communications
• Information retrieval
• System database
Layered information system architecture
The architecture of the Mentcare system
Key points
• A software architecture is a description of how a software
system is organized.
• Architectural design decisions include decisions on the
type of application, the distribution of the system, the
architectural styles to be used.
• Architectures may be documented from several different
perspectives or views such as a conceptual view, a logical
view, a process view, and a development view.
• Architectural patterns are a means of reusing knowledge
about generic system architectures. They describe the
architecture, explain when it may be used and describe its
advantages and disadvantages.
Key points
• Models of application systems architectures help us
understand and compare applications, validate
application system designs and assess large-scale
components for reuse.
• Transaction processing systems are interactive systems
that allow information in a database to be remotely
accessed and modified by a number of users.
• Language processing systems are used to translate texts
from one language into another and to carry out the
instructions specified in the input language. They
include a translator and an abstract machine that
executes the generated language.
Q & A?
Introduction to
Software Engineering
Design and Implementation

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Object-oriented design using the UML
• Design patterns
• Implementation issues
• Open source development
What is Sofware Design?
• Software design is the process of preparing the plan for a
software application while satisfying a problem’s
functional requirements and not violating its non-
functional constraints.
• During this process, tradeoffs need to be made, like the
tradeoff between performance and resource
consumption, so that the application is optimized to meet
the non-functional requirements. There can be no
tradeoffs among functional requirements because they all
need to be met.
• What (requirements) vs how (design): The design process
converts the “what” into the “how”.
02 phases to the design process:
• Architectural Design - The process of carving up the app
into components and assigning behavior/functionality to
each component and detailing how the components are
going to interact with each other.
• Detailed Design - The process of breaking down the
individual components into classes and interfaces that
can be implemented
Object-Oriented Analysis and Design
lifecycle:
Why is software design important?
• Because complicated things do not work well and often
don’t work at all if their pieces are created without a
good understanding of how they will work together. This
is true of all forms of design, hardware, homes, software,
databases, and highways. The more complex the system,
the more important is design.
• In software, design need not be the first step, but for
anything more than a trivial product not to consider
design at all is a terrible mistake. This is one reason why
refactoring is strongly recommended in incremental
development projects.
What is good software design?
• It should be well defined. Its purpose and its usage scope.
• Easy to find the problem and add feature when needed or
customer demands.
• From coding perspective it should be loosely coupled.
Highly readable to any other software Developer. Should
be very easy to find bugs when reported and every chunk
of whole code should be tested.
What is the importance of software
design?
• Good software design optimizes the code structure for
business needs. Typically changeability (if users don't ask
changes for a product, they probably don't use it much), but
also others, depending on product: performance, scalability,
security, monitoring, instrumentation, fast addition of new
developers to the team etc.

• For most modern applications, changeability is important. So

it's in the benefit of the business to structure the code so that
the cost of adding a new feature depends mostly on the
complexity of the feature, and very little on the complexity of
the solution. That is, in a well designed codebase, a developer
can add a new feature without fearing that he/she will
introduce regressions, and without having to dig too much in
the existing code.
What is software design tool?
There are many types of software design tools:
• Prototyping tools, programming frameworks, CASE tools which
convert requirements directly to code (IBM Rational Rose),
Database definition / creation / data modelling tools, GUI
screen design tools etc, 4G tools which convert programs from
higher level definition languages to lower level execution
languages like C etc.
All these tools improve the productivity of software
engineering, but the efficiency of the code generated is not
optimal. However, this limitation is overcome as hardware
resources become much cheaper and abundant.
What is a software designer?
Computer software engineers apply the principles and
techniques of computer science, engineering, and
mathematical analysis to the design, development, testing,
and evaluation of the software and the systems that enable
computers to perform their many applications.

Software engineers are involved in the design and

development of many types of software, including software
for operating systems and network distribution, and software
for compilers (which convert programs for execution on a
computer). In programming, or coding, software engineers
instruct a computer, line by line, how to perform a desired
function.
Software Design and implementation
• Software design and implementation is the stage in the
software engineering process at which an executable
software system is developed.
• Software design and implementation activities are
invariably inter-leaved.
• Software design is a creative activity in which you identify
software components and their relationships, based on a
customer’s requirements.
• Implementation is the process of realizing the design as a
program.
Build or buy
• In a wide range of domains, it is now possible to buy off-
the-shelf systems (COTS) that can be adapted and
tailored to the users’ requirements.
• For example, if you want to implement a medical records
system, you can buy a package that is already used in
hospitals. It can be cheaper and faster to use this approach
rather than developing a system in a conventional
programming language.
• When you develop an application in this way, the design
process becomes concerned with how to use the
configuration features of that system to deliver the
system requirements.
Software Design Concepts
1. Abstraction
2. Refinement
3. Modularity
4. Sofware Architecture
5. Control Hierachy
6. Structural Partitioning
7. Data Structure
8. Software Procedure
9. Information Hiding
1. Abstraction
• Abstraction is the process of genealization by reducing
the Information content of a concept
• It is an act of Representing essential features without
including the background details or explanations
2 Refinement
• It is the Process oof elaboration.
• One or several instructions of a given program are
decomposed into more detailed instructions.
• Abstration and refinement ar complementary concepts.
3 Modularity
• Sofware Architecture is divided into components call
modules
4 Sofware Architecture
• The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system.
5 Control Hierachy
• A program structure that represents the organization of
a program component and implies a hierachy of control.
6. Structural Partitioning
• The program structure can be divided both horizontaly
and vertically
• Horizontal partitions define separate branches of
modular hierachy for each major program function.
• Vertical partitioning suggests that control and work
should be distributed top down in the program
structure.
7. Data Structure
• It is a representation of the logical relationship among
individual elements of data
8. Sofware Procedure
• It focus on the processing of each module individually
9. Information Hiding
• Modules should be specified and design so that
information containd within a module is inaccessible to
other modules that have no need for such information.
Software Design Consideration
• Compatibility:
• Extensibility
• Modularity
• Fault Tolerance
• Maintainability
• Reliability
• Reusability
• Robustness
• Security
Compatibility:
1. Compatibility:
2. Extensibility
3. Modularity
4. Fault Tolerance
5. Maintainability
6. Reliability
7. Reusability
8. Robustness
9. Security
10. Usability
11. Performance
12. Portability
13. Scalability
Compatibility:
• The Software is able to operate with other products that
are designed for interoperability with another product.
• For example, a piece of Software may be backward-
compatible with an older version of itself
Extensibility
• New capabilities can be added to the Software without
major changes to the underlying architecture.
Modularity
• Ther resulting software comprises well defined,
independent components which leads to better
maintainability
• The components could be then implemented and tested
in isolation before being integrated to form a desired
software system
Fault Tolerance
• The software is resistant to and able to recover from
component failure
Maintainability
• A measure of how easily bug fixes of functional
modifications can be accomplished
Reliability
• The software is able to perform a required function
under stated conditions for a specified period of time
Reusability
• The ability to use some or all of the aspects of the
preexisting software in other projects with little to no
modification.
Robustness
• The software is able to operate under stress or tolerate
unpredictable or invalid input
Security
• The software is able to withstand and resist hostile acts
and influences
Usability
• The software user interface must be usable for its target
user/audience
Performance
• The software performs its tasks within a time-frame that
is acceptable for the user, and does not require too
much memery.
Portability
• The software should be usable across a number of
different conditions and enviroments
Scalability
• The software addpts well to increasing data or number
of user
What is Sofware Implementation?
• Software implementation begins with the effort of software
fabrication.
• Software fabrication involves programmatic design, source code
editing or programming, and testing of each software unit. This
series of technical tasks represents how software procedures,
routines, modules, objects, or graphical models are produced. Each
software unit is presumed to be suitable for their intended purpose
or role in the overall architectural context.
• The result of software fabrication should be a documented unit of
source code that has been tested against its structural unit
specification. This source code (software unit) is then available to
be assembled, integrated, and compiled with other fabricated
software elements to craft larger software components.
• These integrated software components are tested against structural
component specifications to ensure their correctness. Software
integration progresses until a completely integrated and tested
software configuration item is realized and available for acceptance
testing.
Open source development
Open source development
• Open source development is an approach to software
development in which the source code of a software
system is published and volunteers are invited to
participate in the development process
• Its roots are in the Free Software Foundation
(www.fsf.org), which advocates that source code should
not be proprietary but rather should always be available
for users to examine and modify as they wish.
• Open source software extended this idea by using the
Internet to recruit a much larger population of volunteer
developers. Many of them are also users of the code.
Open source systems
• The best-known open source product is, of course, the
Linux operating system which is widely used as a server
system and, increasingly, as a desktop environment.
• Other important open source products are Java, the
Apache web server and the mySQL database
management system.
Open source issues
• Should the product that is being developed make use of
open source components?
• Should an open source approach be used for the
software’s development?
Open source business
• More and more product companies are using an open
source approach to development.
• Their business model is not reliant on selling a software
product but on selling support for that product.
• They believe that involving the open source community
will allow software to be developed more cheaply, more
quickly and will create a community of users for the
software.
Open source licensing
• A fundamental principle of open-source development is
that source code should be freely available, this does
not mean that anyone can do as they wish with that
code.
• Legally, the developer of the code (either a company or an
individual) still owns the code. They can place restrictions on
how it is used by including legally binding conditions in an
open source software license.
• Some open source developers believe that if an open source
component is used to develop a new system, then that system
should also be open source.
• Others are willing to allow their code to be used without this
restriction. The developed systems may be proprietary and
sold as closed source systems.
License models
• The GNU General Public License (GPL). This is a so-called
‘reciprocal’ license that means that if you use open
source software that is licensed under the GPL license,
then you must make that software open source.
• The GNU Lesser General Public License (LGPL) is a variant
of the GPL license where you can write components that
link to open source code without having to publish the
source of these components.
• The Berkley Standard Distribution (BSD) License. This is a
non-reciprocal license, which means you are not obliged
to re-publish any changes or modifications made to open
source code. You can include the code in proprietary
systems that are sold.
License management
• Establish a system for maintaining information about
open-source components that are downloaded and
used.
• Be aware of the different types of licenses and
understand how a component is licensed before it is
used.
• Be aware of evolution pathways for components.
• Educate people about open source.
• Have auditing systems in place.
• Participate in the open source community.
Key points
• Software design and implementation are inter-leaved activities.
The level of detail in the design depends on the type of system and
whether you are using a plan-driven or agile approach.
• When developing software, you should always consider the
possibility of reusing existing software, either as components,
services or complete systems.
• Open source development involves making the source code of a
system publicly available. This means that many people can
propose changes and improvements to the software.
Q & A?
Introduction to
Software Engineering
Software Testing

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Quality Concepts • Inspections and testing
• Why Testing? • Software inspections
• Possible Software • Advantages of inspections
Problems • Testing & Software Life
• Software Testing Cycle
• Program testing goals • Testing Best Practices
• Testing Principles • Test Planning
• Testing Methods • Test Case
• Seven Types Of Software • Debug
Tests
Quality Concepts
• Software engineering discipline strives to control the:
• Process use in software projects.
• Quality of software products.
• Quality of compliance:
• Degree to which the defined process is followed in the
development of the software product.
• Quality assurance
• The process of reviews, auditing for compliance and
reporting quality issues to management for making
decisions.
• Quality Control (Testing)
• The process of inspections and tests used to ensure that
a software product meets its requirements.
Possible Software Problems
• Wrong requirements for the software product.
• Wrong data for the software system.
• Data is not available to process during execution.
• Wrong data for configuration items.
• Construction (coding) errors.
• Software failure can be very costly.
• Software failure in critical systems (i.e. flight control,
nuclear reactor monitoring, medical equipment
applications, etc.) could mean loss of life.
• To ensure software’s reliability we must test it
thoroughly.
• Software testing is a critical component of the software
engineering process.
Why Testing?
• Make sure software works as expected.
• Make sure software meets customer’s
requirements.
• Make sure software doesn’t crash.
• Identify and fix errors.
• Keep customer happy.
• Establish better confidence in software work.
• Verify the requirements specification.
• Ensure quality in software products.
Software Testing
• Software testing is:
• The process of executing the software with the
intent of finding errors and ensuring that the
software performs according to plan.
• A good test case is one that has a high
probability of finding an undiscovered error.
• Software testing is not :
• A means of demonstrating that there are no
errors in the program.
Program testing goals
• To demonstrate to the developer and the customer that
the software meets its requirements.
• To discover situations in which the behavior of the
software is incorrect, undesirable or does not conform to
its specification.
Definitions - 1
 Testing:
 The process of executing a program with the
intention of finding errors.
 Verification:
 An attempt to find errors by executing a program
in a test or simulated environment.
 Validation:
 An attempt to find errors by executing a program
in a real environment (user’s operational
environment).
 Debugging:
 Diagnosing the precise nature of a known error
and then correcting it (debugging is a correction
not a testing activity).
Definitions - 2
 Failure: An unacceptable behaviour exhibited by a
system.
 The frequency of failures measures the reliability .
 Key design goal is to achieve a very low failure rate
and hence high reliability.
 A failure can result from a violation of an explicit or
implicit requirement.
 Defect: A flaw in any aspect of the system that
contributes to the occurrence of one or more failures.
 Could be in the requirements, the design and the
code.
 It might take several defects to cause a particular
failure.
 Error: An inappropriate decision by a software engineer
that leads to the introduction of a defect.
Testing Principles
1. All tests should be traceable to customer requirements.
2. Tests should be planned early in the project during the
requirement phase, long before actual testing begins.
3. The Pareto principle applies to software testing (80% of all
errors uncovered during testing will likely be traced to 20%
of all program modules).
4. Testing should begin on individual modules and progress
toward testing the entire project (many modules).
5. Exhaustive testing is not possible. (It is impossible to test all
scenarios, every path, or every combination.)
6. Testing time and resources are limited (avoid redundant
tests).
7. To be most effective, testing should be conducted by an
independent third party (Software Quality Control).
Testing Methods
• There are two testing methods:
• White box testing - focuses on program control
structure ensuring that all statements in the
software program have been executed.

• Black box testing – focuses on the functional

aspect ensuring that the software functions
accordingly, based on a set of inputs and
outputs.
Testing Strategy
Seven Types Of Software Tests - 1
1. Unit or module test:
• Testing each module or single program, usually
in an special isolated test environment.
2. Integration test:
• Verify the interfaces between system parts
(modules, components, and subsystem).
3. Function test:
• Verify the external system functions as required
in the requirements specification document.
4. Regression test:
• Run a subset of previously executed integration
and function tests to ensure that program
changes have not degraded the system.
Seven Types Of Software Tests - 2
5. System test:
• Verify the system against its initial objectives.
6. Acceptance or validation test:
• Validate that the system meets user’s
requirements, usually conducted in the user’s
environment.
7. Installation test:
• Validate the installability and operability of the
user’s system.
Inspections and testing
• Software inspections Concerned with analysis of
the static system representation to discover problems
(static verification)
• May be supplement by tool-based document and
code analysis.
• Software testing Concerned with exercising and
observing product behaviour (dynamic verification)
• The system is executed with test data and its
operational behaviour is observed.
Inspections and testing
Software inspections
• These involve people examining the source representation
with the aim of discovering anomalies and defects.
• Inspections not require execution of a system so may be used
before implementation.
• They may be applied to any representation of the system
(requirements, design,configuration data, test data, etc.).
• They have been shown to be an effective technique for
discovering program errors.
Advantages of inspections
• During testing, errors can mask (hide) other errors.
Because inspection is a static process, you don’t have to
be concerned with interactions between errors.
• Incomplete versions of a system can be inspected without
additional costs. If a program is incomplete, then you
need to develop specialized test harnesses to test the
parts that are available.
• As well as searching for program defects, an inspection
can also consider broader quality attributes of a program,
such as compliance with standards, portability and
maintainability.
Inspections and testing
• Inspections and testing are complementary and not
opposing verification techniques.
• Both should be used during the V & V process.
• Inspections can check conformance with a specification
but not conformance with the customer’s real
requirements.
• Inspections cannot check non-functional characteristics
such as performance, usability, etc.
Testing & Software Life Cycle
• Traditional life cycles put the testing phase after the construction
phase and many programmers do not prepare for testing and
build test cases until they complete coding.
• Best practices in industry state that planning for testing should
be done at the project planning phase, after requirements are
complete and test cases should be used to validate
requirements.
• Test cases should be updated as the project progresses through
all the phases of the lifecycle. Tests must be designed to have
the highest likelihood of finding the most errors with minimum
amount time and effort.
Testing Best Practices - 1
• Testing should be based on requirements:
• SQA and project managers must review requirements to
identify defects that may cause software failure to meet
requirements.
• Software engineers should start to write test cases
immediately after requirements are complete to validate
requirements.
• If you can not write a test case:
• You do NOT understand the requirements.
• The requirements may be too vague, and not
testable.
• In that case, project manager must conduct review
with customer to verify and get testable requirements.
• Testability is simply how easily a software can be tested.
• Software engineers should use checklists and testing
tools for efficiency and effectiveness.
Testing Best Practices - 2
• Software Testing must be planned early:
• Test cases can be written during requirements
gathering.
• Is this requirement testable?
• Do I need additional data for testing purposes?
• Should I break up currently defined modules or
objects into smaller parts to facilitate test definition?
• Testers (Quality Control) should participate in
requirements development since they can provide
valuable input early in the software process.
• Testers (Quality Control) should also participate in all
software reviews and update their test plan, test cases
and test procedures, if needed.
• Early identification and removal of defects is more effective
and less costly to the project and ensures quality is built-in.
Plan Testing Early During Req.Phase
Testing Best Practices: Reviews
• The quality of software products depends upon the quality of
software reviews in the software development life cycle:
• Software reviews is a critical evaluation of software
artifacts to identify defects.
• Reviews must be conducted “ In-Process”, not after
completion.
• Action items must be documented for tracking.
• Number of defects identified per review is a good metric.
• SQA must ensure consistency and compliance with the
defined process (standards and guidelines).
• All defects should be removed before transition to the
next phase of a software development life cycle.
• Reviews performed in the requirements, design, and
code activities will prevent the majority of errors and
defects from propagating into testing.
• Software developers must take testability into account
throughout the life cycle.
Improve Testing During Design Phase
Test Planning - 1
• Objectives:
• Clearly defines what is expected from each phase of testing.
• Experience:
• Relies on expertise, when available, to mitigate risk/problem
areas and to improve the testing process.
• Responsibilities:
• Identifies individual roles, responsibilities and team
interaction.
• Resources:
• Identifies computer sites required, necessary site
certifications, tools and special test equipment (STE), special
software, and required input data.
• Schedules:
• Plan each testing phase, including resources, experience
and expertise, site utilization, down time, and regression
testing.
Test Planning - 2
• Test methodologies:
Identify methodologies to be used for each phase.
• White box/black box
• Top-down/bottom-up
• Test documentation:
• Plan for development of unit test, integration test,
validation test and system test documentation.
• Test performance priorities:
• Prioritize critical areas of testing to minimize risk and
optimize testing.
• Configuration management:
• Establish software baselines for each test phase.
• Plan for test results storage.
• Define re-test identification, control, and storage.
• Identify the process and documentation to be used for
problem description and resolution.
Test Planning - 3
• Tracking procedures:
• Specify how each phase of testing will be monitored
and how progress will be measured.
• Metrics:
• Determine how metrics will be used to evaluate the
effectiveness of the testing effort and how they will be
used for process improvement.
• Completion criteria:
• Clearly define what must be accomplished in order to
declare each testing phase complete/successful.
Test Planning Checklist
• Are all tests for this project defined?
• Are the scope and objectives for each test clearly stated?
• Are the software and hardware needed for testing identified?
• Are the organizations responsible for each test identified?
• Are the roles, responsibilities and authorities clearly defined?
• Are testers (quality control) independent from software
engineers and programmers?
• Does the project plan cover:
• Software design review
• Test plan
• Test procedure
• Test results
• Is a schedule shown for testing activities?
• Are resources for testing planned?
Test Case - 1
• A test case is an explicit set of instructions
designed to detect a particular defect in a software
system.
• A test case can give rise to many tests.
• Each test is a particular running of the test
case on a particular version of the system.
• A good test case must include the following:
1.Dentification and classification:
• Each test case should have a number, and
may also be given a descriptive title.
• The system, subsystem or module being
tested should also be clearly indicated.
• The importance of the test case should be
indicated.
Test Case - 2
2. Instructions:
• Tell the SQC (tester) exactly what to do.
• The SQC (tester) should not have to refer to any
documentation in order to execute the instructions.
3. Expected result:
• Tells the SQC (tester) what the system should do in
response to the instructions.
• The SQC (tester) reports a failure if the expected result
does not occur.
4. Cleanup (when needed):
• Tells the SQC (tester) how to make the system go ‘back
to normal’ or shut down after the test.
Levels of Importance of Test Cases
• Level 1: (Most critical)
• A “Must pass” critical test case.
• Designed to verify the system runs correctly.
• No further testing is possible.
• Level 2:
• General test cases.
• Verifies day-to-day functions correctly.
• Still permits additional testing of other aspects of the
system.
• Level 3:
• Detailed test cases.
• Test requirements that are less important.
• The system functions most of the time, but has not yet
met quality objectives.
Test Procedure Definition
• A series of sequential steps required to perform a specific
test case. Includes:
• Test operator actions.
• Required equipment.
• Expected results.
• Evaluation criteria.
• Actions to follow in the event of a program stop or
indicated error.
• Procedures to be used to reduce and analyze test
results.
Test Plan
• A test plan is a document that contains a complete set of test
cases for a system along with other information about the
testing process.
• The test plan is one of the standard forms of documentation.
• If a project does not have a test plan:
• Testing will inevitably be done in an ad-hoc manner.
• Leading to poor quality software.
• The test plan should be written early in the project long
before the testing starts, after the requirements phase.
• You can start to develop the test plan once you have
developed the requirements.
The Testing Cycle
• When a failure occurs during testing:
• SQC (Tester) must enter the failure into a “Failure
tracking system” or a document.
• It is then analyzed and assigned a priority.
• High priority failures must be assigned to a software
engineer to correct immediately and re-test again.
• SQC (Tester) must retest the fix and conduct
regression tests.
• SQA will record the incident and verify the result of the
test.
• Low-priority failures may be put on a “known bugs list”
to be corrected later, when there is time or included with
the software’s release notes for further consideration.
• It is possible to stop testing if all level 1 test cases
passed and some predefined percentage of Level 2 and
3 also passed.
Testing Performed By Users
• Alpha testing
• Performed by the users or clients, but under the
supervision of the software development team.
• Beta testing
• Performed by the users or clients in their normal work
environment.
• Recruited from the potential user population.
• An open beta release is the release of low-quality
software to the general population.
• Acceptance testing
• Performed by users and customers on their own
initiative to determine the functionality and quality of the
product before deciding to accept or not accept the
software product.
Debugging
• Debugging is the process by which discovered anomalies
are duplicated, isolated and corrected. This process may
occur at any time during testing.
• Good error handling in the code itself will help to isolate
problems.
• Several types of debugging techniques:
• Brute Force Debugging
• Inductive Process
• Deductive Process
• Others
Debugging Techniques - 1

1. Brute-force Debugging:
A poor and ineffective method of debugging is by “brute
force”
• such as:
• Using a memory dump.
• Scattering “Print” or “Display” statements throughout the
code.
Brute force debugging is only recommended as a
supplement to other methods, or when all else fails.
The Ineffective Brute Force Testing
• Disadvantages of using a memory dump:
• Memory dump cannot easily be produced at the exact
time and point of the error.
• A massive and unwieldy amount of unformatted data
(hex, etc.) is produced.
• Memory Dump is only a static picture; SQC (tester)
needs to see system changes over time.
• No describable methodologies exist for analysis of the
dump.
• Disadvantages of scattering print statements:
• Hit-or-Miss method.
• Causes changes to the code under test.
• May introduce new errors.
• Relatively costly in terms of time, resources, etc.
Debugging Techniques – 2
1.Inductive: Reasoning method whereby inference is made
from the particular to the general:
• Gather/organize data.
• Infer reasonable hypotheses.
• Rank hypotheses by probability/likelihood.
• Test each hypothesis - Verify that the hypothesis
completely explains the data.
2.Deductive: Reasoning method whereby inference is made
from the general to the specific:
• Enumerate all possible causes or hypotheses.
• Eliminate possible causes/hypotheses by analyzing the
data.
• Rank remaining hypotheses by probability/likelihood.
• Test each hypothesis - Verify that the hypothesis
completely explains the data.
Agile methods and acceptance testing
• In agile methods, the user/customer is part of the
development team and is responsible for making
decisions on the acceptability of the system.
• Tests are defined by the user/customer and are
integrated with other tests in that they are run
automatically when changes are made.
• There is no separate acceptance testing process.
• Main problem here is whether or not the
embedded user is ‘typical’ and can represent the
interests of all system stakeholders.
Key points
• Testing can only show the presence of errors in a
program. It cannot demonstrate that there are no
remaining faults.
• Development testing is the responsibility of the
software development team. A separate team should
be responsible for testing a system before it is released
to customers.
• Development testing includes unit testing, in which you
test individual objects and methods component testing
in which you test related groups of objects and system
testing, in which you test partial or complete systems.
Key points
• When testing software, you should try to ‘break’ the software by using
experience and guidelines to choose types of test case that have been
effective in discovering defects in other systems.
• Wherever possible, you should write automated tests. The tests are
embedded in a program that can be run every time a change is made to
a system.
• Test-first development is an approach to development where tests are
written before the code to be tested.
• Scenario testing involves inventing a typical usage scenario and using
this to derive test cases.
• Acceptance testing is a user testing process where the aim is to decide if
the software is good enough to be deployed and used in its operational
environment.
Q & A?
Introduction to
Software Engineering
Software Evolution

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Evolution processes
• Legacy systems
• Software maintenance
Software change
• Software change is inevitable
• New requirements emerge when the software is used;
• The business environment changes;
• Errors must be repaired;
• New computers and equipment is added to the
system;
• The performance or reliability of the system may have
to be improved.
• A key problem for all organizations is implementing and
managing change to their existing software systems.
Importance of evolution
• Organizations have huge investments in their software
systems - they are critical business assets.
• To maintain the value of these assets to the business,
they must be changed and updated.
• The majority of the software budget in large companies is
devoted to changing and evolving existing software rather
than developing new software.
Evolution and servicing
Evolution and servicing
• Evolution
• The stage in a software system’s life cycle where it is in
operational use and is evolving as new requirements are
proposed and implemented in the system.
• Servicing
• At this stage, the software remains useful but the only
changes made are those required to keep it operational
i.e. bug fixes and changes to reflect changes in the
software’s environment. No new functionality is added.
• Phase-out
• The software may still be used but no further changes
are made to it.
Evolution processes
Evolution processes
• Software evolution processes depend on
• The type of software being maintained;
• The development processes used;
• The skills and experience of the people involved.
• Proposals for change are the driver for system
evolution.
• Should be linked with components that are affected by
the change, thus allowing the cost and impact of the
change to be estimated.
• Change identification and evolution continues
throughout the system lifetime.
Change identification and evolution processes
The software evolution process
Change implementation
Change implementation
• Iteration of the development process where the
revisions to the system are designed, implemented and
tested.
• A critical difference is that the first stage of change
implementation may involve program understanding,
especially if the original system developers are not
responsible for the change implementation.
• During the program understanding phase, you have to
understand how the program is structured, how it
delivers functionality and how the proposed change
might affect the program.
Urgent change requests
• Urgent changes may have to be implemented
without going through all stages of the software
engineering process
• If a serious system fault has to be repaired to allow
normal operation to continue;
• If changes to the system’s environment (e.g. an OS
upgrade) have unexpected effects;
• If there are business changes that require a very rapid
response (e.g. the release of a competing product).
The emergency repair process
Agile methods and evolution
• Agile methods are based on incremental
development so the transition from development
to evolution is a seamless one.
• Evolution is simply a continuation of the development
process based on frequent system releases.
• Automated regression testing is particularly
valuable when changes are made to a system.
• Changes may be expressed as additional user
stories.
Handover problems
• Where the development team have used an agile
approach but the evolution team is unfamiliar with
agile methods and prefer a plan-based approach.
• The evolution team may expect detailed documentation to
support evolution and this is not produced in agile processes.
• Where a plan-based approach has been used for
development but the evolution team prefer to use agile
methods.
• The evolution team may have to start from scratch
developing automated tests and the code in the system may
not have been refactored and simplified as is expected in
agile development.
Legacy systems
Legacy systems
• Legacy systems are older systems that rely on
languages and technology that are no longer used
for new systems development.
• Legacy software may be dependent on older
hardware, such as mainframe computers and may
have associated legacy processes and procedures.
• Legacy systems are not just software systems but
are broader socio-technical systems that include
hardware, software, libraries and other supporting
software and business processes.
Legacy system change
• Legacy systems are expensive to change for a number of
reasons:
• No consistent programming style
• Use of obsolete programming languages with few people
available with these language skills
• Inadequate system documentation
• System structure degradation
• Program optimizations may make them hard to understand
• Data errors, duplication and inconsistency
Legacy system management
• Organisations that rely on legacy systems must choose a
strategy for evolving these systems
• Scrap the system completely and modify business processes so
that it is no longer required;
• Continue maintaining the system;
• Transform the system by re-engineering to improve its
maintainability;
• Replace the system with a new system.
• The strategy chosen should depend on the system
quality and its business value.
Legacy system categories
• Low quality, low business value
• These systems should be scrapped.
• Low-quality, high-business value
• These make an important business contribution but are
expensive to maintain. Should be re-engineered or replaced if
a suitable system is available.
• High-quality, low-business value
• Replace with COTS, scrap completely or maintain.
• High-quality, high business value
• Continue in operation using normal system maintenance.
Business value assessment
• Assessment should take different viewpoints into
account
• System end-users;
• Business customers;
• Line managers;
• IT managers;
• Senior managers.
• Interview different stakeholders and collate results.
Issues in business value assessment
• The use of the system
• If systems are only used occasionally or by a small number
of people, they may have a low business value.
• The business processes that are supported
• A system may have a low business value if it forces the use
of inefficient business processes.
• System dependability
• If a system is not dependable and the problems directly
affect business customers, the system has a low business
value.
• The system outputs
• If the business depends on system outputs, then the
system has a high business value.
System quality assessment
• Business process assessment
• How well does the business process support the
current goals of the business?
• Environment assessment
• How effective is the system’s environment and how
expensive is it to maintain?
• Application assessment
• What is the quality of the application software
system?
Business process assessment
• Use a viewpoint-oriented approach and seek answers
from system stakeholders
• Is there a defined process model and is it followed?
• Do different parts of the organisation use different processes
for the same function?
• How has the process been adapted?
• What are the relationships with other business processes and
are these necessary?
• Is the process effectively supported by the legacy application
software?
• Example - a travel ordering system may have a low
business value because of the widespread use of web-
based ordering.
Factors used in environment assessment
Factor Questions

Supplier Is the supplier still in existence? Is the supplier financially

stability stable and likely to continue in existence? If the supplier is no
longer in business, does someone else maintain the systems?

Failure rate Does the hardware have a high rate of reported failures?
Does the support software crash and force system restarts?

Age How old is the hardware and software? The older the
hardware and support software, the more obsolete it will be. It
may still function correctly but there could be significant
economic and business benefits to moving to a more modern
system.

Performance Is the performance of the system adequate? Do performance

problems have a significant effect on system users?
Factors used in environment assessment
Factor Questions
Support requirements What local support is required by the hardware
and software? If there are high costs associated
with this support, it may be worth considering
system replacement.

Maintenance costs What are the costs of hardware maintenance

and support software licences? Older hardware
may have higher maintenance costs than
modern systems. Support software may have
high annual licensing costs.

Interoperability Are there problems interfacing the system to

other systems? Can compilers, for example, be
used with current versions of the operating
system? Is hardware emulation required?
Factors used in application assessment
Factor Questions

Understandability How difficult is it to understand the source code of

the current system? How complex are the control
structures that are used? Do variables have
meaningful names that reflect their function?
Documentation What system documentation is available? Is the
documentation complete, consistent, and current?

Data Is there an explicit data model for the system? To

what extent is data duplicated across files? Is the
data used by the system up to date and consistent?

Performance Is the performance of the application adequate? Do

performance problems have a significant effect on
system users?
Factors used in application assessment
Factor Questions
Programming Are modern compilers available for the
language programming language used to develop the
system? Is the programming language still used
for new system development?
Configuration Are all versions of all parts of the system
management managed by a configuration management
system? Is there an explicit description of the
versions of components that are used in the
current system?
Test data Does test data for the system exist? Is there a
record of regression tests carried out when new
features have been added to the system?

Personnel skills Are there people available who have the skills to
maintain the application? Are there people
available who have experience with the system?
Software maintenance
Software maintenance
• Modifying a program after it has been put into use.
• The term is mostly used for changing custom software.
Generic software products are said to evolve to create
new versions.
• Maintenance does not normally involve major changes to
the system’s architecture.
• Changes are implemented by modifying existing
components and adding new components to the system.
Types of maintenance
• Fault repairs
• Changing a system to fix bugs/vulnerabilities and correct
deficiencies in the way meets its requirements.
• Environmental adaptation
• Maintenance to adapt software to a different operating
environment
• Changing a system so that it operates in a different
environment (computer, OS, etc.) from its initial
implementation.
• Functionality addition and modification
• Modifying the system to satisfy new requirements.
Maintenance effort distribution
Maintenance costs
• Usually greater than development costs (2*to
100*depending on the application).
• Affected by both technical and non-technical
factors.
• Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.
• Ageing software can have high support costs
(e.g. old languages, compilers etc.).
Maintenance costs
• It is usually more expensive to add new features to a
system during maintenance than it is to add the same
features during development
• A new team has to understand the programs being
maintained
• Separating maintenance and development means there is no
incentive for the development team to write maintainable
software
• Program maintenance work is unpopular
• Maintenance staff are often inexperienced and have limited domain
knowledge.
• As programs age, their structure degrades and they become
harder to change
Maintenance prediction
• Maintenance prediction is concerned with assessing
which parts of the system may cause problems and
have high maintenance costs
• Change acceptance depends on the maintainability of the
components affected by the change;
• Implementing changes degrades the system and reduces its
maintainability;
• Maintenance costs depend on the number of changes and
costs of change depend on maintainability.
Maintenance prediction
Change prediction
• Predicting the number of changes requires and
understanding of the relationships between a system
and its environment.
• Tightly coupled systems require changes whenever the
environment is changed.
• Factors influencing this relationship are
• Number and complexity of system interfaces;
• Number of inherently volatile system requirements;
• The business processes where the system is used.
Software reengineering
• Restructuring or rewriting part or all of a legacy system without
changing its functionality.
• Applicable where some but not all sub-systems of a larger system
require frequent maintenance.
• Reengineering involves adding effort to make them easier to
maintain. The system may be re-structured and re-documented.
Advantages of reengineering
• Reduced risk
• There is a high risk in new software development. There
may be development problems, staffing problems and
specification problems.
• Reduced cost
• The cost of re-engineering is often significantly less than
the costs of developing new software.
The reengineering process
Reengineering process activities
• Source code translation
• Convert code to a new language.
• Reverse engineering
• Analyse the program to understand it;
• Program structure improvement
• Restructure automatically for understandability;
• Program modularisation
• Reorganise the program structure;
• Data reengineering
• Clean-up and restructure system data.
Reengineering approaches
Reengineering cost factors
• The quality of the software to be reengineered.
• The tool support available for reengineering.
• The extent of the data conversion which is required.
• The availability of expert staff for reengineering.
• This can be a problem with old systems based on technology
that is no longer widely used.
Refactoring
• Refactoring is the process of making improvements to
a program to slow down degradation through change.
• You can think of refactoring as ‘preventative
maintenance’ that reduces the problems of future
change.
• Refactoring involves modifying a program to improve
its structure, reduce its complexity or make it easier to
understand.
• When you refactor a program, you should not add
functionality but rather concentrate on program
improvement.
Refactoring and reengineering
• Re-engineering takes place after a system has been
maintained for some time and maintenance costs are
increasing. You use automated tools to process and re-
engineer a legacy system to create a new system that is
more maintainable.
• Refactoring is a continuous process of improvement
throughout the development and evolution process. It is
intended to avoid the structure and code degradation
that increases the costs and difficulties of maintaining a
system.
‘Bad smells’ in program code
• Duplicate code
• The same or very similar code may be included at different
places in a program. This can be removed and implemented
as a single method or function that is called as required.
• Long methods
• If a method is too long, it should be redesigned as a number
of shorter methods.
• Switch (case) statements
• These often involve duplication, where the switch depends
on the type of a value. The switch statements may be
scattered around a program. In object-oriented languages,
you can often use polymorphism to achieve the same thing.
‘Bad smells’ in program code
• Data clumping
• Data clumps occur when the same group of data items (fields
in classes, parameters in methods) re-occur in several places in
a program. These can often be replaced with an object that
encapsulates all of the data.
• Speculative generality
• This occurs when developers include generality in a program in
case it is required in the future. This can often simply be
removed.
Key points
• Software development and evolution can be thought of as an
integrated, iterative process that can be represented using a
spiral model.
• For custom systems, the costs of software maintenance
usually exceed the software development costs.
• The process of software evolution is driven by requests for
changes and includes change impact analysis, release
planning and change implementation.
• Legacy systems are older software systems, developed using
obsolete software and hardware technologies, that remain
useful for a business.
Key points
• It is often cheaper and less risky to maintain a legacy
system than to develop a replacement system using
modern technology.
• The business value of a legacy system and the quality of
the application should be assessed to help decide if a
system should be replaced, transformed or maintained.
• There are 3 types of software maintenance, namely bug
fixing, modifying software to work in a new
environment, and implementing new or changed
requirements.
Key points
• Software re-engineering is concerned with restructuring
and re-documenting software to make it easier to
understand and change.
• Refactoring, making program changes that preserve
functionality, is a form of preventative maintenance.
Q & A?
Introduction to
Software Engineering

Project Management

Instructor: Huy Nguyen Dang Quang, Msc

Email: [email protected]
 PROJECT MANAGEMENT Hien Le

WHAT IS PROJECT MANAGEMENT?

What Is A Project?

❑A project is a sequence of unique, complex, and

connected activities having one goal or purpose and that
must be completed by specific time, within budget, and
according to specification
Situation
SITUATION: I want to repair my old house including the
following works
• Replacing the wooden attic with a concrete one
• Expanding the bedroom
• Making the plaster ceiling
The contractor estimated 100 million and planned to get it
done within 10 days
➔ Based on the estimation, I prepared that amount and intend
to start on Nov 15, 2021 and end date will be on Nov 24, 2021

Is there any
problem with
this?
Why is project management important?
What Is Project Management ?
Deadline
Negotiation
Goals

Communication
Risks

PR OJECT MANAGEMENT
Controls Team spirit

Milestones
Analysis

Problem solving

Budget

Planning
What Is Project Management ?
• Concerned with activities involved in ensuring
that software is delivered on time and on schedule and in
accordance with the requirements of the organisations
developing and procuring the software.

• Project management is needed because software

development is always subject to budget and schedule
constraints that are set by the organisation developing the
software.
Project organization
Software project management
consists of the following phases
Success criteria
The success criteria for project management obviously vary
from project to project, but, for most projects, important goals
are:
• to Deliver the software to the customer at the agreed time.
• to Keep overall costs within budget.
• to Deliver software that meets the customer’s
expectations.
• to Maintain a coherent and well-functioning development
team.
Factors influencing project
management
• Company size
• Software customers
• Software size
• Software type
• Organizational culture
• Software development processes
• These factors mean that project managers in different
organizations may work in quite different ways.
Universal management activities
• Project planning
• Project managers are responsible for planning.
estimating and scheduling project development and
assigning people to tasks.
• Risk management
• Project managers assess the risks that may affect a
project, monitor these risks and take action when
problems arise.
• People management
• Project managers have to choose people for their team
and establish ways of working that leads to effective
team performance.
Universal management activities
• Reporting
• Project managers are usually responsible for reporting
on the progress of a project to customers and to the
managers of the company developing the software.
• Proposal writing
• The first stage in a software project may involve writing a
proposal to win a contract to carry out an item of work.
The proposal describes the objectives of the project and
how it will be carried out.
Project Planning
Software Project Planning
• Purpose

• To establish and maintain plans that define all

• Software project activities.

• Meaning

• Developing project plan.

• Interacting with stakeholders appropriately.

• Getting the necessary commitments.

• Maintaining the plan.

The Project Plan
• The project plan defines the work and how it will be done. It
provides a definition of each major task, estimates the time
and resources needed, identifies reviews and control
activities.
• The project plan is developed at the beginning of the project
and is successively refined as work progresses.
• The project should be subdivided into smaller tasks that are
each defined, estimated and tracked by a technique called
Work Breakdown Structure (WBS).
• The project plan must identify periodic reviews with
management and customers for tracking progress against
the plan.
The Project Plan
• A Project Plan should include the following:
• Goals and Objectives of the project
• The project’s chosen software life cycle
• A list of products to be developed (Deliverables)
• A Work Breakdown Structure (WBS)
• Schedules Estimates (Cost, size, effort, etc.)
• Facilities, support tools, hardware
• Project risks - identify, mitigate
• Plans must be based on estimates of size, effort, cost,
schedule, etc. Project managers should:
• Use historical data, where available
• Document assumptions and estimates
Project Priorities & Deliverables
• A software project consists of a set of priorities. These
priorities can be classified by what must be done, what should
be done, and what may be done.
• These priorities will vary among stakeholders. Project
managers must manage the conflict to achieve a set of
priorities for the work to be done.
• A software project consists of several tasks or deliverables or
that project stakeholders will receive at the end of each project
phase or when the project is complete.
• Project manager will identify these deliverables when planning
the project.
• Deliverables can be software products, documents, reports,
hardware, etc.
Project Tasks
• Before a project can begin, it is necessary to define project
tasks. The most common way to do this is through a Work
Breakdown Structure (WBS).
• Work Breakdown is the process of breaking large projects into
many smaller components to make accurate estimates of
schedule and cost.
• Tips: Typical amount of time to work on each component is
about 40 hours for a person (man/week).
• Before something can be estimated, it must be defined and
scoped, Project Managers must ask:
• Does a requirements document exist?
• Does a statement of work (SOW) exist?
• Do project constraints exist? (Cost, schedule, staffing, etc.)
Risk management
Risk management
• Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a project.
• Software risk management is important because of the
inherent uncertainties in software development.
• These uncertainties stem from loosely defined
requirements, requirements changes due to changes in
customer needs, difficulties in estimating the time and
resources required for software development, and
differences in individual skills.
• You have to anticipate risks, understand the impact of these
risks on the project, the product and the business, and take
steps to avoid these risks.
Risk classification
• There are two dimensions of risk classification

• The type of risk (technical, organizational, ..)

• What is affected by the risk:

• Project risks affect schedule or resources;

• Product risks affect the quality or performance of the

software being developed;

• Business risks affect the organisation developing or

procuring the software.
Examples of project, product, and
business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is
finished.
Management change Project There will be a change of organizational
management with different priorities.
Hardware Project Hardware that is essential for the project will not be
unavailability delivered on schedule.
Requirements Project and There will be a larger number of changes to the
change product requirements than anticipated.
Specification delays Project and Specifications of essential interfaces are not
product available on schedule.
Size underestimate Project and The size of the system has been underestimated.
product
CASE tool Product CASE tools, which support the project, do not
underperformance perform as anticipated.
Technology change Business The underlying technology on which the system is
built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.
The risk management process
• Risk identification
• Identify project, product and business risks;
• Risk analysis
• Assess the likelihood and consequences of these
risks;
• Risk planning
• Draw up plans to avoid or minimise the effects of
the risk;
• Risk monitoring
• Monitor the risks throughout the project;
The risk management process
Managing people
Managing people
• People are an organisation’s most important assets.

• The tasks of a manager are essentially people-oriented.

Unless there is some understanding of people, management
will be unsuccessful.

• Poor people management is an important contributor to

project failure.
People management factors
• Consistency
• Team members should all be treated in a comparable
way without favourites or discrimination.
• Respect
• Different team members have different skills and these
differences should be respected.
• Inclusion
• Involve all team members and make sure that people’s
views are considered.
• Honesty
• You should always be honest about what is going well
and what is going badly in a project.
Motivating people
• An important role of a manager is to motivate the people
working on a project.
• Motivation means organizing the work and the working
environment to encourage people to work effectively.
• If people are not motivated, they will not be interested in
the work they are doing. They will work slowly, be more
likely to make mistakes and will not contribute to the
broader goals of the team or the organization.
• Motivation is a complex issue but it appears that their are
different types of motivation based on:
• Basic needs (e.g. food, sleep, etc.);
• Personal needs (e.g. respect, self-esteem);
• Social needs (e.g. to be accepted as part of a group).
Human needs hierarchy
Case study: Individual motivation
Alice is a software project manager working in a company that develops alarm
systems. This company wishes to enter the growing market of assistive
technology to help elderly and disabled people live independently. Alice has been
asked to lead a team of 6 developers than can develop new products based
around the company’s alarm technology.

Alice’s assistive technology project starts well. Good working relationships

develop within the team and creative new ideas are developed. The team decides
to develop a peer-to-peer messaging system using digital televisions linked to the
alarm network for communications. However, some months into the project, Alice
notices that Dorothy, a hardware design expert, starts coming into work late, the
quality of her work deteriorates and, increasingly, that she does not appear to be
communicating with other members of the team.
Alice talks about the problem informally with other team members to try to find out
if Dorothy’s personal circumstances have changed, and if this might be affecting
her work. They don’t know of anything, so Alice decides to talk with Dorothy to try
to understand the problem.
Case study: Individual motivation

After some initial denials that there is a problem, Dorothy admits that she
has lost interest in the job. She expected that she would be able to
develop and use her hardware interfacing skills. However, because of the
product direction that has been chosen, she has little opportunity for this.
Basically, she is working as a C programmer with other team members.

Although she admits that the work is challenging, she is concerned that
she is not developing her interfacing skills. She is worried that finding a
job that involves hardware interfacing will be difficult after this project.
Because she does not want to upset the team by revealing that she is
thinking about the next project, she has decided that it is best to minimize
conversation with them.
Comments on case study
• If you don’t sort out the problem of unacceptable work,
the other group members will become dissatisfied and
feel that they are doing an unfair share of the work.
• Personal difficulties affect motivation because people
can’t concentrate on their work. They need time and
support to resolve these issues, although you have to
make clear that they still have a responsibility to their
employer.
• Alice gives Dorothy more design autonomy and
organizes training courses in software engineering that
will give her more opportunities after her current
project has finished.
Teamwork
Teamwork
• Most software engineering is a group activity
• The development schedule for most non-trivial software
projects is such that they cannot be completed by one
person working alone.
• A good group is cohesive and has a team spirit. The people
involved are motivated by the success of the group as well
as by their own personal goals.
• Group interaction is a key determinant of group
performance.
• Flexibility in group composition is limited
• Managers must do the best they can with available
people.
Group cohesiveness
• In a cohesive group, members consider the group to be more
important than any individual in it.
• The advantages of a cohesive group are:
• Group quality standards can be developed by the group
members.
• Team members learn from each other and get to know
each other’s work; Inhibitions caused by ignorance are
reduced.
• Knowledge is shared. Continuity can be maintained if a
group member leaves.
• Refactoring and continual improvement is encouraged.
Group members work collectively to deliver high quality
results and fix problems, irrespective of the individuals
who originally created the design or program.
Team spirit
Alice, an experienced project manager, understands the importance of creating a
cohesive group. As they are developing a new product, she takes the opportunity of
involving all group members in the product specification and design by getting them
to discuss possible technology with elderly members of their families. She also
encourages them to bring these family members to meet other members of the
development group.

Alice also arranges monthly lunches for everyone in the group. These lunches are
an opportunity for all team members to meet informally, talk around issues of
concern, and get to know each other. At the lunch, Alice tells the group what she
knows about organizational news, policies, strategies, and so forth. Each team
member then briefly summarizes what they have been doing and the group
discusses a general topic, such as new product ideas from elderly relatives.

Every few months, Alice organizes an ‘away day’ for the group where the team
spends two days on ‘technology updating’. Each team member prepares an update
on a relevant technology and presents it to the group. This is an off-site meeting in
a good hotel and plenty of time is scheduled for discussion and social interaction.
The effectiveness of a team
• The people in the group
• You need a mix of people in a project group as software
development involves diverse activities such as
negotiating with clients, programming, testing and
documentation.
• The group organization
• A group should be organized so that individuals can
contribute to the best of their abilities and tasks can be
completed as expected.
• Technical and managerial communications
• Good communications between group members, and
between the software engineering team and other project
stakeholders, is essential.
Selecting group members
• A manager or team leader’s job is to create a cohesive
group and organize their group so that they can work
together effectively.

• This involves creating a group with the right balance of

technical skills and personalities, and organizing that group
so that the members work together effectively.
Group organization
• The way that a group is organized affects the decisions that
are made by that group, the ways that information is
exchanged and the interactions between the development
group and external project stakeholders.
• Key questions include:
• Should the project manager be the technical leader of
the group?
• Who will be involved in making critical technical
decisions, and how will these be made?
• How will interactions with external stakeholders and
senior company management be handled?
• How can groups integrate people who are not co-
located?
• How can knowledge be shared across the group?
Group organization
• Small software engineering groups are usually organised
informally without a rigid structure.

• For large projects, there may be a hierarchical structure

where different groups are responsible for different sub-
projects.

• Agile development is always based around an informal group

on the principle that formal structure inhibits information
exchange
Group communications
• Good communications are essential for effective group
working.

• Information must be exchanged on the status of work,

design decisions and changes to previous decisions.

• Good communications also strengthens group cohesion as

it promotes understanding.
Group communications
• Group size
• The larger the group, the harder it is for people to
communicate with other group members.
• Group structure
• Communication is better in informally structured groups than
in hierarchically structured groups.
• Group composition
• Communication is better when there are different personality
types in a group and when groups are mixed rather than
single sex.
• The physical work environment
• Good workplace organisation can help encourage
communications.
Key points
• Good project management is essential if software engineering
projects are to be developed on schedule and within budget.
• Software management is distinct from other engineering
management. Software is intangible. Projects may be novel or
innovative with no body of experience to guide their
management. Software processes are not as mature as traditional
engineering processes.
• Risk management involves identifying and assessing project risks
to establish the probability that they will occur and the
consequences for the project if that risk does arise. You should
make plans to avoid, manage or deal with likely risks if or when
they arise.
Key points
• People management involves choosing the right people to work
on a project and organizing the team and its working
environment.
• People are motivated by interaction with other people, the
recognition of management and their peers, and by being given
opportunities for personal development.
• Software development groups should be fairly small and cohesive.
The key factors that influence the effectiveness of a group are the
people in that group, the way that it is organized and the
communication between group members.
• Communications within a group are influenced by factors such as
the status of group members, the size of the group, the gender
composition of the group, personalities and available
communication channels.
Q & A?
Introduction to
Software Engineering
Project Management

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Risk management
• Managing people
• Teamwork
Software project management
• Concerned with activities involved in ensuring
that software is delivered on time and on schedule and
in accordance with the requirements of the
organisations developing and procuring the software.
• Project management is needed because software
development is always subject to budget and schedule
constraints that are set by the organisation developing
the software.
Success criteria
• Deliver the software to the customer at the agreed time.
• Keep overall costs within budget.
• Deliver software that meets the customer’s
expectations.
• Maintain a coherent and well-functioning development
team.
Software management distinctions
• The product is intangible.
• Software cannot be seen or touched. Software
project managers cannot see progress by simply
looking at the artefact that is being constructed.
• Many software projects are 'one-off' projects.
• Large software projects are usually different in some
ways from previous projects. Even managers who
have lots of previous experience may find it difficult
to anticipate problems.
• Software processes are variable and organization
specific.
• We still cannot reliably predict when a particular
software process is likely to lead to development
problems.
Factors influencing project management
• Company size
• Software customers
• Software size
• Software type
• Organizational culture
• Software development processes
• These factors mean that project managers in different
organizations may work in quite different ways.
Universal management activities
• Project planning
• Project managers are responsible for planning. estimating
and scheduling project development and assigning people to
tasks.
• Covered in Chapter 23.
• Risk management
• Project managers assess the risks that may affect a project,
monitor these risks and take action when problems arise.
• People management
• Project managers have to choose people for their team and
establish ways of working that leads to effective team
performance.
Management activities
• Reporting
• Project managers are usually responsible for reporting on the
progress of a project to customers and to the managers of the
company developing the software.
• Proposal writing
• The first stage in a software project may involve writing a
proposal to win a contract to carry out an item of work. The
proposal describes the objectives of the project and how it
will be carried out.
Project Planning
Software Project Planning
• Purpose
• To establish and maintain plans that define all
• Software project activities.
• Meaning
• Developing project plan.
• Interacting with stakeholders appropriately.
• Getting the necessary commitments.
• Maintaining the plan.
The Project Plan
• The project plan defines the work and how it will be
done. It provides a definition of each major task,
estimates the time and resources needed, identifies
reviews and control activities.
• The project plan is developed at the beginning of
the project and is successively refined as work
progresses.
• The project should be subdivided into smaller tasks
that are each defined, estimated and tracked by a
technique called Work Breakdown Structure
(WBS).
• The project plan must identify periodic reviews with
management and customers for tracking progress
against the plan.
The Project Plan
• A Project Plan should include the following:
• Goals and Objectives of the project
• The project’s chosen software life cycle
• A list of products to be developed (Deliverables)
• A Work Breakdown Structure (WBS)
• Schedules Estimates (Cost, size, effort, etc.)
• Facilities, support tools, hardware
• Project risks - identify, mitigate
• Plans must be based on estimates of size, effort,
cost, schedule, etc. Project managers should:
• Use historical data, where available
• Document assumptions and estimates
Project Priorities & Deliverables
• A software project consists of a set of priorities.
These priorities can be classified by what must be
done, what should be done, and what may be done.
• These priorities will vary among stakeholders. Project
managers must manage the conflict to achieve a set
of priorities for the work to be done.
• A software project consists of several tasks or
deliverables or that project stakeholders will receive
at the end of each project phase or when the project
is complete.
• Project manager will identify these deliverables when
planning the project.
• Deliverables can be software products, documents,
reports, hardware, etc.
Project Tasks
• Before a project can begin, it is necessary to define
project tasks. The most common way to do this is
through a Work Breakdown Structure (WBS).
• Work Breakdown is the process of breaking large
projects into many smaller components to make
accurate estimates of schedule and cost.
• Tips: Typical amount of time to work on each component is
about 40 hours for a person (man/week).
• Before something can be estimated, it must be
defined and scoped, Project Managers must ask:
• Does a requirements document exist?
• Does a statement of work (SOW) exist?
• Do project constraints exist? (Cost, schedule, staffing, etc.)
Risk management
Risk management
• Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a project.
• Software risk management is important because of the
inherent uncertainties in software development.
• These uncertainties stem from loosely defined requirements,
requirements changes due to changes in customer needs,
difficulties in estimating the time and resources required for
software development, and differences in individual skills.
• You have to anticipate risks, understand the impact of
these risks on the project, the product and the business,
and take steps to avoid these risks.
Risk classification
• There are two dimensions of risk classification
• The type of risk (technical, organizational, ..)
• what is affected by the risk:
• Project risks affect schedule or resources;
• Product risks affect the quality or performance of the
software being developed;
• Business risks affect the organisation developing or
procuring the software.
Examples of project, product, and business
risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is
finished.
Management change Project There will be a change of organizational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be
delivered on schedule.
Requirements change Project and product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule.
Size underestimate Project and product The size of the system has been underestimated.

CASE tool Product CASE tools, which support the project, do not
underperformance perform as anticipated.
Technology change Business The underlying technology on which the system is
built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.
The risk management process
• Risk identification
• Identify project, product and business risks;
• Risk analysis
• Assess the likelihood and consequences of these risks;
• Risk planning
• Draw up plans to avoid or minimise the effects of the
risk;
• Risk monitoring
• Monitor the risks throughout the project;
The risk management process
Managing people
Managing people
• People are an organisation’s most important assets.
• The tasks of a manager are essentially people-oriented.
Unless there is some understanding of people,
management will be unsuccessful.
• Poor people management is an important contributor
to project failure.
People management factors
• Consistency
• Team members should all be treated in a comparable way
without favourites or discrimination.
• Respect
• Different team members have different skills and these
differences should be respected.
• Inclusion
• Involve all team members and make sure that people’s views
are considered.
• Honesty
• You should always be honest about what is going well and
what is going badly in a project.
Motivating people
• An important role of a manager is to motivate the
people working on a project.
• Motivation means organizing the work and the working
environment to encourage people to work effectively.
• If people are not motivated, they will not be interested in the
work they are doing. They will work slowly, be more likely to
make mistakes and will not contribute to the broader goals of
the team or the organization.
• Motivation is a complex issue but it appears that their
are different types of motivation based on:
• Basic needs (e.g. food, sleep, etc.);
• Personal needs (e.g. respect, self-esteem);
• Social needs (e.g. to be accepted as part of a group).
Human needs hierarchy
Need satisfaction
• In software development groups, basic physiological
and safety needs are not an issue.
• Social
• Provide communal facilities;
• Allow informal communications e.g. via social networking
• Esteem
• Recognition of achievements;
• Appropriate rewards.
• Self-realization
• Training - people want to learn more;
• Responsibility.
Case study: Individual motivation
Alice is a software project manager working in a company that develops alarm
systems. This company wishes to enter the growing market of assistive
technology to help elderly and disabled people live independently. Alice has been
asked to lead a team of 6 developers than can develop new products based
around the company’s alarm technology.

Alice’s assistive technology project starts well. Good working relationships

develop within the team and creative new ideas are developed. The team decides
to develop a peer-to-peer messaging system using digital televisions linked to the
alarm network for communications. However, some months into the project, Alice
notices that Dorothy, a hardware design expert, starts coming into work late, the
quality of her work deteriorates and, increasingly, that she does not appear to be
communicating with other members of the team.
Alice talks about the problem informally with other team members to try to find out
if Dorothy’s personal circumstances have changed, and if this might be affecting
her work. They don’t know of anything, so Alice decides to talk with Dorothy to try
to understand the problem.
Case study: Individual motivation

After some initial denials that there is a problem, Dorothy admits that she
has lost interest in the job. She expected that she would be able to
develop and use her hardware interfacing skills. However, because of the
product direction that has been chosen, she has little opportunity for this.
Basically, she is working as a C programmer with other team members.

Although she admits that the work is challenging, she is concerned that
she is not developing her interfacing skills. She is worried that finding a
job that involves hardware interfacing will be difficult after this project.
Because she does not want to upset the team by revealing that she is
thinking about the next project, she has decided that it is best to minimize
conversation with them.
Comments on case study
• If you don’t sort out the problem of unacceptable work,
the other group members will become dissatisfied and
feel that they are doing an unfair share of the work.
• Personal difficulties affect motivation because people
can’t concentrate on their work. They need time and
support to resolve these issues, although you have to
make clear that they still have a responsibility to their
employer.
• Alice gives Dorothy more design autonomy and
organizes training courses in software engineering that
will give her more opportunities after her current
project has finished.
Personality types
• The needs hierarchy is almost certainly an over-
simplification of motivation in practice.
• Motivation should also take into account different
personality types:
• Task-oriented people, who are motivated by the work they
do. In software engineering.
• Interaction-oriented people, who are motivated by the
presence and actions of co-workers.
• Self-oriented people, who are principally motivated by
personal success and recognition.
Personality types
• Task-oriented.
• The motivation for doing the work is the work itself;
• Self-oriented.
• The work is a means to an end which is the achievement of
individual goals - e.g. to get rich, to play tennis, to travel etc.;
• Interaction-oriented
• The principal motivation is the presence and actions of
co-workers. People go to work because they like to go to
work.
Motivation balance
• Individual motivations are made up of elements
of each class.
• The balance can change depending on personal
circumstances and external events.
• However, people are not just motivated by personal factors but
also by being part of a group and culture.
• People go to work because they are motivated by the people that
they work with.
Teamwork
Teamwork
• Most software engineering is a group activity
• The development schedule for most non-trivial software
projects is such that they cannot be completed by one person
working alone.
• A good group is cohesive and has a team spirit. The
people involved are motivated by the success of the
group as well as by their own personal goals.
• Group interaction is a key determinant of group
performance.
• Flexibility in group composition is limited
• Managers must do the best they can with available people.
Group cohesiveness
• In a cohesive group, members consider the group to be
more important than any individual in it.
• The advantages of a cohesive group are:
• Group quality standards can be developed by the group members.
• Team members learn from each other and get to know each
other’s work; Inhibitions caused by ignorance are reduced.
• Knowledge is shared. Continuity can be maintained if a group
member leaves.
• Refactoring and continual improvement is encouraged. Group members
work collectively to deliver high quality results and fix problems,
irrespective of the individuals who originally created the design or
program.
Team spirit
Alice, an experienced project manager, understands the importance of creating a
cohesive group. As they are developing a new product, she takes the opportunity of
involving all group members in the product specification and design by getting them
to discuss possible technology with elderly members of their families. She also
encourages them to bring these family members to meet other members of the
development group.

Alice also arranges monthly lunches for everyone in the group. These lunches are
an opportunity for all team members to meet informally, talk around issues of
concern, and get to know each other. At the lunch, Alice tells the group what she
knows about organizational news, policies, strategies, and so forth. Each team
member then briefly summarizes what they have been doing and the group
discusses a general topic, such as new product ideas from elderly relatives.

Every few months, Alice organizes an ‘away day’ for the group where the team
spends two days on ‘technology updating’. Each team member prepares an update
on a relevant technology and presents it to the group. This is an off-site meeting in
a good hotel and plenty of time is scheduled for discussion and social interaction.
The effectiveness of a team
• The people in the group
• You need a mix of people in a project group as software
development involves diverse activities such as negotiating
with clients, programming, testing and documentation.
• The group organization
• A group should be organized so that individuals can
contribute to the best of their abilities and tasks can be
completed as expected.
• Technical and managerial communications
• Good communications between group members, and
between the software engineering team and other project
stakeholders, is essential.
Selecting group members
• A manager or team leader’s job is to create a cohesive
group and organize their group so that they can work
together effectively.
• This involves creating a group with the right balance of
technical skills and personalities, and organizing that
group so that the members work together effectively.
Assembling a team
• May not be possible to appoint the ideal people to work on a
project
• Project budget may not allow for the use of highly-paid staff;
• Staff with the appropriate experience may not be available;
• An organisation may wish to develop employee skills on a
software project.
• Managers have to work within these constraints especially when
there are shortages of trained staff.
Group composition
• Group composed of members who share the
same motivation can be problematic
• Task-oriented - everyone wants to do their own thing;
• Self-oriented - everyone wants to be the boss;
• Interaction-oriented - too much chatting, not enough work.
• An effective group has a balance of all types.
• This can be difficult to achieve software engineers are
often task-oriented.
• Interaction-oriented people are very important as they
can detect and defuse tensions that arise.
Group composition
In creating a group for assistive technology development, Alice is aware of
the importance of selecting members with complementary personalities.
When interviewing potential group members, she tried to assess whether
they were task-oriented, self-oriented, or interaction-oriented. She felt that
she was primarily a self-oriented type because she considered the project
to be a way of getting noticed by senior management and possibly
promoted. She therefore looked for one or perhaps two interaction-
oriented personalities, with task-oriented individuals to complete the team.
The final assessment that she arrived at was:

Alice—self-oriented
Brian—task-oriented
Bob—task-oriented
Carol—interaction-oriented
Dorothy—self-oriented
Ed—interaction-oriented
Fred—task-oriented
Group organization
• The way that a group is organized affects the
decisions that are made by that group, the ways
that information is exchanged and the
interactions between the development group
and external project stakeholders.
• Key questions include:
• Should the project manager be the technical leader of
the group?
• Who will be involved in making critical technical
decisions, and how will these be made?
• How will interactions with external stakeholders and
senior company management be handled?
• How can groups integrate people who are not co-
located?
• How can knowledge be shared across the group?
Group organization
• Small software engineering groups are usually organised
informally without a rigid structure.
• For large projects, there may be a hierarchical structure
where different groups are responsible for different sub-
projects.
• Agile development is always based around an informal
group on the principle that formal structure inhibits
information exchange
Informal groups
• The group acts as a whole and comes to a consensus on decisions
affecting the system.
• The group leader serves as the external interface of the group
but does not allocate specific work items.
• Rather, work is discussed by the group as a whole and tasks are
allocated according to ability and experience.
• This approach is successful for groups where all members are
experienced and competent.
Group communications
• Good communications are essential for effective group
working.
• Information must be exchanged on the status of work,
design decisions and changes to previous decisions.
• Good communications also strengthens group cohesion
as it promotes understanding.
Group communications
• Group size
• The larger the group, the harder it is for people to
communicate with other group members.
• Group structure
• Communication is better in informally structured groups than
in hierarchically structured groups.
• Group composition
• Communication is better when there are different personality
types in a group and when groups are mixed rather than
single sex.
• The physical work environment
• Good workplace organisation can help encourage
communications.
Key points
• Good project management is essential if software engineering
projects are to be developed on schedule and within budget.
• Software management is distinct from other engineering
management. Software is intangible. Projects may be novel or
innovative with no body of experience to guide their
management. Software processes are not as mature as traditional
engineering processes.
• Risk management involves identifying and assessing project risks
to establish the probability that they will occur and the
consequences for the project if that risk does arise. You should
make plans to avoid, manage or deal with likely risks if or when
they arise.
Key points
• People management involves choosing the right people to work
on a project and organizing the team and its working
environment.
• People are motivated by interaction with other people, the
recognition of management and their peers, and by being given
opportunities for personal development.
• Software development groups should be fairly small and cohesive.
The key factors that influence the effectiveness of a group are the
people in that group, the way that it is organized and the
communication between group members.
• Communications within a group are influenced by factors such as
the status of group members, the size of the group, the gender
composition of the group, personalities and available
communication channels.
Q & A?
Introduction to
Software Engineering
The Software Quality Assurance

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Lecture Objectives
• Upon completion of this lecture, students will be
able to:
• Understand the meaning of Software Quality
Assurance SQA).
• Understand the role, responsibilities of SQA.
• Outcomes:
• Be able to develop an SQA plan.
• Be able to conduct an SQA review using checklists.
• Be able to write an SQA status report to
management.
• Be able to follow the defined SQA process.
Issues With Quality
• Most Project Managers are concerned with schedule, cost,
and functionality. Quality is desirable but usually not
emphasized.
• Few people know that poor quality performance is the root
cause of most software cost and schedule problems.
• There are many definitions of software quality:
• Total characteristics in a software entity that bear on its ability to
satisfy stated and implied customer needs.
• Software quality is the existence of characteristics in a product that
can be assigned to requirements.
• Software quality defines as how well software is designed and how
well the software conforms to that design.
• Software quality consists of internal and external quality
characteristics. External quality characteristics are those parts of a
product that face its users, where internal quality characteristics
are those that do not.
• Different people view quality differently.
Software quality management
• Concerned with ensuring that the required level of
quality is achieved in a software product.
• Three principal concerns:
• At the organizational level, quality management is
concerned with establishing a framework of organizational
processes and standards that will lead to high-quality
software.
• At the project level, quality management involves the
application of specific quality processes and checking that
these planned processes have been followed.
• At the project level, quality management is also concerned
with establishing a quality plan for a project. The quality plan
should set out the quality goals for the project and define
what processes and standards are to be used.
Quality Principles
1. If customers do not demand a quality product, they will probably
do not get one.
2. The quality of a product is determined by the quality of the
process used to develop it.
3. To produce quality products, the project team must manage the
quality of their work.
4. To manage the quality of their work, the project team must
measure quality and consistently test their product.
5. Since testing removes only a fraction of a product’s defects, the
project team must follow the defined quality process to get a
quality product.
6. To ensure that the project has a defined quality process and the
project team follows that process, the project needs an
independent review to objectively monitor both the process and
the product: The Software Quality Assurance function.
Quality management activities
• Quality management provides an independent check on
the software development process.
• The quality management process checks the project
deliverables to ensure that they are consistent with
organizational standards and goals
• The quality team should be independent from the
development team so that they can take an objective
view of the software. This allows them to report on
software quality without being influenced by software
development issues.
Quality Concepts
• Software engineering discipline strives to control the:
• Process use in software projects.
• Quality of software product.
• Quality of compliance:
• Degree to which the defined process is followed in the
development of the software product.
• Quality assurance:
• The process of reviewing, auditing for compliance and
reporting quality issues to management for making
decisions.
• Quality control (testing):
• The process of inspections and tests to ensure that a
software product meet its requirements.
SQC and SQA
• Software Quality Control (SQC) or testing is the process used
to verify that the software product delivers the functionality
as required by the stakeholders and, as a result, identifies
defects.
• Software Quality Assurance (SQA) is the process used to
objectively evaluate whether or not the project team, in
developing the software product, are compliant with the
defined process descriptions, standards, and procedures.
• Through a series of reviews and audits, an SQA identifies
noncompliance issues, reports them to management and
ensures that these non-compliance issues are addressed.
• Organizations who are interested in establishing consistency
in the way software is developed, and want to define a
better process to improve quality, must establish a SQA
function.
Organization Structure
Software Quality Assurance (SQA)
• Purpose
• Provide the project manager and project team with objective
insight into processes and associated software products.
• Meaning
• Objectively evaluate processes, products, and services
against the defined process, standards, and procedures.
• Identify non-compliance issues.
• Provide feedback to project manager and team.
• Ensure non-compliance issues are addressed.
• The value of SQA is that it provides an independent
view of project activities, process, and product.
• SQA verifies that project teams are doing what they say
they will do.
Software Quality Assurance Context
Diagram
Product and Process Quality Assurance
Process Assurance Benefits
SQA assures management that the defined process is being
implemented by confirming that:
• The appropriate methodology is selected.
• Projects follow standards and procedures in their work.
• Project plan and other artifacts are in place.
• Project artifacts are produced during, not after
development.
• Independent reviews and audits are conducted.
• Documentation is produced accordingly.
• Mechanisms are in place to control changes.
• Risk management processes are being used.
• Project tasks are tested and completed satisfactorily.
• Deviations to process are identified, analyzed and
documented.
• Quality control work is in place and functions properly.
Process Assurance Benefits
SQA assures management that the defined process is being
implemented by confirming that:
• The appropriate methodology is selected.
• Projects follow standards and procedures in their work.
• Project plan and other artifacts are in place.
• Project artifacts are produced during, not after
development.
• Independent reviews and audits are conducted.
• Documentation is produced accordingly.
• Mechanisms are in place to control changes.
• Risk management processes are being used.
• Project tasks are tested and completed satisfactorily.
• Deviations to process are identified, analyzed and
documented.
• Quality control work is in place and functions properly.
Improve Customer Satisfaction
• Customer satisfaction means better relationships and
better business. If customers are not happy with a
software product they may never do business with the
company again.
• Application functionality, product defects and quality
attributes (usability, maintainability, etc.) are key factors
in determining customer satisfaction or dissatisfaction.
• SQA reviews project activities to identify defects, missing
functionality, and other quality attributes stated in the
project plan, as well as compliance with the defined
process to ensure that the software product will meet
customers’ expectations.
SQA Responsibilities
• Review all plans in the software project (Project plan, CM
plan, Testing plan, etc.) for completeness.
• Participate in project reviews as indicated in the project
plan.
• Review all test plans for compliance to the defined
process.
• Review a sample of all test results for compliance to
plans.
• Audit Configuration Management performance to
determine compliance to the defined process.
• Participate in the establishment of standards, procedures,
and defined processes in the organization.
SQA Process
• Software quality assurance participants must plan their
activities and document them in an SQA plan.
• SQA reviews all project activities to objectively check for
compliance to the defined process.
• All project team members are informed of software
quality assurance activities and results.
• Non-compliance issues are communicated with project
teams for resolution.
• Non-compliance issues that cannot be resolved within the
software project are addressed by management.
• SQA participates in product testing to ensure the final
software product meets quality goals.
SQA Process Flow
Planning SQA in Software Project
• During the planning of the software project, Project
Managers should review the organization’s defined
process for Software
• Quality Assurance to:
• Understand SQA process
• Understand project responsibilities
• Project Managers and SQA work together to plan all
SQA activities throughout the life of the project.
• SQA documents activities in the project’s SQA plan.
• The Project’s SQA Plan is organized to meet the specific
needs of the project.
SQA Roles In Projects
• Requirements Phase - Discuss with project managers which
activities of the software projects should be reviewed and
audited.
• SQA Plan and Processes – Write a plan describing how SQA
will conduct all required activities based on the defined
processes, as well as the sequence of events that relate to the
project.
• Schedules - Schedule SQA reviews and audits in the project.
• Progress is tracked and metrics are kept on schedule variance.
• Training - Train software engineers on quality issues and
measure their effectiveness.
• Reviews – Conduct reviews and report findings, issues found
are recorded and tracked for closure.
SQA Reviews
• Although all software development activities are potentially
subjected to SQA reviews, not all activities have to be reviewed by
SQA.
• SQA should focus on a few important activities for maximum
benefits and better utilization of resources.
• During project planning, SQA and project managers must decide
which activities need to be reviewed and which ones don’t.
• Because of the independent nature and to avoid conflict of interest,
SQA members should not report to the project manager.
• Senior management must identifies SQA priorities and resource
commitments to accomplish the overall quality plan by:
• Identifying what areas are subjected to an SQA audit
• When and in what phase of the project
• Review and audit criteria
• Escalation process for non-compliance status report
• Budget for SQA
Example Of An SQA Plan
• Purpose & goals
• SQA function
• Roles, responsibilities, authority
• Charter, membership, training, tools
• Organization defined processes, procedures, guidelines
• Other documentations
• SQA process:
• SQA reviews (Planned activities)
• SQA audits (Random activities)
• SQA relationship with SCM
• SQA forms:
• SQA checklists
• SQA review forms
• SQA problem reporting
• SQA audit forms
• SQA tools, techniques, and methodologies
SQA Review
• Project Manager:
• Notify project team members and SQA representative of
the upcoming review.
• Schedule a place/time/date for the review.
• Review the appropriate SQA checklist.
• Gather appropriate documentation for the review.
• SQA Representative:
• Review the project’s SQA Plan.
• Review the defined process for SQA review.
• Review the appropriate SQA checklist.
• Conduct SQA review.
Software Reviews
• Purpose of software review is to find defects before they are passed
on to the next phase of the lifecycle or released to the customer.
• Software engineers conduct technical reviews at the end of each
lifecycle phase (i.e., Requirements, Architecture, Design, Code and
Test) to identify and fix defects.
• Technical Reviews:
• Informal = walkthroughs (Between software engineers in
project)
• Formal = Software inspections (Between software engineers
and project managers, SQA and other stakeholders)
• SQA participates in these reviews to ensure that they are conducted
according to the project plan and the defined process.
• Software review is an effective means for improving software
quality.
Reviews and Software Quality Assurance
• During review, software engineers must:
• Collect information about software defects.
• Track each defect as to its cause (root cause
analysis).
• Apply Pareto principle (80% of the defects can be
traced to 20% of the causes) to isolate the "vital
few" defect causes.
• Create corrective action plan to fix the defects.
• Create a plan to fix the problems that caused the
defects (defect prevention).
• SQA must:
• Ensure software engineers follow the defined
process.
• Collect defect data.
Quality Attributes - 1
• Software quality consists of many attributes and the
evaluation of software quality must be defined for each
project based on the appropriate criteria needed to be
identified for the environment.
• Project managers and SQA must work together to
determine which attribute is important and must be met.
Following is a set of quality attributes:
• Correctness: The extent to which a program fulfills its
requirements specifications.
• Efficiency: The use of resources, execution and
storage.
• Flexibility: The ease of making changes in the
operating environment.
• Integrity: The protection of the program from
unauthorized access.
• Interoperability: The effort required to couple the
system to another system.
Quality Attributes - 2
• Maintainability: The effort required to locate and fix an
error in the program within its operating environment.
• Portability: The effort required to transfer a program from
one environment to another.
• Reliability: The ability not to fail.
• Reusability: The ease of re-using software in a different
context.
• Testability: The ease of testing the program to ensure that
it is error-free and meets its specification.
• Usability: The ease of use of the software.
Project Review / Audit Report
• SQA will provide a review/audit report to the project
manager that identifies the processes audited and non-
compliance issues.
• SQA will give the project team a reasonable time to fix the
noncompliance issues (for example: 1 week or 30 days).
• SQA will track all items for closure.
• If non-compliance is not resolved within the time allowed,
SQA will escalate the issue to senior management.
• SQA will produce a monthly status report to senior
managers on all activities including a list of all outstanding
issues.
• SQA will present status and results to senior management
on a quarterly basis and discuss overall quality issues
within the organization.
SQA People
• Since SQA is critical for project success in
achieving customer satisfaction, it is essential
that organizations have experienced people to
work in SQA.
• Best practices in Industry:
• Rotate experienced programmers into SQA every
6 months in order for them to understand the
defined process and have “total view” of the
project and product development.
• New project managers must spend at least 6
months working as SQA before promoting to a
software project manager.
• SQA should not be considered a “Dead-end” job.
• Rotation of experienced people in and out of SQA
is the preferred process.
• Organizations should NEVER put a new hire or
Software Quality Assurance Process
Q & A?
 Introduction to
Software Engineering
Defining a Configuration
Management Process

Instructor: Huy Nguyen Dang Quang, Msc

Email: [email protected]

Referenced from Prof.Redley of CMU

Content
1. What is Configuration Management?
2. Why use Configuration Management?
3. Where does Configuration Management fit?
4. How does Configuration Management work?
5. Terminology

Referenced from Prof.Redley of CMU

Software evolution

Software is developed over time

• Many different elements are created throughout
the duration of the project
• There are many different versions
• Teams work in parallel to deliver the final
product
• The system is subject to continuous change

Referenced from Prof.Redley of CMU

What are the changes?
Change business requirements

Change Technical Requirements

Change user requirements

Project Other
Plan Software Model Document

Testing Source Code

Data

Referenced from Prof.Redley of CMU

Software Configuration

Pieces
Referenced from Prof.Redley of CMU
Problems

Many people have to work on changing software

Multiple versions of the software must be supported:
• System released
• Custom configured system (different functions)
• The system is under development
Software must run on other machines and operating systems
together
→ Therefore, need for good management and
coordination

Referenced from Prof.Redley of CMU

 What is Configuration Management?

▪ Configuration Management (CM) is the process

of controlling and documenting change to a
continually evolving system
▪ It is part of change management
▪ Software Configuration Management (SCM) is
Configuration Management specifically designed
to meet the needs of software development and
maintenance projects

Referenced from Prof.Redley of CMU

Why Use SCM?
▪ Consider this scenario:
• Software Engineer1 opens foo.cpp
• Software Engineer2 opens foo.cpp
• Software Engineer1 makes a change to foo.cpp
• Software Engineer2 makes a change to foo.cpp
• Software Engineer1 saves foo.cpp
• Software Engineer2 saves foo.cpp, wiping out
Software Engineer1’s changes
▪ Or this one:
• A serious defect is reported for a previous release of
our product. How do we fix that defect only and
generate a new release?
Referenced from Prof.Redley of CMU
Why Use SCM?
▪ So we will always know:
• Where all revisions of all files necessary to create any
product version can be found
• Which source files revisions were used in each build
• What changed in each revision of our source files, and
why
• How to recreate previous product releases
• How to work as a team to make changes (defects and/or
new features) in future builds and releases

Referenced from Prof.Redley of CMU

Why Use SCM?
▪ So it is easy for developers to make changes, test their
changes and integrate the results into the product
▪ So developers don’t waste a lot of time tracking down
bugs in other people’s code that prevent them from
testing
▪ So the QA team has a stable product to work with
▪ So the project team can easily release updated
versions of their product in a repeatable manner
▪ If done right, significantly reduces Development & Test
time

Referenced from Prof.Redley of CMU

Where Does SCM Fit?

New Development Change Requests

Change Control

Approved
Changes

SCM
Repository
What Goes Under SCM Control?
▪ Everything!
• Product source code
• Scripts to build source code
• Tools used to build product
• 3rd party products used to create product
• Data files
• Scripts to build or populate database
• Specifications
• User documentation
• Test scripts
• Plans
• Etc.
Referenced from Prof.Redley of CMU
How Does SCM Work?
▪ Generic Model Master SCM Repository

foo.cpp

•Checks out foo.cpp

•Makes change to foo.cpp
•Builds product on local laptop
•Tests product change on local laptop
Software Engineer1 •Rebuilds & retests product using
latest source code
•Checks in updated foo.cpp

Referenced from Prof.Redley of CMU

 How Does SCM Work? • Checks out foo.cpp
• Makes change to foo.cpp
• Builds product on local laptop
• Tests product change on local laptop
• Checks in updated foo.cpp

Software Engineer 1 Software Engineer 2

• Checks out foo.cpp Master SCM Repository
• Makes change to foo.cpp
• Builds product on local laptop
• Tests product change on local
laptop
• Checks in updated foo.cpp
foo.cpp

• Checks out foo.cpp

• Makes change to foo.cpp
• Builds product on local laptop
• Tests product change on local
laptop
• Checks in updated foo.cpp

Referenced from Prof.Redley of CMUSoftware Engineer 3

 How Does SCM Work?
▪ Generic Model
Master SCM Repository

foo.cpp
Software Engineer 1 Software Engineer 2

If Software Engineer2 checks out foo.cpp when Software

Engineer1 has it checked out, then the SCM system will
automatically merge the files when they are checked in

Referenced from Prof.Redley of CMU

How Does SCM Work?
▪ Generic Model
Master SCM Repository

source files
Software Engineer 1

At any time the software product can be built from the

source files for testing

Referenced from Prof.Redley of CMU

Terminology
• Source File
• Any file required to build the product on a clean
machine. Includes build scripts, DDLs, install
scripts, tests, etc.
• Product Build
• Classic definition: Source files compiled and
linked into an executable file
• Modern definition: Putting everything associated
with a product together in a usable format

Referenced from Prof.Redley of CMU

Terminology (cont)
◼ Product Release
 Providing software files to others for use.
Typically this is a build that passed tests and is
considered ‘good’
◼ Revision
 A instance of a source file that contains specific
changes
◼ Version
 A unique identifier given to a Release, typically
associated with all source file revisions that a
build is comprised of
Referenced from Prof.Redley of CMU
Revision Control
▪ Changes to source files must be captured using
a revision control system so the team always
knows what changed, and can revert to
previous source file revisions if necessary
▪ Example:
• Source File foo.cpp
▪ Revision 1.0 (First time checked in)
▪ Revision 1.1 (Bug fixed)
▪ Revision 1.2 (Another bug fixed)
▪ Revision 1.3 (Yet another bug fixed)

Referenced from Prof.Redley of CMU

Builds
▪ When your product is created from all of the
source code in your repository the product is
called a “build”
▪ Builds are usually given to a QA team for system
testing
• If QA finds defects that must be fixed, then those
defects are fixed and a new build created for system
testing
• If the build passes QA, then that build becomes a
release and made available to users/customers

Referenced from Prof.Redley of CMU

Build tools

Referenced from Prof.Redley of CMU

 JAVA ANT
▪ Java With Ant là dự án nguồn mở, & là công cụ của phần mềm
tự động hóa các quy trình build code.
▪ Phần mềm này được bắt nguồn từ dự án Apache Tomcat dùng
để thay thế cho Make Build của Unix. Song công cụ này được
sử dụng bằng ngôn ngữ Java.
▪ Ant được sử dụng để build các dự án phức tạp của Java. Với
những dự án như Application thì sử dụng Ant để compile các
Source code. Với những dự án như Web hoặc J2EE thì cần
nhiều sources khác nhau. Sử dụng Ant sẽ giúp quản lý và cập
nhật các mối liên hệ này.
▪ Vào năm 2022, Ant là công cụ build được sử dụng nhiều nhất
để phát triển hầu hết các dự án có sử dụng Java. Vì gần như tất
cả những nhà phát triển đều build tệp dựa trên mã nguồn mở
này.
▪ Ant cho phép những nhà phát triển áp dụng có thể thử nghiệm
cũng như lập trình cực đoan dựa trên mã nguồn mở Ant đã cung
cấp. from Prof.Redley of CMU
Referenced
 LỢI ÍCH CỦA JAVA ANT
• Ant mang đến rất nhiều lợi ích. Nhất là khi giúp người dùng
biên dịch mã nguồn rất nhanh chóng. Đặc biệt, với Ant Java
thì chúng ta có thể nhận được mã nguồn biên dịch đã được
đóng gói cẩn thận thành Word, Jar với chỉ một lệnh duy nhất.
• Tiếp đến là có thể sử dụng Ant Java để biên dịch mà không
cần phụ thuộc vào các IDE.
• Thêm nữa, sử dụng Ant có thể build được các ứng dụng như
Java EE, Java SE, Java ME.
• Một tiện ích khác của Ant là có thể sử dụng để soạn thảo các
Editors đơn giản giúp sinh mã hoặc đánh dấu mã, tạo cú
pháp mẫu, biên dịch hoặc chạy ứng dụng…
• Tạo mối liên hệ giữa các Sources trong quá trình build.

Referenced from Prof.Redley of CMU

 MAVENT
• Maven là một công cụ mã nguồn mở, thực hiện chức năng quản
lý, xây dựng và triển khai cho các dự án, được phát triển bởi
Apache Software Foundation. Công cụ này được viết bằng ngôn
ngữ Java để xây dựng các dự án được viết bằng C#, Ruby,
Scala và các ngôn ngữ khác.
Tính năng
• Liên tục cập nhật và phát triển kho lưu trữ thư viện người dùng
lớn.
• Khả năng thiết lập dự án dễ dàng, ưu tiên sử dụng các phương
pháp đem lại hiệu suất tối ưu nhất cho dự án.
• Quản lý phần phụ thuộc, có tính năng cập nhật tự động.
• Tương thích ngược với các phiên bản trước.
• Báo cáo các lỗi nghiêm trọng và tính toàn vẹn.
• Thiết lập tính nhất quán được đảm bảo trên tất cả các dự án.
• Maven có thể mở rộng, bạn dễ dàng viết các phiên bản bổ trợ
bằng ngôn
Referenced ngữ sẵn
from Prof.Redley có hoặc Java.
of CMU
 LỢI ÍCH CỦA MAVENT
• Tạo thuận lợi cho quá trình xây dựng cho bất kỳ dự án nào.
• Duy trì tính đồng nhất trong toàn bộ quá trình xây dựng.
• Maven cung cấp thông tin toàn diện về dự án, giúp ta hiểu về
những gì dự án đang thực hiện.
• Maven cung cấp hướng dẫn để đảm bảo chất lượng trong
một dự án, cần phải phát triển theo cách tốt nhất.
• Các tác vụ di chuyển một dự án được thực hiện một cách
đơn giản.
• Linh hoạt trên kho lưu trữ cấu hình, xây dựng một tham số,
mục tiêu để đưa ra các giải pháp khác nhau cho môi trường
hoặc giai đoạn khác nhau.

Referenced from Prof.Redley of CMU

 GRADLE
• Gradle là một công cụ mã nguồn mở vô cùng mạnh mẽ và
miễn phí, giúp các Developer xây dựng hầu hết các loại phần
mềm một cách linh hoạt, nhanh chóng. Gradle hỗ trợ các lập
trình viên tự động hoá quá trình dựng phần mềm, quản lý thư
viện,.... Từ đó tối ưu việc biên/phiên dịch, đóng gói phần mềm
cũng như triển khai sử dụng.
• Gradle có sẵn các cấu trúc phần mềm phổ biến nên thay vì
phải xây dựng từ đầu, chúng ta chỉ cần dựa vào đó để phát
triển thêm các tính năng mới. Nhờ đó, các lập trình viên có
thể tối ưu thời gian trong quá trình phát triển phần mềm.

Referenced from Prof.Redley of CMU

 LỢI ÍCH CỦA GRADLE
• Build Script viết bằng Gradle trở nên ngắn gọn, trực quan và
dễ đọc hơn.
• Gradle giúp rút ngắn thời gian của quá trình build bằng cách
cho phép chạy Parallel các đoạn code test. Trong tương lai,
để giảm thiểu thời gian chờ đợi, Gradle có thể sẽ cho phép
việc phân phối các đoạn code test qua nhiều machine khác
nhau.
• Khả năng tương thích với nhiều công cụ, hỗ trợ lập trình viên
tương tác với các dự án Gradle trong IDE. Bạn cũng có thể
sử dụng Gradle trong quá trình sử dụng NetBeans, Visual
Studio, các phần mềm IDE khác,... nếu có hỗ trợ.
• Hỗ trợ đa dạng các ngôn ngữ lập trình như C/C++, Object
C++, Object C, Assembler,....

Referenced from Prof.Redley of CMU

Builds and Automation
▪ Automate the creation of your builds
• Use tools like Make or Ant, along with scripts
• Embed the build number in your product
• Ensure your builds are reproducible. That is, if you
provide a build number, the system knows which
source file revisions to include in the build

▪ Automate the packaging of your product, For

example:
• Creating releases for different platforms
• Populating a master CD

Referenced from Prof.Redley of CMU

Unique Release Numbering
▪ Each Build/Release must have a unique ID
▪ Required for developers to determine which
build (& source files) a problem is occurring in
▪ Should be meaningful. I.e., XX.YY.ZZZ,
where:
• XX is the Major Release Number
• YY is the Minor (Maintenance) Release Number
• ZZZZ is the Build Number
Example: 1.01.0012
• Would be the 12th build of release 1.01

Referenced from Prof.Redley of CMU

Version Number

Referenced from Prof.Redley of CMU

Database Version Numbering
▪ If your product has a database you’ll need to
establish a mechanism that ties database
versions to product versions
• Product Version Runs with Database Version
• 1.01.0312 1.0, 1.1, 1.2
• 1.03.0229 1.3, 1.4
• 2.00.0332 1.5
• When your product starts up it checks to make sure
that it is running against a supported database
version

Referenced from Prof.Redley of CMU

Notification and Logs
▪ Build process logs every activity of every step
while it is executing to a log file
• Anyone must be able to determine the state of any
build by inspecting the build’s log file

▪ Email notifications
• Automatically sent to all developers that had new
code checked in with that build
• Summarizes the status of the build (good/bad)

Referenced from Prof.Redley of CMU

Continuous Integration
▪ Build everything from scratch regularly
• Constantly (if anything has changed)
• Based on timer (developers have to get code in by a
certain time)
• At least nightly

▪ If successful, execute test suite

• Automated tests are kept in SCM system too

▪ If all steps complete ok you have a successful build

• Label the source files with the build number
• Update logs and send notifications

Referenced from Prof.Redley of CMU

Group discussion
◼ Discuss in groups of 4 students,
comparing advantage/disadvantage of
the following tools(10 minutes):

Referenced from Prof.Redley of CMU

Test Automation
▪ Ability for anyone to be able to run a suite of unit and/or
system tests against the product at any time using simple
commands
▪ Automated system tests are not intended to be exhaustive
or replace system testing. The intent is to have a
fast, repeatable process for ensuring that:
▪ Time spent adding new unit and/or system tests results in
significantly shorter test cycles when trying to release the
product

Referenced from Prof.Redley of CMU

Build & Release Data Collection
▪ Build Log Data
▪ Build & Release Process
• # of builds
• Changes (by CR#) in each build
▪ System Test Process
• # of product release cycles required to approve
product is ready to ship
• Elapsed time of each product release cycle
• # of defects found during System Test per
release cycle
• Effort required to test each product release
Referenced from Prof.Redley of CMU
Rules for Making Code Changes
▪ Developers are responsible for:
• Keeping their machine in synch with the configuration
management system
• Creating/updating automated unit tests
• Creating/updating automated unit and integration
tests
• Ensuring that all tests run successfully before
checking code back into master repository
• Resolving conflicts when checking code back in
• Updating change documentation

Referenced from Prof.Redley of CMU

Summary
▪ Software Development Teams MUST HAVE a
Software Configuration Management system
▪ Implement Continuous Integration
• Once you have you’ll wonder how you ever got along
without it!

Referenced from Prof.Redley of CMU

Video link
◼ https://www.youtube.com/watch?v=ce
73O3pkgbU

Referenced from Prof.Redley of CMU

References

❑ Ian Sommerville. Software engineering update 10th

edition. Wesley Computer Publishing 2018 Page: 730 -
749
❑ https://en.wikipedia.org/wiki/Software_configuration_mana
gement
❑ https://en.wikipedia.org/wiki/Apache_Subversion
Introduction to
Software Engineering
Configuration Management

Instructor: Huy Nguyen Dang Quang, Msc

Update 2019 Email: [email protected]
Agenda
• Version management
• System building
• Change management
• Release management
Configuration management
• Software systems are constantly changing during
development and use.
• Configuration management (CM) is concerned with the
policies, processes and tools for managing changing
software systems.
• You need CM because it is easy to lose track of what
changes and component versions have been
incorporated into each system version.
• CM is essential for team projects to control changes
made by different developers
CM activities
• Version management
• Keeping track of the multiple versions of system components
and ensuring that changes made to components by different
developers do not interfere with each other.
• System building
• The process of assembling program components, data and
libraries, then compiling these to create an executable system.
• Change management
• Keeping track of requests for changes to the software from
customers and developers, working out the costs and impact
of changes, and deciding the changes should be implemented.
• Release management
• Preparing software for external release and keeping track of
the system versions that have been released for customer
use.
Configuration management activities
Agile development and CM
• Agile development, where components and systems are
changed several times per day, is impossible without
using CM tools.
• The definitive versions of components are held in a
shared project repository and developers copy these into
their own workspace.
• They make changes to the code then use system building
tools to create a new system on their own computer for
testing. Once they are happy with the changes made,
they return the modified components to the project
repository.
Development phases
• A development phase where the development team is
responsible for managing the software configuration and
new functionality is being added to the software.
• A system testing phase where a version of the system is
released internally for testing.
• No new system functionality is added. Changes made are bug
fixes, performance improvements and security vulnerability
repairs.
• A release phase where the software is released to
customers for use.
• New versions of the released system are developed to repair
bugs and vulnerabilities and to include new features.
Multi-version systems
• For large systems, there is never just one ‘working’
version of a system.
• There are always several versions of the system at
different stages of development.
• There may be several teams involved in the development
of different system versions.
Multi-version system development
CM terminology
Term Explanation
Baseline A baseline is a collection of component versions that make
up a system. Baselines are controlled, which means that the
versions of the components making up the system cannot be
changed. This means that it is always possible to recreate a
baseline from its constituent components.
Branching The creation of a new codeline from a version in an existing
codeline. The new codeline and the existing codeline may
then develop independently.
Codeline A codeline is a set of versions of a software component and
other configuration items on which that component depends.
Configuration The process of ensuring that versions of systems and
(version) control components are recorded and maintained so that changes
are managed and all versions of components are identified
and stored for the lifetime of the system.
Configuration item Anything associated with a software project (design, code,
or software test data, document, etc.) that has been placed under
configuration item configuration control. There are often different versions of a
(SCI) configuration item. Configuration items have a unique name.
Mainline A sequence of baselines representing different versions of a
system.
CM terminology
Term Explanation
Merging The creation of a new version of a software component by
merging separate versions in different codelines. These
codelines may have been created by a previous branch of
one of the codelines involved.
Release A version of a system that has been released to customers
(or other users in an organization) for use.
Repository A shared database of versions of software components
and meta-information about changes to these components.
System building The creation of an executable system version by compiling
and linking the appropriate versions of the components
and libraries making up the system.
Version An instance of a configuration item that differs, in some
way, from other instances of that item. Versions always
have a unique identifier.
Workspace A private work area where software can be modified
without affecting other developers who may be using or
modifying that software.
Version management
Version management
• Version management (VM) is the process of keeping track
of different versions of software components or
configuration items and the systems in which these
components are used.
• It also involves ensuring that changes made by different
developers to these versions do not interfere with each
other.
• Therefore version management can be thought of as the
process of managing codelines and baselines.
Codelines and baselines
• A codeline is a sequence of versions of source code with
later versions in the sequence derived from earlier
versions.
• Codelines normally apply to components of systems so
that there are different versions of each component.
• A baseline is a definition of a specific system.
• The baseline therefore specifies the component versions
that are included in the system plus a specification of the
libraries used, configuration files, etc.
Baselines
• Baselines may be specified using a configuration
language, which allows you to define what components
are included in a version of a particular system.
• Baselines are important because you often have to
recreate a specific version of a complete system.
• For example, a product line may be instantiated so that there
are individual system versions for different customers. You may
have to recreate the version delivered to a specific customer if,
for example, that customer reports bugs in their system that
have to be repaired.
Codelines and baselines
Version control systems
• Version control (VC) systems identify, store and control
access to the different versions of components. There
are two types of modern version control system
• Centralized systems, where there is a single master repository
that maintains all versions of the software components that
are being developed. Subversion is a widely used example of a
centralized VC system.
• Distributed systems, where multiple versions of the
component repository exist at the same time. Git is a widely-
used example of a distributed VC system.
Key features of version control
systems
• Version and release identification
• Change history recording
• Support for independent development
• Project support
• Storage management
Public repository and private
workspaces
• To support independent development without interference,
version control systems use the concept of a project
repository and a private workspace.
• The project repository maintains the ‘master’ version of all
components. It is used to create baselines for system
building.
• When modifying components, developers copy (check-out)
these from the repository into their workspace and work on
these copies.
• When they have finished their changes, the changed
components are returned (checked-in) to the repository.
Centralized version control
• Developers check out components or directories of
components from the project repository into their
private workspace and work on these copies in their
private workspace.
• When their changes are complete, they check-in the
components back to the repository.
• If several people are working on a component at the
same time, each check it out from the repository. If a
component has been checked out, the VC system warns
other users wanting to check out that component that
it has been checked out by someone else.

11/12/2014 Chapter 25 Configuration management 20

Repository Check-in/Check-out
Distributed version control
• A ‘master’ repository is created on a server that
maintains the code produced by the development team.
• Instead of checking out the files that they need, a
developer creates a clone of the project repository that
is downloaded and installed on their computer.
• Developers work on the files required and maintain the
new versions on their private repository on their own
computer.
• When changes are done, they ‘commit’ these changes
and update their private server repository. They may
then ‘push’ these changes to the project repository.
Repository
cloning
Benefits of distributed version control
• It provides a backup mechanism for the repository.
• If the repository is corrupted, work can continue and the
project repository can be restored from local copies.
• It allows for off-line working so that developers can
commit changes if they do not have a network
connection.
• Project support is the default way of working.
• Developers can compile and test the entire system on their
local machines and test the changes that they have made.
Open source development
• Distributed version control is essential for open source
development.
• Several people may be working simultaneously on the same
system without any central coordination.
• As well as a private repository on their own computer,
developers also maintain a public server repository to
which they push new versions of components that they
have changed.
• It is then up to the open-source system ‘manager’ to decide
when to pull these changes into the definitive system.
Open-source development
Branching and merging
• Rather than a linear sequence of versions that reflect
changes to the component over time, there may be
several independent sequences.
• This is normal in system development, where different
developers work independently on different versions of the
source code and so change it in different ways.
• At some stage, it may be necessary to merge codeline
branches to create a new version of a component that
includes all changes that have been made.
• If the changes made involve different parts of the code, the
component versions may be merged automatically by
combining the deltas that apply to the code.
Branching and merging
Storage management
• When version control systems were first developed,
storage management was one of their most important
functions.
• Disk space was expensive and it was important to
minimize the disk space used by the different copies of
components.
• Instead of keeping a complete copy of each version, the
system stores a list of differences (deltas) between one
version and another.
• By applying these to a master version (usually the most
recent version), a target version can be recreated.
Storage management using deltas
Storage management in Git
• As disk storage is now relatively cheap, Git uses an
alternative, faster approach.
• Git does not use deltas but applies a standard
compression algorithm to stored files and their
associated meta-information.
• It does not store duplicate copies of files. Retrieving a
file simply involves decompressing it, with no need to
apply a chain of operations.
• Git also uses the notion of packfiles where several
smaller files are combined into an indexed single file.
System building
System building
• System building is the process of creating a complete,
executable system by compiling and linking the system
components, external libraries, configuration files, etc.
• System building tools and version management tools
must communicate as the build process involves
checking out component versions from the repository
managed by the version management system.
• The configuration description used to identify a baseline
is also used by the system building tool.
Build platforms
• The development system, which includes development
tools such as compilers, source code editors, etc.
• Developers check out code from the version management
system into a private workspace before making changes to the
system.
• The build server, which is used to build definitive,
executable versions of the system.
• Developers check-in code to the version management system
before it is built. The system build may rely on external
libraries that are not included in the version management
system.
• The target environment, which is the platform on which
the system executes.
System building
Build system functionality
• Build script generation
• Version management system integration
• Minimal re-compilation
• Executable system creation
• Test automation
• Reporting
• Documentation generation
System platforms
• The development system, which includes
development tools such as compilers, source code
editors, etc.
• The build server, which is used to build definitive,
executable versions of the system. This server
maintains the definitive versions of a system.
• The target environment, which is the platform on
which the system executes.
• For real-time and embedded systems, the target
environment is often smaller and simpler than the
development environment (e.g. a cell phone)
Development, build, and target platforms
Agile building
• Check out the mainline system from the version
management system into the developer’s private
workspace.
• Build the system and run automated tests to ensure that
the built system passes all tests. If not, the build is
broken and you should inform whoever checked in the
last baseline system. They are responsible for repairing
the problem.
• Make the changes to the system components.
• Build the system in the private workspace and rerun
system tests. If the tests fail, continue editing.
Agile building
• Once the system has passed its tests, check it into the
build system but do not commit it as a new system
baseline.
• Build the system on the build server and run the tests.
You need to do this in case others have modified
components since you checked out the system. If this is
the case, check out the components that have failed
and edit these so that tests pass on your private
workspace.
• If the system passes its tests on the build system, then
commit the changes you have made as a new baseline
in the system mainline.
Continuous integration
Pros and cons of continuous integration
• Pros
• The advantage of continuous integration is that it allows
problems caused by the interactions between different
developers to be discovered and repaired as soon as possible.
• The most recent system in the mainline is the definitive
working system.
• Cons
• If the system is very large, it may take a long time to build and
test, especially if integration with other application systems is
involved.
• If the development platform is different from the target
platform, it may not be possible to run system tests in the
developer’s private workspace.
Daily building
• The development organization sets a delivery time (say
2 p.m.) for system components.
• If developers have new versions of the components that they
are writing, they must deliver them by that time.
• A new version of the system is built from these components
by compiling and linking them to form a complete system.
• This system is then delivered to the testing team, which
carries out a set of predefined system tests
• Faults that are discovered during system testing are
documented and returned to the system developers. They
repair these faults in a subsequent version of the
component.
Minimizing recompilation
• Tools to support system building are usually designed to
minimize the amount of compilation that is required.
• They do this by checking if a compiled version of a
component is available. If so, there is no need to
recompile that component.
• A unique signature identifies each source and object
code version and is changed when the source code is
edited.
• By comparing the signatures on the source and object
code files, it is possible to decide if the source code was
used to generate the object code component.
File identification
• Modification timestamps
• The signature on the source code file is the time and
date when that file was modified. If the source code file
of a component has been modified after the related
object code file, then the system assumes that
recompilation to create a new object code file is
necessary.
• Source code checksums
• The signature on the source code file is a checksum
calculated from data in the file. A checksum function
calculates a unique number using the source text as
input. If you change the source code (even by 1
character), this will generate a different checksum. You
can therefore be confident that source code files with
different checksums are actually different.
Timestamps vs checksums
• Timestamps
• Because source and object files are linked by name rather
than an explicit source file signature, it is not usually possible
to build different versions of a source code component into
the same directory at the same time, as these would generate
object files with the same name.
• Checksums
• When you recompile a component, it does not overwrite the
object code, as would normally be the case when the
timestamp is used. Rather, it generates a new object code file
and tags it with the source code signature. Parallel
compilation is possible and different versions of a component
may be compiled at the same time.
Linking source and object code
Change management
Change management
• Organizational needs and requirements change during
the lifetime of a system, bugs have to be repaired and
systems have to adapt to changes in their environment.
• Change management is intended to ensure that system
evolution is a managed process and that priority is given
to the most urgent and cost-effective changes.
• The change management process is concerned with
analyzing the costs and benefits of proposed changes,
approving those changes that are worthwhile and
tracking which components in the system have been
changed.
The change
management
process
A partially completed change request
form (a)
Change Request Form

Project: SICSA/AppProcessing Number: 23/02

Change requester: I. Sommerville Date: 20/07/12
Requested change: The status of applicants (rejected, accepted, etc.) should be shown
visually in the displayed list of applicants.

Change analyzer: R. Looek Analysis date: 25/07/12

Components affected: ApplicantListDisplay, StatusUpdater

Associated components: StudentDatabase

A partially completed change request
form (b)
Change Request Form

Change assessment: Relatively simple to implement by changing the display

color according to status. A table must be added to relate status to colors. No
changes to associated components are required.

Change priority: Medium

Change implementation:
Estimated effort: 2 hours
Date to SGA app. team: 28/07/12 CCB decision date: 30/07/12
Decision: Accept change. Change to be implemented in Release 1.2
Change implementor: Date of change:
Date submitted to QA: QA decision:
Date submitted to CM:
Comments:
Factors in change analysis
• The consequences of not making the change
• The benefits of the change
• The number of users affected by the change
• The costs of making the change
• The product release cycle
Derivation history

// SICSA project (XEP 6087)

//
// APP-SYSTEM/AUTH/RBAC/USER_ROLE
//
// Object: currentRole
// Author: R. Looek
// Creation date: 13/11/2012
//
// © St Andrews University 2012
//
// Modification history
// Version Modifier Date Change Reason
// 1.0 J. Jones 11/11/2009 Add header Submitted to CM
// 1.1 R. Looek 13/11/2012 New field Change req. R07/02
Change management and agile methods
• In some agile methods, customers are directly involved
in change management.
• The propose a change to the requirements and work
with the team to assess its impact and decide whether
the change should take priority over the features
planned for the next increment of the system.
• Changes to improve the software improvement are
decided by the programmers working on the system.
• Refactoring, where the software is continually improved,
is not seen as an overhead but as a necessary part of the
development process.
Release management
Release management
• A system release is a version of a software system that is
distributed to customers.
• For mass market software, it is usually possible to
identify two types of release: major releases which
deliver significant new functionality, and minor releases,
which repair bugs and fix customer problems that have
been reported.
• For custom software or software product lines, releases
of the system may have to be produced for each
customer and individual customers may be running
several different releases of the system at the same
time.
Release components
• As well as the the executable code of the system, a
release may also include:
• configuration files defining how the release should be
configured for particular installations;
• data files, such as files of error messages, that are needed for
successful system operation;
• an installation program that is used to help install the system
on target hardware;
• electronic and paper documentation describing the system;
• packaging and associated publicity that have been designed
for that release.
Factors influencing system release
planning
Factor Description
Competition For mass-market software, a new system release may be
necessary because a competing product has introduced
new features and market share may be lost if these are not
provided to existing customers.
Marketing The marketing department of an organization may have
requirements made a commitment for releases to be available at a
particular date.
Platform changes You may have to create a new release of a software
application when a new version of the operating system
platform is released.
Technical quality of If serious system faults are reported which affect the way in
the system which many customers use the system, it may be necessary
to issue a fault repair release. Minor system faults may be
repaired by issuing patches (usually distributed over the
Internet) that can be applied to the current release of the
system.
Release creation
• The executable code of the programs and all associated data
files must be identified in the version control system.
• Configuration descriptions may have to be written for different
hardware and operating systems.
• Update instructions may have to be written for customers who
need to configure their own systems.
• Scripts for the installation program may have to be written.
• Web pages have to be created describing the release, with links
to system documentation.
• When all information is available, an executable master image of
the software must be prepared and handed over for distribution
to customers or sales outlets.
Release tracking
• In the event of a problem, it may be necessary to
reproduce exactly the software that has been delivered
to a particular customer.
• When a system release is produced, it must be
documented to ensure that it can be re-created exactly in
the future.
• This is particularly important for customized, long-
lifetime embedded systems, such as those that control
complex machines.
• Customers may use a single release of these systems for many
years and may require specific changes to a particular software
system long after its original release date.
Release reproduction
• To document a release, you have to record the specific
versions of the source code components that were
used to create the executable code.
• You must keep copies of the source code files,
corresponding executables and all data and
configuration files.
• You should also record the versions of the operating
system, libraries, compilers and other tools used to
build the software.
Release planning
• As well as the technical work involved in creating a
release distribution, advertising and publicity material
have to be prepared and marketing strategies put in
place to convince customers to buy the new release of
the system.
• Release timing
• If releases are too frequent or require hardware upgrades,
customers may not move to the new release, especially if
they have to pay for it.
• If system releases are too infrequent, market share may be
lost as customers move to alternative systems.
Software as a service
• Delivering software as a service (SaaS) reduces the
problems of release management.
• It simplifies both release management and system
installation for customers.
• The software developer is responsible for replacing the
existing release of a system with a new release and this
is made available to all customers at the same time.
Key points
• Configuration management is the management of an evolving
software system. When maintaining a system, a CM team is
put in place to ensure that changes are incorporated into the
system in a controlled way and that records are maintained
with details of the changes that have been implemented.
• The main configuration management processes are concerned
with version management, system building, change
management, and release management.
• Version management involves keeping track of the different
versions of software components as changes are made to
them.
Key points
• System building is the process of assembling system
components into an executable program to run on a target
computer system.
• Software should be frequently rebuilt and tested
immediately after a new version has been built. This makes it
easier to detect bugs and problems that have been
introduced since the last build.
• Change management involves assessing proposals for
changes from system customers and other stakeholders and
deciding if it is cost-effective to implement these in a new
version of a system.
• System releases include executable code, data files,
configuration files and documentation. Release management
involves making decisions on system release dates, preparing
all information for distribution and documenting each system
release.
Q & A?