Software Engineering Methodology- waterfall, iterative, Rational unified process, Agile

1. SOFTWARE ENGINEERING
METHODOLOGY
1

2. SOFTWARE ENGINEERING METHODOLOGY
Waterfall Model
Iterative Model
Rational Unified Process
Agile
 XP
 Scrum
2

3. 1. CLASSICAL WATERFALL MODEL
 Classical waterfall model divides life cycle into phases:
 feasibility study,
 requirements analysis and specification,
 design,
 coding and unit testing,
 integration and system testing,
 maintenance.
3

4. CLASSICAL WATERFALL MODEL
Feasibility Study
Req. Analysis
Design
Coding &
Unit Testing
Integration
Testing
Maintenance
4

5. ITERATIVE WATERFALL MODEL (CONT.)
Feasibility Study
Req. Analysis
Design
Coding
Testing
Maintenance
5

6. 2. ITERATIVE MODEL
Requirements
Gathering Quick Design
Refine
Requirements
Build Prototype
Customer
Evaluation of
Prototype
Design
Implement
Test
Maintain
Customer
satisfied
6

7. 3. RATIONAL UNIFIED PROCESS (RUP)
 The Rational Unified Process (RUP) is an iterative
software development process framework created
by the Rational Software Corporation, a division of
IBM since 2003.
 It has four phases:
 Inception
 Elaboration
 Construction
 Transition
7

8. RATIONAL UNIFIED PROCESS (RUP)
(CONTD…)
 In each of the iteration, the unit of work is divided
into 9 disciplines:
 6 of 9 are engineering disciplines are:
1)Business modeling
2)Requirements
3)Analysis and Design
4)Implementation
5)Test
6)Deployment
 3 of 9 are supporting disciplines are:
1)Configuration and Change Management
2)Project Management
3)Environment
8

9. PHASES OF RUP
9

10. MILESTONE OF PHASES
10
Each phase is concluded with a well-defined milestone—a
point in time at which certain critical decisions must be
made, and therefore key goals must have been achieved.

11. INCEPTION
 During the inception phase, you establish the
business case for the system and delimit the project
scope.
 To accomplish this you must identify all external
entities with which the system will interact (actors)
and define the nature of this interaction at a high-
level.
 This involves identifying all use cases and
describing a few significant ones. The business
case includes success criteria, risk assessment,
and estimate of the resources needed, and a phase
plan showing dates of major milestones. 11

12. INCEPTION (CONTD…)
The outcome of the inception phase is:
 A vision document: a general vision of the core project's
requirements, key features, and main constraints.
 A initial use-case model (10% -20%) complete).
 An initial project glossary (may optionally be partially
expressed as a domain model).
 An initial business case, which includes business context,
success criteria (revenue projection, market recognition,
and so on), and financial forecast.
 An initial risk assessment.
 A project plan, showing phases and iterations.
 A business model, if necessary.
 One or several prototypes. 12

13. ELABORATION PHASE
 The purpose of the elaboration phase is to analyze
the problem domain, establish a sound architectural
foundation, develop the project plan, and eliminate
the highest risk elements of the project.
 Architectural decisions have to be made with an
understanding of the whole system: its scope,
major functionality and nonfunctional requirements
such as performance requirements.
 In the elaboration phase, an executable
architecture prototype is built in one or more
iterations, depending on the scope, size, risk, and
novelty of the project.
13

14. ELABORATION PHASE
The outcome of the elaboration phase is:
 A use-case model (at least 80% complete) — all use cases
and actors have been identified, and most use case
descriptions have been developed.
 Supplementary requirements capturing the non functional
requirements and any requirements that are not associated
with a specific use case.
 A Software Architecture Description.
 An executable architectural prototype.
 A revised risk list and a revised business case.
 A development plan for the overall project, including the
coarse-grained project plan, showing iterations” and
evaluation criteria for each iteration.
 An updated development case specifying the process to be
used.
 A preliminary user manual (optional). 14

15. CONSTRUCTION PHASE
 During the construction phase, all remaining
components and application features are developed
and integrated into the product, and all features are
thoroughly tested.
 The construction phase is, in one sense, a
manufacturing process where emphasis is placed
on managing resources and controlling operations
to optimize costs, schedules, and quality.
 The outcome of the construction phase is a product
ready to put in hands of its end-users.
15

16. CONSTRUCTION PHASE (CONTD…)
At minimum, it consists of:
 The software product integrated on the adequate
platforms.
 The user manuals.
 A description of the current release.
 Here you decide if the software, the sites, and the
users are ready to go operational, without exposing
the project to high risks. This release is often called
a “beta” release.
16

17. TRANSITION PHASE
 The purpose of the transition phase is to transition
the software product to the user community.
 Once the product has been given to the end user,
issues usually arise that require you to develop new
releases, correct some problems, or finish the
features that were postponed.
 The transition phase is entered when a baseline is
mature enough to be deployed in the end-user
domain.
17

18. TRANSITION PHASE (CONTD…)
This includes:
 “beta testing” to validate the new system against
user expectations
 parallel operation with a legacy system that it is
replacing
 conversion of operational databases
 training of users and maintainers
 roll-out the product to the marketing, distribution,
and sales teams
18

19. TRANSITION PHASE (CONTD…)
 The transition phase focuses on the activities
required to place the software into the hands of the
users.
 Typically, this phase includes several iterations,
including beta releases, general availability
releases, as well as bug-fix and enhancement
releases.
19

20. WORKFLOW
 A workflow is a sequence of activities that produces
a result of observable value.
 In UML terms, a workflow can be expressed as a
sequence diagram, a collaboration diagram, or an
activity diagram.
 There are nine core process workflows in the
Rational Unified Process, which represent a
partitioning of all workers and activities into logical
groupings.
20

21. CORE WORKFLOW
The core process workflows are divided into six core
“engineering” workflows:
1. Business modeling workflow
2. Requirements workflow
3. Analysis & Design workflow
4. Implementation workflow
5. Test workflow
6. Deployment workflow
And three core “supporting” workflows:
1. Project Management workflow
2. Configuration and Change Management workflow
3. Environment workflow
21

22. BUSINESS MODELING
 In Business Modeling we document business
processes using so called business use cases.
 This assures a common understanding among all
stakeholders of what business process needs to be
supported in the organization.
 The business use cases are analyzed to
understand how the business should support the
business processes.
 This is documented in a business object-model.
Many projects may choose not to do business
modeling
22

23. REQUIREMENTS
 The goal of the Requirements workflow is to describe
what the system should do and allows the developers
and the customer to agree on that description.
 To achieve this, we elicit, organize, and document
required functionality and constraints; track and
document tradeoffs and decisions.
 A Vision document is created, and stakeholder needs
are elicited. Actors are identified, representing the users,
and any other system that may interact with the system
being developed.
 Use cases are identified, representing the behavior of
the system.
 Because use cases are developed according to the
actor's needs, the system is more likely to be relevant to
the users.
23

24. ANALYSIS & DESIGN
 The goal of the Analysis & Design workflow is to
show how the system will be realized in the
implementation phase. You want to build a system
that:
 Performs—in a specific implementation
environment—the tasks and functions specified in
the use-case descriptions.
 Fulfills all its requirements.
 Is structured to be robust (easy to change if and
when its functional requirements change).
24

25. IMPLEMENTATION
The purpose of implementation is:
 To define the organization of the code, in terms of
implementation subsystems organized in layers.
 To implement classes and objects in terms of
components (source files, binaries, executables,
and others).
 To test the developed components as units.
 To integrate the results produced by individual
implementers (or teams), into an executable
system.
25

26. TEST
The purposes of testing are:
 To verify the interaction between objects.
 To verify the proper integration of all components of
the software.
 To verify that all requirements have been correctly
implemented.
 To identify and ensure defects are addressed prior
to the deployment of the software.
26

27. DEPLOYMENT
The purpose of the deployment workflow is to successfully
produce product releases, and deliver the software to its
end users. It covers a wide range of activities including:
 Producing external releases of the software.
 Packaging the software.
 Distributing the software.
 Installing the software.
 Providing help and assistance to users.
 In many cases, this also includes activities such as:
 Planning and conduct of beta tests.
 Migration of existing software or data.
 Formal acceptance.
27

28. PROJECT MANAGEMENT
 Software Project Management is the art of
balancing competing objectives, managing risk, and
overcoming constraints to deliver, successfully, a
product in which meets the needs of both
customers and the users.
 This workflow focuses mainly on the specific aspect
of an iterative development process. Our goal with
this section is to make the task easier by providing:
 A framework for managing software-intensive projects.
 Practical guidelines for planning, staffing, executing, and
monitoring projects.
 A framework for managing risk.
28

29. CONFIGURATION & CHANGE MANAGEMENT
 In this workflow we describe how to control the numerous
artifacts produced by the many people who work on a common
project.
 Control helps avoid costly confusion, and ensures that resultant
artifacts are not in conflict due to some of the following kinds of
problems:
 Simultaneous Update When two or more workers work
separately on the same artifact, the last one to make changes
destroys the work of the former.
 Limited Notification When a problem is fixed in artifacts
shared by several developers, and some of them are not notified
of the change.
 Multiple Versions Most large programs are developed in
evolutionary releases. One release could be in customer use,
while another is in test, and the third is still in development. If
problems are found in any one of the versions, fixes need to be
propagated between them. Confusion can arise leading to costly
fixes and re-work unless changes are carefully controlled and
monitored.
29

30. ENVIRONMENT
 The purpose of the environment workflow is to
provide the software development organization with
the software development environment—both
processes and tools—that are needed to support
the development team.
 It focuses on activities to develop the guidelines
needed to support a project.
 A step-by-step procedure is provided describing
how you implement a process in an organization.
 The environment workflow also contains a
Development Kit providing you with the guidelines,
templates and tools necessary to customize the
process. 30

31. AGILE METHODOLOGY
 An extension to the iterative approach to build
applications in a nimble fashion with a light weight
process.
 Agile methodology is an alternative to traditional
project management, typically used in software
development.
 It helps teams respond to unpredictability through
incremental, iterative work cadences, known as
sprints. Agile methodologies are an alternative to
waterfall, or traditional sequential development.
31

32. TWELVE PRINCIPLES BEHIND THE AGILE
MANIFESTO
 satisfy the customer through early and continuous
delivery of valuable software.
 Welcome changing requirements, even late in
development.
 Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference
to the shorter timescale.
 Business people and developers must work
together daily throughout the project.
 Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
32

33. TWELVE PRINCIPLES BEHIND THE AGILE
MANIFESTO
 The most efficient and effective method of conveying
information to and within a development team is face-to-
face conversation.
 Working software is the primary measure of progress.
 Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
 Continuous attention to technical excellence and good
design enhances agility.
 Simplicity is essential.
 The best architectures, requirements, and designs
emerge from self-organizing teams.
 At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly. 33

34. PLAN DRIVEN SOFTWARE DEVELOPMENT
VS AGILE SOFTWARE DEVELOPMENT
34

35. PLAN DRIVEN SOFTWARE DEVELOPMENT
VS AGILE SOFTWARE DEVELOPMENT(CONTD..)
 the team will deploy
one increment of
software at the end of
the project
 a process starts after
successful completion
of another (Sequential)
 the team will deploy a
very small change of
the software or more
frequently.
 we plan all the time
(Concurrent)
Plan driven development Agile driven development
35

36. WATERFALL VS AGILE
•Customer satisfaction by rapid, continuous delivery
of useful software.
•People and interactions are emphasized rather than
process and tools.
•Customers, developers and testers constantly
interact with each other.
36

37. WATERFALL VS AGILE (CONTD…)
 Working software is delivered frequently (weeks
rather than months).
 Face-to-face conversation is the best form of
communication.
 Close, daily cooperation between business people
and developers.
 Continuous attention to technical excellence and
good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed.
37

38. WATERFALL VS AGILE (CONTD…)
 The key is in Agile technique compressing the five
sequences of the conventional software
development method - called the Waterfall method -
to a one-week cycle. It manages to do this by
developing a system through repeated cycles
(iterative) and in smaller portions (incremental),
allowing developers to test and review during
development. Speed, lower cost, and flexibility are
key benefits.
38

39. AGILE
 The participants in an agile process
are not afraid of change.
 They view changes to the
requirements as good things,
because those changes mean that
the team has learned more about
what it will take to satisfy the
customer.
 Agile team members work together
on all aspects of the project. Each
member is allowed input into the
whole.
 No single team member is solely
responsible for the architecture or
the requirements or the tests. The
team shares those responsibilities,
and each team member has
influence over them.
39

40. AGILE PROCESSES
 There are many agile processes: SCRUM, Crystal,
Behavior-Driven Development (BDD), Test-Driven
Development (TDD), Feature-Driven Development
(FDD), Adaptive Software Development (ADP),
Extreme Programming (XP), and more... However,
the vast majority of successful agile teams have
drawn from all these processes to tune their own
particular flavor of agility. These adaptations appear
to come together with the combination of SCRUM
and XP, in which SCRUM practices are used to
manage multiple teams that use XP.
40

41. EXTREME PROGRAMMING (XP)
 Extreme Programming emphasizes teamwork.
Managers, customers, and developers. It improves a
software project in five essential ways: communication,
simplicity, feedback, respect, and courage.
 According to Wiki definition: "Extreme Programming
(XP) is a software development methodology which is
intended to improve software quality and
responsiveness to changing customer requirements. As
a type of agile software development, it advocates
frequent "releases" in short development cycles, which
is intended to improve productivity and introduce
checkpoints where new customer requirements can be
adopted." 41

42. EXTREME PROGRAMMING (XP) (CONTD…)
 Extreme Programming is a set of simple and
concrete practices that combine into an agile
development process.
 XP is a good general-purpose method for
developing software.
 Many project teams will be able to adopt it as it is.
 Many others will be able to adapt it by adding or
modifying practices.
42

43. EXTREME PROGRAMMING (XP) (CONTD…)
 XP is a set of practices that conforms to the values
and principles of Agile. XP is a discrete method,
whereas Agile is a classification.
 There are many Agile methods, XP is just one of
them.
43

44. SCRUM & XP
 None of the other Agile methods are as well
defined, or as broad in scope as XP. Scrum, for
example, is roughly equivalent to XP’s Planning
game practice, with elements of Whole Team.
 It is fair to say that Scrum is a subset of XP.
 Indeed, many Scrum teams augment their process
by adding in many of the XP practices such as
Acceptance Testing, Pair Programming, Continuous
Integration, and especially Test Driven
Development.
44

45. XP PRACTICES
45

46. SCRUM
 Scrum is an iterative and incremental agile software
development framework for managing software
projects and product or application development.
 Its focus is on "a flexible, holistic product
development strategy where a development team
works as a unit to reach a common goal" as
opposed to a "traditional, sequential approach”.
46

47. SCRUM (CONTD…)
 Scrum asks why does it take so long and so much
effort to do stuff.
 And why are we so bad at figuring out how long and
how much effort things will take.
 Scrum embraces uncertainty and creativity.
 It places a structure around the learning process,
enabling teams to assess both what they’ve
created, and just as importantly, how they created
it.
47

48. SCRUM PROCESS
48

49. SCRUM (CONTD…)
49

50. SCRUM ROLES
 There are these core roles for producing the
product:
 Product Owner
 Development Team
 ScrumMaster
 Stakeholders
 Managers
50

51. PRODUCT OWNER
51
•The Product Owner should be a person with vision, authority, and
availability.
•The Product Owner is responsible for continuously communicating the
vision and priorities to the development team.
•Product Owners must be available to answer questions from the team.

52. DEVELOPMENT TEAM
 Responsible for delivering potentially shippable
product increments at the end of each Sprint.
 Made up of 3–9 people with cross-functional skills
who do the actual work (analyze, design, develop,
test, technical communication, document, etc.).
 Self-organizing, even though they may interface
with project management organizations (PMOs).
52

53. SCRUMMASTER
 Accountable for removing impediments to the ability
of the team to deliver the sprint goal/deliverables.
 Is not the team leader, but acts as a buffer between
the team and any distracting influences.
 Ensures that the Scrum process is used as
intended.
 Enforcer of rules.
 Protector of the team and keep it focused on the
tasks at hand.
53

54. SCRUMMASTER
 Also been referred to as a servant-leader to
reinforce these dual perspectives.
 Differs from a Project Manager in that the latter may
have people management responsibilities unrelated
to the role of ScrumMaster.
 Excludes any such additional people
responsibilities.
54

55. BARRIERS TO FURTHER AGILE ADOPTION
55

56. AGILE SUCCESS FACTORS
56