slides

1. Advance Software Engineering
Lecture 1

2. Recommended books
• lan sommerville software engineering, 9th edition
• Roger S. Pressman, Software Engineering, A
Practitioner’s Approach, Latest Edition, 2005.
• Systems Analysis and Design with UML Version 2.0 An
Object-Oriented Approach, 2nd Ed, Alan Dennis,
Barbara Haley Wixom, David Tegarden

3. 3
Activity
Think about all the devices and systems
that you encounter in your everyday life
which have software controlling them…
List as many as you can
Virtually all countries
depend on complex
computer-based
systems.

4. Software
Programs
Documentation
Data
4
What is Software?
System
Documentation
User
Documentation

5. Software products
• Generic products
– Stand-alone systems that are marketed and sold to
any customer who wishes to buy them.
– Examples – PC software such as graphics programs,
project management tools; CAD software; software
for specific markets such as appointments systems for
dentists.
• Customized products
– Software that is commissioned by a specific customer
to meet their own needs.
– Examples – embedded control systems, air traffic
control software, traffic monitoring systems.
Chapter 1 Introduction 30/10/2014 5

6. Product specification
• Generic products
– 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
– 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.
Chapter 1 Introduction 30/10/2014 6

7. Reasons of Software Failure
• Does not solve user problem
• Schedule Slippage
• Cost overrun
• Poor maintenance

8. Importance of Software Engineering
Adhoc Software development results in such problems:
No planning of development work i.e. no milestones defined.
Deliverables to user not defined.
Poor understanding of user requirements.
No control or review.
Technical incompetence of developers.
Poor understanding of cost and effort by developer and user.

9. 9
Software Crisis
Example 1: 2009,Computer glitch delays flights
Saturday 3rd October 2009-London, England (CNN)
• Dozens of flights from the UK were delayed Saturday after
a glitch in an air traffic control system in Scotland, but the
problem was fixed a few hours later.
• The agency said it reverted to backup equipment as
engineering worked on the system.
• The problem did not create a safety issue but could cause
delays in flights.
• Read more at:
http://edition.cnn.com/2009/WORLD/europe/10/03/uk.fl
ights.delayed

10. 10
Software Crisis
Example 2: Ariane 5 Explosion
• European Space Agency spent 10 years and $7
billion to produce Ariane 5.
• Crash after 36.7 seconds.
• Caused by an overflow error. Trying to store a 64-bit
number into a 16-bit space.
• Watch the video:
http://www.youtube.com/watch?v=z-r9cYp3tTE

11. 11
Software Crisis
Example 3: 1992, London Ambulance Service
• Considered the largest ambulance service in the
world.
• Overloaded problem.
• It was unable to keep track of the ambulances
and their statuses. Sending multiple units to some
locations and no units to other locations.
• Generates many exceptions messages.
• 46 deaths.

12. And Since…
A clever person solves a problem.
A wise person avoids it.
- Albert Einstein

13. 13
Therefore…
A well-disciplined approach to software
development and management is
necessary. This is called engineering.

14. Software Engineering - IEEE
1. The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software; that is,
the application of engineering to software.

15. ‘all aspects of software production’ - Software
engineering is not just concerned with the
technical processes of software development but
also with activities such as software project
management and with the development of tools,
methods and theories to support software
production.
-Sommerville
Software Engineering

16. A software engineer is challenged to
produce high-quality software with
finite amount of resources and to a
predicted schedule and budget.

17. Law of diminishing returns
Making the engineering decision!
Benefit
Cost

18. Software Engineering
Software Engineering is not just about
producing software, but about producing
software in a COST-EFFECTIVE manner.

19. The Balancing Act!
Potentially conflicting requirements
 Cost vs. Efficiency
 Cost vs. Reliability
 Efficiency vs. User-interface
Challenge is to balance these requirements.

20. Well-Engineered Software
 Provides the required functionality
 Reliable
 User-friendly
 Cost-effective
 Efficient
 Maintainable

21. 21
Software Engineering vs. Computer Science
“Computer science is no more about computers than
astronomy is about telescopes.” Edsger Dijkstra
Computer Science
• Theory.
• Fundamentals.
Software Engineering
• Practicalities of software
design, development and
delivery.

22. 22
What is a Software Process?
 Activities and results that produce a software product:
SW Process Activity What is going on there?
Specification
What does the customer need?
What are the constraints?
Development Design & programming.
Validation Checking whether it meets requirements.
Evolution Modifications (e.g. customer/market).

23. Management
Construction
project planning and
management
configuration management
quality assurance
installation and training
etc.
Requirements
Design
Coding
Testing
Maintenance
etc.

24. Software Life-Cycle Steps
Life-cycle model (formerly, process model)
– Requirements phase
– Specification phase
– Design phase
– Implementation phase
– Integration phase
– Maintenance phase
– Retirement

25. 25
What is a Software Process Model?
A software process model is a standardized format for
• planning • organizing, and • running a development project.
Determine the order.
Establish the transition criteria.
Examples of views Focus on…
Workflow
Activities = human actions.
What is input, output, and dependencies.
Dataflow
Activities = transformations of information.
How the input is transformed into output.
Role/Action
What is the role of people involved in each step of
the process?

26. Different Lifecycle Models
• Build-and-fix model
• Waterfall model
• Rapid prototyping model
• Incremental model
• Extreme programming
• Synchronize-and-stabilize model
• Spiral model
• Object-oriented life-cycle models
• Comparison of life-cycle models

27. Waterfall Model
Requirement
Definition
System and
Software Design
Implementation
and Unit Testing
Integration and
System Testing
Operation and
Maintenance

28. Waterfall Model

29. Waterfall Model
Advantages:
Simple and easy to understand
Easy to manage.
Phase don’t overlap.
Suitable for small projects.
Dis Advantages:
Difficult to go back and change.
No working software until late stages.
Risk and uncertainty.
Not suitable for complex projects.

30. Frequently asked questions about
software engineering
Question Answer
What is software? Computer programs and associated documentation.
Software products may be developed for a particular
customer or may be developed for a general market.
What are the attributes of good software? Good software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What are the fundamental software
engineering activities?
Software specification, software development, software
validation and software evolution.
What is the difference between software
engineering and computer science?
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities
of developing and delivering useful software.
What is the difference between software
engineering and system engineering?
System engineering is concerned with all aspects of
computer-based systems development including
hardware, software and process engineering. Software
engineering is part of this more general process.
Chapter 1 Introduction 30

31. Frequently asked questions about
software engineering
Question Answer
What are the key challenges facing
software engineering?
Coping with increasing diversity, demands for reduced
delivery times and developing trustworthy software.
What are the costs of software
engineering?
Roughly 60% of software costs are development costs,
40% are testing costs. For custom software, evolution
costs often exceed development costs.
What are the best software engineering
techniques and methods?
While all software projects have to be professionally
managed and developed, different techniques are
appropriate for different types of system. For example,
games should always be developed using a series of
prototypes whereas safety critical control systems require
a complete and analyzable specification to be developed.
You can’t, therefore, say that one method is better than
another.
What differences has the web made to
software engineering?
The web has led to the availability of software services
and the possibility of developing highly distributed service-
based systems. Web-based systems development has led
to important advances in programming languages and
software reuse.
Chapter 1 Introduction 31

32. Agile Software Development
Agile software development is a group of software development
methodologies based on iterative and incremental development,
where requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams.

33. Manifesto for Agile Software
Development
“uncovering better ways of developing software by doing it and
helping others do it”
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

34. Agile Software Development

35. Agile SDLC

36. Phases of Agile Method
1. Requirements
The first step in the Agile Software Development Process is to identify some high-
level requirements as well as the scope of the release. Because requirements are not
set in stone and are open to more conversation by the team during other phases, the
agile method is more adaptable to changes in requirements as the project grows.

37. Phases of Agile Method
2. Architecture and Design
The goal of the architecture and design phase is to try to identify an architecture that
has a good chance of working. The architecture is often defined using free- form
diagrams which explore the technical infrastructure, and the major business entities
and their relationships.

38. Phases of Agile method
3. Development
The development phase uses an evolutionary method that is an iterative and
incremental approach to software development.
Instead of creating a comprehensive prerequisite such as a requirements
specification, that you review and accept before creating a complete design model; the
critical development piece evolves over time in an iterative manner.
The system is delivered incrementally over time, in small modules that have
immediate business value.

39. Phases of Agile method
4. Test & Feedback
One of the key principles of the Agile Methodology is to conduct the testing of the
software as it is being developed. The software development is test driven. The unit
testing is achieved from the developer’s perspective and the acceptance testing is
conducted from the customer’s perspective

40. Top Agile Practices
1) Daily stand up Meetings
2) Continuous Integration
3) Retrospectives
4) Iteration Demo
5) Iteration planning
6) Burn down Tracking
7) Pair Programming
8) Release Planning
9) Product Backlog
10) Code Refactoring
11) Automated Unit Testing
12) Continuous Testing

41. Daily Stand up Meetings
A stand-up meeting (or simply "stand-up") is a daily team meeting held to provide a
status update to the team members. The 'semi-real-time' status allows participants
to know about potential challenges as well as coordinate efforts to resolve difficult
and/or time-consuming issues.
The meetings are usually time boxed to 5–15 minutes and are held standing up to
remind people to keep the meeting short and to the point.

42. Continuous Integration
Continuous Integration (CI) involves producing a clean build of the system several
times per day.
The idea is not to try to solve every issue up front but, instead, to focus on what you
already know. So the team designs, builds, and tests what they know about the
desired functionality. This creates a working product based on a subset of the
complete product's requirements. Then the team moves on to the next-highest
priority set of requirements and repeats the process.

43. Retrospectives
Retrospective (from Latin retrospectare, "look back") generally means to take a look
back at events that already have taken place.
Retrospectives play a crucial role in software teams. They reflect on how the team
is performing and what can be done to improve.

44. Iteration Demo
At the end of an iteration, the entire team comes together to reflect on the iteration.
Attendees include:
the Scrum Master, who facilitates the meeting,
the Product Owner,
the developers,
the testers,
any other contributors, and
any interested stakeholders.
The goal of the meeting is to create visibility around what occurred in the course of
the iteration and to amplify learning about what could then be planned for the next
iteration.

45. Iteration Demo
The meeting also invites inspection of the metrics that show what occurred in
accepting (or not accepting) items. The attendees evaluate:
 how many items were not completed
 what risks arose
 what items were more complex than originally planned
 what tests were run, passed, or failed
 how many defects were logged
 any other measurements the team has chosen to track in an effort to
continually improve how it prioritizes, estimates, and commits to value delivery in
every iteration

46. Iteration planning
Iteration lengths typically range between 1 and 6 weeks. The team holds a planning
meeting at the beginning of each iteration to break down each of the features
scheduled for the iteration into specific technical tasks. Iteration planning meetings
generally last from 2-4 hours - any more than that and you may be spending too much
time in unnecessary planning; less time than that and you may not be doing enough
planning and collaborating.

47. Burn Down Tracking
A burn down chart is a graphical representation of work left to do versus time. The
outstanding work (or backlog) is often on the vertical axis, with time along the
horizontal.
It is useful for predicting when all of the work will be completed.

48. Pair Programming
Pair programming is an agile software development technique in which two
programmers work together at one workstation. One, the driver, writes code while
the other, the observer (or navigator), reviews each line of code as it is typed in.
The two programmers switch roles frequently.
While reviewing, the observer also considers the strategic direction of the work,
coming up with ideas for improvements and likely future problems to address.
This frees the driver to focus all of his/her attention on the "strategic" aspects of
completing the current task, using the observer as a safety net and guide.

49. Release Planning
The goal of initial release planning is to estimate roughly which features will be
delivered by the release deadline. We use this information to decide whether or
not the project will produce enough ROI (Return on Investment ) to at least pay
for itself, and therefore whether or not we should proceed.

50. Product Backlog
The product backlog is an ordered list of "requirements" that is maintained for a
product. It contains Product Backlog Items that are ordered by the Product
Owner based on considerations like risk, business value, dependencies, date
needed, development effort etc. The features added to the backlog are
commonly written in story format. The product backlog is the “What” that will be
built, sorted in the relative order it should be built in. It is open and editable by
anyone, but the Product Owner is ultimately responsible for ordering the stories
on the backlog for the Development Team.
For example, if the “add spellcheck” and “add table support” features have the
same business value, the one with the smallest development effort will probably
have higher priority, because the ROI (Return on Investment) is higher.

51. Code Refactoring
Refactoring is the process of clarifying and simplifying the design of existing code,
without changing its behavior. Agile teams are maintaining and extending their
code a lot from iteration to iteration, and without continuous refactoring, this is
hard to do. This is because un-refactored code tends to rot.
Rot takes several forms: unhealthy dependencies between classes or packages,
bad allocation of class responsibilities, way too many responsibilities per method
or class, duplicate code, and many other varieties of confusion.

52. Automated Unit Testing
Agile Manifesto favors working software. Automated unit tests bring us close to
that point quicker than other processes.
Automated unit testing also promotes a transparent view into the code’s health
by producing reports that allow anyone to see which problems occur and their
precise locations in the code.
automated unit testing reduces the number of regression bugs,
preventing development sprints from becoming bogged down
and enabling developers to maintain a constant, sustainable work pace.

53. Continuous Testing
Need to ensure that software is of high quality throughout the development. We
need to test early and we need to test often.
Make sure that we get correct requirements to begin with and to ensure that we
test throughout development and not leave testing just before release.

54. Agile Methods
Well-known Agile Software Development
methodsinclude:
Agile Development
• Scrum
• XP (Extreme Programming)
• Lean
• ASD (Adaptive Software
Development)
• FDD (Feature Driven Development)

55. Principles of Agile
Methods
Principle Description
Customer Involvement The customer should be closely involved throughout the
development process.
Their role is to 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 recognised.
The team should be left to develop their own ways of
working without prescriptive processes.
Embrace Change Expect the system requirements to change and design the
system so that it can accommodate these changes.
Maintain Simplicity Focus on simplicity in both the software being developed
and in the development process used.

56. Problems with Agile methods
• It can be difficult to keep the interest of customers 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.

57. THE END!
57