1

CHAPTER 1: INTRODUCTION TO SOFTWARE ENGINEERING

Software engineering

 Concerned with theories, methods, and tools for professional software development.
 Expenditure on software represents a significant fraction of GNP (Gross National Product) in all
developed countries.
 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
o Using appropriate theories and methods to solve problems bearing in mind organization
and financial constraints.
 All aspects of software production
o Technical process of development, project management, and development of
tools/methods… to support software production

Importance of software engineering

 Be able to produce reliable and trustworthy systems economically and quickly as more and
more individuals/society rely on advanced software system
 Instead of writing the program as if it were a personal programming project, it is typically more
cost-effective in the long run to apply software engineering processes and techniques for
software systems. The majority of system types, come from modifying the software after the
system has been put into service.

Software costs

 Software costs often dominate computer system costs. PC software’s costs > PC hardware’s
costs
 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.
 2

Software project failure

 Increasing system complexity

o The requirements evolve as we construct bigger, more complicated systems thanks to
new software engineering approaches. Systems need to be developed and supplied
more quickly, they need to be bigger and even more complicated, and they need to
have new capabilities that were previously unthinkable
 Failure to use software engineering methods
o Writing computer programs without using software engineering methods is fairly
simple. As businesses' goods and services have developed, many have strayed into the
software development space. They don't regularly use software engineering techniques
in their work. As a result, their software is frequently more expensive and less reliable
than it should be.

Professional software development

 Software
o Computer programs and associated documentation. Software products may be
developed for a particular customer or may be developed for a general market.
 Attributes of good software
o Should deliver the required functionality and performance to the user and should be
maintainable, dependable, and usable.
 Software engineering
o An engineering discipline that is concerned with all aspects of software production.
 Fundamental software engineering activities
o Software specification, software development, software validation, software evolution.
 Difference between software engineering and computer science
o Computer science: focuses on theory and fundamentals.
o Software engineering: concerned with the practicalities of developing and delivering
useful software.
 Difference between software engineering and system engineering
o System engineering: concerned with all aspects of computer-based systems
development including hardware, software, and process engineering.
 3

o Software engineering: part of this more general process

 What are the key challenges facing software engineering?
o Coping with increasing diversity, demands for reduced delivery times and developing
trustworthy software.
 Costs of software engineering
o 60% of software costs are development costs.
o 40% of software costs are testing costs.
o For custom software, evolution costs often exceed development costs.
 Best software engineering techniques and methods
o Software projects have to be professionally managed and developed.
o Different techniques are appropriate for different types of system  cannot say that
one method is better than another.
 What differences has the web made to software engineering?
o Wed led to the availability of software services and the possibility of developing highly
distributed service-based systems.
o Web-based systems development has led to important advances in programming
languages and software reuse.

Software products

 Generic products
o Stand-alone systems that are marketed and sold to any customer who wishes to buy
them.
o Example: PC software – graphics programs; project management tool; CAD software;
software for specific markets – appointments systems for dentists
 Customized products
o Software that is commissioned by a specific customer to meet their own needs.
o Example: Embedded control systems, air traffic control software, traffic monitoring
systems.

Product specification

 Generic products
 4

o The specification of what the software should do is owned by the software developer
and decisions on software change are made by the developer.
 Customized products
o The specification of what the software should do is owned by the customer for the
software and they make decisions on software changes that are required.

Essential attributes of good software

 Maintainability
o Software SHOULD BE written in such a way so that it can evolve to meet the changing
needs of customers.
o This is a critical attribute because software change is inevitable requirement of a
changing business environment
 Dependability and security
o Software dependability includes a range of characteristics including reliability, security,
and safety.
o Dependable software SHOULD NOT cause physical or economic damage in the event of
system failure.
o Malicious users SHOULD NOT be able to access or damage the system
 Efficiency
o Software SHOULD NOT make wasteful use of system resources such as memory and
processor cycles.
o Efficiency therefore includes responsiveness, processing time, memory utilization, …
 Acceptability
o Software MUST be acceptable to the type of users for which it is designed  it MUST be
understandable, usable, and compatible with other systems that they use.

Software process activities

 Software specification: the process through which customers and engineers specify the
requirements for the software that will be create.
 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
 5

 Software evolution: where the software is modified to reflect changing customer and market
requirements.

General issues that affect software

 Heterogeneity
o Systems must increasingly function as distributed systems over networks that contain
various computer and mobile device kinds.
 Business and social change
o With the growth of emerging economies and the availability of new technology,
business and society are evolving at an incredibly rapid pace. They must be able to
modify their current software and create new software quickly.

General issues that affect software

 Security and trust

o We must be able to trust the software since it affects every part of our existence.
 Scale
o From very small embedded systems in portable or wearable devices to Internet-scale,
cloud-based systems that service a worldwide community, software must be developed
across a very broad range of scales.

Software engineering diversity

 There are numerous different kinds of software systems, and no single set of software
techniques can be used for all of them.
 The methods and tools used in software engineering depend on the kind of application being
produced, the client's needs, and the team's prior experience.

Application types

 Stand-alone applications
o These are local computer-based application platforms, like PCs. They come with all
necessary features and don't require a network connection.
 Interactive transaction-based applications
o Applications that users can access from their own PCs or terminals while running on a
remote device. Web applications like e-commerce ones are among them.
 6

 Embedded control system

o These are software-based hardware management and control solutions. In terms of
quantity, embedded systems most likely outnumber all other types of systems.
 Batch processing systems
o These are commercial systems built to handle big batches of data processing. To
produce corresponding outputs, they process a lot of different inputs.
 Entertainment systems
o These are devices that are primarily designed for individual usage and are meant to
entertain the user.
 Systems for modeling and simulation
o These systems were created by scientists and engineers to model complex physical
events or processes that involve numerous, unrelated, interacting components.
 Data collection systems
o These are systems that gather information about their surroundings from a variety of
sensors and transmit it to further systems for processing.
 Systems of systems
o These systems are built from a variety of other software systems.

Software engineering fundamentals

 Some fundamental principles apply to all types of software system, irrespective of the
development techniques used:
o A controlled and clear development process should be used while creating systems. Of
course, several processes are employed for various software kinds.
o For all systems, dependability and performance are essential.
o It's important to understand and manage the software requirements and specifications
(what the software should be able to perform).
o You should reuse previously created software whenever possible rather than creating
new software.
 7

Software engineering ethics

 More than just the use of technical abilities is involved in software engineering.
 If software engineers want to be considered as professionals, they must conduct themselves
honestly and responsibly.
 More than only upholding the law, ethical behavior requires following to a set of morally just
ideals.

Issues of professional responsibility

 Confidentiality
o Whether or not a formal confidentiality agreement has been written, engineers should
generally maintain the confidentiality of their employers or clients.
 Competence
o Engineers shouldn't exaggerate how skilled they are. They shouldn't intentionally accept
work that is beyond their areas of expertise.
 Intellectual property rights
o Engineers need to be knowledgeable with regional laws controlling the use of
intellectual property, including copyright and patents. They should take care to preserve
the intellectual property of their clients and employers.
 Computer misuse
o Software developers shouldn't abuse other people's machines by using their technical
knowledge. Computer abuse can range from very minor offences, like playing games on
a work computer, to very serious ones (dissemination of viruses)
 8

CHAPTER 2: SOFTWARE PROCESSES

The software processes.

 A structured set activities required to develop a software system.

 Many different software processes but all involve:
o Specification – defining what the system should do.
o Design and implementation – defining the organization of the system and implementing
the system.
o Validation – checking that it does what the customer wants.
o Evolution – changing the system in response to changing customer needs.
 A software process model – an abstract representation of a process. It presents a description of
a process from some particular perspective.

Software process descriptions

 Activities in processes – specifying a data model, designing a user interface, … and the ordering
of these activities.
 Process description may also include:
o Products – the outcomes of a process activity
o Roles – reflect the responsibilities of the people involved in the process.
o Pre- and post-conditions – statements that are true before and after a process activity
has been enacted or a product produced.

Plan-driven and agile processes

 Plan-driven processes – processes where all of the process activities are planned in advance and
progress is measured against this plan.
 In agile processes, planning is incremental, and it is easier to change the process to reflect
changing customer requirements.
 In practice, most practical processes include elements of both plan-driven and agile approaches.
 There are NO right or wrong software process.
 9

Software process models

 The waterfall model

o Plan-driven model. Separate and distinct phases of specification and development

o Waterfall model phases

 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 MAIN drawback of the waterfall model is the difficulty of accommodating
change after the process is underway.
 In principle, a phase has to be complete BEFORE moving onto the next phase
o Waterfall model problems
 Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements
 Only appropriate when the requirements are clearly known and when
the amount of change during the design process would be relatively
small
 Business systems rarely have consistent requirements
 10

 Waterfall model is MOSTLY used for LARGE SYSTEMS ENGINEERING PROJECTS

where a system is developed at several site
 In those circumstances, the plan-driven nature of the waterfall model
helps coordinate the work
 Incremental development
o Specification, development, and validation are interleaved. May be plan-driven or agile

o 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
 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 waterfall process
o Incremental development problems
 The process is not visible
 System structure tends to degrade as new increments are added
 11

 Integration and configuration

o The system is assembled from existing configurable components. May be plan-driven or
agile
o Based on software reuse where systems are integrated from existing components or
application systems (COTS – Commercial-off-the-shelf system)
o Reused elements may be configured to adapt their behavior and functionality to a user’s
requirements
o Reuse is now the standard approach for building many types of business system

Types of reusable software

 Stand-alone application systems (COTS) that are configured for use in particular environment.
 Collections of objects that are developed as a package to be integrated with a component
framework such as .NET or J2EE.
 Web services that are developed according to service standards and which are available for
remote invocation.

Reuse-oriented software engineering

 Advantages and disadvantages

o Reduced costs and risks as less software is developed from scratch
o Faster delivery and deployment system
o Requirements compromises are inevitable so system may not meet real needs of users
o Loss of control over evolution of reused system elements.
 12

Process activities

 REAL software processes are inter-leaved sequences of technical, collaborative, and managerial
activities with the overall goal of specifying, designing, implementing, and testing a software
system
 4 basis process activities of specification, development, validation, and evolution are organized
differently in different development processes
 Example: waterfall model
o In waterfall model, they are organized in sequence, whereas in incremental
development they are inter-leaved

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
o Requirements elicitation and analysis
o Requirements specification
o Requirements validation
 13

Software design and implementation

 The process of converting the system specification into an executable system

 Software design
o Design a software structure that realizes the specification
 Implementation
o 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 – identify the overall structure of the system, the principal components
(subsystems or modules), their relationships and how they are distributed
 Databased design – design the system data structures and how these are to be represented in a
database
 Interface design – define the interfaced between system components
 Component selection and design – search for reusable components. If unavailable, you design
how it will operate
 14

System implementation

 The software is implemented either by developing a program or programs or by configuring an

application system
 Design and implementation are inter-leaved 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
 Involve 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

Stage of testing

 Component testing
o Individual components are tested independently
o Components may be functions or objects or coherent groupings of these entities
 System testing
o Testing of the system as a whole. Testing of emergent properties is particularly
important
 Customer testing
o Testing with customer data to check that the system meets the customer’s needs
 15

Testing phases in a plan-driven software process (V-model)

Software 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
 16

Copy with change

 Change is inevitable in all large software projects

o Business changes lead to new and changed system requirements
o New technologies open up new possibilities for improving implementations
o Changing platforms require application changes
 Change leads to rework so the costs of change include both rework (e.g. re-analyzing
requirements) as well as the costs of implementing new functionality

Reducing the costs of rework

 Change anticipation is the technique of anticipation potential changes in software before

considerable rework is necessary
o Example:
 A prototype system may be developed to show some key features of the system
to customers
 Change tolerance, which refers to the process’s ability to accommodate changes at a low cost
o This involves a type of progressive development. Modifications that have not yet been
developed in increments may be implemented. If this is not possible, the change might
only have required changing a single increment, or a very tiny portion of the system

Coping with changing requirements

 System prototyping – 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 – 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:
 17

o The requirements engineering process to help with requirements elicitation and

validation
o In design processes to explore options and develop a UI design
o 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

Process of prototype development

Prototype development

 May be based on rapid prototyping languages or tools

 May involve leaving out functionality
o Prototype should focus on areas of the product that are not well-understood
o Error checking and recovery may not be included in the prototype
o 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:
o It may be impossible to tune the system to meet non-functional requirements
 18

o Prototypes are normally undocumented

o The prototype structure is usually degraded through rapid change
o The prototype probably will not meet normal organizational quality standards

Incremental delivery

 Instead of offering the system as a single delivery, development and delivery are divided into
increments, each of which provides a portion of the necessary capability
 User requirements are prioritized, 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
o Develop the system in increments and evaluate each increment before proceeding to
the development of the next increment
o Normal approach used in agile methods
o Evaluation done by user/customer proxy
 Incremental delivery
o Deploy an increment for use by end-users
o More realistic evaluation about practical use of software
o Difficult to implement for replacement systems as increments have less functionality
than the system being replaced
 19

o 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
o Problems
 Most systems require a set of basis facilities that are used by different
parts of the system
 It can be challenging to discover common facilities that are
required by all increments because needs are not established in
full until an increment is to be implemented
 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
 20

The spiral model

 A heavy-weight, plan-driven, highly structured approach for large projects

 Especially designed for those with higher chances of failure
 Combines iterative model, emphasizes risk assessment, customer participation, prototyping, and
more…
definitely an iterative process
 21

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.
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.
Processes may be structured for iterative development and delivery so that changes may be made
without disrupting the system as a whole
The principal approaches to process improvement are agile approaches, geared to reducing process
overheads, and maturity-based approaches based on better process management and the use of
good software engineering practice.
The SEI process maturity framework identifies maturity levels that essentially correspond to the use
of good software engineering practice
 22

CHAPTER 3: AGILE SOFTWARE DEVELOPMENT

Rapid software development

 Rapid development and delivery is now often the most important requirement for software
systems
o Businesses operate in a fast – changing requirement and it is practically impossible to
produce a set of stable software requirements
o 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

 23

 Plan-driven development
o 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
o Not necessarily waterfall model – plan-driven, incremental development is possible
o Iteration occurs within activities
 Agile development
o 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

 Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s
led to the creation of agile methods. These methods:
o Focus on the code rather than the design
o Are based on an iterative approach to software development
o 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 (by limiting
documentation) and to be able to respond quickly to changing requirements without excessive
rework
 24

Agile manifesto

 Individuals and interactions over processes and tools.

 Working software over comprehensive documentation.
 Customer collaboration over contract negotiation
 Responding to change over following plan
 While there is value in the items on the right, we value the items on the left
more

Principles of agile methods

 Customer involvement
o Customers SHOULD BE closely involved throughout the development process.
o Their role is provided and prioritize new system requirements and to evaluate the
iterations of the system
 Incremental delivery
o The software is developed in increment with the customer specifying the requirements
to be included in each increment.
 People do not process
o 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
process
 Embrace change
o Expect the system requirements to change and so design the system to accommodate
these changes
 Maintain simplicity
o 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

 25

 Product development where a software company is developing a small or medium-sized product

for sale
o Virtually all software products and apps are now developed using an agile approach
 Customer system development within organization, where there is 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

Scrum

 An agile method that focuses on managing iterative development rather than specific agile
practices
 There are 3 phases in Scrum:
o The initial phase is an outline planning phase where you establish the general
objectives for the project and design the software architecture
o Followed by a series of sprint cycles, where each cycle develops an increment of the
system
o The project closure phases 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

 Development team
o 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 product increment
 26

o The software increment that is delivered from a sprint. The idea is that this 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, this is not always
achievable
 Product backlog
o This is a list of tasks that the Scrum team needs to complete. They could be user stories,
software requirement specifications, feature definitions, or descriptions of additional
tasks like architecture definition or user documentation
 Product owner
o A person (or potentially a small group) whose responsibility it is to identify product
requirements or features, rank them for development, and then continually assess the
product backlog to make sure the project is still meeting crucial business needs. The
product owner may be a consumer or another stakeholder representative, such as a
product manager in a software firm
 Scrum
o A daily scrum team meeting where tasks for the day are prioritized and progress is
reviewed. This SHOULD ideally be a brief, in-person meeting with the entire team.
 Scrum-master
o The scrum-master is in charge of ensuring that the scrum methodology is adhered to
and directing the team in its efficient application. He or she is charge of liaising with the
rest of the business and making sure that outside interference does not distract the
scrum team. The scrum-master should not be viewed as a project manager, insist the
scrum developers. Others, however, might not always find it simple to distinguish
between the two
 Sprint
o An improvement cycles. Sprints typically last 2-4 weeks
 Velocity
o An estimate of the amount of work on the product backlog that a team can complete in
one sprint. Knowing a team’s velocity enables them to predict how much ground they
can cover in a sprint and offers a foundation for evaluating how well they are
performing.
 27

Scrum sprint cycle

Scrum framework

ROLES

 PRODUCT OWNER
 SCRUM-MASTER
 TEAM

MEETINGS

 SPRINT PLANNING
 SPRINT REVIEW
 SPRINT RETROSPECTIVE
 DAILY SCRUM MEETING

COMPONENTS

 PRODUCT BACKLOG
 SPRINT BACKLOG
 BURNDOWN CHARTS

Product owner manager

 28

 Define the features of the product (specification)

 Decide on release date and content 14-Dec
 Be responsible for the profitability of the product (ROI) (which 335 need not do)
 Prioritize features according to market value (what you’re supposed to learn in 335)
 Adjust features and priority every iteration, as needed (not in 335)
 Accept or reject work results (or grade the projects)

The Scrum-master (Rick and SLs, sort of)

 Represents management to the project

 Responsible for enacting scrum values and practices (summarized in grading criteria, schedule,
meetings)
 Removes impediments (respond if things are getting in the way)
 Ensure that the team is fully functional and productive (summarized in grading criteria,
schedule, meetings)
 Enable close co-operation across all roles and functions (meetings)
 Shield the team from external interferences (we’re)

The team

 Typically, 5-9 people (3-4)

 Cross-functional:
o Programmers, testers, user experience designers…

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 channeled 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

The Scrum sprint cycle

 Sprints are fixed length, normally 2-4 weeks

 29

 The starting point for planning is the product backlog, which is the list of work to be done on the
project
 The project team as a whole chooses the features and functionality from the product backlog to
be created during the sprint while in the selection phase

Putting it all together

The Daily Scrum

 At start of day (team meetings)

 Time boxed: n minutes
 Stand-up: to keep it short
 Not for problem solving, which comes late
o Whole world is invited (PM and team only)
o Only team members, Scrum-master, product owner, can talk
 Helps avoid other unnecessary meetings
 30

Iteration Burndown Chart

 Burn down charts are a graphical representation of work left to do versus time
 31

Teamwork in Scrum
 32

 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
o 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 positive culture is created in which
everyone expects the project to succeed.

Distributed Scrum

 The Scrum-master should be located with the development team so that he/she is aware of
everyday problems
 The product owner should visit the developers and try to establish a good relationship with
them. It is essential that they trust each other.
 Real-time communications between team members for informal communication, particularly
instant messaging and video calls
 Continuous integration, so that all team members can be aware of the state of the product at
any time
 A common development environment for all teams.
 Videoconferencing between the product owner and the development team

Extreme programming
 33

 A very influential agile method, developed in the late 1990s, that introduced a range of agile
development techniques
 Extreme Program (XP) takes an “extreme” approach to iterative development
o New versions may be built several times per day
o Increments are delivered to customers every 2 weeks
o All tests must be run for every build and the build is only accepted IF tests run
successfully

Extreme program release cycle

 Product backlog  user stories

 Sprint (4 weeks)  released (2 weeks)

Extreme programming practices

 34

 Incremental planning
o 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”
 Small releases
o The minimal useful set of functionalities that provides business value is developed first.
Releases of the system are frequent and incrementally add functionality to the first
release
 System metaphor (Description of the system)
o Guide all development with a simple shared story of how the whole system works
 Simple design
o Enough design is carried out meet the current requirements and no more
 Test-first development
o An automated unit test framework is used to write tests for a new piece of functionality
before that functionality itself is implemented
 Refactoring (code refactoring)
o All developers are expected to refactor the code continuously as soon as possible code
improvements are found. This keeps the code simple and maintainable
 Pair programming
o Developers work in pairs, checking each other’s work and providing the support to
always do a good job
 Collective ownership
o 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
o 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
o 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
 35

o 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
 Coding standards
o Programmers write all code in accordance with rules emphasizing communication
throughout the code

Value of extreme programming

 Communication
o Building software systems requires:
 Communicating system requirements to the developers of the system.
 Communicating the software interfaces (APIs) to fellow developers.
o In formal software development methodologies, this task is accomplished through
documentation.
o Extreme programming techniques can be viewed as methods for efficiently building and
disseminating institutional knowledge among members of a development team.
o The goal is to give all developers a shared view of the system which matches the view
held by the users of the system.
o To this end, extreme programming favors simply designs, common metaphors,
collaboration of users and programmers, frequent verbal communication, and
feedback
o During coding, automated code documentation generation tools (e.g., Doxygen,
Javadoc) can be used to facilitate communication between developers.
 Simplicity
o Extreme programming encourages starting with the simplest solution. Extra
functionality can then be added later
o The difference between this approach and more conventional system development
methods is the focus on designing and coding for the needs of today instead of those of
tomorrow, next week, or next month.
o Often summed up as the “You aren’t gonna need it” approach.
 36

o Coding and designing for uncertain future requirements implies the risk of spending
resources on something that might not be needed, while perhaps delaying crucial
features that are needed now.
o A simple design with very simple and neat code could be easily understood by most
programmers in the team.
o When many little steps are made, the customer and the developers have more control
and feedback over the development process and the system that is being developed.
 Feedback
o Feedback from the system – by writing unit tests, or running periodic integration tests,
the programmers have direct feedback from the state of the system after implementing
changes
o Feedback from the customer – the functional tests are provided by the customer and
the testers. They will get concrete feedback about the current state of their system. This
review is planned once in every 2 or 3 weeks during the delivery of each build so the
customer can easily steer the development.
o Feedback from the team – when customers come up with new requirements in the
planning game the team directly gives an estimate of the time that it will take to
implement.
o Feedback is closely related to communication and simplicity.
o Flaws in the system are easily communicated by writing a unit test that proves a certain
piece of code will break.
o The direct feedback from the systems tells programmers to recode this part.
o A customer is able to test the system periodically according to the functional
requirements, simplified as user stories
 Courage
o Several XP practices required courage. One is to always design and code for today and
not for tomorrow. This is an effort to avoid getting bogged down in overly complicated
design and concentrate on what is required now.
o Courage enables developers to feel comfortable with refactoring their code when
necessary. This means reviewing the existing system and modifying it so that future
changes can be implemented more easily.
 37

o Continuous is integration forces all individuals to confront their own code with the
main body of code, which might uncover design flaws or omissions.
o Pair programming forces individuals to uncover their lack of knowledge or erroneous
code to tier peers as they are working in pairs.
o Courage is required when code needs to be thrown away: courage to remove source
code that is obsolete, no matter how much effort was used to write it.
 Respect
o The respect value includes respect for others as well as self-respect.
o Programmers should never commit changes that break compilation that make existing
unit-tests fail, or that otherwise delay the work of their peers.
o Members respect their own work by always striving for high quality and seeking for the
best design for the solution at hand through refactoring, and to follow coding
standards.
o Adopting good values leads to respect gained from others in the team. Nobody on the
team should feel unappreciated or ignored if they embrace the values common to the
team.
o This ensures a high level of motivation and encourages loyalty toward the team and
toward the goal of the project.
o This value is very dependent upon the other values, and is very much oriented toward
people in a team.
 Embracing change
o The principle of embracing change is about not working against changes but embracing
them.
o For instance, if at one of the iterative meetings it appears that the customer’s
requirements have changed dramatically, programmers are to embrace this and plan
the new requirements for the next iteration.
o If the design of the system shows significant flaws that are hampering further
development, its change should be embraced through redesign and refactoring.
o When encountering unit testing failures or integration problems, one should see this as
an opportunity to improve the system.
 38

XP and agile principles

 Incremental development is supported through small frequent system releases.

 Customer involvement means full time customers engagement with the team.
 People do 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 for XP, the method as originally defined is
not widely used.
 Key practices
o User stories for specification
o Refactoring
o Test-first development
o 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.
 39

Task cards for prescribing medication (Example)

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.
 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.
 40

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
o Test-first development
o Incremental test development from scenarios
o User involvement in test development and validation
o Automated test harnesses are used to run all component test each time that a new
release is built.
 Problems
o 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.
o Some tests can be very difficult to write incrementally.
o 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.

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.
o 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 development 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.
 41

 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 automation

 Test automation means that tests are written as executable components before the task is
implemented.
o 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 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.
o 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.

Pair programming

 Pair programming involves programmers working in pairs, developing code together.

 This help 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.
 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.
 42

Agile project management

 The principal responsibility of software project managers is to manage the project so that
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.

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 important to maintain agile fundamentals:
o 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.
 43

 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.
o 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:
o Are systems that are developed using an agile approach maintainable, given the
emphasis in the development process of minimizing formal documentation?
o 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:

o Lack of product documentation
o Keeping customers involved in the development process.
o 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.
 44

Agile and plan-driven methods

 Most projects include elements of plan-driven and agile processes. Deciding on the balance
depends on:
o 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.
o 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.
o 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 This depends on having a customer who is willing and able to spend
involvement 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 Rapid iterations and short-term planning for development does not
delivery 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
 45

Maintain Under pressure from delivery schedules, team members may not
simplicity have time to carry out desirable system simplifications.
People not Individual team members may not have suitable personalities for the
process 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?

o Agile methods are most effective a relatively small co-located team who can
communicate informally.
 What type of system is being developed?
o 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?
o Long-lifetime systems require documentation to communicate the intentions of the
system developers to the support team.
 Is the system subject to external regulation?
o If a system is regulated you will probably be required to produce detailed
documentation as part of the system safety case.
 46

People and teams

 How good are the designers and programmers in the development team?
o 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?
o Design documents may be required if the team is distributed.
 What support technologies are available?
o IDE support for visualization 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.
 47

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

 48

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
o Each team has a Product Owner for their work component and ScrumMaster.
 Product architects
o Each team chooses a product architect, and these architects collaborate to design and
evolve the overall system architecture.
 Release alignment
o The dates of product releases from each team are aligned so that a demonstrable and
complete system is produced.
 Scrum of Scrums
o There is a daily Scrum of Scrums where representatives from each team meet to discuss
progress and 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.
 49

Problems with agile methods

 It can be difficult to keep the interest of customers / users who are involved in the process.
 Team members may be unsuited to the intense involvement that characterizes agile methods.
 Prioritizing changes can be difficult where there are multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other approaches to iterative development.
 Because of their focus on small, tightly integrated teams, there are problems in scaling agile
methods to large systems.
 Less emphasis on documentation - harder to maintain when you get a new team for
maintenance.

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
Scrum is an agile method that provides a project management framework.
 It is centered 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.
 50

CHAPTER 4: REQUIREMENTS ENGINEERING

Requirement 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 generated
during the requirements engineering process.

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.
o May be the basis for a bid for a contract – therefore must be open to interpretation.
o May be the basis for the contract itself – therefore must be defined in detail.
 Both these statements may be called requirements

Requirements abstraction (Davis)

 If a company wishes to let a contract for a large software development project, it MUST defined
its needs in a sufficiently abstract way that a solution is not pre-defined.
 The requirements must be written so that several contractors can bid for the contract,
offering, perhaps, different ways of meeting the client organization’s needs.
 Once a contract has been awarded, the contractor must write a system definition for the client
in more detail so that the client understands and can validate what the software will do
 Both of these documents may be called the requirements document for the
system.
 51

Type of requirement

 User requirements
o Statements in natural languages diagrams of the services the system provides and its
operational constraints. Written for customers.
o Example:
 The Mentcare (mental health care) system shall generate monthly management
reports showing the cost of drugs prescribed by each clinic during that month.
o Readers:
 Client managers
 System end-users
 Client engineers
 Contractor managers
 System architects
 System requirements
o 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.
o Example:
 On the last working day of each month, a summary of the drugs prescribed,
their cost and the prescribing clinics shall be generated.
 The system shall generate the report for printing after 17:30 on the last working
day of the month.
 A report shall be created for each clinic and shall list the individual drug names,
the total number of prescriptions, the number of doses prescribed and the total
cost of the prescribed drugs.
 If drugs are available in different dose units separate reports shall be created for
each dose unit
 Access to drug cost reports shall be restricted to authorized users as listed on a
management access control list.
o Readers:
 52

 System end-users
 Client engineers
 Software architects
 Software developers

System stakeholders

 Any person or organization who is affected by the system in some way and so who has a
legitimate interest.
 Stakeholder types
o End-users
o System managers
o System owners
o External stakeholders

Stakeholders in the Mentcare system

 Patients whose information is recorded in the system.

 Doctors who are responsible for assessing and treating patients.
 Nurses who coordinate the consultations with doctors and administer some treatments.
 Medical receptionists who manage patients’ appointments.
 IT staff who are responsible for installing and maintaining the system.
 A medical ethics manager who must ensure that the system meets current ethical guidelines for
patient care.
 Health care managers who obtain management information from the system.
 Medical records staff who are responsible for ensuring that system information can be
maintained and preserved, and that record keeping procedures have been properly
implemented.

Agile methods and requirements

 Many agile methods argue that producing detailed system requirements is a waste of time as
requirements change so quickly.
 The requirements document is therefore always out of date.
 53

 Agile methods usually use incremental requirements engineering and may express requirements
as “user stories”.
 This is practical for business systems but problematic for systems that require pre-delivery
analysis (e.g., critical systems) or systems developed by several teams.

Functional and non-functional requirements

 Functional requirements
o Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
o May state what the system should not do.
 Non-functional requirements
o Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, …
o Often apply to the system as a whole rather than individual features or services.
 Domain requirements
o 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.

Mentcare system: functional requirements

 A user shall be able to search the appointments lists for all clinics.
 The system shall generate each day, for each clinic, a list of patients who are expected to attend
appointments that day.
 Each staff member using the system shall be uniquely identified by his or her 8-digit employee
number.
 54

Requirements imprecision

 Problems arise when functional requirements are not precisely stated.

 Ambiguous requirements may be interpreted in different ways by developers and users.
 Consider the term search:
o User intention – search for a patient name across all appointments in all clinics;
o Developer interpretation – search for a patient name in an individual clinic. User
chooses clinic then search.

Requirements completeness and consistency

 In principle, requirements should be both complete and consistent:

o Complete:
 They should include descriptions of all facilities required.
o Consistent:
 There SHOULD BE no conflicts or contradictions in the descriptions of the
system facilities.
 In practice, because of system and environmental complexity, it is impossible to produce a
complete and consistent requirement document.

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, …
 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.
 55

Types of non-functional requirement

Non-functional requirements implementation

 Non-functional requirements may affect the overall architecture of a system rather than the
individual components.
o 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.
o It may also generate requirements that restrict existing requirements.
 56

Non-functional classifications

 Product requirements
o Requirements which specify that the delivered product must behave in a particular way
(e.g., execution speed, reliability, …)
 Organizational requirements
o Requirements which are a consequence of organizational policies and procedures (e.g.
process standards used, implementation requirements, …)
 External requirements
o Requirements which arise from factors which are external to the system and its
development process (e.g. interoperability requirements, legislative requirements, …)

Goals and requirements

 Non-functional requirements may be very difficult to state precisely, and imprecise

requirements may be difficult to verify.
 Goal
o A general intention of the user such as ease of use.
 Verifiable non-functional requirement
o A statement using some measure that can be objectively tested.
 Goals are helpful to developers as they convey the intentions of the system users.

Usability requirements

 The system should be easy to use by medical staff and should be organized in such a way that
user errors are minimized. (Goal)
 Medical staff shall be able to use all the system functions after four hours of training. After this
training, the average number of errors made by experienced users shall not exceed two per
hour of system use. (Testable non-functional requirement)
 57

Metrics for specifying non-functional 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 system

Requirements engineering (RE) processes.

 The processes used for RE vary widely depending on the application domain, the people
involved and the organization developing the requirements.
 There are number of generic activities common to all processes.
o Requirements elicitation.
o Requirements analysis.
o Requirements validation.
 58

o Requirements management.
 In practice, RE is an iterative activity in which these processes are interleaved.

Spiral view of the requirements engineering process

Requirements elicitation and analysis

 Sometimes called requirements elicitation or requirements discovery.

 Involves technical staff working with customers to find out about the application domain, the
services that the system should provide and the system’s operational constraints.
 May involve end-users, managers, engineers involved in maintenance, domain experts, trade
unions… These are called stakeholders.
 59

Requirement elicitation

 Software engineers work with a range of system stakeholders to find out about the application
domain, the services that the system should provide, the required system performance,
hardware constraints, other system…
 Stages include:
o Requirements discovery
 Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
o Requirements classification and organization
 Groups related requirements and organized them into coherent clusters.
o Requirements prioritization and negotiation
 Prioritizing requirements and resolving requirements conflicts.
o Requirements specification
 Requirements are documented and input into the next round of the spiral.
 Problems:
o Stakeholders don’t know what they really want.
o Stakeholders express requirements in their own terms.
o Different stakeholders may have conflicting requirements.
o Organizational and political factors may influence the system requirements.
o The requirements change during the analysis process. New stakeholders may emerge,
and the business environment may change.
 60

 The requirements elicitation and analysis process

Interviewing

 Formal or informal interviews with stakeholders are part of most RE processes.

 Types of interviews
o Closed interviews based on pre-determined list of questions.
o Open interviews where various issues are explored with stakeholders.
 Effective interviewing
o Be open-minded, avoid pre-conceived ideas about the requirements and are willing to
listen to stakeholders.
o Prompt the interviewee to get discussions going using a springboard question, a
requirements proposal, or by working together on a prototype system.
 61

Interviews in practice

 Normally a mix of closed and open-ended interviewing.

 Interviews are good for getting an overall understanding of what stakeholders do and how they
might interact with the system.
 Interviewers need to be open-minded without preconceived ideas of what the system should
do.
 You need to prompt the use to talk about the system by suggesting requirements rather than
simply asking them what they want.

Problems with interview

 Application specialists may use language to describe their work that isn’t easy for the
requirements engineer to understand.
 Interviews are not good for understanding domain requirements.
o Requirements engineers cannot understand specific domain terminology.
o Some domain knowledge is so familiar that people find it hard to articulate or think that
it isn’t worth articulating.

Ethnography (nhân chủng học)

 A social scientist spends a considerable time observing and analyzing how people actually
work.
 People do not have to explain or articulate their work.
 Social and organizational factors of importance may be observed.
 Ethnography studies have shown that work is usually richer and more complex than suggested
by simple system models.

Scope of ethnography
 62

 Requirements that are derived from the way that people actually work rather than the way I
which process definitions suggest that they ought to work.
 Requirements that are derived from co-operation and awareness of other people’s activities.

Focused ethnography

 Developed in a project studying the air traffic control process.

 Combines ethnography with prototyping.
 Prototype development results in unanswered questions which focus the ethnographic analysis.
 The problem with ethnography is that it studies existing practices which may have some
historical basis which is no longer relevant.

Ethnography and prototyping for requirements analysis

Stories and scenarios

 Scenarios and user stories are real-life examples of how a system can be used.
 Stories and scenarios are a description of how a system may be used for a particular task.
 Because they are based on a practical situation, stakeholders can relate to them and can
comment on their situation with respect to the story.

Scenarios

 A structured form of user story

 Include:
o A description of the starting situation.
o A description of the normal flow of events.
o A description of what can go wrong.
o Information about other concurrent activities.
 63

o A description of the state when the scenario finishes.

Requirements specification

 The process of writing down the user and system requirements in a requirements document
 User requirements have to be understandable by end-users and customers who do not have a
technical background.
 System requirements are more detailed requirements and may include more technical
information.
 The requirements may be part of a contract for the system development.
o It is therefore important that these are as complete as possible.

Ways of writing a system requirements specification

Notation Description
Natural language The requirements are written using numbered sentences in
natural language. Each sentence should express one
requirement.
Structured natural The requirements are written in natural language on a standard
language form or template. Each field provides information about an
aspect of the requirement.
Design description This approach uses a language like a programming language, but
languages with more abstract features to specify the requirements by
defining an operational model of the system. This approach is
now rarely used although it can be useful for interface
specifications.
Graphical notations Graphical models, supplemented by text annotations, are used
to define the functional requirements for the system; UML use
case and sequence diagrams are commonly used.
Mathematical These notations are based on mathematical concepts such as
 64

specifications finite-state machines or sets. Although these unambiguous

specifications can reduce the ambiguity in a requirements
document, most customers don’t understand a formal
specification. They cannot check that it represents what they
want and are reluctant to accept it as a system contract

Requirements and design

 In principle, requirements should state what the system should do and the design should
describe how it does this.
 In practice, requirements and design are inseparable:
o A system architecture may be designed to structure the requirements.
o The system may inter-operate with other systems that generate design requirements.
o The use of a specific architecture to satisfy non-functional requirements may be a
domain requirement.
o This may be the consequence of a regulatory requirement.

Natural language specification

 Requirements are written as natural language sentences supplemented by diagrams and tables.
 Used for writing requirements because it is expressive, intuitive and universal. This means that
the requirements can be understood by users and customers.

Guidelines for writing requirements

 Invent a standard format and use it for all requirements.

 Use language in a consistent way. Use shall for mandatory requirements, should for desirable
requirements.
 Use text highlighting to identify key parts of the requirement.
 Avoid the use of computer jargon.
 Include explanation (rational) of why a requirement is necessary.

Problems with natural language

 Lack of clarity
o Precision is difficult without making the document difficult to read.
 65

 Requirements confusion
o Functional and non-functional requirements tend to be mixed-up.
 Requirements amalgamation
o Several different requirements may be expressed together.

Structure specifications

 An approach to writing requirements where the freedom of the requirements writer is limited
and requirements are written in a standard way.
 This works well for some types of requirements (e.g., requirements for embedded control
system but is sometimes too rigid for writing business system requirements.)

Form-based specifications

 Definition of the function or entity.

 Description of inputs and where they come from.
 Description of outputs and where they go to.
 Information about the information needed for the computation and other entities used.
 Description of the action to be taken.
 Pre and post conditions (if appropriate).
 The side effects (if any) of the function.

Tabular specification

 Used to supplement natural language.

 Particularly useful when you have to define a number of possible alternative courses of action.
 For example, the insulin pump systems bases its computations on the rate of change of blood
sugar level and the tabular specification explains how to calculate the insulin requirement for
different scenarios.

Use-cases

 Use-cases are a kind of scenario that are include in the UML.

 Use-cases identify the actors in an interaction, and which describe the interaction itself.
 A set of use-cases should describe all possible interactions with the system.
 66

 High-level graphical model supplemented by more detailed tabular description.

 UML sequence diagrams may be used to add detail to use-cases by showing the sequence of
event processing in the system.

Use-cases for the Mentcare system

The software requirements document

 The software requirements document is the official statement of what is required of the system
developers.
 SHOULD include both a definition of user requirements and a specification of the system
requirements.
 It is NOT a design document. As far as possible, it should set of WHAT the system should do
rather than HOW it should do it.
 67

Users of a requirements document

Requirements document variability

 Information in requirements document depends on type of system and the approach to

development used.
 Systems developed incrementally will, typically, have less detail in the requirements document.
 Requirements documents standards have been designed e.g. IEEE standard. These are mostly
applicable to the requirements for large systems engineering projects.
 68

The structure of a requirements document

Chapter Description
Preface This should define the expected readership of the document and describe
its version history, including a rationale for the creation of a new version
and a summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe
the system’s functions and explain how it will work with other systems. It
should also describe how the system fits into the overall business or
strategic objectives of the organization commissioning the software
Glossary This should define the technical terms used in the document. You should
not make assumptions about the experience or expertise of the reader
User Describe the services provided for the user. The nonfunctional system
requirement requirements should also be described in this section. This description
s definition may use natural language, diagrams, or other notations that are
understandable to customers. Product and process standards that must
be followed should be specified.
System This chapter should present a high-level overview of the anticipated
architecture system architecture, showing the distribution of functions across system
modules. Architectural components that are reused should be
highlighted.
System This should describe the functional and nonfunctional requirements in
requirement more detail. If necessary, further detail may also be added to the
s nonfunctional requirements. Interfaces to other systems may be defined.
specification
System This might include graphical system models showing the relationships
models between the system components and the system and its environment.
 69

System This should describe the fundamental assumptions on which the system
evolution is based, and any anticipated changes due to hardware evolution,
changing user needs, and so on. This section is useful for system
designers as it may help them avoid design decisions that would constrain
likely future changes to the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database
descriptions. Hardware requirements define the minimal and optimal
configurations for the system. Database requirements define the logical
organization of the data used by the system and the relationships
between data
Index Several indexes to the document may be included. As well as a normal
alphabetic index, there may be an index of diagrams, an index of
functions, and so on.
 70

IEEE 830 – the part of an SRS

Table of Contents
1. Introduction
1. Purpose
2. Scope
3. Definitions, Acronyms, and Abbreviations
4. References
5. Overview
2. Overall Description
1. Product Perspective
2. Product Functions
3. User Characteristics
4. Constraints
5. Assumptions and Dependencies
3. Specific Requirements
1. External Interfaces
2. Functional requirements
1. Function 1
1. Introduction
2. Input
3. Process
4. Output
2. Function 2
3. …
4. Function n
 71

3. Performance requirements
4. Design constraints
5. Quality attributes

Requirements validation

 Concerned with demonstrating that the requirements define the system that the customer
really wants.
 Requirements error costs are high, so validation is very important.
o Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error.

Requirements checking

 Validity – does the system provide the functions which best support the customer’s needs?
 Consistency – are there any requirements conflicts?
 Completeness – are all functions required by the customer included?
 Realism – can the requirements be implemented given available budget and technology?
 Verifiability – can the requirements be checked?

Requirements validation techniques

 Requirements reviews
o Systematic manual analysis of the requirements.
 Prototyping
o Using an executable model of the system to check requirements.
 Test-case generation
o Developing tests for requirements to check testability.

Requirements reviews

 Regular reviews should be held while the requirements definition is being formulated.
 Both client and contractor staff should be involved in reviews.
 Reviews may be formal (with completed documents) or informal. Good communications
between developers, customers and users can resolve problems at an early stage.
 72

Review checks

 Verifiability – is the requirement realistically testable?

 Comprehensibility – is the requirement properly understood?
 Traceability – is the origin of the requirement clearly stated?
 Adaptability – can the requirement be changed without a large impact on other requirements?

Changing requirements

 The business and technical environment of the system always changes after installation.
o 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,
o 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.
 Large systems usually have a diverse user community, with many users having different
requirements and priorities that may be conflicting or contradictory.
o 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
 73

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:
o Requirements identification
 Each requirement must be uniquely identified so that it can be cross-referenced
with other requirements.
o 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.
o Traceability policies
 These policies define the relationships between each requirement and between
the requirements and the system design that should be recorded.
o Tool support
 74

 Tools that may be used range from specialist requirements management

systems to spreadsheets and simple database systems.

Requirements change management.

 Deciding if requirements change should be accepted.

o 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.
o 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.
o 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.
 75

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.
The requirement’s 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.
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
Requirements validation is the process of checking the requirements for validity, consistency,
 76

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.

CHAPTER 5: SYSTEM MODELING

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 modeling helps the analyst to understand the functionality of the system and models
are used to communicate with customers.

Existing and planned system models.

 Models of the existing system are used during requirements engineering. They help clarify
what the existing system does and can be used as a basis for discussing its strengths and
weaknesses. These then lead to the requirements for the new system.
 Models of the new system are used during requirements engineering to help explain the
proposed requirements to other system stakeholders. Engineers use these models to discuss
design proposals and to document the system for implementation.
 In a model-driven engineering process, it is possible to generate a complete or partial system
implementation from the system model.

UML origin
 77

 OOD in late 1980s and early 1990s:

o Different software development houses were using different notations.
o Methodologies were tied to notations.
 UML developed in early 1990s to:
o Standardize the large number of object-oriented modeling notations.

UML lineology

 Based principally on:

o OMT (Rumbaugh 1991)
o Booch’s methodology (Booch 1991)
o OOSE (Jacobson 1992)
o Odell’s methodology (Odell 1992)
o Shlaer and Mellor (Shlaer 1992)

Different object modeling techniques in UML

UML as a standard

 Adopted by Object Management Group (OMG) in 1997.

o OMG is an association of industries.
o Promotes consensus notations and techniques.
o Used outside software development.
o Example: Car manufacturing.
 78

Why are UML models required?

 A model is an abstraction mechanism:

o Capture only important aspects and ignores the rest.
o Different models result when different aspects are ignored.
o An effective mechanism to handle complexity.
 UML is a graphical modelling tool.
 Easy to understand and construct.

UML Diagrams

 Nine diagrams are used to capture different view of a system.

 Views:
o Provide different perspectives of a software system.
 Diagrams can be refined to get the actual implementation of a system.

 UML model views

o Views of a system:
 79

 User’s view.
 Structural view
 Behavioral view
 Implementation view
 Environmental view
 All views are not required for developing a typical system.
o Use case diagram, class diagram and one of the interaction diagrams for a simple
system.
o State chart diagram required to be developed when a class state changes.
o However, when states are only one or two, state chart model becomes trivial.
o Deployment diagram in case of large number of hardware components used to develop
the system.

Use case model.

 Consists of set of “use cases”.

 An important analysis and design artifact.
 The central model:
o Other models must confirm to this model.
o Not really an object-oriented model.
o Represents a functional or process model.
 Use cases were developed originally to support requirements elicitation and now incorporated
into the UML.
 Each use case represents a discrete task that involves external interaction with a system.
 Actors in a use case may be people or other systems.
 Represented diagrammatically to provide an overview of the use case and in a more detailed
textual form.
 Use cases:
o Different ways in which a system can be used by the users.
o Corresponds to the high-level requirements.
o Represents transaction between the user and the system.
o Defines external behavior without revealing internal structure of system.
o Set of related scenarios tied together by a common goal.
 80

o Normally, use cases are independent of each other.

o Implicit dependencies may exist.
o Example use cases:
 For library information system:
 Issue-book
 Query-book
 Return-book
 Create-member
 Add-book…

o Representation of use cases

 Represent by use case diagram.

 A use case is represented by an eclipse.

 System boundary is represented by a rectangle.
 Users are represented by stick person icons (actor)
 Communication relationship between actor and use case by a line.
 External system by a stereotype.
 Why develop a use case diagram?
o Serves as requirements specification.
o How are actor identification useful in software development?
 81

 User identification helps in implementing appropriate interfaces for different

categories of users.
 Another use in preparing appropriate documents.

 Factoring use cases

o Two main reasons for factoring
 Complex use cases need to be factored into simpler use cases.
 To represent common behavior across different use cases.
o Three ways of factoring
 Generalization

 Includes
 82

 Extends

 Hierarchical Organization of use cases

 83

Class Diagram

 Describes static structure of a system.

 Main constituents are classes and their relationships:
o Generalization
o Aggregation
o Association
o Various kinds of Dependencies
 Entities with common features, i.e. attributes and operations.
 Classes are represented as solid outline rectangle with compartments.
 Compartments for name, attributes, and operations.
 Attribute and operation compartments are optional depending on the purpose of a diagram.
 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, …
 84

 Object Diagram

 Interaction Diagram
o Models how groups of objects collaborate to realize some behavior.
o Typically, each interaction diagram realizes behavior of a single use case.
o Two kinds:
 Sequence diagrams
 Show interaction among objects as a two-dimensional chart.
 Objects are shown as boxes at top.
 If object created during execution, then shown at appropriate place.
 Object existences are shown as dashed line (lifeline)
 Objects activeness shown as a rectangle on lifeline.
 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.
 Sequence Diagram Cont…
o Messages are shown as arrows.
o Each message labelled with corresponding message name.
o Each message can be labelled with some control information.
 85

o Two types of control information

 Condition ([])
 Iteration (*)
o Elements of a sequence diagram

o Example:

 Collaboration diagrams
 86

 Show both structural and behavioral aspects.

 Objects are collaborator, shown as boxes.
 Messages between objects shown as a solid line.
 A message is shown as a labelled arrow placed near the link.
 Messages are prefixed with sequence numbers to show relative
sequencing.
 Example:

o Two diagrams are equivalent.

 Portray different perspectives.
o These diagrams play a very important role in the design process.
 Activity diagram
o Not present in earlier modeling techniques:
 Possibly based on event diagram of Odell (1992).
o Represents processing activity, may not correspond to methods.
o Activity is a state with an internal action and one/many outgoing transitions
o Somewhat related to flowcharts.
 Activity diagram vs Flow Chart
 Can represent parallel activity and synchronization aspects.
 87

 Swim lanes can be used to group activities based on who is performing

them.
 Example:
o Academic department vs hotel.
o Normally employed in business process modeling.
o Carried out during requirements analysis and specification stage.
o Can be used to develop interaction diagrams.
o Example:
 88

 State Chart Diagram

o Based on the work of David Harel (1990)
o Model how the state of an object changes in its lifetime.
o Based on finite state machine (FSM) formalism.
o State chart avoids the problem of state explosion of FSM.
o Hierarchical model of a system:
 Represents composite nested states.
o Example:

o Elements of state chart diagram:

 Initial state – a filled circle.
 Final state – a filled circle inside a larger circle.
 State – rectangle with rounded corners
 Transitions – arrow between states, also Boolean logic condition (guard)
 89

 Component diagram
o Captures the physical structure of the implementation (code components)

o Components:
 Executables
 Library
 Table
 File
 Document
o Built as part of architectural specification.
o Purpose:
 Organized source code.
 Construct an executable release.
 Specify a physical database.
o Developed by architects and programmers.
 90

 Deployment Diagram
o Captures the topology of a system’s hardware.
 91

Context models

 Context models are used to illustrate the operational context of a system – they show that lies
outside the system boundaries.
 Social and organizational concerns may affect the decision on where to position system
boundaries.
 Architectural models show the system and its relationship with other systems.
 Context of the mentcare system

System boundaries

 System boundaries are established to define what is inside and what is outside the system.
o 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.
o There may be pressures to develop system boundaries that increase/decrease the
influence or workload of different parts of an organization.
 92

Process perspective

 Context models simply show the other systems in the environment, not how the system being
developed is used in that environment.
 Process models reveal how the system being developed is used in broader business processes.
 UML activity diagrams may be used to define business process models.

Process model of involuntary detention

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.
 93

Generalization

 An everyday technique that we use to manage complexity.

 Rather than learn the detailed characteristics of every entity that we experience, we place these
entities in more general classes (animals, cars, houses, etc.) and learn the characteristics of
these classes.
 This allows us to infer that different members of these classes have some common
characteristics (e.g., squirrels and rats are rodents).
 In modeling systems, it is often useful to examine the classes in a system to see if there is
scope for generalization. If changes are proposed, then you do not have to look at all classes in
the system to see if they are affected by the change.
 In object-oriented languages, such as Java, generalization is implemented using the class
inheritance mechanisms built into the language.
 In a generalization, the attributes and operations associated with higher-level classes are also
associated with the lower-level classes.
 The lower-level classes are subclasses inherit the attributes and operations from their super-
classes. These lower-level classes then add more specific attributes and operations.
 A generalization hierarchy
 94

Behavioral models

 Behavioral models are models of the dynamic behavior of a system as it is executing. They
show what happens or what is supposed to happen when a system responds to a stimulus
from its environment.
 You can think of these stimuli as being of two types:
o Data:
 Some data arrives that has to be processed by the system.
o Events:
 Some event happens that triggers system processing. Events may have
associated data, although this is not always the case.

Data-driven modeling

 Many business systems are data-processing systems that are primarily driven by data. They
are controlled by the data input to the system, with relatively little external event processing.
 Data-driven models show the sequence of actions involved in processing input data and
generating an associated output.
 They are particularly useful during the analysis of requirements as they can be used to show
end-to-end processing in a system.

An activity model of the insulin pump’s operation

 95

Event-driven modeling

 Real-time systems are often event-driven, with minimal data processing. For example, a
landline phone switching system responds to events such as ‘receiver off hook’ by generating a
dial tone.
 Event-driven modeling shows how a system responds to external and internal events.
 It is based on the assumption that a system has a finite number of states and that events
(stimuli) may cause a transition from one state to another.

State machine models

 These model the behavior 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.
 State charts are an integral part of the UML and are used to represent state machine models.

Model-driven engineering

 Model-driven engineering (MDE) is an approach to software development where models

rather than programs are the principal outputs of the development process.
 The programs that execute on a hardware/software platform are then generated automatically
from the models.
 Proponents of MDE argue that this raises the level of abstraction in software engineering so that
engineers no longer have to be concerned with programming language details or the specifics of
execution platforms.
 Usage:
o Model-driven engineering is still at an early stage of development, and it is unclear
whether or not it will have a significant effect on software engineering practice.
o Pros:
 Allows systems to be considered at higher levels of abstraction.
 Generating code automatically means that it is cheaper to adapt systems to new
platforms.
 96

o Cons:
 Models for abstraction and not necessarily right for implementation.
 Savings from generating code may be outweighed by the costs of developing
translators for new platforms.

Model driven architecture.

 Model-driven architecture (MDA) was the precursor of more general model-driven

engineering.
 MDA is a model-focused approach to software design and implementation that uses a subset of
UML models to describe a system.
 Models at different levels of abstraction are created. From a high-level, platform independent
model, it is possible, in principle, to generate a working program without manual intervention.

 Adoption of MDA
o A range of factors has limited the adoption of MDE/MDA.
o Specialized tool support is required to convert models from one level to another.
o There is limited tool availability and organizations may require tool adaptation and
customization to their environment.
o For the long-lifetime systems developed using MDA, companies are reluctant to develop
their own tools or rely on small companies that may go out of business.
o Models are a good way of facilitating discussions about a software design. However, the
abstractions that are useful for discussions may not be the right abstractions for
implementation.
 97

o For most complex systems, implementation is not the major problem – requirements
engineering, security and dependability, integration with legacy systems and testing are
all more significant.
o The arguments for platform-independence are only valid for large, long-lifetime
systems. For software products and information systems, the savings from the use of
MDA are likely to be outweighed by the costs of its introduction and tooling.
o The widespread adoption of agile methods over the same period that MDA was evolving
has diverted attention away from model-driven approaches.

Types of models

 A computation independent model (CIM)

o These model the important domain abstractions used in a system. CIMs are sometimes
called domain models.
 A platform independent model (PIM)
o These model the operation of the system without reference to its implementation. The
PIM is usually described using UML models that show the static system structure and
how it responds to external and internal events.
 Platform specific models (PSM)
o These are transformations of the platform-independent model with a separate PSM for
each application platform. In principle, there may be layers of PSM, with each layer
adding some platform-specific detail.

Multiple platform-specific models

 98

Agile methods and MDA

 The developers of MDA claim that it is intended to support an iterative approach to

development and so can be used within agile methods.
 The notion of extensive up-front modeling contradicts the fundamental ideas in the agile
manifesto, and I suspect that few agile developers feel comfortable with modeldriven
engineering.
 If transformations can be completely automated and a complete program generated from a
PIM, then, in principle, MDA could be used in an agile development process as no separate
coding would be required.

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.
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.
Model-driven engineering is an approach to software development in which a system is
represented as a set of models that can be automatically transformed to executable code.
 99

CHAPTER 5.1: COHESION AND COUPLING

Introduction

 Design phase transforms SRS document:

o To a form easily implementable in some programming language.

Item designed during design phase.

 Module structure.

o A module consists of:

 Several functions
 associated data structures.
o High-level design
 Identity:
 Modules
 Control relationships among modules
 Interfaces among modules.
 Detailed design
 For each module, design:
o Data structure
 100

o Algorithms
 Outcome of detailed design:
o Module specification.
 Control relationship among the modules.
o Call relationship or invocation relationship.
 Interface among different modules.
o Data items exchanged among different modules.
 Data structures of individual modules.
 Algorithms for individual modules.

Modularity

 Modularity is a fundamental attribute of any good design.

o Decomposition of a problem cleanly into modules:
 Modules are almost independent of each other.
 Divide and conquer principle.
 In technical terms, modules should display:
o High cohesion.
o Low coupling.

Cohesion and Coupling

 Cohesion is a measure of:

o Functional strength of a module.
o A cohesive module performs a single task or function.
 Coupling between two modules:
o A measure of the degree of the interdependence or interaction between the two
modules.
 A module having high cohesion and low coupling:
o Functionally independent of other modules:
 A functionally independent module has minimal interaction with other modules.
 Advantages of functional independence:
 Better understandability and good design:
o Complexity of design is reduced.
 101

 Different modules easily understood in isolation:

o Modules are independent.

Classification of cohesiveness

 Coincidental cohesion.
o The module performs a set of tasks:
 Which relate to each other very loosely, if at all.
 The module contains a random collection of functions.
 Functions have been put in the module out of pure coincidence
without any thought or design.
 Logical cohesion
o All elements of the module perform similar operations:
 Ex: error handling, data input, data output, …
o An example of logical cohesion:
 A set of print functions to generate an output report arranged into a single
module.
 Temporal cohesion
o The module contains tasks that are related by the fact:
 All the tasks must be executed in the same time span.
o Example:
 The set of functions responsible for:
 Initialization
 Start-up, shutdown of some process, …
 Procedural cohesion
o The set of functions of the module:
 All part of a procedure (algorithm)
 Certain sequence of steps has to be carried out in a certain order for achieving
an objective.
 Ex: the algorithm for decoding a message.
 102

 Communication cohesion
o All functions of the module:
 Reference or update the same data structure.
o Example:
 The set of functions defined on an array or a stack.
 Sequential cohesion
o Elements of a module form different parts of a sequence.
 Output from one element of the sequence is input to the next.
 Functional cohesion
o Different elements of a module cooperate:
 To achieve a single function
 Ex: managing an employee's payroll.
o When a module displays functional cohesion.
 Describe the function using a single sentence.

Coupling

 Coupling indicates:
o How closely two modules interact or how interdependent they are.
o The degree of coupling between two modules depends on their interface complexity.
 Data coupling
o Two modules are data coupled:
 If they communicate via a parameter:
 An elementary data item.
 Ex: an integer, a float, a character, …
 The data item should be problem related:
 Not used for control purpose.
 Stamp coupling
o Two modules are stamp coupled:
 If they communicate via a composite data item:
 A record in PASCAL
 A structure in C
 103

 Control coupling
o Data from one module is used to direct:
 Order of instruction execution in another.
o Example of control coupling:
 A flag set in one module and tested in another module.
 Common coupling
o Two modules are common coupled:
 If they share some global data
 Content coupling
o Content coupling exists between two modules:
 If they share code.
 Ex: branching from one module into another module.
o The degree of coupling increases from data coupling to content coupling.

Function-Oriented Design (FOD)

 A system is looked upon as something that performs a set of functions.

 Starting at this high-level view of the system:
o Each function is successively refined into more detailed functions.
o Functions are mapped to a module structure.
 Example:
o The function create-new-library- member:
 Creates the record for a new member.
 Assigns a unique membership number.
 Prints a bill towards the membership.
 104

Object-Oriented Design (OOD)

 System is viewed as a collection of objects (Ex: entities).

 System state is decentralized among the objects:
o Each object manages its own state information.
 Example:
o Library Automation Software:
 Each library member is a separate object with its own data and functions.
 Functions defined for one object:
 Cannot directly refer to or change data of other objects.
 Objects have their own internal data:
o Defines their state.
 Similar objects constitute a class.
o Each object is a member of some class.
 Classes may inherit features.
o From a super class.
 Conceptually, objects communicate by message passing.

Object-Oriented Design versus Function-oriented Design

 Unlike function-oriented design:

o In OOD the basic abstraction is not functions such as “sort”, “display”, “track”, …
o But real-world entities such as “employee”, “picture”, “machine”, “radar system”, …
 In OOD:
o Software is not developed by designing functions such as:
 Update-employee-record
 Get-employee-address, …
o But by designing objects such as:
 Employees, …
 Departments, …
 Function-oriented techniques group functions together if:
o As a group, they constitute a higher-level function.
 105

 On the other hand, object-oriented techniques group functions together:

o On the basis of the data, they operate on.

Fire-alarm system

 We need to develop a computerized fire alarm system for a large multi-storied building:
o There are 80 floors and 1000 rooms in the building.
 Different rooms of the building:
o Fitted with smoke detectors and fire alarms.
 The fire alarm system would monitor:
o Status of the smoke detectors.
 Whenever a fire condition is reported by any smoke detector, the fire alarm system should:
o Determine the location from which the fire condition was reported.
o Sound the alarms in the neighboring locations.
 The fire alarm system should flash an alarm message on the computer console:
o Firefighting personnel man the console round the clock.
 106

CHAPTER 6: ARCHITECTURAL DESIGN

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.

Agility and architecture

 It is generally accepted that an stage of agile processes is to design an overall systems

architecture.
 Refactoring the system architecture is usually expensive because it affects so many components
in the system.

The architecture of a packing robot control system

 107

 This robotic system can pack different kinds of objects.

 It uses a vision component to pick out objects on a conveyor, or identify the object type, and
select suitable packaging.
 The system then moves objects from the delivery conveyor to be packaged. It places packaged
objects on another conveyor.

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 enterprises 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.

Importance of software architecture

 Software architecture is important because it affects the performance, robustness,

disreputability, and maintainability of a system (Bosch 2000)
 108

 As Bosch explains, individual components implement the functional system requirements, but
the dominant influence on the non-functional system characteristics is the system’s
architecture.

Advantages of explicit architecture

 Stakeholder communication
o Architecture may be used as a focus of discussion by system stakeholders.
 System analysis
o Means that analysis of whether the system can meet its non-functional requirements is
possible.
 Large-scale reuse
o The architecture may be reusable across a range of systems.
o Product-line architectures may be developed.

Architectural representations

 Simple, informal block diagrams showing entities and relationships are the most frequently used
method for documenting software architectures.
 But these have been criticized because they lack semantics, do not show the types of
relationships between entities not the visible properties of entities in the architecture.
 Depends on the use of architectural models. The requirements for model semantics depends on
how the models are used.

Box and line diagrams

 Very abstract – they do not show the nature of component relationships nor the externally
visible properties of the sub-systems.
 However, useful for communication with stakeholders and for project planning.

Use of architectural models

 As a way of facilitating discussion about the system design.

 As a way of documenting an architecture that has been designed.
 109

Architectural design decisions

 Architectural design is a creative process, so the process differs depending on the type of system
being developed, the background and experience of the system architect, and the specific
requirements for the system.
 However, a number of common decisions span all design processes, and these decisions affect
the non-functional characteristics of the system.

Architecture reuse

 Systems in the same domain often have similar architectures that reflect domain concepts.
 Application product line are built around a core architecture with variants that satisfy particular
customer requirements.
 The architecture of a system may be designed around one of more architectural patterns or
“styles”.
o These capture the essence of an architecture and can be instantiated in different ways.

Architecture and system characteristics.

 Performance
o Localize critical operations and minimize communications. Use large rather than fine
grain components.
 Security
o Use a layered architecture with critical assets in the inner layers.
 Safety
 110

o Localize safety critical features in a small number of sub-systems.

 Availability
o Include redundant components and mechanisms for fault tolerance.
 Maintainability
o Use fine-grain, replaceable components.

Architectural views

 Each architectural model only shows one view or perspective of the system.
o It might show how a system is decomposed into modules, how the run-time processes
interact or the different ways in which system components are distributed across a
network. For both design and documentation, you usually need to present multiple
views of the software architecture.

View model of software architecture

 A logical view
o Shows the abstractions in the system as objects or object classes.
 A process views.
o Shows how, at run-time, the system is composed of interacting processes.
 A development views.
o Shows how the software is decomposed for development.
 A physical view
 111

o Shows the system hardware and how software components are distributed across the
processors in the system.
 Related using use cases or scenarios.

Representing architectural views

 Some people argue that the Unified Modeling Language (UML) is an appropriate notation for
describing and documenting system architectures.
 In contrast, some think that the UML do not includes abstractions appropriate for high-level
system descriptions.
 Architectural description languages (ADLs) have been developed but are not widely used.

Architectural patterns

 Patterns are 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 they are not useful.
 Patterns may be represented using tabular and graphical descriptions.

The Model-View-Controller (MVC) pattern

Name MVC
Description Separates presentation and interaction from the system data. The system is
 112

structed into 3 logical components that interact with each other.

 The Model component manages the system data and associated
operations on that data.
 The View component defines and manages how the data is presented
to the user.
 The Controller components manages user interaction and passes
these interactions to the View and the Model
Example Figure above shows the architecture of a web-based application system
organized using the MVC pattern
When used Used when there are multiples ways to view and interact with data. Also used
when the future requirements for interaction and presentation of data are
unknown.
Advantages Allows the data to change independently of its representation and vice versa.
Supports presentation of the same data in different ways with changes made
in one representation shown in all of them
Disadvantages Can involve additional code and code complexity when the data model and
interactions are simple

Web application architecture using the MVC pattern

 113

Layered architecture.
 114

 Used to model the interfacing of sub-systems.

 Organizes the system into a set of layers (or abstract machines) each of which provide a set of
services.
 Supports the incremental development of sub-systems in different layers. When a layer
interface changes, only the adjacent layer is affected.
 However, often artificial to structure systems in this way.

Name Layered architecture

Description Organizes the system into layers with related functionality associated
with each layer. A layer provides services to the layer above it so the
lowest-level layers represent core services that are likely to be used
throughout the system
Example A layered model of a system for sharing copyright documents held in
different libraries
When used Used when building new facilities on top of existing systems; when
the development is spread across several teams with each team
responsibility for a layer of functionality; when there is a requirement
for multi-level security.
Advantages Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities can be provided in each layer to
increase the dependability of the system.
Disadvantages In practice, providing a clean separation between layers is often
difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately below it.
Performance can be a problem because of multiple levels of
interpretation of a service request as it is processed at each layer

A generic layered architecture

 115

The architecture of the iLearn system

Repository architecture
 116

 Sub-systems must exchange data. This may be done in two ways:

o Shared data is held in a central database or repository and may be accessed by all sub-
systems.
o Each sub-system maintains its own database and passes data explicitly to other sub-
systems.
 When large amounts of data are to be shared, the repository model of sharing is most
commonly used a this is an efficient data sharing mechanism.
 Repository pattern

Name Repository
Description All data in a system is managed in a central repository that is accessible to all
system components. Components do not interact directly, only through the
repository.
When used Use this pattern when you have a system in which large volumes of information
are generated that has to be stored for a long time. You may also use it in data-
driven systems where the inclusion of data in the repository triggers an action
or tool
Advantages Components can be independent—they do not need to know of the existence
of other components. Changes made by one component can be propagated to
all components. All data can be managed consistently as it is all in one place.
Disadvantag The repository is a single point of failure so problems in the repository affect
e the whole system. May be inefficiencies in organizing all communication
through the repository. Distributing the repository across several computers
may be difficult.

 A repository architecture for an IDE

 117

Client-server architecture

 Distributed system model which show how a data and processing is distributed across a range of
components.
o Can be implemented on a single computer.
 Set of stand-alone servers which provide specific services such as printing, data management, …
 Set of clients which call on these services.
 Network which allows clients to access servers.
 Client-server pattern

Name Client-server
Description In a client–server architecture, the functionality of the system is
organized into services, with each service delivered from a separate
server. Clients are users of these services and access servers to make use
of them.
When used Used when data in a shared database has to be accessed from a range of
locations. Because servers can be replicated, may also be used when the
load on a system is variable.
Advantages The principal advantage of this model is that servers can be distributed
across a network. General functionality can be available to all clients and
does not need to be implemented by all services.
Disadvantag Each service is a single point of failure so susceptible to denial-of-service
e attacks or server failure. Performance may be unpredictable because it
depends on the network as well as the system. May be management
 118

problems if servers are owned by different organizations.

 A client–server architecture for a film library

Pipe and filter architecture

 Functional transformations process their inputs to produce outputs.

 119

 May be referred to as a pipe and filter model (as in UNIX shell).

 Variants of this approach are very common. When transformations are sequential, this is a batch
sequential model which is extensively used in data processing systems.
 Not really suitable for interactive systems.
 Pattern

Name Pipe and filter

Description The processing of the data in a system is organized so that each
processing component (filter) is discrete and carries out one type of data
transformation. The data flows (as in a pipe) from one component to
another for processing.
When used Commonly used in data processing applications (both batch- and
transaction-based) where inputs are processed in separate stages to
generate related outputs.
Advantages Easy to understand and supports transformation reuse. Workflow style
matches the structure of many business processes. Evolution by adding
transformations is straightforward. Can be implemented as either a
sequential or concurrent system.
Disadvantage The format for data transfer has to be agreed upon between
s communicating transformations. Each transformation must parse its
input and unparsed its output to the agreed form. This increases system
overhead and may mean that it is impossible to reuse functional
transformations that use incompatible data structures.
 120

Application architectures

 Application systems are designed to meet an organizational 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
o As a starting point for architectural design.
o As a design checklist.
o As a way of organizing the work of the development team.
o As a means of assessing components for reuse.
o As a vocabulary for talking about application types.

Examples of application types

 Data processing applications

o Data driven applications that process data in batches without explicit user intervention
during the processing.
 Transaction processing applications
o Data-centered applications that process user requests and update information in a
system database.
 121

 Event processing systems

o Applications where system actions depend on interpreting events from the system’s
environment.
 Language processing systems
o 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
o E-commerce systems.
o Reservation systems.
o Process user requests for information from a database or requests to update the
database.
o From a user perspective a transaction is:
 Any coherent sequence of operations that satisfies a goal.
o Users make asynchronous requests for service which are then processed by a
transaction manager.

 Language processing systems

o Compilers
o Command interpreters.

The software architecture of an ATM system

 122

Information systems architecture

 Information systems have a generic architecture that can be organized as a layered

architecture.
 These are transaction-based systems as interaction with these systems generally involves
database transactions.
 Layers include:
o The user interface
o User communications
o Information retrieval
o System database.

Layered information system architecture.

 123

Web-based information systems

 Information and resource management systems are now usually web-based systems where
the user interfaces are implemented using a web browser.
o Example: e-commerce systems are Internet-based resource management systems that
accept electronic orders for goods or services and then arrange delivery of these goods
or services to the customer.
 In an e-commerce system, the application-specific layer includes additional functionality
supporting a ‘shopping cart’ in which users can place a number of items in separate
transactions, then pay for them all together in a single transaction.

Sever implementation.

 These systems are often implemented as multi-tier client server/architectures.

o The web server is responsible for all user communications, with the user interface
implemented using a web browser.
o The application server is responsible for implementing application-specific logic as well
as information storage and retrieval requests.
o The database server moves information to and from the database and handles
transaction management.

Language processing systems

 124

 Accept a natural or artificial language as input and generate some other representation of that
language.
 May include an interpreter to act on the instructions in the language that is being processed.
 Used in situations where the easiest way to solve a problem is to describe an algorithm or
describe the system data.
o Meta-case tools process tool descriptions, method rules, … and generate tools.

Compiler components
 125

 A lexical analyzer, which takes input language tokens and converts them to an internal form.
 A symbol table, which holds information about the names of entities (variables, class names,
object names, etc.) used in the text that is being translated.
 A syntax analyzer, which checks the syntax of the language being translated.
 A syntax tree, which is an internal structure representing the program being compiled.
 A semantic analyzer that uses information from the syntax tree and the symbol table to check
the semantic correctness of the input language text.
 A code generator that ‘walks’ the syntax tree and generates abstract machine code.

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.
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.

CHAPTER 7: DESIGN AND IMPLEMENTATION

Design and implementation

 126

 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.
o Software design is a creative activity in which you identify software components and
their relationships, based on a customer’s requirements.
o Implementation is the process of realizing the design as a program.

An object-oriented design processes.

 Structure object-oriented design processes involve developing a number of different systems

models.
 They require a lot of effort for development and maintenance of these models, and for small
systems, this may not be cost-effective.
 However, for large systems developed by different groups design models are an important
communication mechanism.

A design process.

 Developed from various methodologies.

 UML has been designed to be usable with any design methodology.
 From requirements specification, initial model is developed (OOA).
 Analysis model is iteratively refined into a design model.
 Design model is implemented using OO concepts.

OOAD

Unified development process cont.

 127

Domain Modelling

 Represents concepts or objects appearing in the problem domain.

 Also capture relationships among objects
 3 types of objects are identified.
o Boundary objects.
o Entity objects.
o Controller objects.

Class stereotypes
 128

 Three different stereotypes on classes are used:

o Boundary

 Interact with actors:

o User interface objects
 Include screens, menus, forms, dialog…
 DON’T perform processing but validates, formats, …
o Control

 Coordinate the activities of a set of entity objects.

 Interface with the boundary objects.
 Realizes use case behavior.
 Embody most of the logic involved with the use case realization.
 There can be more than one controller to realize a single use case.
o Entity

 Hold information:
o Such as data tables & files
 Normally are dumb serves.
 Responsible for storing data, fetching data…
 Elementary operations on data such as searching, sorting,…
 Entity objects are identified by examining nouns in problem description.

Use case realization.

 129

Class Responsibility Collaborator (CRC) cards

 Pioneered by Ward Cunningham and Kent Beck.

 Index cards prepared one each per class.
 Class responsibility is written on these cards.
 Collaborating object is also written.
 CRC card cont.
o Require for developing interaction diagram of complex use cases.
o Team members participate to determine:
 The responsibility of classes involved in the use case realization.

Patterns vs Idioms

 Patterns
o The essential idea
 If you can master a few important patterns, you can easily spot them in
application development and use the pattern solutions.
o Describes a recurring problem.
o Describes the core of a solution.
o Is capable of generating many distinct designs.

 Idioms
 130

o More restricted:
 Still describes a recurring problem.
 Provide a more specific solution with fewer variations.
 Applies only to a narrow context.
o In English
 A group a words that has meaning different from a simple juxtaposition of the
meanings of the individual words.
o A C idiom:
 for (i=0;i<1000;i++){
}

Anti-pattern

 if a pattern represents a best practice:

o antipattern represents lessons learned from a bad design.
 Antipatterns help to recognize deceptive solutions:
o That appear attractive at first but turn out to be a liability later.

Design patterns

 Standard solutions to commonly recurring problems.

 Provide good solution based on common sense.
 Has 4 important parts
o Problem
o Context
o Solution
o Context in which it works or does not work.
 Design pattern
o A way of reusing abstract knowledge about a problem and its solution.
 Pattern
o A description of the problem and the essence of its solution.
o Pattern elements:
 Name – a meaningful pattern identifier
 Problem descriptions.
 131

 Solution descriptions.
 Not a concrete design but a template for a design solution that can be
instantiated in different ways.
 Consequences
 The results and trade-offs of applying the pattern.
 It should be sufficiently abstract to be reused in different settings.
 Pattern descriptions usually make use of object-oriented characteristics such as inheritance and
polymorphism.
 Design problems
o To use patterns in your design, you need to recognize that any design problem you are
facing may have an associated pattern that can be applied.
 Tell several objects that the state of some object has changed (observer
pattern).
 Tidy up the interfaces to a number of related objects that have been developed
incrementally (Façade pattern).
 Provide a standard way of accessing the elements in a collection, irrespective of
how that collection is implemented (Iterator pattern).
 Allow for the possibility of extending the functionality of an existing class at run-
time (Decorator pattern).

Process stages

 There are a variety of different object-oriented design processes that depend on the
organization using the process.
 Common activities in these processes include:
o Define the context and modes of use of the system.
o Design the system architecture.
o Identify the principal system objects.
o Develop design models.
o Specify object interfaces.
 Process illustrates here using a design for a wilderness weather station.

System context and interactions

 132

 Understanding the relationship between the software that is being designed and its external
environment is essential for deciding how to provide the required system functionality and how
to structure the system to communicate with its environment.
 Understanding of the context also lets you establish the boundaries of the system. Setting the
system boundaries helps you decide what features are implemented in the system being
designed and what features are in other associated systems.

Context and interaction models

 System context model

o A structural model that demonstrates the other systems in the environment of the
system being developed.
 Interaction model
o A dynamic model that shows how the system interacts with its environment as it is
used.

System context for the weather station

Weather station use cases.

 133

Use case description – report weather.

System Weather station

Use case Report weather
Actors Weather information system, Weather station
Description The weather station sends a summary of the weather data that has been
collected from the instruments in the collection period to the weather
information system.
The data sent are the maximum, minimum, and average ground and air
temperatures; the maximum, minimum, and average air pressures; the
maximum, minimum, and average wind speeds; the total rainfall; and the wind
direction as sampled at five-minute intervals.
Stimulus The weather information system establishes a satellite communication link with
the weather station and requests transmission of the data.
Response The summarized data is sent to the weather information system.
comments Weather stations are usually asked to report once per hour but this frequency
may differ from one station to another and may be modified in the future

Architectural design
 134

 Once interactions between the system and its environment have been understood, you use this
information for designing the system architecture.
 You identify the major components that make up the system and their interactions, and then
may organize the components using an architectural pattern such as a layered or client-server
model.
 The weather station is composed of independent sub-systems that communicate by
broadcasting messages on a common infrastructure.

High-level architecture of the weather station

Architecture of data collection system

Object class identification

 135

 Identifying object classes is often a difficult part of object-oriented design.

 There is no “magic formula” for object identification. It relies on the skill, experience, and
domain knowledge of system designers.
 Object identification is an iterative process. You are unlikely to get it right first time.

Approaches to identification.

 Use a grammatical approach based on a natural language description of the system.

 Base the identification on tangible things in the application domain.
 Use a behavioral approach and identify objects based on what participates in what behaviors.
 Use a scenario-based analysis. The objects, attributes, and methods in each scenario are
identified.

Weather station object classes.

 Object class identification in the weather station system may be based on the tangible hardware
and data in the system.
o Ground thermometer, Anemometer, Barometer.
 Application domain objects that are “hardware” objects related to the
instruments in the system.
o Weather station
 The basic interface of the weather station to its environment. It therefore
reflects the interactions identified in the use-case model.
o Weather data.
 Encapsulates the summarized data from the instruments.

Design models

 Design models show the objects and object classes and relationships between these entities.
 2 kinds of design models.
o Structural models describe the static structure of the system in terms of object classes
and relationships.
o Dynamic models describe the dynamic interactions between objects.

 Example of design models

 136

o Sub-system models that show logical groupings of objects into coherent sub-systems.
o Sequence models that show the sequence of object interactions.
o State machine models that show how individual objects change their state in response
to events.
o Other models include use-case models, aggregation models, generalization models,…

Sub-system models

 Shows how the design is organized into logically related groups of objects.
 In UML, these are shown using packages – an encapsulation construct. This is a logical model.
The actual organization of objects in the system may be different.

Sequence models

 Show the sequence of object interactions that take place.

o Objects are arranged horizontally across the top.
o Time is represented vertically so models are read top to bottom.
o Interactions are represented by labelled arrows (different styles of arrow represent
different types of interaction).
o A thin rectangle in an object lifeline represents the time when the object is the
controlling object in the system.
 Sequence diagram describing data collection.
 137

State diagrams

 State diagrams are used to show how objects respond to different service requests and the
state transitions triggered by these requests.
 State diagrams are useful high-level models of a system or an object’s run-time behavior.
 State diagram don’t usually need for all of the objects in the system. Many of the objects in a
system are relatively simple and a state model adds unnecessary detail to the design.
 Weather station state diagram

Interface specification

 Object interfaces have to be specified so that the objects and other components can be
designed in parallel.
 Designers should avoid designing the interface representation but should hide this in the object
itself.
 Objects may have several interfaces which are viewpoints on the methods provided.
 The UML uses class diagrams for interface specification but Java may also be used.
 138

Implementation issues

 Reuse
o Most modern software is constructed by reusing existing components or system.
o When you are developing software, you should make as much use as possible of
existing code.
o From the 1960s to the 1990s, most new software was developed from the scratch by
writing all code in a high-level programming language.
 The only significant reuse or software was the reuse of functions and objects in
programming languages libraries.
o Costs and schedule pressure mean that this approach became increasingly unviable,
especially for commercial and internet-based systems.
o An approach to development based around the reuse of existing software emerged and
is now generally used for business and scientific software.
o Reuse level:
 Abstraction level
 Don’t reuse the software directly but use knowledge of successful
abstractions in the design of your software.
 Object level
 Directly reuse objects from a library rather than writing the code
yourself.
 Component level
 Collections of objects and object classes that you reuse in application
systems.
 System level
 Reuse entire application system.
o Reuse costs
 The costs of the time spent in looking for software to reuse and assessing
whether or not it meets your needs.
 Where applicable, the costs of buying the reusable software. For large off-the-
shelf systems, these costs can be very high.
 139

 The costs of adapting and configuring the reusable software components or

systems to reflect the requirements of the system that you are developing.
 The cost of integrating reusable software elements with each other (if you are
using software from different sources) and with the new code that you have
developed.
o Software reuse

 Configuration management.
o During the development process, you have to keep track of the many different versions
of each software component in a configuration management system.
o Configuration management is the name given to the general process of managing
software system.
o Aim:
 Support the system integration process so that all developers can access the
project code and documents in a controlled way, find out what changes have
been made, and compile and link components to create a system.
 140

o Configuration management activities

 Version management:
 Where support is provided to keep track of the different versions of
software components.
 Include facilities to coordinate development by several programmers.
 System integration:
 Where support is provided to help developers define what versions of
components are used to create each version of a system.
 This description is then used to build a system automatically by
compiling and linking the required components.
 Problem tracking
 Where support is provided to allow users to report bugs and other
problems and allow all developers to see who is working on these
problems and when they are fixed.
o Configuration management tool interaction.
 141

 Host-target development.
o Production software does not usually execute on the same computer as the software
development environment.
o Rather, you develop it on one computer (the host system) and execute it on a separate
computer (the target system).

o Most software is developed on one computer (the host) but runs on a separate machine
(the target).
o Development platform and execution platform
 A platform is more than just hardware.
 Includes the installed operation system plus other supporting software such as a
database management system or, for development platforms, an interaction
development environment.
 Development platform tools
 An integrated compiler and syntax-directed editing system that allows
you to create, edit and compile code.
 A language debugging system.
 Graphical editing tools.
 Testing tools
 Project support tools that help you organize the code for different
development projects.
 142

o Development platform usually has different installed software than execution platform;
these platforms may have different architectures.

Integrated development environments (IDEs)

 Software development tools are often grouped to create an integrated development

environment (IDE).
 An IDE is a set of software tools that supports different aspects of software development,
within some common framework and user interface.
 IDEs are created to support development in a specific programming language such as Java. The
language IDE may be developed specially, or may be an instantiation of a general-purpose IDE,
with specific language-support tools.

Component/system deployment factors

 If a component is designed for a specific hardware architecture, or relies on some other

software system, it must obviously be deployed on a platform that provides the require
hardware and software support.
 High availability systems may require components to be deployed on more than one platform.
This means that, in the event of platform failure, an alternative implementation of the
component is available.
 If there is a high level of communication traffic between components, it usually makes sense to
deploy them on the same platform or on platforms that are physically close to one other. This
reduces the delay between the time a message is sent by one component and received by
another.

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, 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.
 143

 Open-source systems
o The best-known open-source product is the Linux operating system which is widely used
as a server system and as a desktop environment.
o Other important open-source products are Java, the Apache web server and the MySQL
database management system.
 Open-source issues
o Should the product that is being developed make use of open source components?
o Should an open-source approach be used for the software’s development?
 Open-source business
o More and more product companies are using an open-source approach to development.
o Their business model is not reliant on selling a software product but on selling support
for that product.
o 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
o A fundamental principal 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) is a so-called “reciprocal” listen 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.
 144

 The Berkley Standard Distribution (BSD) License 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 system that are sold.
 License management
o Established a system for maintaining information about open-source components that
are downloaded and used.
o Be aware of the different types of licenses and understand how a component is licensed
before it is used.
o Be aware of evolution pathways for components.
o Educate people about open source.
o Have auditing system in place.
o 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.
The process of object-oriented design includes activities to design the system architecture, identify
objects in the system, describe the design using different object models and document the
component interfaces.
A range of different models may be produced during an objectoriented design process. These
include static models (class models, generalization models, association models) and dynamic
models (sequence models, state machine models).
Component interfaces must be defined precisely so that other objects can use them. A UML
interface stereotype may be used to define interfaces.
When developing software, you should always consider the possibility of reusing existing software,
either as components, services or complete systems.
Configuration management is the process of managing changes to an evolving software system. It is
essential when a team of people are cooperating to develop software.
Most software development is host-target development. You use an IDE on a host machine to
develop the software, which is transferred to a target machine for execution.
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.
 145

CHAPTER 8: SOFTWARE TESTING

Program testing

 Testing is intended to show that a program does what it is intended to do and to discover
program defects before it is put into use.
 When you test software, you execute a program using artificial data.
 You check the result of the test run for errors, anomalies or information about the program’s
non-functional attributes.
 Can reveal the presence of errors NOT their absence.
 Testing is a part of a more general verification and validation process, which also includes
static validation techniques.

Program testing goals.

 To demonstrate to the developer and the customer that software meets its requirements.
 To discover situations in which the behavior of the software is incorrect, undesirable or does not
conform to its specification.

Validation and defect testing

 The first goal leads to validation testing.

o You expect the system to perform correctly using a given set of test cases that reflect
the system’s expected use.
 The second goal leads to defect testing.
o The test cases are designed to expose defects. The test cases in defecting can be
deliberately obscure and need not reflect how the system is normally used.

Testing process goals

 Validation testing
o To demonstrate to the developer and the system customer that the software meets its
requirements.
o A successful test shows that the system operates as intended.
 Defect testing
o To discover faults or defects in the software where its behavior is incorrect or not in
conformance with its specification.
 146

o A successful test is a test that makes the system perform incorrectly and so exposes a
defect in the system.

Input-output model of program testing

Verification vs validation (V vs V)

 Verification
o The software should conform to its specification.
o “Are we building the product right?”
 Validation
o The software should do what the user really requires.
o “Are we building the right product?”
 147

V & V confidence

 Aim of V&V is to establish confidence that the system is “fit for purpose”.
 Depends on system’s purpose, user expectations and marketing environment.
o Software purpose
 The level of confidence depends on how critical the software is to an
organization.
o User expectations
 Users may have low expectations of certain kinds of software.
o Marketing environment
 Getting a product to market early may be more important than finding defects
in the program.

Inspections and testing.

 Software inspections
o Concerned with analysis of the static system representation to discover problems (static
verification)
 May be supplemented by tool-based document and code analysis.
 Software testing
o Concerned with exercising and observing product behavior (dynamic verification)
 The system is executed with test data and its operational behavior is observed.
 148

 Inspections and testing are complementary and not opposing verification techniques.
 Both should be used during the V & V process.
 Inspection 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,…

Software inspections.

 Involve people examining the source representation with the aim of discovering anomalies and
defects.
 Inspections not required execution of a system so may be used before implementation.
 May applied to any representation of the system (requirements, design, configuration data, test
data, etc.…)
 Shown to be an effective technique for discovering program errors.

Advantages of inspections.

 Errors can hide other errors during testing.

o 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.
o If a program is incomplete, then you need to develop specialized test harnesses to test
the parts that are available.
 When searching for program defects, an inspection can also consider broader quality attributes
of a program, such as compliance with standards, portability and maintainability.

A model of the software testing process.

 149

Stages of testing

 Development testing
o The system is tested during development to discover bugs and defects.
 Release testing
o A separate testing team test a complete version of the system before it is released to
users.
 User testing
o Users or potential users of a system test the system in their own environment.

Development testing

 Includes all testing activities that are carried out by the team developing the system.
o Unit testing
 Where individual program units or object classes are tested.
 Focus on testing the functionality of object or methods.
o Component testing
 Where several units are integrated to create composite components.
 Focus on testing component interfaces.
o System testing
 Where some or all of the components in a system are integrated and the system
is tested as a whole.
 Focus on testing component interactions.

Unit testing

 Unit testing is the process of testing individual components in isolation.

 It is a defect testing process.
 Units may be:
o Individual functions or methods within an object.
o Object classes with several attributes and methods.
o Composite components with defined interfaced used to access their functionality.
 150

Object class testing

 Complete test coverage of a class involves.

o Testing all operations associated with an object.
o Setting an interrogating all object attributes.
o Exercising the object in all possible states.
 Inheritance makes it more difficult to design object class tests as the information to be tested is
not localized.

Weather station testing

 Need to define test cases for report-Weather, calibrate, test, startup and shutdown.
 Using state model, identify sequences of state transitions to be tested and the event sequences
to cause these transitions.

Automated testing

 Whenever possible, unit testing should be automated so that tests are run and checked without
manual intervention.
 In automated unit testing, you make use of a test automation framework (Junit) to write and run
program tests.
 Unit testing frameworks provide generic test classes that you extend to create specific test case.
They can then run all of the tests that you have implemented and report, often through some
GUI, on the success of otherwise of the tests.
 Automated test components:
o Setup part
 Where you initialize the system with the test case, namely the inputs and
expected outputs.
o Call part
 Where you call the object or method to be tested.
o Assertion part
 Where you compare the result of the call with expected result. If the assertion
evaluates to true, the test has been successful if false, then it has failed.
 151

Choosing unit test cases

 The test cases should show that, when used as expected, the component that you are testing
does what it is supposed to do.
 If there are defects in the component, these should be revealed by test cases.
 2 types of unit test case:
o First test case
 Should reflect normal operation of a program and should show that the
component works as expected.
o Second test case:
 Should be based on testing experience of where common problems arise. It
should use abnormal inputs to check that these are properly processed and do
not crash the component.

Testing strategies

 Partition testing
o Where you identify groups of inputs that have common characteristics and should be
processed in the same way.
 You should choose tests from within each of these groups.
o Input data and output results often fall into different classes where all members of a
class are related.
o Each of these classes is an EQUIVALENCE PARTITION or domain where the program
behaves in an equivalent way for each class members.
o EQUIVALENCE PARTITION
 152

o Test cases should be chosen from each partition.

 Guideline-based testing
o Where you use testing guidelines to choose test cases.
 These guidelines reflect previous experience of the kinds of errors that
programmers often make when developing components.
o Testing guidelines (sequences)
 Test software with sequences which have only a single value.
 Use sequences of different sizes in different tests.
 153

 Derive tests so that the first, middle and last elements of the sequence are
accessed.
 Test with sequences of zero length.
o General testing guidelines
 Choose inputs that force the system to generate all error messages.
 Design inputs that cause input buffers to overflow.
 Repeat the same input or series of inputs numerous times.
 Force invalid outputs to be generated.
 Force computation results to be too large or too small.

Component testing

 Software components are often composite components that are made up of several interacting
objects.
 You access the functionality of these objects through the defined component interface.
 Testing composite components should therefore focus on showing that the component
interface behaves according to its specification.

Interface testing

 Objectives are to detect faults due to interface errors or invalid assumptions about interfaces.

 Interface types
o Parameter interfaces
o Shared memory interfaces
 154

o Procedural interfaces
o Message passing interfaces.
 Interface errors
o Interface misuse
 A calling component calls another component and makes an error in its use of
its interface.
o Interface misunderstanding
 A calling component embeds assumptions about the behavior of the called
component which are incorrect.
o Timing errors
 The called and the calling component operate at different speeds and out-of-
date information is accessed.
 Interface testing guidelines
o Design tests so that parameters to a called procedure are at the extreme ends of their
ranges.
o Always test pointer parameters with null pointers.
o Design tests which cause the component to fail.
o Use stress testing in message passing systems.
o In shared memory systems, vary the order in which components are activated.

System testing

 System testing during development involves integrating components to create a version of the
system and then testing the integrated system.
 The focus in system testing in testing the interactions between components.
 System testing checks that components are compatible interact correctly and transfer the right
data at the right time across their interfaces.
 System testing tests the emergent behavior of a system.
 During system testing
o Functional requirements are validated through functional tests.
o Non-functional requirements validated through performance tests.
 155

Release testing (black-box testing)

 The process of testing a particular release of a system that is intended for use outside of the
development team.
 The primary goal of the release testing process is to convince the supplier of the system that it is
good enough for use
o Release testing, therefore, has to show that the system delivers its specified
functionality, performance and dependability, and that it does not fail during normal
use.
 Release testing is usually a black-box testing process where tests are only derived from the
system specification.

Release testing and system testing

 Release testing is a form of system testing.

 Important differences:
o A separate team that has not been involved in the system development, should be
responsible for release testing.
o System testing by the development team should focus on discovering bugs in the system
(defect testing).
o The objective of release testing is to check that the system meets its requirements and
is good enough for external use (validation testing).

Requirements based testing.

 Involves examining each requirement and developing a test or tests for it.

Performance testing

 Part of release testing may involve testing the emergent properties of a system, such as
performance and reliability.
 Tests should reflect the profile of use of the system.
 Performance tests usually involve planning a series of tests where the load is steadily increased
until the system performance becomes inacceptable.
 Stress testing is a form of performance testing where the system is deliberately overloaded to
test its failure behavior.
 156

 Addressed non-functional requirements.

o May sometimes involve testing hardware and software together.
o There are several categories of performance testing.

User testing

 A stage in the testing process in which users or customer provide input and advice on system
testing.
 User testing is essential, even when comprehensive system and release testing have been
carried out.
o The reason for this is that influences from the user’s working environment have a major
effect on the reliability, performance, usability and robustness of a system. These
cannot be replicated in a testing environment.
 User testing types
o Alpha testing
 Users of the software work with the development team to test the software at
the developer’s site.
o Beta testing
 A release of the software is made available to users to allow them to
experiment and to raise problems that they discover with the system
developers.
o Acceptance testing
 Customers test a system to decide whether or not it is ready to be accepted
from the system developers and deployed in the customer environment.
Primarily for custom systems.

 Stages in the acceptance testing process.

o Define acceptance criteria.
o Plan acceptance testing.
 157

o Derive acceptance tests.

o Run acceptance tests.
o Negotiate test results.
o Reject/accept system.

Mutation testing

 The software is first tested:

o Using an initial testing method based on white-box strategies.
 After the initial testing is complete
o Mutation testing is taken up.
 The idea behind mutation testing
o Make a few arbitrary small changes to a program at a time.
 Each time the program is changed:
o It is called a mutated program.
o The change is called a mutant.
 A mutated program
o Tested against the full test suite of the program.
 If there exists at least one test case in the test suite for which:
o A mutant gives an incorrect result, then the mutant is said to be dead.
 If a mutant remains alive
o Even after all test cases have been exhausted, the test suite is enhanced to kill the
mutant.
 The process of generation and killing of mutants
o Can be automated by predefining a set of primitive changes that can be applied to the
program.
 The primitive changes can be:
o Altering an arithmetic operator.
o Changing the value of a constant.
o Changing a data type.
 A major disadvantage of mutation testing:
o Computationally very expensive.
 158

o A large number of possible mutants can be generated.

Stress testing

 Evaluates system performance.

o When stressed for short periods of time.
 Stress testing
o Known as endurance testing.
 Stress tests are black box tests
o Designed to impose a range of abnormal and even illegal input conditions.
o To stress the capabilities of the software.
 If the requirements is to handle a specified number of users, or devices:
o Stress testing evaluates system performance when all users or devices are busy
simultaneously.
 If an operating system is supposed to support 15 multi-programmed jobs.
o The system is stressed by attempting to run 15 or more jobs simultaneously.
 A real-time system might be tested.
o To determine the effect of simultaneous arrival of several high-priority interrupts.

Volume testing

 Addresses handling large amounts of data in the system:

o Whether date structures are large enough to handle all possible situations.
o Fields, records, and files are stressed to check if their size can accommodate all possible
data volumes.

Configuration testing

 Analyze system behavior:

o In various hardware and software configurations specified in the requirements.
o Sometimes systems are built in various configurations for different users.
o For instance, a minimal system may serve a single user, other configurations for
additional users.
 159

Recovery testing

 These tests check response to:

o Presence of faults or to be the loss of data, power, devices or services
o Subject system to loss of resources
 Check If the system recovers properly.

Maintenance testing

 Diagnostic tools and procedures:

o Help find source of problems.
o It may be required to supply.
 Memory maps
 Diagnostic programs
 Traces of transactions
 Circuit diagrams…
 Verify that:
o All required artifacts for maintenance exist.
o They function properly.

Environmental testing

 These tests check the system’s ability to perform at the installation site.
 Requirements might include tolerance for:
o Heat
o Humidity
o Chemical presence
o Portability
o Electrical or magnetic fields
o Disruption of power…

Test summary report

 160

 Generated towards the end of testing phase.

 Covers each sub-system:
o A summary of tests which have been applied to the sub-system.
 Specifies
o How many tests have been applied to a sub-system?
o How many tests have been successful?
o How many have been unsuccessful, and the degree to which they have been
unsuccessful.

Regression testing

 Does not belong to either unit test, integration test, or system test.
o Instead, it is a separate dimension to these three forms of testing.
 Regression testing is the running of test suite:
o After each change to the system after each bug fix.
o Ensures that no new bug has been introduced due to the change or the bug fix.
 Regression testing assure:
o The new system’s performance is at least as good as the old system.
o Always used during incremental system development.
 161

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.
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 that determines if the software is good enough to be
deployed and used in its operational environment.
Mutation testing:
 make arbitrary small changes.
 see if the existing test suite detect these.
 if not, augment test suite.
Functional test
Performance test
 stress
 volume
 configuration
 Maintenance
Regression Testing
 Is a separate dimension to these three forms of testing.
 162

 Ensures the new system’s performance is at least as good as the old system

CHAPTER 22 – PROJECT MANAGEMENT

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 organizations 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 organization 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.

o Software cannot be seen or touched. Software project managers cannot see progress
simply looking at the artefact that is being constructed.
 Many software projects are “one-off” projects.
o 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.
o 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.
 163

 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
o Project managers are responsible for planning, estimating, and scheduling project
development and assigning people to tasks.
 Risk management
o Project managers assess the risks that may affect a project, monitor these risks and take
action when problems arise.
 People management.
o Project managers have to choose people for their team and establish ways of working
that leads to effective team performance.

Management activities

 Reporting
o 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.
o 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.

Risk management

 Risk management is concerned with identifying risks and drawing up plans to minimize their
effect on a project.
 Software risk management is important because of the inherent uncertainties in software
development.
 164

o These uncertainties stem from loosely defined requirements, requirements change 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.
 The risk management process
o Risk identification
 Identify project, product, and business risks.
 May be a team activities or based on the individual project manager’s
experience.
 A checklist of common risks may be used to identify risks in a project
 Technology risks
o Late delivery of hardware or support software may report
technology problems.
 Organizational risks.
o Organizational gossip, lack of action by senior management.
 People risks.
o Poor staff morale, poor relationships amongst team members,
high staff turnover.
 Requirement risks.
o Many requirements change requests, customer complaints.
 Estimation risks.
o Failure to meet agreed schedule, failure to clear reported
defects.
 Tools risks
o Reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations.
o Risk analysis.
 Assess the likelihood and consequence of these risks.
 Assess probability and seriousness of each risk.
 Probability may be very low, low, moderate, high or very high.
 Risk consequences might be catastrophic, serious, tolerate or insignificant.
 165

o Risk planning.
 Draw up plans to avoid or minimize the effects of the risk.
 Consider each risk and develop a strategy to manage that risk.
 Avoidance strategies
 The probability that the risk will arise is reduced.
 Minimization strategies
 The impact of the risk on the project or product will be reduced.
 Contingency plans.
 If the risk arises, contingency plans are plans to deal with those risks.
o Risk monitoring
 Monitor the risks throughout the project.
 Assess each identified risks regularly to decide whether or not it is becoming
less or more probable.
 Also assess whether the effects of the risk have changed.
 Each key risk should be discussed at management progress meetings.
 Risk management process

Risk classification

 There are 2 dimensions of risk classification.

o The type of risk (technical, organizational…)
o What is affected by the risk.
 Project risks
o Affect schedule or resource.
o Affect the quality of performance of the software being developed.
 166

 Business risks
o Affect the organization developing or procuring the software.

Managing people

 People are an organization’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
o Team members should all be treated in a comparable way without favorites or
discrimination.
 Respect
o Different team members have different skills, and these differences should be
respected.
 Inclusion
o Involve all team members and make sure that people’s views are considered.
 Honesty
o 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.
o 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 there are different types of motivation based
on:
o Basic needs
 167

o Personal needs
o Social needs.

Need satisfaction.

 In software development groups, basic physiological and safety needs are not an issue.
 Social
o Provide communal facilities.
o Allow informal communications e.g. via social networking
 Esteem
o Recognition of achievements.
o Appropriate rewards.
 Self-realization
o Training
o Responsibility

Personality types

 The need hierarchy is almost certainly an over-simplification of motivation in practice.

 Motivation should also take into account different personality types.
o Task-oriented people
 The motivation for doing the work is the work itself.
o Interaction-oriented people
 The principal motivation is the presence and actions of co-workers.
o Self-oriented people
 The work is a means to an end which is the achievement of individual goals.

Motivation balance

 Individual motivations are made up of elements of each class.

 The balance can change depending on personal circumstances and external events.
 People are not just motivated by personal factors but also being part of a group and culture.
 People go to work because they are motivated by the people that they work with.
 168

Teamwork

 Software engineering is a group activity.

o 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.
o 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.
 Advantages of a cohesive group are:
o Group quality standards can be developed by the group members.
o Team members learn from each other and get to know each other’s work. Inhibitions
caused by ignorance are reduced.
o Knowledge is shared. Continuity can be maintained if a group member leaves.
o 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.

The effectiveness of a team

 People in the group

o 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.
 Group organization
o 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.
o Good communications between group members, and between the software engineering
team and other project stakeholders, is essential.
 169

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

 Group composed of members who share the same motivation can be problematic.
o Task-oriented
 Everyone wants to do their own thing
o Self-oriented
 Everyone wants to be the boss.
o 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 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.
 Small software engineering groups are usually organized informally without a rigid structure.
 For large projects, there may be a hierarchy 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:
o The group acts as a whole and comes to a consensus on decisions affecting the system.
o The group leader serves as the external interface of the group but does not allocate
specific work items.
 170

o Rather, work is discussed by the group as a whole and tasks are allocated according to
ability and experience.
o This approach is successful for group where all members are experienced and
competent.

Group communications

 Good communications are essential for effective group working.

 Information must be exchanges on the status of work, design decisions and exchanges to
previous decisions.
 Good communications also strengthens group cohesion as it promotes understanding.
 Group size:
o The larger the group, the harder it is for people to communicate with other group
members.
 Group structure
o Communication is better in informally structured groups than in hierarchically
structured groups.
 Group composition
o 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
o Good workplace organization can help encourage communication.
 171

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.
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.
 172

CHAPTER 23 – PROJECT PLANNING

Project planning

 Breaking down the work into parts and assigning these project team members, anticipating
problems that might arise, and preparing tentative solutions to those problems.
 The project plan – created at the start of a project – is used to communicate how the work will
be done to the project team and customers and to help assess progress on the project.
 The most time-consuming project management activity.
 Continuous activity from initial concept through to system delivery. Plans must be regularly
revised as new information becomes available.
 Various different types of plans may be developed to support the main software project plan
that is concerned with schedule and budget.

Planning stages

 Proposal stage (planning)

o Bidding for a contract to develop or provide a software system.
o Planning may be necessary with only outline software requirements.
o Aim:
 Provide information that will be used in setting a price for the system to
customers.
o Project pricing involves estimating how much the software will cost to develop, taking
factors such as staff costs, hardware costs, software costs…into account.
 Project startup phase (planning)
o Plan who will work on the project, how the project will be broken down into increments,
how resources will be allocated across your company…
o Know more about the system requirements but do not have design or implementation
information.
 173

o Create a plan with enough detail to make decisions about the project budget and
staffing.
 The basis for project resource allocation.
o The startup plan also defines project monitoring mechanisms.
o A startup plan is needed for agile development to allow resources to be allocated to the
project.
 Periodically throughout the project, when you modify your plan in the light of experience gained
and information from monitoring the progress of the work.
 Development planning
o The project plan should be regularly amended as the project progresses and you know
more about the software and its development.
o The project schedule, cost-estimate and risks have to be regularly revised.

Software pricing

 Estimates are made to discover the cost, to the developer, of producing a software system.
o Take into account, hardware, software, travel, training, and effort costs.
 There is not a simple relationship between the development cost and the price charged to the
customer.
 Factor effecting software pricing:
o Contractual terms
 A customer may be willing to allow the developer to retain ownership of the
source code and reuse it in other projects.
 The price charged may then be less than if the software source code is handed
over to the customer.
o Cost estimate uncertainty
 If an organization is unsure of its cost estimate, it may increase its price by a
contingency over and above its normal profit.
o Financial health
 Developers in financial difficulty may lower their price to gain a contract. It is
better to make a smaller than normal profit or break even than to go out of
business. Cash flow is more important than profit in difficult economic times.
o Market opportunity
 174

 A development organization may quote a low price because it wishes to move

into a new segment of the software market.
 Accepting a low profit on one project may give the organization the opportunity
to make a greater profit later. The experience gained may also help it develop
new products.
o Requirements volatility
 If the requirements are likely to change, an organization may lower its price to
win a contract. After the contract is awarded, high prices can be charged for
changes to the requirements.
 Pricing strategies
o Under pricing
 A company may underprice a system in order to gain a contract that allows
them to retain staff for future opportunities.
 A company may underprice a system to gain access to a new market area.
o Increase pricing.
 The price may be increased when a buyer wishes a fixed price contract and so
the seller increases the price to allow for unexpected risks.
 Pricing to win.
o The software is priced according to what the software developer believes the buyer is
willing to pay.
o If this is less than the development costs, the software functionality may be reduced
accordingly with a view to extra functionality being added in a later release.
o Additional costs may be added as the requirements change and these may be priced ar a
higher level to make up the shortfall in the original price.

Plan-driven development

 Plan-driven or plan-based development is an approach to software engineering where the

development process is planned in detail.
o Plan-driven development is based on engineering project management techniques and
is the “traditional” way of managing large software development projects.
 A project plan is created that records the work to be done, who will do it, the development
schedule and the work products.
 175

 Managers use the plan to support project decision making and as a way of measuring progress.

 Pros and cons

o The arguments in favor of a plan-driven approach are that early planning allows
organizations issues to be closely taken into account, and that potential problems and
dependencies are discovered before the project starts, rather than once the project is
underway.
o The principal argument against plan-driven development is that many early decisions
have to be revised because of changes to the environment in which the software is to be
developed and used.

Project plans

 In a plan-driven development project, a project plan sets out the resources available to the
project, the work breakdown and a schedule for carrying out the work.
 Plan sections
o Introduction
o Project organization
o Risk analysis
o Hardware and software resources requirements.
o Work breakdown
o Project schedule
o Monitoring and reporting mechanisms.
 Project plan supplements
o Configuration management plan
 Describes the configuration management procedures and structures to be used.
o Deployment plan
 Describes how the software and associated hardware will be deployed in the
customer’s environment. This should include a plan for migrating data from
existing systems.
o Maintenance plan
 Predicts the maintenance requirements, costs, and effort.
 176

o Quality plan
 Describes the quality procedures and standards that will be used in a project.

o Validation plan
 Describes the approach, resources, and schedule used for system validation.

The planning process.

 Project planning – is an iterative process that starts when you create an initial project plan
during the project startup phase.
 Plan changes are inevitable.
o As more information about the system and the project team becomes available during
the project, you should regularly revise the plan to reflect requirements, schedule and
risk changes.
o Changing business goals also leads to changes in project plans. As business goals change,
this could affect all projects, which may then have to be re-planned.
 Project planning process

 Planning assumptions
o Should make realistic rather than optimistic assumptions when you are defining a
project plan.
o Problems of some description always arise during a project, and these lead to project
delays.
 177

o Your initial assumptions and scheduling should therefore take unexpected problems
into account.
o You should include contingency in your plan so that if things go wrong, then your
delivery schedule is not seriously disrupted.

Risk mitigation

 If there are serious problems with the development work that are likely to lead to significant
delays, you need to initiate risk mitigation actions to reduce the risks of project failures.
 In conjunction with these actions, you also have to re-plan the project.
 This may involve renegotiating the project constraints and deliverables with the customer. A
new schedule of when work should be completed also has to be established and agreed with the
customer.

Project scheduling

 The process of deciding how the work in a project will be organized as separate tasks, and
when and how these tasks will be executed.
 You estimate the calendar time needed to complete each task, the effort required and who will
work on the tasks that have been identified.
 You also have to estimate the resources needed to complete each task, such as the disk space
required on a server, the time required on specialized hardware such as a simulator, and what
the travel budget will be.
 Project scheduling activities
o Split project into tasks and estimate time and resources required to complete each task.
o Organize tasks concurrently to make optimal use of workforce.
o Minimize task dependencies to avoid delays caused by one task waiting for another to
complete.
o Dependent on project managers intuition and experience.
 Project scheduling process
 178

 Project scheduling problems

o Estimating the difficulty of problems and hence the cost of developing a solution is hard.
o Productivity is not proportional to the number of people working on a task.
o Adding people to a late project makes it later because of communication overheads.
o The unexpected always happens. Always allow contingency in planning.
 Project scheduling presentation
o Graphical notations are normally used to illustrate the project schedule.
o These show the project breakdown into tasks. Tasks should not be too small. They
should take about a week or two.
o Calendar-based
 Bar charts are the most commonly used representation for project schedules.
They show the schedule as activities or resources against time.
o Activity networks
 Show task dependencies.

Project activities.

 Project activities (tasks) are the basic planning element.

 Each activity has
o A duration in calendar days or months.
o An effort estimate, which shows the number of person-days or person-months to
complete the work.
o A deadline by which the activity should be complete.
o A defined end-point, which might be a document, the holding of a review meeting, the
successful execution of all tests.
 179

Gantt Chart

 A commonly used graphical depiction of a project schedule.

 Bar chart showing the start and finish dates of a project’s elements such as resources, planning
and dependencies.
 Gantt chart helps in scheduling, managing, and monitoring specific tasks and resources in a
project.
 Gantt charts can be used in managing projects of all sizes and types.

PERT charts

 Program Evaluation Review Technique (PERT) chart is a graphical representation of a project’s

timeline that displays all the individual tasks necessary to complete the project.
 A PERT chart uses circles or rectangles called nodes to represent project events or milestones.
These nodes are linked by vectors, or lines, representing various tasks and their dependencies.
 A PERT chart allows managers to evaluate the time and resources necessary to manage a
project.

Experience-based approaches

 Experience-based techniques rely on judgements based on experience of past projects and the
effort expended in these projects on software development activities.
 Typically, you identify the deliverables to be produced in a project and the different software
components or systems that are to be developed.
 You document these in a spreadsheet, estimate them individually and compute the total effort
required.
 It usually helps to get a group of people involved in the effort estimation and to ask each
member of the group to explain their estimate.
 Problem with experience-based approach.
o The difficulty with experience-based techniques is that a new software project may not
have much in common with previous projects.
o Software development changes very quickly and a project will often use unfamiliar
techniques such as web services, application system configuration or HTML5.
 180

o If you have not worked with these techniques, your previous experience may not help
you to estimate the effort required, making it more difficult to produce accurate costs
and schedule estimates.

COCOMO cost modeling.

 An empirical model based on project experience.

 Well-documented, “independent” model which is not tied to a specific software vendor.
 Long-history from initial version published in 1981 (COCOMO-81) through various instantiations
to COCOMO 2.
 COCOMO 2 takes into account different approaches to software development, reuse,…
 COCOMO 2 models
o Incorporates a range of sub-models that produce increasingly detailed software
estimates.
o The sub-models in COCOMO 2 are:
 Application composition model
 Used when software is composed from existing parts.
 Early design model
 Used when requirements are available, but design has not yet started.
 Reuse model
 Used to compute the effort of integrating reusable components.
 Post-architecture model
 Used once the system architecture has been designed and more
information about the system is available.
 COCOMO estimation models
 181

The reuse model.

 Takes into account black-box code that is reused without change and code that has to be
adapted to integrate it with new code.
 There are 2 versions:
o Black-box.
 Reuse where code is NOT modified. An effort estimate (PM) is computed.
o White-box
 Reuse where code is modified. A size estimate equivalent to the number of lines
of new source code is computed. This then adjusts the size estimate for new
code.

Multiplier

 Product attributes
o Concerned with required characteristics of the software product being developed.
 182

 Computer attributes
o Constraints imposed on the software by the hardware platform.
 Personnel attributes.
o Multipliers that take the experience and capabilities of the people working on the
project into account.
 Project attributes.
o Concerned with the particular characteristics of the software development project.

Key points
The price charged for a system does not just depend on its estimated development costs and the
profit required by the development company. Organizational factors may mean that the price is
increased to compensate for increased risk or decreased to gain competitive advantage.
Software is often priced to gain a contract and the functionality of the system is then adjusted to
meet the estimated price.
Plan-driven development is organized around a complete project plan that defines the project
activities, the planned effort, the activity schedule and who is responsible for each activity.
Project scheduling involves the creation of various graphical representations of part of the project
plan. Bar charts, which show the activity duration and staffing timelines, are the most commonly
used schedule representations.
A project milestone is a predictable outcome of an activity or set of activities. At each milestone, a
formal report of progress should be presented to management. A deliverable is a work product that
 183

is delivered to the project customer.

The agile planning game involves the whole team in project planning. The plan is developed
incrementally and, if problems arise, it is adjusted so that software functionality is reduced instead
of delaying the delivery of an increment.
Estimation techniques for software may be experience-based, where managers judge the effort
required, or algorithmic, where the effort required is computed from other estimated project
parameters.
The COCOMO II costing model is a mature algorithmic cost model that takes project, product,
hardware, and personnel attributes into account when formulating a cost estimate.

CHAPTER 25 – CONFIGURATION 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 incorporated into each system version.
 CM is essential for team projects to control changes made by different developers.
 Activities:
o Version management.
 Keep track of the multiple version of system components and ensuring that
changes made to components by different developers do not interfere with
each other.
 184

o System building
 The process of assembling program components, data and libraries, then
compiling these to create an executable system.
o 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.
o Release management.
 Preparing software for external release and keeping track of the system versions
that have been released for customer use.

Agile development and CM

 Agile development, where components and systems are changed several times per day, is
impossible without using CM tools.
 The definition 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
 185

 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.
o 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.
o 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 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.

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
 186

is always possible to recreate a baseline from its constituent components.

Branching The creation of a new code-line from a version in an existing code-line.
The new code-line and the existing codeline may then develop
independently.
Code-line A code-line is a set of versions of a software component and other
configuration items on which that component depends.
Configuration (version) The process of ensuring that versions of systems and components are
control 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 or Anything associated with a software project (design, code, test data,
software configuration document, etc.) that has been placed under configuration control.
item (SCI) There are often different versions of a configuration item. Configuration
items have a unique name.
Mainline A sequence of baselines representing different versions of a system.
Merging The creation of a new version of a software component by merging
separate versions in different code-lines.
These code-lines may have been created by a previous branch of one of
the code-lines 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.
 187

 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, VM can be thought of as the process of managing code-lines and baselines.

 Code-lines and baselines

o A code-line is a sequence of versions of source code with later versions in the

sequence derived from earlier versions.
 Code-lines normally apply to components of systems so that there are different
versions of each component.
o 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, …
 Baselines may be specified using a configuration language, which allows you to
define what components are included in a version of a particular system.
 188

 Baselines are important because you often have to recreate a specific version
of a complete system.

Version control systems.

 Version control (VC) system identify, store, and control access to the different versions of
components.
 There are 2 types of modern version control system.
o 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.
o 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
o Version and release identification
o Change history recording.
o Support for independent development.
o Project support
o Storage management.

Public repository and private workspace

 To support independent development without interference, VC systems use the concept of a

project repository and a private workspace.
 189

 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 component warns other users wanting
to check out that component that it has been checked out by someone else.

Repository check-in/check-out
 190

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 version on their private repository
on their own computer.
 191

 When changes are done, they “commit” these changes and update their private server
repository. They may then “push” these changes to the project repository.
 Benefits
o 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.
o Allows for off-line working so that developers can commit changes if they do not have a
network connection.
o 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.

o 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.
o It is then up to the open-source system “manager” to decide when to pull these changes
into the definitive system.

Branching and merging

 Rather than a linear sequence of versions that reflect changes to the component over time,
there may be several independent sequences.
o 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.
 192

o 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.

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.
 193

 Instead of keeping a complete copy of each version, the system stores a list of differences
(deltas) between one version and another.
o 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

o As disk storage is now relatively cheap, Git uses an alternative, faster approach.
o Git does not use deltas but applies a standard compression algorithm to stored files and
their associated meta-information.
o It does not store duplicate copies of files. Retrieving a file simply involves decompressing
it, with no need to apply a chain of operations.
o Git also uses the notion of pack-files where several smaller files are combined into an
indexed single file.

System building

 System building is the process of creating a complete, executable system by compiling and
linking the system components, external libraries, configuration files, …
 194

 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, …
o 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.
o 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.

Build system functionality.

 Build script generation.

 Version management system integration.
 195

 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, …
 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.
o For real-time and embedded systems, the target environment is often smaller and
simpler than the development environment.

Development, build and target platforms.

Agile building

 Check out the mainline system from the version management system into the developer’s
private workspace.
 196

 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.
 Once the system has passed its tests, check 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 component 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.

Continuous integration

 Pros
o 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.
 197

o The most recent system in the mainline is the definitive working system.
 Cons
o 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.
o 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.

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.
 198

 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.

Factors in change analysis

 The consequences of not making the change

 199

 The benefits of the change

 The number of users affected by the change.
 The costs of making the change
 The product release cycle.

Change management and agile methods.

 In some agile methods, customers and 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

 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:
o Major release:
 Deliver significant new functionality.
o Minor release:
 Repair bugs and fix customer problems that have been reported.
 For customer 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 executable code of the system, a release may also include:
 200

o Configuration files:
 Defining how the release should be configured for particular installations.
o Data files (such as files of error messages)
 Needed for successful system operation.
o Installation program
 Used to help install the system on target hardware.
o Electronic and paper document
 Describing the system.
o Packaging and associated publicity
 Designed for that release.

Factors influencing system release planning.

 Competition
o 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 requirements.
o The marketing department of an organization may have made a commitment for
releases to be available at a particular date.
 Platform changes.
o 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 the system.
o If serious system faults are reported which affect the way in 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
 201

 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.
o 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
 202

 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
o 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.
o 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
 203

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.
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.