Introduction to Software Engineering & Programming (3)
Introduction to Software Engineering & Programming (3)
Software
methods were developed, such as structured
programming, information hiding, and object-
oriented development.
Engineering
Tools and standard notations were
developed which are the basis of
today’s software engineering.
Software engineering is essential for the
functioning of government, society, and
national and international businesses and
Introduction institutions.
What are the attributes of Good software should deliver the required functionality
good and performance to the user and should be maintainable,
software? dependable and usable.
What is the difference between System engineering is concerned with all aspects of
software engineering and computer-based systems development including hardware,
system software and process engineering. Software engineering is
engineering? part of this more general process.
What are the key challenges Coping with increasing diversity, demands for reduced
facing software engineering? delivery times and developing trustworthy software.
What are the best software While all software projects have to be professionally
engineering techniques and managed and developed, different techniques are
methods? appropriate for different types of system.
For example, games should always be developed using a
series of prototypes whereas safety critical control systems
require a complete and analyzable specification to be
developed.
There are no methods and techniques that are good for
everything.
Professional Software Development (Contd.)
• Software engineers are concerned with developing
software products, that is, software that can be sold to
a customer.
• Intellectual Property Rights: He should be aware of local laws governing the use of
intellectual property, such as patents and copyrights. He should be careful
to protect the intellectual property of his employers and clients.
• Computer Misuse: He should not use his technical skills to misuse other
people’s computers. Computer misuse ranges from relatively trivial (game
playing on an employer’s machine) to extremely serious (disseminating
viruses or other malware).
Software Processes
• A software process is a set of related activities that
leads to the production of a software system.
• System And Software Design: The systems design process allocates the requirements to
either hardware or software systems. It establishes an overall system
architecture. Software design involves identifying and describing the fundamental
software system abstractions and their relationships.
• Implementation And Unit Testing: The software design is realised as a set of programs
or program units during this stage. Unit testing involves verifying that each unit
meets its specifications.
• Integration And System Testing: The individual program units or programs are
integrated and tested as a complete system to ensure the software requirements
have been met. After testing, the software system is delivered to the customer.
• Operation And Maintenance: Normally, this is the longest life-cycle phase. The system
is installed and put into practical use. Maintenance involves correcting errors not
discovered in earlier stages of the life cycle, improving the implementation of
system units, and enhancing the system’s services as new requirements are
discovered.
The Waterfall Model (Contd.)
• In principle, the result of each phase in the waterfall model is
one or more approved documents (“signed off”). The
following phase should not start until the previous phase has
finished.
• For hardware development, where high manufacturing costs
are involved, this makes sense. However, for software
development, these stages overlap and feed information to
each other.
• During design, problems with requirements are identified;
during coding, design problems are found, and so on.
• The software process, in practice, is never a simple linear
model but involves feedback from one phase to another.
The Waterfall Model (Contd.)
• The need for early commitment and system rework when changes
are made means that the waterfall model is only appropriate for
some types of systems:
• Embedded systems, where the software has to interface with hardware
systems. Because of the inflexibility of hardware, it is not usually possible
to delay decisions on the software’s functionality until it is implemented.
• Critical systems, where there is a need for extensive safety and security
analysis of the software specification and design. The specification and
design documents must be complete in these systems to make this analysis
possible. Safety-related problems in the specification and design are usually
costly to correct at the implementation stage.
58
RAPID SOFTWARE DEVELOPMENT
Rapid development and delivery is now often the most
important requirement for software systems
Businesses operate in a fast – changing requirement and it is practically
impossible to produce a set of stable software requirements
Software has to evolve quickly to reflect changing business needs.
60
PLAN-DRIVEN
AND AGILE
DEVELOPMENT
61
PLAN-DRIVEN AND AGILE
DEVELOPMENT
Plan-driven development
A plan-driven approach to software engineering is based on
separate development stages with the outputs to be
produced at each of these stages planned in advance.
Not necessarily waterfall model – plan-driven, incremental
development is possible
Iteration occurs within activities.
Agile development
Specification, design, implementation and testing are inter-
leaved and the outputs from the development process are
decided through a process of negotiation during the
software development process.
AGILE METHODS
Dissatisfaction with the overheads involved in software design
methods of the 1980s and 1990s led to the creation of agile
methods. These methods:
Focus on the code rather than the design
Are based on an iterative approach to software development
Are intended to deliver working software quickly and evolve this quickly to
meet changing requirements.
The aim of agile methods is to reduce overheads in the software
process (e.g. by limiting documentation) and to be able to
respond quickly to changing requirements without excessive
rework.
63
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.
64
THE PRINCIPLES OF AGILE METHODS
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
65
AGILE METHOD APPLICABILITY
▪Product development where a software company is
developing a small or medium-sized product for sale.
Virtually all software products and apps are now developed using an
agile approach
▪Custom system development within an organization,
where there is a clear commitment from the customer
to become involved in the development process and
where there are few external rules and regulations that
affect the software.
66
AGILE DEVELOPMENT
TECHNIQUES
67
A very influential agile method,
developed in the late 1990s, that
introduced a range of agile
development techniques.
Extreme Programming (XP) takes an
‘extreme’ approach to iterative
EXTREME development.
PROGRAMMING New versions may be built several times per
day;
Increments are delivered to customers every 2
weeks;
All tests must be run for every build and the
build is only accepted if tests run successfully.
68
THE EXTREME
PROGRAMMING RELEASE
CYCLE
69
EXTREME PROGRAMMING PRACTICES (A)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and their
relative priority. The developers break these stories into development
‘Tasks’.
Small releases The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and incrementally
add functionality to the first release.
Simple design Enough design is carried out to meet the current requirements and no
more.
Test-first development An automated unit test framework is used to write tests for a new piece
of functionality before that functionality itself is implemented.
Refactoring All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and
maintainable.
70
EXTREME PROGRAMMING PRACTICES (B)
Pair programming Developers work in pairs, checking each other’s work and providing
the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that no
islands of expertise develop and all the developers take responsibility
for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into the
whole system. After any such integration, all the unit tests in the
system must be passed.
Sustainable pace Large amounts of overtime are not considered acceptable as the net
effect is often to reduce code quality and medium-term productivity
On-site customer A representative of the end-user of the system (the customer) should
be available full time for the use of the XP team. In an extreme
programming process, the customer is a member of the development
team and is responsible for bringing system requirements to the team
for implementation.
71
XP AND AGILE PRINCIPLES
Incremental development is supported through small,
frequent system releases.
Customer involvement means full-time customer
engagement with the team.
People not process through pair programming, collective
ownership and a process that avoids long working hours.
Change supported through regular system releases.
Maintaining simplicity through constant refactoring of
code.
72
INFLUENTIAL XP PRACTICES
Extreme programming has a technical focus and is not
easy to integrate with management practice in most
organizations.
Consequently, while agile development uses practices
from XP, the method as originally defined is not widely
used.
Key practices
User stories for specification
Refactoring
Test-first development
Pair programming
73