COMSCI 3100: SOFTWARE ENGINEERING

CHAPTER 1: INTRODUCTION 2. Customized Products

LECTURE 1  Software that is commissioned by specific
Software Engineering is the science and art of building customers to meet their own needs.
significant software systems that are:  Examples – embedded control systems, air traffic
control software, traffic monitoring systems.
1. on time  The specification of what the software should do
2. on budget is owned by the customer for the software and
3. with acceptable performance they make decisions on software changes that are
4. with correct operation. required.

Software Engineering FAQs

 The economies of ALL developed nations are 1. What is software?
dependent on software. - Computer programs and associated
 More and more systems are software controlled documentation. Software products may be
 Software engineering is concerned with theories, developed for a particular customer or may be
methods and tools for professional software developed for a general market
development. 2. What are the attributes of good software?
 Expenditure on software represents a significant - Good software should deliver the required
fraction of Gross National Product (GNP) in all functionality and performance to the user and
developed countries should be maintainable, dependable and usable.
3. What is software engineering?
Software Costs
- Software engineering is an engineering discipline
 Software costs often dominate computer system that is concerned with all aspects of software
costs. The costs of software on a PC are often production.
greater than the hardware cost. 4. What are the fundamental software engineering
 Software costs more to maintain than it does to activities?
develop. For systems with a long life, maintenance - Software specification, software development,
costs may be several times development costs. software validation and software evolution.
 Software engineering is concerned with cost- 5. What is the difference between software
effective software development. engineering and computer science?
- Computer science focuses on theory and
Software Products fundamentals; software engineering is concerned
1. Generic products with the practicalities of developing and delivering
useful software.
 Stand-alone systems that are marketed and sold 6. What is the difference between software
to any customer who wishes to buy them. engineering and system engineering?
 Examples – PC software such as graphics - System engineering is concerned with all aspects
programs, project management tools; CAD of computer-based systems development
software; and software for specific markets such including hardware, software and process
as appointment systems for dentists. engineering. Software engineering is part of this
 The specification of what the software should do more general process.
is owned by the software developer and decisions 7. What are the key challenges facing software
on software change are made by the developer. engineering?
- Coping with increasing diversity, demands for
reduced delivery times and developing
trustworthy software
COMSCI 3100: SOFTWARE ENGINEERING

8. What are the costs of software engineering? 4. Acceptability

- Roughly 60% of software costs are development - Software must be acceptable to the type of users
costs, 40% are testing costs. For custom software, for which it is designed. This means that it must be
evolution costs often exceed development costs. understandable, usable and compatible with other
9. What are the best software engineering techniques systems that they use.
and methods?
- While all software projects have to be Importance of Software Engineering
professionally managed and developed, different  More and more, individuals and society rely on
techniques are appropriate for different types of advanced software systems. We need to be able
system. For example, games should always be to produce reliable and trustworthy systems
developed using a series of prototypes whereas economically and quickly.
safety critical control systems require a complete  It is usually cheaper, in the long run, to use
and analyzable specification to be developed. You software engineering methods and techniques
can’t, therefore, say that one method is better for software systems rather than just write the
than another. programs as if it was a personal programming
10. What differences has the web made to software project. For most types of system, the majority
engineering? of costs are the costs of changing the software
- The web has led to the availability of software after it has gone into use.
services and the possibility of developing highly
distributed service-based systems. Web-based Software Process Activities
systems development has led to important
1. Software specification, where customers and
advances in programming languages and software
engineers define the software that is to be
reuse.
produced and the constraints on its operation.
Essential Attributes of Good Software 2. Software development, where the software is
Product designed and programmed.
3. Software validation, where the software is checked
1. Maintainability to ensure that it is what the customer requires.
- Software should be written in such a way so that it 4. Software evolution, where the software is modified
can evolve to meet the changing needs of to reflect changing customer and market
customers. This is a critical attribute because requirements.
software change is an inevitable requirement of a
changing business environment. General Issues that Affect most Software
2. Dependability and Security 1. Heterogeneity
- Software dependability includes a range of - Increasingly, systems are required to operate as
characteristics including reliability, security and distributed systems across networks that include
safety. Dependable software should not cause different types of computer and mobile devices.
physical or economic damage in the event of 2. Business and Social Change
system failure. Malicious users should not be able
- Business and society are changing incredibly
to access or damage the system. quickly as emerging economies develop and new
3. Efficiency technologies become available. They need to be
- Software should not make wasteful use of system able to change their existing software and to
resources such as memory and processor cycles. rapidly develop new software.
Efficiency therefore includes responsiveness, 3. Security and Trust
processing time, memory utilisation, etc.
- As software is intertwined with all aspects of our
lives, it is essential that we can trust that software.
COMSCI 3100: SOFTWARE ENGINEERING

Software Engineering Diversity Software Engineering Fundamentals

 There are many different types of software Some fundamental principles apply to all types of
system and there is no universal set of software software system, irrespective of the development
techniques that is applicable to all of these. techniques used:
 The software engineering methods and tools
 Systems should be developed using a managed
used depend on the type of application being
and understood development process. Of
developed, the requirements of the customer
course, different processes are used for
and the background of the development team.
different types of software.
Application Types  Dependability and performance are important
for all types of system.
1. Stand-alone applications  Understanding and managing the software
- These are application systems that run on a local specification and requirements (what the
computer, such as a PC. They include all necessary software should do) are important.
functionality and do not need to be connected to  Where appropriate, you should reuse software
a network. that has already been developed rather than
2. Interactive transaction-based applications write new software.
- Applications that execute on a remote computer
and are accessed by users from their own PCs or Software Engineering and the Web
terminals. These include web applications such as  The Web is now a platform for running
e-commerce applications. application and organizations are increasingly
3. Embedded control systems developing web-based systems rather than local
- These are software control systems that control systems.
and manage hardware devices. Numerically, there  Web services (discussed in Chapter 19) allow
are probably more embedded systems than any application functionality to be accessed over
other type of system. the web.
4. Batch processing systems  Cloud computing is an approach to the
- These are business systems that are designed to provision of computer services where
process data in large batches. They process large applications run remotely on the ‘cloud’.
numbers of individual inputs to create ▪ Users do not buy software buy pay
corresponding outputs. according to use.
5. Entertainment systems
- These are systems that are primarily for personal Web Software Engineering
use and which are intended to entertain the user.  Software reuse is the dominant approach for
6. Systems for modeling and simulation constructing web-based systems.
- These are systems that are developed by scientists ▪ When building these systems, you
and engineers to model physical processes or think about how you can assemble
situations, which include many, separate, them from pre-existing software
interacting objects. components and systems.
7. Data collection systems  Web-based systems should be developed and
- These are systems that collect data from their delivered incrementally.
environment using a set of sensors and send that ▪ It is now generally recognized that it is
data to other systems for processing. impractical to specify all the
8. Systems of systems requirements for such systems in
- These are systems that are composed of a number advance.
of other software systems.  User interfaces are constrained by the
capabilities of web browsers.
COMSCI 3100: SOFTWARE ENGINEERING

▪ Technologies such as AJAX allow rich ACM/IEEE Code of Ethics

interfaces to be created within a web
browser but are still difficult to use.  The professional societies in the US have
Web forms with local scripting are more cooperated to produce a code of ethical
commonly used. practice.
 Members of these organisations sign up to the
code of practice when they join.
 The Code contains eight Principles related to
LECTURE 2: ETHICS
the behaviour of and decisions made by
Software Engineering Ethics professional software engineers, including
practitioners, educators, managers, supervisors
 Software engineering involves wider
and policy makers, as well as trainees and
responsibilities than simply the application of
students of the profession.
technical skills.
 Software engineers must behave in an honest
and ethically responsible way if they are to be
respected as professionals.
 Ethical behaviour is more than simply upholding
the law but involves following a set of principles
that are morally correct.

Issues of Professional Responsibility

1. Confidentiality
- Engineers should normally respect the
confidentiality of their employers or clients
irrespective of whether or not a formal
confidentiality agreement has been signed.
2. Competence
- Engineers should not misrepresent their level of
competence. They should not knowingly accept
work which is outwith their competence.
3. Intellectual Property Rights
- Engineers should be aware of local laws governing
the use of intellectual property such as patents,
copyright, etc. They should be careful to ensure
that the intellectual property of employers and
clients is protected.
4. Computer Misuse Ethical Principles
- Software engineers should not use their technical 1. PUBLIC - Software engineers shall act
skills to misuse other people’s computers. consistently with the public interest.
Computer misuse ranges from relatively trivial 2. CLIENT AND EMPLOYER - Software engineers
(game playing on an employer’s machine, say) to shall act in a manner that is in the best interests
extremely serious (dissemination of viruses). of their client and employer consistent with the
public interest.
3. PRODUCT - Software engineers shall ensure
that their products and related modifications
COMSCI 3100: SOFTWARE ENGINEERING

meet the highest professional standards - Sends signals to a micro-pump to deliver the
possible. correct dose of insulin.
4. JUDGMENT - Software engineers shall maintain - Safety-critical system as low blood sugars can lead
integrity and independence in their professional to brain malfunctioning, coma and death; high-
judgment. blood sugar levels have long-term consequences
5. MANAGEMENT - Software engineering such as eye and kidney damage.
managers and leaders shall subscribe to and
promote an ethical approach to the
management of software development and
maintenance.
6. PROFESSION - Software engineers shall advance
the integrity and reputation of the profession
consistent with the public interest. -
7. COLLEAGUES - Software engineers shall be fair
to and supportive of their colleagues.
8. SELF - Software engineers shall participate in
lifelong learning regarding the practice of their
profession and shall promote an ethical -
approach to the practice of the profession.
Essential High-level requirements
Ethical Dilemmas
- The system shall be available to deliver insulin
 Disagreement in principle with the policies of when required.
senior management. - The system shall perform reliably and deliver
 Your employer acts in an unethical way and the correct amount of insulin to counteract the
releases a safety-critical system without current level of blood sugar.
finishing the testing of the system. - The system must therefore be designed and
 Participation in the development of military implemented to ensure that the system always
weapons systems or nuclear systems meets these requirements.

Case Studies A patient information system for mental health

care
1. A personal insulin pump
- An embedded system in an insulin pump used by - A patient information system to support mental
diabetics to maintain blood glucose control. health care is a medical information system that
2. A mental health case patient management system maintains information about patients suffering
- A system used to maintain records of people from mental health problems and the
receiving care for mental health problems. treatments that they have received.
3. A wilderness weather station - Most mental health patients do not require
- A data collection system that collects data about dedicated hospital treatment but need to
weather conditions in remote areas. attend specialist clinics regularly where they can
meet a doctor who has detailed knowledge of
Insulin Pump Control System
their problems.
- Collects data from a blood sugar sensor and - To make it easier for patients to attend, these
calculates the amount of insulin required to be clinics are not just run in hospitals. They may
injected. also be held in local medical practices or
- Calculation based on the rate of change of blood community centres.
sugar levels.
COMSCI 3100: SOFTWARE ENGINEERING

MHC-PMS patients sectioned, the drugs prescribed and their

costs, etc.
- The MHC-PMS (Mental Health Care-Patient
Management System) is an information system MHC-PMS Concerns
that is intended for use in clinics.
- It makes use of a centralized database of patient
1. Privacy
information but has also been designed to run on - It is essential that patient information is
a PC, so that it may be accessed and used from confidential and is never disclosed to anyone
sites that do not have secure network apart from authorised medical staff and the
connectivity. patient themselves.
- When the local systems have secure network 2. Safety
access, they use patient information in the - Some mental illnesses cause patients to become
database but they can download and use local suicidal or a danger to other people. Wherever
copies of patient records when they are possible, the system should warn medical staff
disconnected. about potentially suicidal or dangerous patients.
- The system must be available when needed
MHC-PMS goals otherwise safety may be compromised and it may
be impossible to prescribe the correct medication
- To generate management information that allows
to patients.
health service managers to assess performance
against local and government targets. Wilderness Weather Station
- To provide medical staff with timely information
to support the treatment of patients. - The government of a country with large areas of
wilderness decides to deploy several hundred
weather stations in remote areas.
- Weather stations collect data from a set of
instruments that measure temperature and
pressure, sunshine, rainfall, wind speed and wind
direction.

MHC-PMS Key Features

1. Individual Care Management
- Clinicians can create records for patients, edit the
information in the system, view patient history,
etc. The system supports data summaries so that Weather Information System
doctors can quickly learn about the key problems
1. The weather station system
and treatments that have been prescribed.
- This is responsible for collecting weather data,
2. Patient Monitoring
carrying out some initial data processing and
- The system monitors the records of patients that
transmitting it to the data management system.
are involved in treatment and issues warnings if
2. The data management and archiving system
possible problems are detected.
- This system collects the data from all of the
3. Administrative Reporting
wilderness weather stations, carries out data
- The system generates monthly management
processing and analysis and archives the data
reports showing the number of patients treated at
3. The station maintenance system
each clinic, the number of patients who have
entered and left the care system, number of
COMSCI 3100: SOFTWARE ENGINEERING

- This system can communicate by satellite with all

wilderness weather stations to monitor the health
of these systems and provide reports of problems.

Additional Software Functionality

 Monitor the instruments, power and
communication hardware and report faults to
the management system.
 Manage the system power, ensuring that
batteries are charged whenever the
environmental conditions permit but also that
generators are shut down in potentially
damaging weather conditions, such as high
wind.
 Support dynamic reconfiguration where parts of
the software are replaced with new versions
and where backup instruments are switched
into the system in the event of system failure.

Key Points
 Software engineering is an engineering
discipline that is concerned with all aspects of
software production.
 Essential software product attributes are
maintainability, dependability and security,
efficiency and acceptability.
 The high-level activities of specification,
development, validation and evolution are part
of all software processes.
 The fundamental notions of software
engineering are universally applicable to all
types of system development.
 There are many different types of system and
each requires appropriate software engineering
tools and techniques for their development.
 The fundamental ideas of software engineering
are applicable to all types of software system.
 Software engineers have responsibilities to the
engineering profession and society. They should
not simply be concerned with technical issues.
 Professional societies publish codes of conduct
which set out the standards of behaviour
expected of their members.
COMSCI 3100: SOFTWARE ENGINEERING

CHAPTER 2: SOFTWARE PROCESSES Software Process Models

LECTURE 1 1. The Waterfall Model
- Plan-driven model. Separate and distinct phases of
Software Process
specification and development
 A structured set of activities required to develop a 2. Incremental Development
software system. - Specification, development and validation are
 Many different software processes but all involve: interleaved. May be plan-driven or agile.
1. Specification – defining what the system should 3. Reuse-oriented Software Engineering
do; - The system is assembled from existing
2. Design and implementation – defining the components. May be plan-driven or agile
organization of the system and implementing the
system; In practice, most large systems are developed using a
3. Validation – checking that it does what the process that incorporates elements from all of these
customer wants; models.
4. Evolution – changing the system in response to
Waterfall Model
changing customer needs
 A software process model is an abstract
representation of a process. It presents a
description of a process from some particular
perspective.

Software Process Descriptions

 When we describe and discuss processes, we
usually talk about the activities in these processes
such as specifying a data model, designing a user
interface, etc. and the ordering of these activities
 Process descriptions may also include: Waterfall Model Phases
- Products, which are the outcomes of a process
activity;  There are separate identified phases in the waterfall
- Roles, which reflect the responsibilities of the model:
people involved in the process; - Requirements analysis and definition
- Pre- and post-conditions, which are statements - System and software design
that are true before and after a process activity - Implementation and unit testing
has been enacted or a product produced. - Integration and system testing
- Operation and maintenance
Plan-driven and Agile Processes  The main drawback of the waterfall model is the
difficulty of accommodating change after the
- Plan-driven processes are processes where all of
process is underway. In principle, a phase has to be
the process activities are planned in advance and
complete before moving onto the next phase.
progress is measured against this plan.
- In agile processes, planning is incremental and it is Waterfall Model Problems
easier to change the process to reflect changing
customer requirements.  Inflexible partitioning of the project into distinct
- In practice, most practical processes include stages makes it difficult to respond to changing
elements of both plan-driven and agile customer requirements.
approaches. - Therefore, this model is only appropriate when
- There are no right or wrong software processes. the requirements are well-understood and
COMSCI 3100: SOFTWARE ENGINEERING

changes will be fairly limited during the design 3. More rapid delivery and deployment of useful
process. software to the customer is possible.
- Few business systems have stable requirements. - Customers are able to use and gain value from the
 The waterfall model is mostly used for large systems software earlier than is possible with a waterfall
engineering projects where a system is developed process.
at several sites.
- In those circumstances, the plan-driven nature of Incremental Development Problems
the waterfall model helps coordinate the work. 1. The process is not visible.
- Managers need regular deliverables to measure
Incremental Development
progress. If systems are developed quickly, it is not
cost-effective to produce documents that reflect
every version of the system.
2. System structure tends to degrade as new
increments are added.
- Unless time and money is spent on refactoring to
improve the software, regular change tends to
corrupt its structure. Incorporating further
software changes becomes increasingly difficult
and costly.

Reuse-oriented Software Engineering

 Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems.
 Process stages
- Component analysis;
- Requirements modification;
- System design with reuse;
- Development and integration.
 Reuse is now the standard approach for building
many types of business system
- Reuse covered in more depth in Chapter 16.

Incremental Development Benefits

1. The cost of accommodating changing customer
requirements is reduced.
Types of Software Component
- The amount of analysis and documentation that
has to be redone is much less than is required with 1. Web services that are developed according to
the waterfall model. service standards and which are available for
2. It is easier to get customer feedback on the remote invocation.
development work that has been done. 2. Collections of objects that are developed as a
- Customers can comment on demonstrations of package to be integrated with a component
the software and see how much has been framework such as .NET or J2EE.
implemented. 3. Stand-alone software systems (COTS) that are
configured for use in a particular environment.
COMSCI 3100: SOFTWARE ENGINEERING

Process Activities  Implementation

- Translate this structure into an executable
 Real software processes are inter-leaved sequences program;
of technical, collaborative and managerial activities  The activities of design and implementation are
with the overall goal of specifying, designing, closely related and may be inter-leaved.
implementing and testing a software system.
 The four basic process activities of specification, A General Model of the Design Process
development, validation and evolution are
organized differently in different development
processes. In the waterfall model, they are
organized in sequence, whereas in incremental
development they are inter-leaved.

Software Specification
 The process of establishing what services are
required and the constraints on the system’s
operation and development.
 Requirements engineering process
1. Feasibility study
a. Is it technically and financially feasible
to build the system?
2. Requirements elicitation and analysis Design Activities
a. What do the system stakeholders 1. Architectural design, where you identify the overall
require or expect from the system? structure of the system, the principal components
3. Requirements specification (sometimes called sub-systems or modules), their
a. Defining the requirements in detail relationships and how they are distributed.
4. Requirements validation 2. Interface design, where you define the interfaces
a. Checking the validity of the between system components.
requirements 3. Component design, where you take each system
component and design how it will operate.
The Requirements Engineering Process 4. Database design, where you design the system data
structures and how these are to be represented in a
database.

Software Validation
 Verification and validation (V & V) is intended to
show that a system conforms to its specification
and meets the requirements of the system
customer.
 Involves checking and review processes and system
testing.
Software Design and Implementation
 System testing involves executing the system with
 The process of converting the system specification test cases that are derived from the specification of
into an executable system. the real data to be processed by the system.
 Software design  Testing is the most commonly used V & V activity.
- Design a software structure that realises the
specification;
COMSCI 3100: SOFTWARE ENGINEERING

Stages of Testing Key Points

 Software processes are the activities involved in
producing a software system. Software process
models are abstract representations of these
processes.
1. Development or component testing  General process models describe the
- Individual components are tested independently; organization of software processes. Examples of
- Components may be functions or objects or these general models include the ‘waterfall’
coherent groupings of these entities. model, incremental development, and reuse-
2. System testing oriented development.
- Testing of the system as a whole. Testing of  Requirements engineering is the process of
emergent properties is particularly important. developing a software specification.
3. Acceptance testing  Design and implementation processes are
- Testing with customer data to check that the concerned with transforming a requirements
system meets the customer’s needs. specification into an executable software
system.
Testing Phases in a Plan-driven Software  Software validation is the process of checking
Process 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.

Software Evolution
LECTURE 2
 Software is inherently flexible and can change.
 As requirements change through changing business Coping with Change
circumstances, the software that supports the  Change is inevitable in all large software projects
business must also evolve and change. - Business changes lead to new and changed
 Although there has been a demarcation between system requirements
development and evolution (maintenance) this is - New technologies open up new possibilities
increasingly irrelevant as fewer and fewer systems for improving implementations
are completely new. - Changing platforms require application
changes
System Evolution
 Change leads to rework so the costs of change
include both rework (e.g. re-analysing
requirements) as well as the costs of implementing
new functionality

Reducing the costs of rework

 Change avoidance, where the software process
includes activities that can anticipate possible
changes before significant rework is required.
COMSCI 3100: SOFTWARE ENGINEERING

 Change tolerance, where the process is designed so - Error checking and recovery may not be
that changes can be accommodated at relatively included in the prototype;
low cost. - Focus on functional rather than non-
functional requirements such as
Software Prototyping reliability and security
 A prototype is an initial version of a system used to
Throw-away prototypes
demonstrate concepts and try out design options.
 A prototype can be used in:  Prototypes should be discarded after
- The requirements engineering process to development as they are not a good basis for a
help with requirements elicitation and production system:
validation; o It may be impossible to tune the system
- In design processes to explore options and to meet non-functional requirements;
develop a UI design; o Prototypes are normally
- In the testing process to run back-to-back undocumented;
tests. o The prototype structure is usually
degraded through rapid change;
Benefits of Prototyping o The prototype probably will not meet
1. Improved system usability. normal organisational quality
2. A closer match to users’ real needs. standards.
3. Improved design quality.
Incremental delivery
4. Improved maintainability.
5. Reduced development effort  Rather than deliver the system as a single
delivery, the development and delivery is
Process of Prototype Development broken down into increments with each
increment delivering part of the required
functionality.
 User requirements are prioritised and the
highest priority requirements are included in
early increments.
 Once the development of an increment is
started, the requirements are frozen though
requirements for later increments can continue
to evolve.

Incremental development and delivery

1. Incremental development
a. Develop the system in increments and
evaluate each increment before proceeding
to the development of the next increment;
Prototype development b. Normal approach used in agile methods;
 May be based on rapid prototyping languages c. Evaluation done by user/customer proxy.
or tools 2. Incremental delivery
 May involve leaving out functionality a. Deploy an increment for use by end-users;
- Prototype should focus on areas of the b. More realistic evaluation about practical
product that are not wellunderstood; use of software;
c. Difficult to implement for replacement
systems as increments have less
COMSCI 3100: SOFTWARE ENGINEERING

functionality than the system being

replaced.

Incremental delivery advantages

 Customer value can be delivered with each
increment so system functionality is available
Spiral Model Sectors
earlier.
 Early increments act as a prototype to help elicit 1. Object setting
requirements for later increments. - Specific objectives for the phase are
 Lower risk of overall project failure. identified.
 The highest priority system services tend to 2. Risk assessment and reduction
receive the most testing. - Risks are assessed and activities put in
place to reduce the key risks.
Incremental delivery problems
3. Development and validation
 Most systems require a set of basic facilities - A development model for the system is
that are used by different parts of the system. chosen which can be any of the generic
 The essence of iterative processes is that the models
specification is developed in conjunction with 4. Planning
the software. - The project is reviewed and the next
phase of the spiral is planned.
Boehm’s spiral model
 Process is represented as a spiral rather than as Spiral Model Usage
a sequence of activities with backtracking.  Spiral model has been very influential in helping
 Each loop in the spiral represents a phase in the people think about iteration in software
process. processes and introducing the risk-driven
 No fixed phases such as specification or design - approach to development.
loops in the spiral are chosen depending on  In practice, however, the model is rarely used as
what is required. published for practical software development.
 Risks are explicitly assessed and resolved
throughout the process. The Rational Unified Process
 A modern generic process derived from the
work on the UML and associated process.
 Brings together aspects of the 3 generic process
models discussed previously.
 Normally described from 3 perspectives
1. A dynamic perspective that shows phases
over time;
2. A static perspective that shows process
activities;
COMSCI 3100: SOFTWARE ENGINEERING

3. A practice perspective that suggests good models, component models, object

practice. models and sequence models.
4. Implementation
Phases in Rational Unified Process
- The components in the system are
implemented and structured into
implementation sub-systems.
Automatic code generation from design
models helps accelerate this process
5. Testing
RUP Phases - Testing is an iterative process that is
carried out in conjunction with
1. Inception
implementation. System testing follows
- Establish the business case for the
the completion of the implementation.
system.
6. Deployment
2. Elaboration
- A product release is created, distributed
- Develop an understanding of the
to users and installed in their
problem domain and the system
workplace.
architecture.
7. Configuration and change management
3. Construction
- This supporting workflow managed
- System design, programming and
changes to the system (see Chapter 25).
testing.
8. Project management
4. Transition
- This supporting workflow manages the
- Deploy the system in its operating
system development (see Chapters 22
environment.
and 23).
RUP Iteration 9. Environment
- This workflow is concerned with making
1. In-phase iteration appropriate software tools available to
- Each phase is iterative with results the software development team.
developed incrementally
2. Cross-phase iteration
- As shown by the loop in the RUP model, RUP Good Practice
the whole set of phases may be enacted
1. Develop software iteratively
incrementally.
- Plan increments based on customer
Static Workflows in the Rational Unified priorities and deliver highest priority
Process increments first.
2. Manage requirements
1. Business modelling - Explicitly document customer
- The business processes are modelled requirements and keep track of changes
using business use cases. to these requirements.
2. Requirements 3. Use component-based architectures
- Actors who interact with the system are - Organize the system architecture as a
identified and use cases are developed set of reusable components.
to model the system requirements 4. Visually model software
3. Analysis and design - Use graphical UML models to present
- A design model is created and static and dynamic views of the
documented using architectural software.
COMSCI 3100: SOFTWARE ENGINEERING

5. Verify software quality

- Ensure that the software meet’s
organizational quality standards.
6. Control changes to software
- Manage software changes using a
change management system and
configuration management tools.

Key Points
 Processes should include activities to cope with
change. This may involve a prototyping phase
that helps avoid poor decisions on requirements
and design.
 Processes may be structured for iterative
development and delivery so that changes may
be made without disrupting the system as a
whole.
 The Rational Unified Process is a modern
generic process model that is organized into
phases (inception, elaboration, construction
and transition) but separates activities
(requirements, analysis and design, etc.) from
these phases.
COMSCI 3100: SOFTWARE ENGINEERING

CHAPTER 3: SOFTWARE Agility

METHODOLOGIES
 Agility is the ability to continuously adapt and
make improvements to the way you work
 Ability to think and understand quickly

History of Agile
History: The Agile Manifesto.

On February 11-13, 2001, at The Lodge at Snowbird ski

resort in the Wasatch mountains of Utah, seventeen
people met to talk, ski, relax, and try to find common
ground—and of course, to eat. What emerged was the
Agile 'Software Development' Manifesto.

"Agile software development” refers to a group of

software development methodologies based on
iterative development, where requirements and
solutions evolve via collaboration between self-
organizing cross-functional teams.

Agile Vs. Waterfall

Agile
 It is not a methodology
 Specific way of Developing Software
 Not a Framework or Process
 Agile is a set of Values and Principles
 Following different practices from various
methodologies and developing specific tools the
teams should follow.
 Guidelines on how to choose: Methods and
Procedure that will work best for the team.
COMSCI 3100: SOFTWARE ENGINEERING

Agile Manifesto 4. What does a self-managing team means?

 We are uncovering better ways of developing - “Self-organizing teams choose how best
software by doing it and helping others do it. to accomplish their work, rather than
Through this work we have come to value: being directed by others outside the
 Individuals and interactions over processes and team.” - from the Scrum Guide
tools 5. Constant feedback cycles and continuous
 Working software over comprehensive improvement
documentation - Agile teams must define a feedback
 Customer collaboration over contract loop. Simply mean informally gathering
negotiation information that the team can discuss
 Responding to change over following a plan and use to improve their efforts.
 That is, while there is value in the items on the Retrospective Meeting.
right, we value the items on the left more. 6. Constant feedback cycles and continuous
improvement
Agile Principles - Agile teams must define a feedback
loop. Keep it Simple and impersonal.
- Don’t wait for your process to break.
Keep learning and adapting.
7. Rapid responsiveness and swarming behavior
- Plan less, deliver more; Stop starting
and start finishing
- Swarming - the act of coming together
to solve a problem or get something
done quickly. Use swarming as a
planned activity not just on addressing
critical issues or key activity that needs
Being Agile to be done.
- Great teams don’t point fingers at
1. Highly Cohesive others or engage in blamestorming.
- Closely United. Swarming focuses energy at a critical
- Their activities are logically consistent area or key activity so it gets done
and supportive of one another 8. Diverse skill sets and share a common vision
2. Loosely Coupled - The developers have the ability to get
- They don’t rely upon a single individual the job done without excessive reliance
to fully define or implement a major on outsiders.
system capability. - The team members have to work
- Thus, epics or large chunk of work together with a shared purpose and a
should be divided into small elements unified commitment.
to be able to deliver working software o Shared knowledge and pairing
iteratively and incrementally. Anyone o Collaboration
can select a portion of the system and o Simple techniques
work on it. o Trust and respect
3. Decentralized o Backlog management
- Servant Leaders – They lead instead of o Quality results
“Command and Control” approach
- Self Organizing teams
COMSCI 3100: SOFTWARE ENGINEERING

Do Agile  Extreme Programming (XP) takes an ‘extreme’

approach to iterative development.
 Engineering practices: o New versions may be built several times
1. Client feedback per day;
2. Daily builds o Increments are delivered to customers
3. Test driven every 2 weeks;
4. Time boxing o All tests must be run for every build and
5. Risk driven the build is only accepted if tests run
Lean successfully.

 Eliminate Waste Pair Programming

o Seeing Waste  In XP, programmers work in pairs, sitting
o unnecessary code or functionality together to develop code.
o starting more than can be completed  In pair programming, programmers sit together
o delay in the software development at the same workstation to develop the
process software.
o unclear or constantly changing  This helps develop common ownership of code
requirements and spreads knowledge across the team.
o bureaucracy slow or ineffective  It serves as an informal review process as each
communication line of code is looked at by more than 1 person.
o partially done work  The sharing of knowledge that happens during
o defects and quality issues pair programming is very important as it
o task switching reduces the overall risks to a project when team
 Amplify Learning members leave.
o Feedback
 Decide as Late as Possible Agile Project Management
o Options Thinking, Making Decisions
 The principal responsibility of software
 Deliver as Fast as Possible
project managers is to manage the project
o Pull Systems, Continuous Integration,
so that the software is delivered on time
Simplicity, Work as a Team
and within the planned budget for the
 Empower the Team
project.
o Self-Determination, Motivation,
 The standard approach to project
Leadership, Expertise
management is plan-driven. Managers draw
o Respecting:
up a plan for the project showing what
o learning how to be assertive and
should be delivered, when it should be
disagree with a point of view, without
delivered and who will work on the
sounding aggressive or threatening or
development of the project deliverables.
just plain argumentative.
 Agile project management requires a
 Build Integrity In
different approach, which is adapted to
o Refactoring, Testing, TDD, Automation.
incremental development and the particular
 See the Whole
strengths of agile methods.
o Measurements, Contracts

Extreme Programming
 Perhaps the best-known and most widely used
agile method.