GOALS OF DEFINING THE SOFTWARE

DEVELOPMENT PROCESS

Dr Chaya Ravindra
LIFE CYCLE MODELS

1
SOFTWARE LIFE Conceptualiz
CYCLE
e

Specify
Retire

Design
Maintain

Deliver Code

Test

2
 LIFE CYCLE MODEL
• A software life cycle model (also process model or SDLC):
–A descriptive and diagrammatic model of software life
cycle:
–Identifies all the activities undertaken during product
development,
–Establishes a precedence ordering among the different activities,
–Divides life cycle into phases.
4
 LIFE CYCLE MODEL (CONT.)

•Each life cycle phase consists of several

activities.
–For example, the design stage might consist of:
•structured analysis
•structured design
•Design review
5
 WHY MODEL LIFE CYCLE?

• A graphical and written description:

–Helps common understanding of activities among the software
developers.

–Helps to identify inconsistencies, redundancies, and omissions

in the development process.

–Helps in tailoring a process model for specific projects.

6
 LIFE CYCLE MODEL (CONT.)

•The development team must identify a suitable life cycle

model:
–and then adhere to it.
–Primary advantage of adhering to a life cycle model:
•Helps development of software in a systematic and
disciplined manner.

7
 LIFE CYCLE MODEL (CONT.)

• When a program is developed by a single programmer ---

– The problem is within the grasp of an individual.
– He has the freedom to decide his exact steps and still succeed ---
called
Exploratory model--- One can use it in many ways Fi
x
– CodeTest Design
Initia
Tes
– CodeDesign Test  Change Code  l
Codi t
Do
Until
ng Done
– Specify code Design Test  etc.

8
 LIFE CYCLE
MODEL (CONT.)

•When software is being developed by a team:

–There must be a precise understanding among team
members as to when to do what,

–Otherwise, it would lead to chaos and project

failure.

9
 LIFE CYCLE MODEL (CONT.)

• A software project will never succeed if:

–one engineer starts writing code,
–another concentrates on writing the test document first,
–yet another engineer first defines the file structure
–another defines the I/O for his portion first.

1
 Phase Entry and Exit Criteria
•A life cycle model:
–defines entry and exit criteria for every
phase.
–A phase is considered to be complete:
•only when all its exit criteria are satisfied.

11
 LIFE CYCLE MODEL (CONT.)

• What is the phase exit criteria for the software requirements

specification phase?
–Software Requirements Specification (SRS) document is
complete, reviewed, and approved by the customer.
•A phase can start:
–Only if its phase-entry criteria have been satisfied.

12
LIFE CYCLE MODEL: MILESTONES

•Milestones help software project managers:

–Track the progress of the project.
–Phase entry and exit are
important milestones.

13
 Life Cycle and Project Management
•When a life cycle model is followed:
–The project manager can at any time fairly
accurately tell,
•At which stage (e.g., design, code, test,
etc.) the project is.

14
 Project Management Without Life Cycle Model
• It becomes very difficult to track the progress of the project.
–The project manager would have to depend on the guesses
of the team members.
• This usually leads to a problem:
–known as the 99% complete syndrome.

15
 PROJECT DELIVERABLES:
MYTH AND REALITY
Myth:
The only deliverable for a successful project is the working
program.
Reality:
Documentation of all aspects of software development are
needed to help in operation and maintenance.

16
• Many life cycle models have been proposed.
• We confine our attention to only a few commonly used models.
–Waterfall
–V model, Life Cycle Model (CONT.)

–Evolutionary, Traditional models

–Prototyping
–Spiral model,
–Agile models

17
• Software life cycle (or software process):
–Series of identifiable stages that a software
product undergoes during its life time:
•Feasibility study
•Requirements analysis and specification,
•Design,
•Coding,
•Testing
Software Life Cycle
•Maintenance
.
18
 CLASSICAL WATERFALL
MODEL

– Requirements analysis and

Conceptualiz
specification, e
Specify
Retire

– Design, Design
Maintain
– Coding and unit testing,
Code
– Integration and system testing, Deliver

Test
– Maintenance.
1
9
CLASSICAL WATERFALL
Feasibility Study
MODEL
Req.
Analysis
Desi Simplest and most
gn intuitive
Coding

Testing

Maintena
nce
2
0
 RELATIVE EFFORT FOR
PHASES
• Phases between feasibility study and 60
50
testing
40
– Called development phases. 30

Relative
• Among all life cycle phases 20

Effort
10
– Maintenance phase
consumes maximum 0

Maintnce
Design

Coding
Test
Req. Sp
effort.
• Among development
phases,
– Testing phase consumes
• Most organizations usually define:
– Standards on the outputs (deliverables) produced at the end of every phase
– Entry and exit criteria for every phase.

• They also prescribe methodologies for:

– Specification,
Process Model
– Design,
– Testing,
– Project management, etc.
 CLASSICAL WATERFALL
MODEL (CONT.)
• The guidelines and methodologies of an organization:
–Called the organization's software development methodology.
• Software development organizations:
– Expect fresh engineers to master the
organization's software development methodology.

23
FEASIBILITY STUDYEconomic
feasibility
(also
called
cost/benef
it
feasibility)

Technic Feasibili Schedul

al ty e
feasibili Dimensio feasibili
ty ns ty

24
• Main aim of feasibility study: determine whether developing the
software is:
– Financially worthwhile
Feasibility Study
– Technically feasible.
• Roughly understand what customer wants: First Step
– Data which would be input to the system,
– Processing needed on these data,
– Output data to be produced by the system,
– Various constraints on the behavior of the system.

25
• SPF Scheme for CFL
• CFL has a large number of employees, exceeding 50,000.
• Majority of these are casual labourers
• Mining being a risky profession:
– Casualties are high Case Study
• Though there is a PF:
– But settlement time is high
• There is a need of SPF:
– For faster disbursement of benefits

26
FEASIBILITY: CASE
STUDY
• Manager visits main office, finds out the
main functionalities required
• Visits mine site, finds out the data to be input
• Suggests alternate solutions
• Determines the best solution
• Presents to the CFL Officials
• Go/No-Go Decision
26
 ACTIVITIES DURING
FEASIBILITY STUDY
•Work out an overall understanding of the problem.
•Formulate different solution strategies.
•Examine alternate solution strategies in terms of:
•resources required,
•cost of development, and
•development time.
28
•Perform a cost/benefit analysis:
–Determine which solution is the best.
–May also find that none of the solutions is
feasible due to: Activities during Feasibility Study
•high cost,
•resource constraints,
•technical reasons.

29
 COST BENEFIT ANALYSIS (CBA)

• Need to identify all costs --- these could be:

– Development costs
– Set-up
– Operational costs
• Identify the value of benefits

• Check benefits are greater than costs

30
THE BUSINESS
CASE • Benefits of delivered project
must outweigh costs
Benefit
s • Costs include:
Cost - Development
s - Operation
Rs • Benefits:
Rs
– Quantifiable
– Non-quantifiable

31
 THE BUSINESS CASE
• Feasibility studies should help write a ‘business case’
• Should provide a justification for starting the project
• Should show that the benefits of the project will
exceed:
– Various costs

• Needs to take account of business risks

3
2
 WRITING AN EFFECTIVE
1. Executive summary
2. Project background:
BUSINESS CASE
 The focus must be on what, exactly, the project is undertaking, and should not be confused with what might be a bigger picture.

3. Business opportunity
- What difference will it make?
- What if we don’t do it?

4. Costs
- Should include the cost of development, implementation, training, change management, and operations.

5. Benefits
 Benefits usually presented in terms of revenue generation and cost reductions.

6. Risks
- Identify risks.
- Explain how these will be managed.

3
3
 CLASSICAL WATERFALL
Feasibility
Study MODEL
Req.
Analysis
Design

Codi
ng
Testing

Maintena
nce

34
TEST DRIVEN DEVELOPMENT (TDD)

1.Test-Driven Development (TDD) is a software development

practice that complements Agile methodologies by
improving code quality and fostering collaboration.

2. In Agile, the emphasis is on iterative development, where

features are delivered incrementally, and changes are
frequent.

3.TDD fits well into this framework by ensuring that the

codebase remains stable, reliable, and adaptable to change
KEY ASPECTS OF TDD IN AGILE

1.TDD Process:
TDD involves writing tests before writing the actual code. The typical
cycle follows:
• Write a failing test: Create a test for the next piece of functionality
you want to implement. The test should initially fail since the code
hasn’t been written yet.
• Write the minimum code to pass the test: Implement just enough
functionality to pass the failing test.
• Refactor: Improve the code, optimizing it for readability,
maintainability, and performance, while ensuring that all tests still
pass.
• Repeat: The cycle continues for each small piece of functionality,
allowing incremental progress.
2.TEST-FIRST APPROACH:

1.In Agile, requirements may evolve, and testing often

needs to be adapted.
2.The test-first approach ensures that developers always
have clear goals, as tests are written to match user
stories or acceptance criteria.
3. It also helps catch issues early in the development
cycle, reducing the time and cost of fixing bugs later on.
3.CONTINUOUS INTEGRATION:

1.TDD and Agile both align with continuous integration (CI)

practices, where developers frequently integrate code
into a shared repository.
2. Automated tests (written as part of TDD) run in the CI
pipeline, providing immediate feedback on code
changes.
3.This ensures that new code doesn’t break existing
functionality, which is vital in Agile's fast-paced, iterative
development environment
4.Improved Code Quality: Writing tests first leads to simpler, more modular code. The
code is usually more robust since developers consider edge cases upfront. TDD also
results in better test coverage, as each piece of functionality is tested early and
often.

5.Collaboration and Feedback: TDD encourages better collaboration between

developers, testers, and stakeholders. In Agile, close communication with the
product owner is essential to refine user stories. With TDD, the process also fosters
a more frequent feedback loop, allowing stakeholders to see working software early
and ensure that the product meets expectations
6.Documentation by Tests: In TDD, tests serve as a form of documentation. As Agile focuses
on delivering working software rather than extensive documentation, the tests provide a
living specification of what the system is supposed to do. New team members can
understand the codebase more easily by looking at the test cases.

7.Adapting to Change: Agile methodologies expect changing requirements. TDD provides a

safety net for refactoring and adapting code to new business needs. Because tests are
already in place, developers can refactor confidently, knowing they’ll be alerted if
something breaks.
BENEFITS OF TDD IN AGILE:

1. Higher code quality and fewer bugs.

2. Rapid feedback loops on code changes.
3. Faster delivery of features, with confidence that code
is working as expected.
4. Reduced debugging time, since issues are caught
early.
5. Easier maintenance, thanks to modular code and
automated tests.
TEST DRIVEN DEVELOPMENT (TDD)
EXAMPLES

1. Calculator Function: When building a calculator function, a TDD approach

would involve writing a test case for the “add” function and then writing the
code for the process to pass that test. Once the “add” function is working
correctly, additional test cases would be written for other functions such as
“subtract”, “multiply” and “divide”.
2. User Authentication: When building a user authentication system, a TDD
approach would involve writing a test case for the user login functionality
and then writing the code for the login process to pass that test. Once the
login functionality works correctly, additional test cases will be written for
registration, password reset, and account verification.
3. E-commerce Website: When building an e-commerce website, a TDD
approach would involve writing test cases for various features such as
product listings, shopping cart functionality, and checkout process. Tests
would be written to ensure the system works correctly at each process
stage, from adding items to the cart to completing the purchase
TDD VS. TRADITIONAL TESTING

1. Approach: TDD is an agile development methodology where tests are written

before the code is developed. In contrast, traditional testing is performed
after the code is written.
2. Testing Scope: TDD focuses on testing small code units at a time, while
traditional testing covers testing the system as a whole, including integration,
functional, and acceptance testing.
3. Iterative: TDD follows an iterative process, where small chunks of code are
developed, tested, and refined until they pass all tests. The code is usually
tested once and then refined based on the results in traditional testing.
4. Debugging: TDD aims to catch errors as early as possible in the development
process, making debugging and fixing them easier. Traditional testing, on the
other hand, may require more effort to debug errors that are discovered later
in the development process.
5. Documentation: TDD documentation typically focuses on the test cases and
their results, while traditional testing documentation may include more
detailed information about the testing process, the test environment, and the
system under test
THREE PHASES OF TEST DRIVEN
DEVELOPMENT

1. Create precise tests: Developers need to create exact unit tests

to verify the functionality of specific features. They must ensure
that the test compiles so that it can execute. In most cases, the
test is bound to fail. This is a meaningful failure as developers
create compact tests based on their assumptions of how the
feature will behave.
2. Correcting the Code: Once a test fails, developers must make
the minimal changes required to update the code to run
successfully when re-executed.
3. Refactor the Code: Once the test runs successfully, check for
redundancy or any possible code optimizations to enhance overall
performance. Ensure that refactoring does not affect the external
behavior of the program.
CI/CD

1. Company face challenges in keeping up with rapidly evolving

competition, security needs, and scalability, while also striving to
balance operational stability with fast-paced software
development.
2. To address these challenges, companies are adopting practices
like Continuous Integration and Continuous Delivery
(CI/CD), which allow for fast and secure software updates without
sacrificing system stability
1. Continuous integration (CI) is a software development practice where
developers regularly merge their code changes into a central repository, after
which automated builds and tests are run.
2. CI most often refers to the build or integration stage of the software release
process and requires both an automation component (for example a CI or build
service) and a cultural component (for example learning to integrate
frequently).
3. The key goals of CI are to find and address bugs more quickly, improve
software quality, and reduce the time it takes to validate and release new
software updates.
CONTINUOUS DELIVERY (CD)

1. Continuous delivery (CD) is a software development practice

where code changes are automatically built, tested, and prepared
for production release.
2. It expands on continuous integration by deploying all code
changes to a testing environment, a production environment, or
both after the build stage has been completed.
3. Continuous delivery can be fully automated with a workflow
process or partially automated with manual steps at critical points.
4. When continuous delivery is properly implemented, developers
always have a deployment-ready build artifact that has passed
through a standardized test process.
TESTING STAGES IN CONTINUOUS
INTEGRATION AND CONTINUOUS
DELIVERY
1. Unit tests are on the bottom of the pyramid. They are both the
fastest to run and the least expensive. Therefore, unit tests should
make up the bulk of your testing strategy. A good rule of thumb is
about 70 percent. Unit tests should have near-complete code
coverage because bugs caught in this phase can be fixed quickly
and cheaply.
2. Service, component, and integration tests are above unit tests on
the pyramid. These tests require detailed environments and
therefore, are more costly in infrastructure requirements and
slower to run.
3. Performance and compliance tests are the next level-They require
production-quality environments and are more expensive yet.
4. UI and user acceptance tests are at the top of the pyramid and
require production-quality environments as well
 BUILDING

1. Unit Testing – Tests a specific section of code to ensure the code does what it is
expected to do. The unit testing is performed by software developers during the
development phase. At this stage, a static code analysis, data flow analysis, code
coverage, and other software verification processes can be applied.
2. Static Code Analysis – This test is performed without actually running the
application after the build and unit testing. This analysis can help to find coding
errors and security holes, and it also can ensure conformance to coding
guidelines.
3. Static Application Security Testing (SAST) – This test is used to analyze
code against security violations such as XML External Entity Processing ,
SQL Injection and Cross Site Scripting. As soon as violations are detected, the
build will fail and any progress will be blocked in the pipeline. For further details,
see Security in every stage of CI/CD pipeline.
BUILDING

4.Secrets Detection – This check is used to identify secrets such as usernames,

passwords, and access keys in code. As soon as secrets are discovered, the build
will fail immediately. For further details, see
Security in every stage of CI/CD pipeline.
5.Software Composition Analysis (SCA) – SCA tools enable users to manage
and analyze the open-source components in their applications. They also verify
licensing and assess security vulnerabilities. SCA tools can launch workflows to fix
these vulnerabilities. Any findings that exceed the configured threshold will
immediately fail the build and stop any forward progress in the pipeline. These
tools also require a software bill of materials (SBOM) existence. For further details,
see Security in every stage of CI/CD pipeline.
6.Software Bill of Materials (SBOM) – SBOM is a reporting mechanism to detail
all the components and dependencies involved in the development and delivery of
an application. This will allow visibility of product components, assure file integrity,
leverage licensing governance, and robust vulnerability scanning. For further
details, see Security in every stage of CI/CD pipeline.
 STAGING

In the staging phase, full environments are created that mirror the eventual
production environment. The following tests are performed
1. Integration testing – Verifies the interfaces between components against
software design. Integration testing is an iterative process and facilitates
building robust interfaces and system integrity.
2. Component testing – Tests message passing between various components and
their outcomes. A key goal of this testing could be idempotency in component
testing. Tests can include extremely large data volumes, or edge situations and
abnormal inputs.
3. System testing – Tests the system end-to-end and verifies if the software
satisfies the business requirement. This might include testing the user interface
(UI), API, backend logic, and end state.
4.Performance testing – Determines the responsiveness and stability of a system as it
performs under a particular workload. Performance testing also is used to investigate,
measure, validate, or verify other quality attributes of the system, such as scalability,
reliability, and resource usage. Types of performance tests might include load tests, stress
tests, and spike tests. Performance tests are used for benchmarking against predefined
criteria.
5.Compliance testing – Checks whether the code change complies with the requirements of a
nonfunctional specification and/or regulations. It determines if you are implementing and
meeting the defined standards.
6.User acceptance testing – Validates the end-to-end business flow. This testing is performed
by an end user in a staging environment and confirms whether the system meets the
requirements of the requirement specification. Typically, customers employ alpha and beta
testing methodologies at this stage.
7.Dynamic Application Security Testing (DAST) - This type of testing is used to check for
security problems in an application while it is running. DAST tools evaluate the application by
attacking like a malicious user would from outside. For further details, see
Security in every stage of CI/CD pipeline
 Requirements Analysis and Specification
•Aim of this phase:
–Understand the exact requirements of the customer,
–Document them properly.
•Consists of two distinct activities:
–Requirements gathering and analysis
–Requirements specification.

56
 REQUIREMENTS ANALYSIS
AND SPECIFICATION
• Gather requirements data from the customer:
Analyze the collected data to understand what customer wants
•Remove requirements problems:
Inconsistencies
Anomalies
Incompleteness
• Organize into a Software Requirements Specification (SRS)
document.
35
 REQUIREMENTS
GATHERING
•Gathering relevant data:
–Usually collected from the end-users through interviews and
discussions.
–Example: for a business accounting software:
•Interview all the accountants of the organization to find out their
requirements.

58
 REQUIREMENTS ANALYSIS (CONT...)

•The data you initially collect from the users:

–Usually contain several contradictions and ambiguities.

–Why?

–Each user typically has only a partial and incomplete view

of the system.

59
 REQUIREMENTS
ANALYSIS (CONT...)
•Ambiguities and contradictions:
–must be identified

–resolved by discussions with the customers.

•Next, requirements are organized:

–into a Software Requirements Specification (SRS) document.

60
REQUIREMENT GATHERING
TECHNIQUES
 CLASSICAL
Feasibility
WATERFALL
Study MODEL
Req.
Analysis
Desi
Design
gn
Codi
ng
Testing

Maintenan
ce

64
 DESIGN
• During design phase requirements specification
is transformed into :
– A form suitable for implementation in some
programming language.
• Two commonly used design approaches:
–Traditional approach,
–Object oriented approach
6
5
 TRADITIONAL DESIGN APPROACH

•Consists of two activities:

–Structured analysis (typically carried out by

using DFD)

–Structured design

6
6
 STRUCTURED DESIGN
root

• High-level design: orde quer

y
r
inde
–decompose the system into modules, Handle-
nt
Handle- Handle-
order indent query
–represent invocation relationships among
the modules.
Accept Process-
• Detailed design: - Get-order
order order

–different modules designed in greater detail:

•data structures and algorithms for each module are designed.
6
7
• First identify various objects (real world entities) occurring in
the problem:
– Identify the relationships among the objects.
– For example, the objects in a pay-roll software may be:
• employees,

• managers, Object-Oriented Design

• pay-roll register,

• Departments, etc.

6
8
 OBJECT ORIENTED
DESIGN (CONT.) • Object structure:
– Refined to obtain the detailed design.

• OOD has several advantages:

– Lower development effort,

– Lower development time,

– Better maintainability.

6
9
 FUNCTIONAL REQUIREMENTS

1. These are the requirements that the end user specifically demands as basic facilities that
the system should offer. All these functionalities need to be necessarily incorporated into
the system as a part of the contract.
2. These are represented or stated in the form of input to be given to the system, the
operation performed and the output expected. They are the requirements stated by the
user which one can see directly in the final product, unlike the non-functional
requirements.
3. Example:
• What are the features that we need to design for this system?
• What are the edge cases we need to consider, if any, in our design?
 NON-FUNCTIONAL REQUIREMENTS
These are the quality constraints that the system must satisfy according to the project contract.
The priority or extent to which these factors are implemented varies from one project to another.
They are also called non-behavioral requirements. They deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Example:
• Each request should be processed with the minimum latency?
• System should be highly valuable.
Feasibility
Study

REQ. ANALYSIS
Classical Waterfall
Design Model
Codi
ng
Testing

Maintena
nce

73
CODING AND UNIT
TESTING •During this phase:
–Each module of the design is coded,
–Each module is unit tested
•That is, tested independently as a stand alone unit, and
debugged.

–Each module is documented.

74
Feasibility
Study

Req.
Analysis CLASSICAL WATERF
Design
MODEL
Codi
ng
Testin
Testing
g
Maintenan
ce

75
 INTEGRATION AND
SYSTEM TESTING
• Different modules are integrated in a planned
manner:
–Modules are usually integrated through a
steps. of
number
M1 M2 M5 M7
• During each integration step,
M3 M4 M6
–the partially integrated system is tested.
M8

76
 SYSTEM TESTING
• After all the modules have been successfully integrated and
tested:

–System testing is carried out.

• Goal of system testing:

– Ensure that the developed system functions according to its requirements

as specified in the SRS document.

77
Feasibility
Study

REQ. ANALYSIS
Design Classical Waterfall
Model
Codi
ng
Testing

Maintenan
Maintena
ce
nce

78
 MAINTENANCE
•Maintenance of any software:
–Requires much more effort than the effort to develop
the product itself.
–Development effort to maintenance effort is typically
40:60.

79
TYPES OF
MAINTENANCE?
• Corrective maintenance:
– Correct errors which were not discovered during the product
development phases.
• Perfective maintenance:
– Improve implementation of the system
– enhance functionalities of the system.
• Adaptive maintenance:
– Port software to a new environment,
• e.g. to a new computer or to a new operating system.
80
 ITERATIVE WATERFALL
MODEL
•Classical waterfall model is idealistic:
–Assumes that no defect is introduced during any
development activity.
–In practice:
•Defects do get introduced in almost every phase of
the life cycle.

81
 ITERATIVE WATERFALL MODEL (CONT.)

•Defects usually get detected much later in the life cycle:

–For example, a design defect might go unnoticed till the

coding or testing phase.

–The later the phase in which the defect gets detected, the
more expensive is its removal --- why?

82
 ITERATIVE WATERFALL
MODEL (CONT.)

• Once a defect is detected:

–The phase in which it occurred needs to be reworked.

– Redo some of the work done during that and all subsequent
phases.

• Therefore need feedback paths in the classical waterfall

model.
83
Feasibility ITERATIVE WATERFALL
Study
Req.
MODEL (CONT.)

Analysis
Design

Coding

Testing

Maintenance

56
 PHASE CONTAINMENT OF
ERRORS (CONT...)
• Errors should be detected:
 In the same phase in which they are introduced.

• For example:
 If a design problem is detected in the design phase itself,
 The problem can be taken care of much more easily
 Than say if it is identified at the end of the integration and system testing
phase.

85
 PHASE CONTAINMENT
OF ERRORS
• Reason: rework must be carried out not only to the design but also
to code and test phases.
• The principle of detecting errors as close to its point of introduction
as possible:
– is known as phase containment of errors.
• Iterative waterfall model is by far the most widely used model.
– Almost every other model is derived from the waterfall model.

86
Feasibility
ITERATIVE WATERFALL
Study MODEL (CONT.)

Req.
Analysis
Design

Coding

Testing

Maintenance

59
 WATERFALL STRENGTHS

• Easy to understand, easy to use, especially by

inexperienced staff
• Milestones are well understood by the team
• Provides requirements stability during
development
• Facilitates strong management control (plan,
staff, track)
88
 WATERFALL
DEFICIENCIES
• All requirements must be known upfront – in most
projects requirement change occurs after project start
• Can give a false impression of progress
• Integration is one big bang at the end
• Little opportunity for customer to pre-view the system.

89
 WHEN TO USE THE
WATERFALL MODEL?
• Requirements are well known and stable

• Technology is understood
• Development team have experience with similar
projects

62
 CLASSICAL WATERFALL
MODEL (CONT.)

•Irrespective of the life cycle model actually followed:

–The documents should reflect a classical waterfall model
of development.

–Facilitates comprehension of the documents.

91
 CLASSICAL WATERFALL
MODEL (CONT.)

•Metaphor of mathematical theorem proving:

–A mathematician presents a proof as a single chain of
deductions,
•Even though the proof might have come from a
convoluted set of partial attempts, blind alleys and backtracks.

92
V MODEL

7/18/202
0 93
 V MODEL
• It is a variant of the Waterfall
– emphasizes verification and validation
– V&V activities are spread over the entire life cycle.

• In every phase of development:

– Testing activities are planned in
parallel with development.

94
 Production,
PROJECT PLANNING Operation &
Maintenance

Requirements System Testing

Specification

High Level Design Integration Testing

Detailed Design Unit testing

Coding

95
 V MODEL STEPS

• Planning

• Requirements Analysis • System test design

and Specification
• High-level Design
• Integration Test dsign

• Detailed Design • Unit test design

96
 V MODEL: STRENGTHS
• Starting from early stages of software development:

– Emphasizes planning for verification and

validation of the software

• Each deliverable is made testable

• Easy to use

97
 V MODEL
WEAKNESSES
• Does not support overlapping of phases
Production,
Project Operation &
Planning Maintenance

• Does not handle iterations or phases Requirements

Specification
System Testing

• Does not easily accommodate

Integration
High Level Design Testing

later changes to requirements

Detailed Design Unit testing

Coding

• Does not provide support for effective risk handling

98
 WHEN TO USE V MODEL
• Natural choice for systems requiring high reliability:

– Embedded control applications, safety-critical software

• All requirements are known up-front

• Solution and technology are known

99
 PROTOTYPING MODEL

7/18/202
0 10
 PROTOTYPING MODEL
• A derivative of waterfall model. Prototype
Construction
Desig

• Before starting actual n

Codi

development,
ng
– A working prototype of the system should first be built. Testin
g

• A prototype is a toy implementation of a system:

Maintenan
ce

–Limited functional capabilities,

–Low reliability,
–Inefficient performance.

10
 REASONS FOR
PROTOTYPING
• Learning by doing: useful where requirements are
Prototype
only partially known Construction

Desig
• Improved communication n
Codi
ng
• Improved user involvement Testin
g
• Reduced need for documentation Maintenan
ce

• Reduced maintenance costs

10
 REASONS FOR
DEVELOPING
• Illustrate A
to the customer:
PROTOTYPE
–input data formats, messages, reports, or interactive
dialogs.
• Examine technical issues associated with product
development:
–Often major design decisions depend on
issues like:
•Response time of a hardware controller,
•Efficiency of a sorting algorithm, etc.
10
 PROTOTYPING MODEL (CONT.)

•Another reason for developing a prototype:

–It is impossible to “get it right” the first time,
–We must plan to throw away the first
version:
•If we want to develop a good software.
10
 Prototype
PROTOTYPING MODEL Construction

• Start with approximate requirements. Design

• Carry out a quick design. Coding

Testing
• Prototype is built using several short-
cuts: Maintenan
ce

–Short-cuts might inaccurate,

•Using inefficient, involve: or dummy functions.
•A table look-up rather than performing the actual
computations.
10
PROTOTYPING
Build MODEL
(CONT.) Prototype

Requireme Customer Custom

Evaluation Desig
nts Quick of er
Gathering Design Prototype n
satisfie
d
Refine
Requireme Impleme
nts nt

Test

Mainta
in

10
 PROTOTYPING MODEL (CONT.)
• The developed prototype is submitted to the customer for Build
Prototype

his evaluation: Requireme

nts
Gathering
Quick
Design
Customer
Evaluation
of
Prototype
Custom
er Desig
n
satisfie
d
Refin
Impleme

–Based on the user feedback, the prototype is refined.

R
e equireme
nts nt

Tes
t

–This cycle continues until the user approves the Mainta

in

prototype.
• The actual system is developed using the waterfall
model.
10
 (CONT.
PROTOTYPING MODEL Prototype
)Construction

• Requirements analysis and specification Desig

n

phase becomes redundant: Codin

g

Testin

–Final working prototype (incorporating all user

g

Maintenan
ce
feedbacks) serves as an animated requirements specification.
• Design and code for the prototype is usually thrown away:
–However, experience gathered from developing the prototype helps
a great deal while developing the actual software.

10
 PROTOTYPING MODEL
(CONT.)
• Even though construction of a working prototype model involves
additional cost --- overall development cost usually lower for:
– Systems with unclear user requirements,
– Systems with unresolved technical issues.
• Many user requirements get properly defined and technical
issues get resolved:
– These would have appeared later as change requests and resulted in
incurring massive redesign costs.

10
 PROTOTYPING:
ADVANTAGES
• The resulting software is usually more usable
• User needs are better accommodated
• The design is of higher quality
• The resulting software is easier to maintain
• Overall, the development incurs less cost

11
 PROTOTYPING: DISADVANTAGES

• For some projects, it is expensive

• Susceptible to over-engineering:

– Designers start to incorporate sophistications that they

could not incorporate in the prototype.

11
 Major difficulties of Waterfall-Based Models
1. DIFFICULTY IN ACCOMMODATING
CHANGE REQUESTS DURING
DEVELOPMENT.
 40% of the requirements change during development

2. High cost incurred in developing custom applications.

3. “Heavy weight processes.”

11
 Major difficulties of Waterfall-Based Life Cycle Models

• Requirements for the system are determined at the

start:
– Are assumed to be fixed from that point on.

– Long term planning is made based on this.

11
INCREMENTAL MODEL

7/18/2020
87
• “The basic idea… take advantage of what was being
learned during the development of earlier, incremental,
deliverable versions of the system. Learning comes
from both the development and use of the system…
Start with a simple implementation of a subset of the
software requirements and iteratively enhance the
evolving sequence of versions. At each version design
modifications are made along with adding new
functional capabilities. “ Victor Basili

88
• Key characteristics Incremental and Iterative
–Builds system incrementally Development (IID)
–Consists of a planned number of iterations
–Each iteration produces a working program
• Benefits
–Facilitates and manages changes
• Foundation of agile techniques and the basis for
–Rational Unified Process (RUP)
–Extreme Programming (XP)

11
CUSTOMER’S
PERSPECTIVE
C

A A A
B
B
B

11
INCREMENTAL MODEL

Requireme Split
ntsOutlin Featur Desig
into n
e es

Devel Validat Integrat Validat

Increme
op Increme
e Increme
e eSyste Fin
nt nt nt m Syste
al
m

11
INCREMENTAL MODEL: Split
REQUIREMENTS Featur
into
es
Requirements: High Level
Analysis
Slic

Slic

Slic

Slic

Slic

Slic

Slic

Slic
e

e
11
 INCREMENTAL MODEL
• Waterfall: single release
• Iterative: many releases (increments)
–First increment: core functionality
–Successive increments: add/fix
functionality
–Final increment: the complete
product
• Each iteration: a short mini-project
with a separate lifecycle
12
INCREMENTAL DELIVERY

incremen Custome
design build install r
t Feedback
1

design Customer
incremen build install

t Feedback

incremen Customer
design build install
t
3 Feedback

12
 THE INCREMENTAL
PROCESS
Identify System Objectives
Plann
incremen
ed Plan increments
delive
tal Incremental delivery plan
ry

Design increment

Build the increment

Repeat for Feedba
each Implement the increment ck
increment
Evaluate the results

12
 WHICH STEP FIRST?
• Some steps will be pre-requisite because of physical dependencies
• Others may be in any order
• Value to cost ratios may be used
– V/C where

– V is a score 1-10 representing value to customer

– C is a score 0-10 representing cost to developers

12
 V/C RATIOS: AN EXAMPLE
step value cost r atio

p r o fi t r e p o r t s 9 2 4.5 2nd

online d a t a b a s e 1 9 0.11 5th

ad hoc enquiry 5 5 1 4th

purchasing plans 9 4 2.25 3rd

profit-based pay for 9 1 9 1st

managers

12
EVOLUTIONARY MODEL WITH
ITERATIONS

12
 AN EVOLUTIONARY AND
ITERATIVE DEVELOPMENT
PROCESS...
• Recognizes the reality of changing requirements
–Capers Jones’s research on 8000 projects: 40% of final
requirements arrived after development had already begun
• Promotes early risk mitigation:
– Breaks down the system into mini-projects and focuses on the riskier
issues first.
– “plan a little, design a little, and code a little”
• Encourages all development participants to be involved earlier
on,:
12
EVOLUTIONARY MODEL
WITH ITERATION
• “A complex system will be most successful if implemented in
small steps… “retreat” to a previous successful step on
failure… opportunity to receive some feedback from the real
world before throwing in all resources… and you can correct
possible errors…” Tom Glib in Software Metrics

1
2
7
 EVOLUTIONARY MODEL
WITH ITERATION
• Evolutionary iterative development implies that the
requirements, plan, estimates, and solution evolve or are refined
over the course of the iterations, rather than fully defined and
“frozen” in a major up-front specification effort before the
development iterations begin. Evolutionary methods are
consistent with the pattern of unpredictable discovery and
change in new product development.” Craig Larman

1
2
8
 EVOLUTIONARY MODEL

•First develop the core modules of the software.

•The initial skeletal software is refined into increasing

levels of capability: (Iterations)
–By adding new functionalities in successive versions.

1
2
9
 ACTIVITIES IN AN
ITERATION
•Software developed over several “mini waterfalls”.
•The result of a single iteration:
–Ends with delivery of some tangible code
–An incremental improvement to the software ---
leads to evolutionary development

1
3
0
 EVOLUTIONARY MODEL
WITH ITERATION
• Outcome of each iteration: tested, integrated, executable system
• Iteration length is short and fixed
– Usually between 2 and 6 weeks

– Development takes many iterations (for example: 10-15)

• Does not “freeze” requirements and then conservatively

design :
– Opportunity exists to modify requirements as well as the design…
1
3
1
 EVOLUTIONARY MODEL
(CONT.)

•Successive versions:
–Functioning systems capable of performing some useful
work.
–A new release may include new functionality:
•Also existing functionality in the current release
might have been enhanced.
1
3
2
EVOLUTIONARY MODEL with user feedback:
• Evolves an initial implementation
– Multiple versions until the final version.

Initial
version
Specificati
Initial Intermedia
Rough te versio
Requireme on ns
nts
Final
Developme
versi
on
1
nt 3
3
 ADVANTAGES OF
EVOLUTIONARY MODEL
• Users get a chance to experiment with a partially developed system:
– Much before the full working version is released,

• Helps finding exact user requirements:

– Software more likely to meet exact user requirements.

• Core modules get tested thoroughly:

– Reduces chances of errors in final delivered software.

1
3
4
 ADVANTAGES OF
EVOLUTIONARY MODEL
• Better management of complexity by developing one increment at a
time.

• Better management of changing requirements.

• Can get customer feedback and incorporate them much more

efficiently:
– As compared when customer feedbacks come only after the
development
work is complete. 1
3
5
 ADVANTAGES OF
EVOLUTIONARY MODEL WITH
ITERATION
•Training can start on an earlier release

–customer feedback taken into account

•Frequent releases allow developers to fix
unanticipated problems quicker.

1
3
6
 EVOLUTIONARY MODEL:
PROBLEMS
• The process is intangible:
– No regular, well-defined deliverables.
• The process is unpredictable:
– Hard to manage, e.g., scheduling, workforce allocation, etc.
• Systems are rather poorly structured:
– Continual, unpredictable changes tend to degrade the software structure.
• Systems may not even converge to a final version.

1
3
7
RAD MODEL

1
7/18/2020 3
8
 RAPID APPLICATION
DEVELOPMENT (RAD)

• Sometimes
MODEL referred to as the rapid prototyping
model.
• Major aims:
– Decrease the time taken and the cost incurred to develop
software systems.
– Facilitate accommodating change requests as early
as possible:
1
• Before large investments have been made in development and 3
9
 IMPORTANT
UNDERLYING PRINCIPLE
• A way to reduce development time and cost, and yet
have flexibility to incorporate changes:

• Make only short term plans and make heavy reuse of

existing code.

1
4
0
 METHODOLOGY
•Plans are made for one increment at a time.
• The time planned for each iteration is called a time box.
•Each iteration (increment):
• Enhances the implemented functionality of the application
a little.

1
4
1
 METHODOLOGY

• During each iteration,

• A quick-and-dirty prototype-style software for some
selected functionality is developed.
• The customer evaluates the prototype and gives his
feedback.
• The prototype is refined based on the customer
feedback.
1
4
2
 HOW DOES RAD
FACILITATE FASTER
• RAD achieves fast creation of working prototypes.
DEVELOPMENT?
– Through use of specialized tools.
• These specialized tools usually support the following
features:
– Visual style of development.
– Use of reusable components.
– Use of standard APIs (Application Program Interfaces).
1
4
3
 FOR WHICH
APPLICATIONS IS RAD
SUITABLE?product developed for one or two
•Customized
customers only

•Performance and reliability are not critical.

•The system can be split into several independent

modules.
1
4
4
 FOR WHICH
APPLICATIONS RAD IS
UNSUITABLE?
• Few plug-in components are available

• High performance or reliability required

• No precedence for similar products exists

• The system cannot be modularized.

1
4
5
•In prototyping model: Prototyping versus
RAD
• The developed prototype is primarily used to gain
insights into the solution
• Choose between alternatives
• Elicit customer feedback.
•The developed prototype:
1

• Usually thrown away.

4
6
 PROTOTYPING VERSUS RAD

• In contrast:
• In RAD the developed prototype evolves into
deliverable software.

• RAD leads to faster development compared to traditional

models:
• However, the quality and reliability would possibly be
poorer.
1
4
7
 RAD VERSUS ITERATIVE
• InWATERFALL
the iterative waterfall
MODEL model,
– All product functionalities are developed together.
• In the RAD model on the other hand,
– Product functionalities are developed incrementally through heavy code
and design reuse.
– Customer feedback is obtained on the developed prototype after each
iteration:
• Based on this the prototype is refined.

1
4
8
 RAD versus Iterative Waterfall Model
• The iterative waterfall model:
– Does not facilitate accommodating requirement change requests.
• Iterative waterfall model does have some important
advantages:
– Use of the iterative waterfall model leads to production of good
documentation.
– Also, the developed software usually has better quality and
reliability than that developed using RAD.
1
4
9
 RAD
• Incremental VERSUS
development:
– EVOLUTIONARY MODEL
Occurs in both evolutionary and RAD models.
• However, in RAD:
– Each increment is a quick and dirty
prototype,
– Whereas in the evolutionary model each increment is
systematically developed using the iterative waterfall model.
• Also, RAD develops software in shorter increments:
– The incremental functionalities are fairly large in the
evolutionary
model. 1
5
0
 UNIFIED
PROCESS

1
7/18/2020 5
1
 UNIFIED PROCESS
• Developed Ivar Jacobson, Grady Booch and
James Rumbaugh
– Incremental and iterative

• Rational Unified Process (RUP) is version tailored by

Rational Software:
– Acquired by IBM in February 2003.

1
5
2
FOUR PHASES --- AND
ITERATIVE DEVELOPMENT AT
EVERY PHASE
•Inception Phase

•Elaboration Phase

•Construction Phase

•Transition Phase

1
5
3
UNIFIED PROCESS
ITERATIONS IN PHASES
The duration of and iteration may vary from two weeks or
less.
Iteration Iteration Iteration Iteration
s s s s

Inceptio Elaboratio Constructio Transitio

n n n n

1
5
4
UNIFIED PROCESS
software
incremen
Communicati
t
on incepti
on

Deployme Planni
nt ng

transiti elaborati
on on

Constructi Modeli
on ng

constructi
on
1
5
5
UNIFIED PROCESS
WORK PRODUCTS
Inception Elaboration Construction Transition
phase phase phase phase SW
vision document use-case
initial use-case model design model increment
initial
model business analysis model SW beta test
requirements
case initial risk preliminary components reports user
list project plan model revised test plan feedback
prototype(s) risk list test ...
... preliminary procedure
manual test cases
... user manual
installation
manual
...

1
5
6
 STRUCTURE OF RUP PROCESS
•Two dimensions.
•Horizontal axis:
– Represents time and shows the lifecycle aspects of the
process.
•Vertical axis:
– Represents core process workflows.
1
5
7
TWO DIMENSIONS OF
UNIFIED PROCESS

1
5
8
 INCEPTION
ACTIVITIES
•Formulate scope of project

•Risk management, staffing, project plan

•Synthesize a candidate architecture.

1
5
9
• Initial requirements capture

• Cost Benefit Analysis

Outcome of Inception
• Initial Risk Analysis
Phase
• Project scope definition

• Defining a candidate architecture

• Development of a disposable prototype

• Initial Use Case Model (10% - 20% complete)

• First pass Domain Model

1
6
0
 SPIRAL MODEL
• Proposed by Boehm in 1988.
• Each loop of the spiral represents a phase of the software
process:
– the innermost loop might be concerned with system feasibility,
– the next loop with system requirements definition,
– the next one with system design, and so on.
• There are no fixed phases in this model, the phases
shown in the figure are just examples.
 SPIRAL MODEL (CONT.)
• The team must decide:
– how to structure the project into phases.
• Start work using some generic model:
– add extra phases
• for specific projects or when problems are identified during a
project.
• Each loop in the spiral is split into four sectors
(quadrants).
SPIRAL MODEL

Determi Identify &

ne Resolve
Objectiv Risks
es

Customer
Evaluation Develop Next
of Level of
Prototype Product
 Objective Setting (First Quadrant)
• Identify objectives of the phase,
• Examine the risks associated with these objectives.
– Risk:
•Any adverse circumstance that might
hamper successful completion of a
software project.

• Find alternate solutions possible.

 RISK ASSESSMENT
AND REDUCTION
• For each identified
(SECOND project risk,
QUADRANT)
– a detailed analysis is carried out.
• Steps are taken to reduce the risk.
• For example, if there is a risk that requirements are
inappropriate:
– A prototype system may be developed.
 SPIRAL MODEL (CONT.)

• Development and Validation (Third quadrant):

– develop and validate the next level of the product.
• Review and Planning (Fourth quadrant):
– review the results achieved so far with the customer
and plan the next iteration around the spiral.
• With each iteration around the spiral:
– progressively more complete version of the software gets
built.
• Subsumes all discussed models:
– a single loop spiral represents waterfall Spiral Model as
model.
a Meta Model
– uses an evolutionary approach --
• iterations over the spiral are evolutionary levels.
– enables understanding and reacting to risks during each
iteration
along the spiral.
– Uses:
• prototyping as a risk reduction mechanism
• retains the step-wise approach of the waterfall model.
AGILE
MODELS

1
7/18/202 6
0 8
 What is Agile Software Development?
• Agile: Easily moved, light, nimble, active software
processes

• How agility achieved?

– Fitting the process to the project

– Avoidance of things that waste time

1
6
9
 AGILE MODEL
• To overcome the shortcomings of the waterfall model of
development.
– Proposed in mid-1990s
• The agile model was primarily designed:
– To help projects to adapt to change requests
• In the agile model:
– The requirements are decomposed into many small incremental parts
that can be developed over one to four weeks each.
1
7
0
 IDEOLOGY: AGILE
• MANIFESTO
Individuals and interactions over
– process and tools
• Working Software over
– comprehensive documentation
• Customer collaboration over
– contract negotiation
• Responding to change over http://www.agilemanifesto.org

– following a plan

1
7
1
• XP Agile Methodologies
• Scrum
• Unified process
• Crystal
• DSDM
• Lean
1
7
2
 AGILE MODEL:
• User stories:
PRINCIPAL TECHNIQUES
– Simpler than use cases.
• Metaphors:
– Based on user stories, developers propose a common vision of what is
required.
• Spike:
– Simple program to explore potential solutions.
• Refactor:
– Restructure code without affecting behavior, improve efficiency, structure, etc.

146
 AGILE
• At MODEL:
a time, only NITTY
one increment is planned, developed,
GRITTY
deployed at the customer site.
– No long-term plans are made.

• An iteration may not add significant functionality,

– But still a new release is invariably made at the end of each
iteration

– Delivered to the customer for regular use.

1
7
4
 METHODOLOGY
• Face-to-face communication favoured over written
documents.
• To facilitate face-to-face communication,
– Development team to share a single office space.
– Team size is deliberately kept small (5-9 people)
– This makes the agile model most suited to the development of
small projects.
1
7
5
 Effectiveness
F A C E -TO -FA C E ofO A R D
AT W H I T E B F a c e -to -fa c e

Communication Modes co n v e rs a tion

V i d e o
Communication
Effectiveness

c o n v e rs a tion M o d e ling
O p t i o n s
P h o n e

V i d e ota p e co n v e rs a tion
E m a i l
c o n v e r s a t i o n

A u d i o t a p e
D o c u m e nta tion
O p t i o n s
P a p e r

C o l d H ot
R i c h n e s s of C o m m u n i c a t i o n C h a n n e l
C o p y r i g h t 2 0 0 2 - 2 0 0 5 S cott W . A m b l e r
Original D i a g r a m C o p y r i g h t 2 0 0 2 Alistair
C o c k b u r n

1
7
6
 AGILE MODEL:
• PRINCIPLES
The primary measure of progress:
– Incremental release of working software
• Important principles behind agile model:
– Frequent delivery of versions --- once every few weeks.
– Requirements change requests are easily accommodated.
– Close cooperation between customers and developers.
– Face-to-face communication among team members.

1
7
7
 AGILE
• Travel light:
DOCUMENTATION
– You need far less documentation than you
think.
• Agile documents:
– Are concise
– Describe information that is less likely to change
– Describe “good things to know”
– Are sufficiently accurate, consistent, and detailed
• Valid reasons to document:
– Project stakeholders require it
– To define a contract model
– To support communication with an external group
– To think something through
151
 AGILE SOFTWARE
REQUIREMENTS E a c h i t e r a t i o n i m p l e m e n t t h e
H ig h {
MANAGEMENT h i g h e s t - p r i o r i t y r e q u i r e m e n t s
P r io r ity

E a c h n e w r e q u i r e m e n t
is p r i o r i t i z e d a n d
a d d e d t o t h e s t a c k

R e q u i r e m e n t s m a y
b e r e p r i o r i t i z e d a t
a n y t i m e

R e q u i r e m e n t s m a y
b e r e m o v e d a t a n y
t i m e
L o w

P r io r ity R e q u ir e m e n t C o p y r i g h t 2 0 0 4 S c o t t W .
s A m b l e r
1
7
9
 ADOPTION DETRACTORS
• Sketchy definitions, make it possible to have
– Inconsistent and diverse definitions
• High quality people skills required
• Short iterations inhibit long-term perspective
• Higher risks due to feature creep:
– Harder to manage feature creep and customer expectations
– Difficult to quantify cost, time, quality.
1
8
0
 AGILE MODEL
SHORTCOMINGS
• Derives agility through developing tacit knowledge
within the team, rather than any formal document:
– Can be misinterpreted…
– External review difficult to get…
– When project is complete, and team disperses,
maintenance becomes difficult…
1
8
1
 Agile Model versus Iterative Waterfall Model
• The waterfall model steps through in a planned sequence:
– Requirements-capture, analysis, design, coding, and testing .
• Progress is measured in terms of delivered artefacts:
– Requirement specifications, design documents, test plans, code
reviews, etc.
• In contrast agile model sequences:
– Delivery of working versions of a product in several increments.

1
8
2
 Agile Model versus Iterative Waterfall Model

• As regards to similarity:

– We can say that Agile teams use the

waterfall model on a small scale.

1
8
3
 Agile versus RAD Model
• Agile model does not recommend developing
prototypes:
– Systematic development of each incremental feature
is emphasized.
• In contrast:
– RAD is based on designing quick-and-dirty prototypes, which
are then refined into production quality code.
1
8
4
 AGILE VERSUS
EXPLORATORY
• Similarity:
PROGRAMMING
– Frequent re-evaluation of plans,
– Emphasis on face-to-face communication,
– Relatively sparse use of documents.
• Agile teams, however, do follow defined and
disciplined processes and carry out rigorous designs:
– This is in contrast to chaotic coding in exploratory
programming.
1
8
5
 GRA
MMI
NG
(XP)

1
7/18/202 8
0 6
 EXTREME PROGRAMMING MODEL

• Extreme programming (XP) was proposed by Kent

Beck in 1999.
• The methodology got its name from the fact that:
– Recommends taking the best practices to
extreme levels.
– If something is good, why not do it all the time.
1
8
7
• If code review is good: Taking Good
– Always review --- pair programming Practices to Extreme
• If testing is good:
– Continually write and execute test cases --- test-driven
development
• If incremental development is good:
– Come up with new increments every few days
• If simplicity is good:
– Create the simplest design that will support only the
currently required functionality.
1
8
8
• IfTAKING TO
design is good, EXTREME
– everybody will design daily (refactoring)
• If architecture is important,
– everybody will work at defining and refining the architecture
(metaphor)
• If integration testing is important,
– build and integrate test several times a day (continuous
integration)
1
8
9
• Communication:
4 VALUES
– Enhance communication among team members and with the
customers.
• Simplicity:
– Build something simple that will work today rather than something that
takes time and yet never used
– May not pay attention for tomorrow
• Feedback:
– System staying out of users is trouble waiting to happen
• Courage:
– Don’t hesitate to discard code
1
9
0
 BEST PRACTICES
• Coding:
– without code it is not possible to have a working system.
– Utmost attention needs to be placed on coding.
• Testing:
– Testing is the primary means for developing a fault-free product.
• Listening:
– Careful listening to the customers is essential to develop a good quality
product.

1
9
1
 BEST PRACTICES
• Designing:
– Without proper design, a system implementation becomes too
complex
– The dependencies within the system become too numerous to
comprehend.
• Feedback:
– Feedback is important in learning customer
requirements.
1
9
2
• XP Planning
• Begins with the creation of “user stories”
• Agile team assesses each story and assigns a cost Extreme
• Stories are grouped to for a deliverable increment Programmin
• A commitment is made on delivery date
g Activities
• XP Design
• Follows the KIS principle
• Encourage the use of CRC cards
• For difficult design problems, suggests the creation of “spike solutions”—a
design prototype
• Encourages “refactoring”—an iterative refinement of the internal program
design

193
• XP Coding
• Recommends the construction of unit test cases before coding
commences (test-driven development)
• Encourages “pair programming” Extreme
Programmin
• XP Testing g Activities
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and executed to assess
customer visible functionalities

194
 FULL LIST OF XP
1. PRACTICES
Planning – determine scope of the next release by combining business priorities and
technical estimates

2. Small releases – put a simple system into production, then release new versions in very
short cycles

3. Metaphor – all development is guided by a simple shared story of how the whole
system works

4. Simple design – system is to be designed as simple as possible

5. Testing – programmers continuously write and execute unit tests

1
9
5
 FULL LIST OF XP
7. PRACTICES
Refactoring – programmers continuously restructure the system
without changing its behavior to remove duplication and simplify
8. Pair-programming -- all production code is written with
two programmers at one machine
9. Collective ownership – anyone can change any code anywhere in
the system at any time.
10. Continuous integration – integrate and build the system many
times a day – every time a task is completed.

1
9
6
 FULL LIST OF XP
PRACTICES
11. 40-hour week – work no more than 40 hours a week as a rule

12. On-site customer – a user is a part of the team and available full-
time to answer questions

13. Coding standards – programmers write all code in accordance with

rules emphasizing communication through the code

1
9
7
 EMPHASIZES TEST-DRIVEN
DEVELOPMENT (TDD)
• Based on user story develop test cases
• Implement a quick and dirty feature every couple of days:
– Get customer feedback
– Alter if necessary
– Refactor
• Take up next feature
1
9
8
 Project Characteristics that Suggest Suitability
of Extreme Programming
• Projects involving new technology or research
projects.
– In this case, the requirements change rapidly and unforeseen
technical problems need to be resolved.
• Small projects:
– These are easily developed using extreme programming.
1
9
9
 PRACTICE QUESTIONS
• What are the stages of iterative waterfall model?
• What are the disadvantages of the iterative waterfall model?
• Why has agile model become so popular?
• What difficulties might be faced if no life cycle model is
followed for a certain large project?

2
0
0
 SUGGEST SUITABLE
• ALIFE CYCLE
software MODELinstitution to automate its:
for an academic
– Course registration and grading
– Fee collection
– Staff salary
– Purchase and store inventory
• The software would be developed by tailoring a similar software
that was developed for another educational institution:
– 70% reuse
– 10% new code and 20% modification
2
0
1
 PRACTICE QUESTIONS
• Which types of risks can be better handled using the spiral
model compared to the prototyping model?
• Which type of process model is suitable for the following
projects:
– A customization software
– A payroll software for contract employees that would be add on
to an existing payroll software
2
0
2
 PRACTICE QUESTIONS
• Which lifecycle model would you select for the following project
which has been awarded to us by a mobile phone vendor:
– A new mobile operating system by upgrading the existing operating
system
– Needs to work well efficiently with 4G systems
– Power usage minimization
– Directly upload backup data on a cloud infrastructure maintained
by the
mobile phone vendor
2
0
3
SCRUM

2
0
4
 SCRUM: CHARACTERISTICS

• Self-organizing teams

• Product progresses in a series of month-long sprints

• Requirements are captured as items in a list of product

backlog

• One of the agile processes

2
0
5
DAILY

Scru
Sprint m
Sprin
planni t
ng
Scru revie
Sprint w
Product m Product
backlog backl increme
og nt

2
0
6
 SPRINT
• Scrum projects progress in a series of “sprints”
– Analogous to XP iterations or time boxes
– Target duration is one month
• Software increment is designed, coded, and
tested during the sprint
• No changes entertained during a sprint
2
0
7
 SCRUM
FRAMEWORK
• Roles : Product Owner, ScrumMaster, Team

• Ceremonies : Sprint Planning, Sprint Review, Sprint

Retrospective, and Daily Scrum Meeting
• Artifacts : Product Backlog, Sprint Backlog, and Burndown
Chart

2
0
8
 KEY ROLES AND
RESPONSIBILITIES IN SCRUM
• Product
PROCESS Owner
– Acts on behalf of customers to represent their interests.
• Development Team
– Team of five-nine people with cross-functional skill sets.
• Scrum Master (aka Project Manager)
– Facilitates scrum process and resolves impediments at the team and
organization level by acting as a buffer between the team and outside
interference.
2
0
9
 PRODUCT OWNER

• Defines the features of the product

• Decide on release date and content
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results.

2
1
0
 THE SCRUM MASTER

• Represents management to the project

• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences

2
1
1
 SCRUM TEAM
• Typically 5-10 people
• Cross-functional
– QA, Programmers, UI Designers, etc.
• Teams are self-organizing
• Membership can change only between sprints
2
1
2
 CEREMONIES
• Sprint Planning Meeting

• Sprint

• Daily Scrum

• Sprint Review Meeting

2
1
3
 SPRINT PLANNING
• Goal is to produce Sprint Backlog
• Product owner works with the Team to negotiate what
Backlog Items the Team will work on in order to meet
Release Goals
• Scrum Master ensures Team agrees to realistic goals

2
1
4
• Sprint
Fundamental process flow of Scrum
• A month-long iteration, during which an incremental product
functionality completed

• NO outside influence can interfere with the Scrum team during

the Sprint

• Each day begins with the Daily Scrum Meeting

2
1
5
• Daily
DAILY SCRUM
• 15-minutes
• Stand-up meeting
• Not for problem solving
• Three questions:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?
2
1
6
• Is NOT a problem solving session Daily Scrum
• Is NOT a way to collect information about WHO is behind the
schedule

• Is a meeting in which team members make commitments to each

other and to the Scrum Master

• Is a good way for a Scrum Master to track the progress of the

Team
2
1
7
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features
• Informal
– 2-hour prep time rule
Sprint Review
• Participants Meeting
– Customers
– Management
– Product Owner
– Other engineers
2
1
8
 PRODUCT BACKLOG
• A list of all desired work on the project
– Usually a combination of

• story-based work (“let user search and replace”)

• task-based work (“improve exception handling”)

• List is prioritized by the Product Owner

– Typically a Product Manager, Marketing, Internal Customer, etc.

2
1
9
 PRODUCT BACKLOG
• Requirements for a system, expressed as a prioritized list
of Backlog Items

– Managed and owned by Product Owner

– Spreadsheet (typically)

– Usually is created during the Sprint Planning Meeting

2
2
0
Sample
Product

Backlog

2
2
1
SPRINT BACKLOG

• A subset of Product Backlog Items, which define the work for a Sprint

– Created by Team members

– Each Item has it’s own status

– Updated daily
2
2
2
AGILE TEAM PLANS ITS WORK
WHAT IS A USER STORY?

1. A user story is a requirement which defines what is required by the user as functionality.
A

2. user story can be in two forms:

a) As a <User Role> I want <Functionality> so that <Business Value>
b) In order to <Business value> as a <User Role> I want <Functionality>

During release planning, a rough estimate is given to a user story using relative scale as
points. During iteration planning, the story is broken down into tasks.
.
1. Relationship of User Stories and Tasks

• User story talks about what is to be done. It defines what a user needs.
•  Task talks about how it is to be done. It defines how a functionality is to be
implemented.
•  Stories are implemented by tasks. Each story is a collection of tasks.
• User story is divided into tasks when it is planned in current iteration.
• Tasks are estimated in hours, typically from 2 to 12 hours
 SPRINT BACKLOG DURING
THE SPRINT
• Changes occur:
– Team adds new tasks whenever they need to in order to meet
the Sprint Goal
– Team can remove unnecessary tasks
– But: Sprint Backlog can only be updated by the team

• Estimates are updated whenever there’s new information

2
2
8
 BURN DOWN CHARTS

• Are used to represent “work done”.

• Are remarkably simple but effective Information disseminators
• 3 Types:
– Sprint Burn down Chart (progress of the Sprint)

– Release Burn down Chart (progress of release)

– Product Burn down chart (progress of the Product)

2
2
9
 SPRINT BURN DOWN
CHART
• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to release
• Ideally should burn down to zero to the end of the Sprint
• Actually is not a straight line

2
3
0
SPRINT BURNDOWN
CHART

2
3
1
 RELEASE BURNDOWN
•CHART
Will the final release be done on right time?

• How many more sprints?

• X-axis: sprints

• Y-axis: amount of story

points remaining

2
3
2
PRODUCT BURNDOWN
CHART
• Is a “big picture” view of project’s progress (all the
releases)

2
3
3
 SCALABILITY OF SCRUM
• A typical Scrum team is 6-10 people

• Jeff Sutherland - up to over 800 people

• "Scrum of Scrums" or what called "Meta-Scrum“

• Frequency of meetings is based on the degree of coupling between

packets

2
3
4
 Faculty Name
Department Name 203
 AGILE VS. PLAN-DRIVEN
1. PROCESSES
Small products and teams: 1. Large products and teams;
 Scalability limited hard to scale down
2. Untested on safety-critical 2. Proven for highly critical
products products;
3. Good for dynamic, but 3. Good for stable:
expensive for stable But expensive for
environments. dynamic environments
4. Require experienced 4. Require only few
personnel throughout experienced
5. Personnel thrive on freedom personnel
and chaos 5. Personnel thrive on
structure
and order
AGILE ALM (APPLICATION LIFECYCLE
MANAGEMENT)

- Methodology that combines Agile development with traditional

ALM practices to manage the lifecycle of software applications in
an Agile environment.

- This approach combines agile methodologies such as Scrum, with

traditional project management paradigms such as Waterfall.

- It focuses on delivering the right features at the right time and

allows for frequent changes and iterations to improve the quality
of the end result.
BENEFITS OF IMPLEMENTING AGILE
ALM

1. Faster Time-to-Market: Agile ALM helps organizations deliver software

applications faster by breaking down the development process into smaller,
more manageable iterations.
2. Improved Quality: Agile ALM emphasizes testing and continuous integration,
which helps to identify and fix issues early in the development process, leading
to better quality software.
3. Increased Collaboration: Agile ALM fosters collaboration between
development and operations teams, which helps to ensure that everyone is
working towards a common goal.
4. Flexibility: Agile ALM allows organizations to respond quickly to changing
customer requirements and market conditions.
5. Transparency: Agile ALM provides greater visibility into the development
process, making it easier for teams to identify and address issues as they arise.
6. Continuous Improvement: Agile ALM emphasizes continuous improvement,
allowing organizations to incorporate feedback and make adjustments
throughout the development process.
 AGILE ALM BENEFIT TEAMS
1. Improved Communication: Agile ALM promotes frequent and open
communication between team members, which helps to ensure that everyone is
working towards a common goal.
2. Increased Collaboration: Agile ALM fosters collaboration between
development and operations teams, which helps to ensure that everyone is on
the same page and working towards the same objectives.
3. Greater Visibility: Agile ALM provides greater visibility into the development
process, making it easier for teams to identify and address issues as they arise.
4. Faster Feedback: Agile ALM emphasizes continuous testing and feedback,
which helps teams to identify and address issues early in the development
process.
5. Increased Flexibility: Agile ALM allows teams to be more flexible and
responsive to changing requirements and customer needs.
6. Greater Job Satisfaction: Agile ALM promotes teamwork, collaboration, and
innovation, which can lead to greater job satisfaction among team members.
AGILE ALM PRINCIPLES
1. Customer Satisfaction: Agile ALM is focused on delivering software
that meets the needs of the customer, with a focus on delivering
value quickly and continuously improving based on feedback.
2. Iterative Development: Agile ALM breaks down the software
development process into smaller, more manageable chunks
called sprints, allowing teams to work iteratively and
collaboratively to deliver working software quickly.
3. Cross-Functional Teams: Agile ALM promotes collaboration
between different teams, such as developers, testers, and project
managers, to ensure that everyone is working together towards a
common goal.
AGILE ALM PRINCIPLES

4.Continuous Testing and Integration: Agile ALM emphasizes the

importance of continuous testing and integration, with a focus on
automating these processes to ensure that software is tested and
integrated quickly and reliably.
5.Adaptability: Agile ALM recognizes that requirements and priorities
can change over time, and encourages teams to be flexible and
adaptable in response to these changes.
6.Continuous Improvement: Agile ALM emphasizes the importance of
continuous improvement, with a focus on identifying areas for
improvement and implementing changes to processes and practices
to achieve better results.
COMPONENTS OF AGILE ALM
CHALLENGES WITH AGILE ALM

1. Resistance to Change: Some team members may be resistant to changing their current
development processes and tools, which can make it difficult to adopt Agile ALM.
2. Lack of Experience: Agile ALM requires a significant level of expertise and experience, and
many organizations may not have the necessary skills and knowledge to implement it
effectively.
3. Difficulty Managing Priorities: Agile ALM requires careful management of priorities and trade-
offs, and it can be challenging to balance competing demands and ensure that the most
important work is being prioritized.
4. Coordination Across Teams: Agile ALM involves a high degree of collaboration and coordination
between different teams, and it can be challenging to ensure that everyone is working
effectively together.
5. Difficulty Measuring Progress: Agile ALM relies heavily on metrics and data to track progress,
and it can be challenging to identify the right metrics and ensure that they are being
measured effectively.
6. Need for Ongoing Training and Support: Agile ALM requires ongoing training and support to
ensure that teams are using the tools and processes effectively and continuously improving
their practices.
AGILE ALM VS AGILE

1. The main difference between Agile and ALM is that Agile is a

software development methodology that emphasizes flexibility,
collaboration, and customer satisfaction
2. while ALM is a broader framework that includes all activities
related to software development, from planning to retirement.
3. Agile ALM combines both approaches by using Agile
methodologies within the broader context of ALM principles
RAD (RAPID APPLICATION
DEVELOPMENT) MODEL

1.RAD is a linear sequential software development process

model that emphasizes a concise development cycle
using an element based construction approach.
2. If the requirements are well understood and described,
and the project scope is a constraint, the RAD process
enables a development team to create a fully functional
system within a concise time period
RAD
•Gathering requirements using workshops or focus
groups
•Prototyping and early, reiterative user testing of
designs
•The re-use of software components

•A rigidly paced schedule that refers design

improvements to the next product version

•Less formality in reviews and other team

communication
THE VARIOUS PHASES OF RAD

1.Business Modelling: The information flow among business

functions is defined by answering questions like what data drives the
business process, what data is generated, who generates it, where
does the information go, who process it and so on.
2. Data Modelling: The data collected from business modeling is
refined into a set of data objects (entities) that are needed to
support the business. The attributes (character of each entity) are
identified, and the relation between these data objects (entities) is
defined.
VARIOUS PHASES

3. Process Modelling: The information object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or retrieving a data
object.

4. Application Generation: Automated tools are used to facilitate construction of the

software; even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have already been tested
since RAD emphasis reuse. This reduces the overall testing time. But the new part must be
tested, and all interfaces must be fully exercised
WHEN TO USE RAD MODEL

• When the system should need to create the

project that modularizes in a short span time (2-3
months).
• When the requirements are well-known.
• When the technical risk is limited.
• When there's a necessity to make a system, which
modularized in 2-3 months of period.
• It should be used only if the budget allows the use
of automatic code generating tools.
ADVANTAGE OF RAD MODEL

•This model is flexible for change.

•In this model, changes are adoptable.
•Each phase in RAD brings highest priority functionality to the cus
•It reduced development time.
•It increases the reusability of features
DISADVANTAGE OF RAD MODEL

•It required highly skilled designers.

•All application is not compatible with RAD.
•For smaller projects, we cannot use the RAD model.
•On the high technical risk, it's not suitable.
•Required user involvement
AGILE MANIFESTO

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
•Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
•Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage.
•Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the sho
•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.
•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--the art of maximizing the amount of work not done--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
Cloud Computing

Unit-1

SYSTEMS MODELING,
CLUSTERING AND
VIRTUALIZATION
 TEXT BOOKS AND REFERENCE BOOK

 Text Book:

1. Cloud Computing: Principles and Paradigms by Rajkumar Buyya, James Broberg and
Andrzej
M.Goscinski, Wiley, 2011.
2) Distributed and Cloud Computing, Kai Hwang, Geoffery C.Fox, Jack J.Dongarra, Elsevier,
2012
REFERENCE BOOK:
1) Cloud Computing : A Practical Approach, Anthony T.Velte, Toby J.Velte, Robert Elsenpeter,
Tata McGraw Hill, rp2011.
2) Enterprise Cloud Computing, Gautam Shroff, Cambridge University Press, 2010.
3) Cloud Computing: Implementation, Management and Security, John W. Rittinghouse,
James
F.Ransome, CRC Press, rp2012.
4) Cloud Application Architectures: Building Applications and Infrastructure in the Cloud,
George Reese, O’Reilly, SPD, rp2011
 COURSE OBJECTIVES

1.learning the principles of virtualization

technologies and cloud computing
2. Introduce the concepts of how virtual machines,
hypervisors, virtual networks and virtual storage
work together.
3. Emphasizes how to apply and build cloud
infrastructure in practice.
4. Introduce actual approaches in virtual machine
management and troubleshooting.
 COURSE OUTCOMES

1.The fundamental ideas behind Cloud Computing, the

evolution of the paradigm, its applicability, benefits, as
well as current and future challenges
CLOUD COMPUTING

• Definition of Cloud computing, Roots of Cloud

Computing, Layers and Types of Clouds, Desired Features of a Cloud,

Cloud Infrastructure Management, Infrastructure as a Service
Providers, Platform as a Service Providers.
• Computing Paradigms: High-Performance Computing, Parallel
Computing, Distributed Computing, Cluster Computing, Grid
Computing.
Definition of Cloud Computing

• The “Cloud Computing” refers to

term
services by the cloudthat is
provided delivering of
responsible
services such for computing
as servers, storage, databases,
networking, software , analytics, intelligence,
and more, over the Cloud (Internet).
ADVANTAGES OF CLOUD COMPUTING:

1. Cost: It reduces the huge capital costs of buying

hardware and software.
2. Speed: Resources can be accessed in minutes, typically
within a few clicks.
3. Scalability: We can increase or decrease the
requirement of resources according to the
business requirements.
4. Productivity: While using cloud computing, we put less
operational effort. We do not need to apply patching,
as well as no need to maintain hardware and software.
So, in this way, the IT team can be more productive and
focus on achieving business goals.
5. Reliability: Backup and recovery of data are
less expensive and extremely fast for business
continuity.
6. Security: Many cloud vendors offer a broad
set of policies, technologies, and controls that
strengthen our data security
COMPUTING PARADIGMS:

High-Performance Computing:
For many years, HPC systems emphasize the raw
speed performance. The speed of
HPC systems has increased from Gflops in
the early 1990s to now Pflops in 2010. This
improvement was driven mainly by the demands
from scientific, engineering, and
manufacturing communities
CLOUD COMPUTING

The computing trend moved toward cloud

from concept of computing,
particularly
the grid
resources are when
required to solvecomputing
a single
problem, usinglarge
the ideas of
power as a utility computing and
concepts. However, the other allied
potential
difference between grid and cloud is that
grid
PARALLEL COMPUTING:

Parallel computing is defined as a type of computing where

multiple computer
systems are used simultaneously. Here a problem is
broken into sub-problems and then
.
 DISTRIBUTED COMPUTING:
• Distributed computing is defined as a type of computing where multiple computer systems
work on a single problem. Here all the computer systems are linked together, and the
problem is divided into sub-problems where each part is solved by different computer
systems.

• The goal of distributed computing is to increase the performance and efficiency of the
system and ensure fault tolerance. In the below diagram, each processor has its own local
memory, and all the processors communicate with each other over a network

• Distributed computing is defined as a type of computing where multiple computer

BIOCOMPUTING

• Biocomputing systems use the concepts of biologically derived

or simulated molecules (or models) that perform
computational processes in order to solve a problem.
• The biologically derived models aid in structuring the
computer programs that become part of the
application
 MOBILE COMPUTING
Mobile communication for voice applications (e.g., cellular phone) is
widely established throughout the world and witnesses a very rapid
growth in all its dimensions including the increase in the number of
subscribers of various cellular networks. An extension of this
technology
CLUSTER COMPUTING
• A cluster is a group of independent computers that work
together to perform the tasks given. Cluster computing is
defined as a type of computing that consists of two or more
independent computers, referred to as nodes, that work
together to execute tasks as a single machine.

• The goal of cluster computing is to increase the performance,

scalability and simplicity of the system. As you can see in the
below diagram, all the nodes, (irrespective of whether they
are a parent node or child node), act as a single entity to
perform the tasks.
CLOUD COMPUTING :

An Internet cloud of resources can be either a

centralized or a distributed computing system.
The cloud applies parallel or distributed
computing, or both. Clouds can be built with
physical or virtualized resources over large
data centers that are centralized or distributed
GRID COMPUTING:

• Grid computing is defined as a type of computing

where it is constitutes a network of computers that
work together to perform tasks that may be difficult
for a single machine to handle. All the computers on
that network work under the same umbrella and are
termed as a virtual supercomputer. The tasks they
work on is of either high computing power and
consist of large data sets.
NANOCOMPUTING
Nanocomputing refers to computing systems
that are constructed from nanoscale
components.
The silicon transistors in traditional
computers may be replaced by transistors
based on carbon nanotubes.
MIGRATING INTO A CLOUD
• Cloud computing has been a hotly debated and discussed
topic amongst IT professionals and researchers both in the
industry and in academia. There are intense discussions on
several blogs, in Web sites, and in several research efforts.
This also resulted in several entrepreneurial efforts to help
leverage and migrate into the cloud given the myriad issues,
challenges, benefits, and limitations and lack of
comprehensive understanding
SEVEN-STEP MODEL OF
MIGRATION INTO A CLOUD
• Step-1: Cloud migration assessments comprise assessments to
understand the issues involved in the specific case of
migration at the application level or the code, the design, the
architecture, or usage levels. These assessments are about
the cost of migration as well as about the ROI that can be
achieved in the case of production version.
• Step-2: Isolating all systemic and environmental dependencies
of the enterprise application components within the captive
data center.
• Step-3: Generating the mapping constructs between what
shall possibly remain in the local captive data center and what
goes onto the cloud.
• Step-4: substantial part of the enterprise application needs to
be architected, redesigned, and reimplemented on the cloud
enterprise application in its own small ways.
• Step-5: We leverage the intrinsic features of the cloud
computing service to augment our enterprise application in its
own small ways.
• Step-6: We validate and test the new form of the enterprise
application with an extensive test suite that comprises testing
the components of the enterprise application on the cloud as
well
• Step-7: Test results could be positive or mixed. In the latter
case, we iterate and optimize as appropriate. After several
such optimizing iterations, the migration is deemed successful
SERVICES

• INFRASTRUCTURE AS A SERVICE :
• Public Infrastructure as a Service providers commonly offer virtual servers
containing one or more CPUs, running several choices of operating
systems and a customized software stack. In addition, storage space and
communication facilities are often provided.
• Features
• IAAS offers a set of specialized features that can influence the cost benefit
ratio to be experienced by user applications when moved to the cloud.
• The most relevant features are:
• 1. Geographic distribution of data centers.
• 2. Variety of user interfaces and APIs to access the system.
• 3. Specialized components and services that aid Particular applications
(e.g.,
• load- balancers, firewalls).
• Cloud-centric integration solutions are being developed and
demonstrated for showcasing their capabilities for integrating
enterprise and cloud applications. Now with the arrival and
adoption of the transformative and disruptive paradigm of
cloud computing, every ICT products are being converted
into a collection of services to be delivered via the open
Internet In that line, the standards-compliant integration
suites are being transitioned into services so that any
integration need of any one from any part of the world, can
be easily, cheaply and rapidly
Aneka is a PaaS
• 1. Features multiple programming models allowing
developers to easily build their distributed applications
• 2. Provides resource provisioning facilities in a
seamless and dynamic fashion
• 3. Achieved by means of the resource provisioning
framework . A typical scenario that a medium or large
enterprise may encounter . Combines privately owned
resources with public rented resources to dynamically
increase the resource capacity to a larger scale
• 4. Private resources identify computing and storage
elements kept in the premises. They share similar
internal security and administrative policies
 Platform as a services paas:
• Public Platform as a Service providers commonly
offer a development and deployment environment
that allow users to create and run their applications
with little or no concern to low- level details of the
platform. In addition, specific programming
languages and frameworks are made available in the
platform, as well as other services such as persistent
data storage and in memory caches.
Features
• Programming Models, Languages, and Frameworks:
Programming models made available by providers
define how users can express their applic.
ANEKA—INTEGRATION OF PRIVATE AND
PUBLIC CLOUDS
• Aneka is a software platform and a framework
for developing distributed applications on the
cloud. It harnesses the computing resources of
a heterogeneous network of workstations and
servers or data centers on demand.
• This can be a public cloud available to anyone
through the Internet, a private cloud
constituted by a set of nodes with restricted
access within an enterprise
• Aneka is essentially an implementation of the PaaS
model, and it provides a runtime environment for
executing applications by leveraging the underlying
infrastructure of the cloud. Developers can express
distributed applications by using the API contained in
the Software Development Kit (SDK) or by porting
existing legacy applications to the cloud.
• Such applications are executed on the Aneka
cloud, represented by a collection of nodes
connected through the network hosting the Aneka
container.
• The container is the building block of the
middleware and represents the runtime environment
for executing applications; it contains the core
functionalities of the