MODULE 1 : Introduction to

Software Engineering
 Professional software development

• Software is not just a program themselves but also all

associated documentation and configuration data .

• What is a software Engineering?

Frequently asked questions about
software engineering
 Software products
• Generic products
• Stand-alone systems that are marketed and sold to any customer who
wishes to buy them.
• Examples – PC software such as graphics programs, project management
tools; CAD software; software for specific markets such as appointments
systems for dentists.
• Organization that develops the software controls the software
specification.
• Customized products(bespoke)

• Software that is commissioned by a specific customer to meet their own

needs.

• Examples – embedded control systems, air traffic control software,

traffic monitoring systems.

• Specification is developed and controlled by the organization ie

buying the software.
Essential attributes of good software
 Software Engineering
• Software engineering is an engineering discipline that is
concerned with all aspects of software production from the early
stages of system specification through to maintaining the
system after it has gone into use.

• Engineering discipline
• Using appropriate theories and methods to solve problems
within the organizational and financial constraints.

• All aspects of software production

• Not just technical process of development. Also project
management and the development of tools, methods etc. to
support software production
 Importance of software engineering

• Able to produce reliable and trustworthy systems

economically and quickly.

• It is usually cheaper, in the long run, to use software

engineering methods and techniques for software systems
rather than just write the programs as if it was a personal
programming project.
 Software process activities
•Software specification, where customers and
engineers define the software that is to be produced
and the constraints on its operation.
•Software development, where the software is
designed and programmed.
•Software validation, where the software is checked to
ensure that it is what the customer requires.
•Software evolution, where the software is
modified to reflect changing customer and
market requirements.
General issues that affect most software

• Heterogeneity
• Business and social change
• Security and trust
 Software Engineering diversity
• There are many different types of software system and there is no
universal set of software techniques that is applicable to all of
these.
• The software engineering methods and tools used depend on the
type of application being developed, the requirements of the
customer and the background of the development team.
• Software Engineering fundamentals
• Systems should be developed using a managed and understood
development process.
• Dependability and performance are important for all types of
system.
• Understanding and managing the software specification and
requirements (what the software should do) are important.
• should reuse software that has already been developed rather
than write new software.
 Application types
• Stand-alone applications
• Interactive transaction-based applications
• Embedded control systems
• Batch processing systems
• Entertainment systems
• Data collection systems
• Systems of systems etc…
 Software Engineering and the Web
•The Web is now a platform for running application
and organizations are increasingly developing web-
based systems rather than local systems.

•Cloud computing is an approach to the provision of

computer services where applications run remotely on
the ‘cloud’
 Web software Engineering
• Software reuse is the dominant approach for constructing web-
based systems.
• When building these systems, you think about how you can
assemble them from pre-existing software components and
systems.

• Web-based systems should be developed and delivered

incrementally.
• It is now generally recognized that it is impractical to
specify all the requirements for such systems in advance.

.
 Software engineering ethics
• Software engineering involves wider responsibilities than
simply the application of technical skills.

• Software engineers must behave in an honest and

ethically responsible way if they are to be respected as
professionals.

• Ethical behaviour is more than simply upholding the law but

involves following a set of principles that are morally correct.
 Issues of professional responsibility

• Confidentiality
• Competence
• Intellectual property rights
• Computer misuse
 ACM/IEEE Code of Ethics
• The professional societies in the US have cooperated to
produce a code of ethical practice.

• Members of these organisations sign up to the code of practice

when they join.

• The Code contains eight Principles related to the behaviour of

and decisions made by professional software engineers,
including practitioners, educators, managers, supervisors and
policy makers, as well as trainees and students of the
profession.
The ACM/IEEE Code of Ethics
 SOFTWARE PROCESS: The software process
• A structured set of activities required to develop a software
system.
• Many different software processes but all involve:

• Specification – defining what the system should do;

• Design and implementation – defining the organization of
the system and implementing the system;
• Validation – checking that it does what the customer wants;
• Evolution – changing the system in response to changing
customer needs.

• A software process model is an abstract representation of a

process. It presents a description of a process from some
particular perspective.
 Software process descriptions
• Process descriptions may also include:
• Products, which are the outcomes of a process activity;
• Roles, which reflect the responsibilities of the people
involved in the process;
• Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.
 Plan-driven and agile processes
• Plan-driven processes are 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.
 Software process models
• The waterfall model
• Plan-driven model. Separate and distinct phases of
specification and development.

• Incremental development
• Specification, development and validation are interleaved.
May be plan- driven or agile.

• Reuse-oriented software engineering

• The system is assembled from existing components. May be
plan-driven or agile.

• In practice, most large systems are developed using a process

that incorporates elements from all of these models.
The waterfall model
 Waterfall model phases
• There are separate identified phases in the waterfall model:

– Requirements analysis and definition

– System and software design
– Implementation and unit testing
– Integration and system testing
– Operation and maintenance

• The 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
 Waterfall model problems
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
Incremental development
•Incremental Development is based on the idea of
developing an initial implementation, exposing this to user
comment and evolving it through several versions until an
adequate system has been developed.

• Specification, development and validation activities are

interleaved.

•It is better for business,e-commerce and software systems.

•The customer can evaluate the system at a relatively early

stage in the development to see if it delivers what is
required
 Incremental development benefits
• The cost of accommodating changing customer requirements is
reduced.

• It is easier to get customer feedback on the development work

that has been done.

• More rapid delivery and deployment of useful software to the

customer is possible
Incremental development problems

• The process is not visible.

• System structure tends to degrade as new increments are added
 Process activities

•The four basic process activities of specification,

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/requirement Engg
• The process of establishing and defining what services are
required from the system and identifying the constraints on
the system’s operation and development.

• Is a particularly critical stage of the software process as errors

at this stage inevitably lead to later problems in system design
and implementation.

• RE process aims to produce an agreed requirements document

that specifies a system satisfying stakeholder requirements.

• Requirements are presented at two levels: End users and

customers need a high level statement of the requirements;
system developers need a more detailed system specification.
The requirements engineering process
• .
Software specification
• Requirements engineering process
• Feasibility study
• Is it technically and financially feasible to build the system?
• Developed within the existing budgetary constraints.(cost effective)
• Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
• Observations from existing systems, discussions with potential users ,task analysis.
• This may involve the development of one or more models and prototypes
• Requirements specification
• Is the activity of translating the information gathered during the analysis activity into
a document
• Two types of requirements
• User requirements :are abstract statements of the system requirements for the
customer and end user of the system.
• System requirements are a more detailed description of the functionality to be
provided.
• Requirements validation
• Checking the validity of the requirements(consistent/complete)
 Software design and implementation
•The process of converting the system specification
into an executable system.

•Software design
•Design a software structure that realises the
specification;

•Implementation
•Translate this structure into an executable program;

•The activities of design and implementation are

closely related and may be inter-leaved.
A general model of the design process
 Design activities
•Architectural design, where you identify the overall
structure of the system, the principal components
(sometimes called sub-systems or modules), their
relationships and how they are distributed.
•Interface design, where you define the interfaces
between system components. This interface
specification must be unambiguous.
•Component design, where you take each system
component and design how it will operate.
•Database design, where you design the system data
structures and how these are to be represented in a
database. ,depends on whether an existing database is to
be reused or a new database is to be created.
 Design outputs

• System Architecture
• Database Specification
• Interface specification
• Component specification
 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.

•Validation involves checking and review processes and

system testing.

•System testing involves executing the system with test

cases that are derived from the specification of the real
data to be processed by the system.

•Testing is the most commonly used V & V activity.

 Stages of testing

3 stage process
System components are tested(component defects are
discovered early in the process)
then the integrated system is tested,(interface problems are
found when the system is integrated)
Finally the system is tested with the customers data.
 Testing stages
• Development or component testing
• Individual components are tested independently;
• Components may be functions or objects
• Test automation tools can rerun component tests when new versions of
the components are created, are commonly used.
• System testing
• Testing of the system as a whole.
• system meets its functional and non functional requirements ,
• Acceptance testing(alpha testing)
• This is the final stage in the testing process before the system is
accepted for operational use.
• Testing with customer data to check that the system meets the customer’s
needs.
 • Alpha Testing is a type of software testing performed to
identify bugs before releasing the product to real users or to the
public.

• Alpha Testing is one of the user acceptance testing.

• This alpha testing process continues until the system developer

and the client agree that the delivered system is an acceptable
implementation of requirements.

• Beta testing

• When software is to be marketed as a software product ,beta

testing is used.

• Beta Testing is performed by real users of the software

application in a real environment.
•This involves delivering a system to a number of
potential users who agree to use that system.

•They report problem to system developers.

•This exposes the product to real use and detects

errors that may not have been anticipated by the
system builders.

•After this feedback,the system is modified and

released either for further beta testing or general sale.
Testing phases in a plan-driven software process(v model of
development)
Software evolution
 Coping with change
• Change is inevitable in all large software projects.
• Business changes lead to new and changed system requirements
• New technologies open up new possibilities for improving implementations
• Changing platforms require application changes
• Change leads to rework so the costs of change include both rework (e.g. re-
analyzing requirements) as well as the costs of implementing new functionality
• Reducing the costs of rework
• Change avoidance
• Change tolerance
 Software prototyping
• A prototype is an initial version of a system used to demonstrate concepts and try out design
options, and find out more about the problem and its possible solutions.

• Where a version of the system or part of the system is developed quickly to check the customer
requirements .

• A prototype can be used in:

• The requirements engineering process to help with requirements elicitation and
validation;
• In design processes to explore particular software solutions options and develop a UI design;
• In the testing process to run back-to-back tests.

• Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
 The process of prototype development

• May be based on rapid prototyping languages or tools

• May involve leaving out functionality
• Prototype should focus on areas of the product that are not well-
understood;
• Error checking and recovery may not be included in the prototype;
• Focus on functional rather than non-functional requirements
such as reliability and security
 Throw-away prototypes
• Prototypes should be discarded after development as they are not a good basis for a
production system:
• It may be impossible to tune the system to meet non-functional
requirements;
• Prototypes are normally undocumented;
• The prototype structure is usually degraded through rapid change;
• The prototype probably will not meet normal organisational quality
standards.

Incremental development and delivery

• Incremental development
• Develop the system in increments and evaluate each increment before proceeding to the
development of the next increment;
• Normal approach used in agile methods;
• Evaluation done by user/customer proxy.
• Incremental delivery
• Is an approach to software development where some of the developed increments are delivered
to the customer and deployed for use in an operational environment.
• In an incremental delivery process ,the customer identify the services to be provided by the
system.
• They identify which services are most/less important.

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

• Once an increment is completed and delivered, customers can put into service.
• They can experiment with the system and helps to clarify their requirements for
later system increments.

• As new increments are completed ,they are integrated with the existing
increments so that functionality improves with each delivered increment.
 Incremental delivery advantages
• Customer value can be delivered with each increment so system
functionality is available earlier.
• Early increments act as a prototype to help elicit requirements for later
increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most testing
• Incremental delivery problems
• Most systems require a set of basic facilities that are used by different parts
of the system.
• The essence of iterative processes is that the specification is developed in
conjunction with the software.
 Boehm’s spiral model
• Process is represented as a spiral rather than as a
sequence of activities with backtracking.

• Each loop in the spiral represents a phase in the process.

• The innermost loop might be concerned with system

feasibility,next is requirement definition,system design,….

• No fixed phases such as specification or design - loops in the

spiral are chosen depending on what is required.

• Risks are explicitly assessed and resolved throughout the

process.
 Spiral model sectors
• Objective setting
• Specific objectives for the phase are identified.
• Constraints on the process and the product are identified and a
detailed management plan is drawn up.
• Project risks are identified.
• Risk assessment and reduction
• Risks are assessed and activities put in place to reduce the key risks.
• Development and validation
• A development model for the system is chosen which can be any of the
generic models.
• Planning
• The project is reviewed and the next phase of the spiral is planned.
 Spiral model usage
• Spiral model has been very influential in helping people think about
iteration in software processes and introducing the risk-driven approach to
development.
• In practice, however, the model is rarely used as published for practical
software development.

AGILE software development

• Rapid development and delivery is now often the most important requirement for
software systems
• Businesses operate in a fast –changing requirement and it is practically impossible to produce a
set of stable software requirements
• Software has to evolve quickly to reflect changing business needs.
• Agile development
• Specification, design and implementation are inter-leaved
• System is developed as a series of versions with stakeholders involved in version evaluation
• Extensive tool support is used to support the development process.
• User interfaces are often developed using an IDE and graphical toolset.
 Agile methods
• The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to be
able to respond quickly to changing requirements without
excessive rework.
Plan driven/agile
 Agile manifesto
• We are uncovering better ways of developing software by doing
it and helping others do it. Through this work we have come to
value:
• Individuals and interactions over processes
and tools Working software over
comprehensive documentation Customer
collaboration over contract negotiation
Responding to change over following a plan
• That is, while there is value in the items on the right, we value
the items on the left more.
The principles of agile methods
Agile development techniques:XP(Extreme programming) release cycle
Extreme programming practices
XP practices
• User stories:
• Software requirements always change. In Agile methods , requirements elicitation is
integrated with development by the idea of “user stories”
• After the discussion of development team with customer, they develop a “story card” that
briefly describes a story that encapsulates the customer needs.
• The development team then aims to implement that scenario in a future release of the
software.
• User stories may be used in planning system iterations.
• Once the story cards have been developed, the development team breaks these down into
tasks and estimates the effort and resources required for implementing each task.
• This usually involves discussions with the customer to refine the requirements.
• The customer then prioritizes the stories for implementation, choosing those stories that can be
used immediately to deliver useful business support.
• The intention is to identify useful functionality that can be implemented in about two weeks,
when the next release of the system is made available to the customer.
• If changes are required for a system that has already been delivered, new story cards are
developed and again, the customer decides whether these changes should have priority over
new functionality.
 Test-first development
• Extreme Programming developed a new approach to program testing to address the
difficulties of testing without a specification. Testing is automated and is central to
the development process, and development cannot proceed until all tests have been
successfully executed. The key features of testing in XP are:
• 1. test-first development:
• Write test before write the code.
• Writing tests implicitly defines both an interface and a specification of behavior for
the functionality being developed.
• Problems of requirements and interface misunderstandings are reduced.
• Test-first development requires there to be a clear relationship between system
requirements and the code implementing the corresponding requirements.
• In XP, this relationship is clear because the story cards representing the requirements
are broken down into tasks and the tasks are the principal unit of implementation.
• In test-first development, the task implementers have to thoroughly understand
the specification so that they can write tests for the system.
• This means that ambiguities and omissions in the specification have to be clarified
before implementation begins. It also avoids the problem of “test-lag.” This may
happen when the developer of the system works at a faster pace than the tester.
2. Incremental test development from scenarios,
• Develop each tasks, so that the development schedule can be
maintained.
3. User involvement in the test development and validation, and
• The role of the customer in the testing process is to help develop acceptance
tests for the stories that are to be implemented in the next release of the
system.
• 4. The use of automated testing frameworks.
• Test automation is essential for test-first development. Tests are written as
executable Components before the task is implemented. These testing
components should be stand-alone, should simulate the submission of input
to be tested, and should check that the result meets the output specification.
• An automated test framework is a system that makes it easy to write
executable tests and submit a set of tests for execution. JUnit is a widely used
example of an automated testing framework for Java program
Pair programming:
• The programming pair sits at the same computer to develop the
software. However, the same pair do not always program
together. Rather, pairs are created dynamically so that all team
members work with each other during the development
process.
Pair programming has a number of advantages.
1. It supports the idea of collective ownership and responsibility
for the system.
2. It acts as an informal review process because each line of
code is looked at by at least two people.
3.It encourages refactoring to improve the software structure.
 Agile Project Management
• The principal responsibility of software project managers is to manage the project
so that the software is delivered on time and within the planned budget for the
project.
• Scrum
• The Scrum approach is a general agile method and focus is on managing iterative
practices.
• The Scrum Process
• The Sprint Cycle
• Each process iteration produces a product increment that could be delivered to
customers.
• The starting point for planning is the product backlog, which is the list of work to be
done on the project. —the list of items such as product features, requirements, user
stories and engineering improvement that have to be worked on by the Scrum team.
• The product owner has a responsibility to ensure the level of specification is appropriate
for the work to be done.
• Each sprint cycle lasts a fixed length of time, which is usually between 2 and 4 weeks. At
the beginning of each cycle, the Product Owner prioritizes the items on the product
backlog to define which are the most important items to be developed in that cycle.
• Sprints are never extended to take account of unfinished work. Items are returned to the
product backlog if these cannot be completed within the allocated time for the sprint.
• The whole team is then involved in selecting which of the highest priority items they
believe can be completed. They then estimate the time required to complete these items.
To make these estimates, they use the velocity attained in previous sprints, that is, how
much of the backlog could be covered in a single sprint. This leads to the creation of a
sprint backlog—the work to be done during that sprint.
• The team self-organizes to decide who will work on what, and the sprint begins.
Teamwork in Scrum
• The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of
work to be done, records decisions, measures progress against the backlog and
communicates with customers and management outside of the team.
• The whole team attends short daily meetings (scrum)where all team members share
information, describe their progress since the last meeting, problems that have arisen
and what is planned for the following day.
• This means that everyone on the team knows what is going on and, if problems arise, can
re-plan short-term work to cope with them, there is no top-down direction from the Scrum
Master.
• Everyone participates in this short-term planning; the daily interactions among Scrum
teams may be coordinated using a Scrum board. This is an office whiteboard that includes
information and post-it notes about the Sprint backlog, work done, unavailability of staff,
and so on. This is a shared resource for the whole team, and anyone can change or move
items on the board. It means that any team member can, at a glance, see what others are
doing and what work remains to be done.
• At the end of each sprint, there is a review meeting, which involves the whole team.
This meeting has two purposes.
• First, it is a means of process improvement. The team reviews the way they have
worked and reflects on how things could have been done better.
• Second, it provides input on the product and the product state for the product backlog
review that precedes the next sprint
 Scrum benefits
• The product is broken down into a set of manageable and
understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have visibility of everything and consequently team
communication is improved.
• Customers see on-time delivery of increments and gain feedback on how
the product works.
• Trust between customers and developers is established and a positive culture
is created in which everyone expects the project to succeed.
• For offshore development, the product owner is in a different country from
the development team, which may also be distributed. Figure shows the
requirements for Distributed scrum