Y.M.P.Shantha Y.M.P.Shantha Y.M.P.

Shantha
S So of ft tw wa ar re e D De ev ve el lo op pm me en nt t p pr ra ac ct ti ic ce es s
WHAT
What is Software?
A piece of code which may makes your life easier
What is Software Development?
Making a software to have improved features
What is Practices?
Improving your skills by doing it over and over again
Example with Rubik Puzzle
What are we going to learn here?
Improve your skills
Change the way you are thinking
Put you on the right track
WHY
Why we need to learn this subject?
o Because we want to do things right
Why do we need to do things right?
o We need to show an output at the end
o No one wants to fail on any thing
Why this subject is so important?
o This is the foundation of your carrier
If the foundation is not strong there is no need to talk about what may happen to a building
over a period of time
o The same fact remains true here
CUSTOMER & DEVELOPER
Customer This is not what I wanted
Developer This is exactly what you said that you want to have
Customer But still it is not right and it is not what I wanted to have
Modification Modifications Modifications
Developer Sir or Madam now I have bought what you need exactly
Customer Nope still not what I wanted but this time it is much closer to what I wanted
Oh.. No.. Modifications modifications again
WHAT IS THE REASON FOR THIS?
Lets share your thoughts with rest of the others in the class room
Was it a problem of the customer?
Was it a problem with the Developer?
There may be many
o Communication
o Understanding
o Documentation
o Developing
o Testing
o Delivery
A FAMOUS EXAMPLE OF SOFTWARE DEVELOPMENT
THE PROBLEM
The problem starts with requirements
Either Client does not convey his/her requirements to the developer correctly
The developer understands it in the wrong way
If you dont get the requirements correct,
You are building a wrong solution
You need to change over and over
Any change cost time, energy and money
Having a forecast on the requirement
Before the requirement is fully described the solution is developed in developers mind
Jumping in to conclusion
THE ANSWER
Lets take a look at the small exercise that I gave you last week
Did you understand the requirement properly?
Did you ask questions to clarify your self and to make sure that you do the right thing?
How many of you understand the requirement correctly?
What went wrong there? _ Your feedback
Ask questions to clarify the requirement
Ask questions to make sure that you have understood the requirement correctly.
PRACTICE
This is a group activity
A group may come up with a requirement
Then select another group to describe your requirement
That group has to find a solution for the requirement
Ask questions to clarify the requirement
Document the requirement
Document the solution
Prepare a small presentation combining both
Be realisticGood luck
STAKEHOLDERS
On Oxford Dictionary
o stakeholder n. independent party with whom money etc. wagered is deposited.
In simple
o All parties interested on a project
Who are the stakeholders of a software project?
o Client / Customer
o Business Analysts
o Developer
o Tester
o Users
BUSINESS REQUIREMENT
What it means?
o What must be delivered to provide value
Three most important words to remember in this
definition
o Value
o What
o Delivered
Often value is expressed in money
What means the business requirement
Delivered include Time, Cost and Support
A picture speaks thousands of words. So lets have a
look
REQUIREMENTS IMPACT
Implement needs to be based on the Design
Design needs to be based on Requirements
Requirements Design Implement
Development starts by defining the requirements
Requirements are translated into appropriate
design
Some of the requirements may get lost at the
translation
The design plays a vital role
It is highly unlikely that a programmer detects a
requirement error
REAL WORLD EXAMPLE
Independent testers are more closer to the
business
They are more likely to detect requirement
errors
Y2K error
o Programming error?
o Design error
Clearly It was a Design error
2 digits dates worked for more than 50 years of the computer age
About 2/3 of the errors are already in the design before programmer programs it
and tester test it.
WHAT HAPPEN IN THE PROCESS
Error portion grows as we progress through development
Quality and other success factors continue to deteriorate
Systems usually do get better as we proceed through development
o Example Windows, MS Office, etc
Administrative Sanctions
o User Sign-Off
o Requirements Freezes
This doesnt work practically
We have got to learn to deliver value
ERROR SOURCE BY PHASE
Who are the stakeholders of a software project?
o Client / Customer
o Business Analysts
o Developer
o Tester
o Users
BUSINESS REQUIREMENT
What it means?
o What must be delivered to provide value
Three most important words to remember in this
definition
o Value
o What
o Delivered
Often value is expressed in money
What means the business requirement
Delivered include Time, Cost and Support
A picture speaks thousands of words. So lets have a
look
REQUIREMENTS IMPACT
Implement needs to be based on the Design
Design needs to be based on Requirements
Requirements Design Implement
Development starts by defining the requirements
Requirements are translated into appropriate
design
Some of the requirements may get lost at the
translation
The design plays a vital role
It is highly unlikely that a programmer detects a
requirement error
REAL WORLD EXAMPLE
Independent testers are more closer to the
business
They are more likely to detect requirement
errors
Y2K error
o Programming error?
o Design error
Clearly It was a Design error
2 digits dates worked for more than 50 years of the computer age
About 2/3 of the errors are already in the design before programmer programs it
and tester test it.
WHAT HAPPEN IN THE PROCESS
Error portion grows as we progress through development
Quality and other success factors continue to deteriorate
Systems usually do get better as we proceed through development
o Example Windows, MS Office, etc
Administrative Sanctions
o User Sign-Off
o Requirements Freezes
This doesnt work practically
We have got to learn to deliver value
ERROR SOURCE BY PHASE
Who are the stakeholders of a software project?
o Client / Customer
o Business Analysts
o Developer
o Tester
o Users
BUSINESS REQUIREMENT
What it means?
o What must be delivered to provide value
Three most important words to remember in this
definition
o Value
o What
o Delivered
Often value is expressed in money
What means the business requirement
Delivered include Time, Cost and Support
A picture speaks thousands of words. So lets have a
look
REQUIREMENTS IMPACT
Implement needs to be based on the Design
Design needs to be based on Requirements
Requirements Design Implement
Development starts by defining the requirements
Requirements are translated into appropriate
design
Some of the requirements may get lost at the
translation
The design plays a vital role
It is highly unlikely that a programmer detects a
requirement error
REAL WORLD EXAMPLE
Independent testers are more closer to the
business
They are more likely to detect requirement
errors
Y2K error
o Programming error?
o Design error
Clearly It was a Design error
2 digits dates worked for more than 50 years of the computer age
About 2/3 of the errors are already in the design before programmer programs it
and tester test it.
WHAT HAPPEN IN THE PROCESS
Error portion grows as we progress through development
Quality and other success factors continue to deteriorate
Systems usually do get better as we proceed through development
o Example Windows, MS Office, etc
Administrative Sanctions
o User Sign-Off
o Requirements Freezes
This doesnt work practically
We have got to learn to deliver value
ERROR SOURCE BY PHASE
NARROWING QUALITY GAPS DOWN
The most common way is to repeat the full requirements through implementation process
o This is the ordinary response to Its not right
o Which will consume lot of time and energy
Prevent inappropriate coding by using various testing techniques
o Reviews
o Static analysis and modeling
o Prototyping
Prevent the most waste by using more effective discovery and testing methods to get the
more of the requirements right in the 1st place.
WHY IT IS DIFFICULT TO ELIMINATE GAPS COMPLETELY
Requirements are keep changing
It is really are our awareness of the requirements
That accounts for much of the apparent changes
We could have identified and anticipated
Testing is done to identify faults in the program
o Functional errors
o Bugs
It is not aimed at verifying requirements with deliverables
Testing is planned and proceed as per the design
Lets have a deep look at this in the next lesson.
REQUIREMENT ERRORS
Any gap between the requirement and the delivered product can be considered
as the requirement error
Requirement error are generated as a result of
o Not understanding the customer requirement
Requirement errors that found in a later stage of development are difficult to fix
Cost to correct will also be very high
But it depends on which stage you are in the software development process
Easy and cost effective to fix a requirement error if it is found before starting
coding.
FIXING REQUIREMENT ERRORS
Fixing a requirement error cost lots of Time, Money and Energy, Why?
Programmer is less familiar with the code
o May or may not the original programmer who wrote this code
o Even if it is the same programmer who wrote this, he might have forgotten how he
wrote over a period of time
Testing and re-testing
o Testing by the programmer
o Integration testing
o Regression testing.
FIXING REQUIREMENT ERRORS
If it is in production by the time error is detected, the situation becomes worst
o Data error may be existing
o May have to add new data
o Adding new tables
o Modifying tables
New releases are needed when requirement changes or requirement errors were fixed
Distribution of a new release again cost Time, Money and Energy.
o Client / Server Architecture
o Standalone computers.
COST OF FIXING REQUIREMENT ERRORS
Cost of fixing a requirement error in production is much more higher than fixing it
at requirement gathering.
New versions may be on CDs or DVDs
Time spent on uninstalling the earlier version, installing and configuring the new version.
Failures in requirements can cause unrecoverable errors and damage to the goodwill.
o Example Billing system that takes automated backup which never tested for safe
recovery
Loosing customer confident with frequent changes.
TIME VERSUS COST
Spending more time on a product
o Does not add value to it
o It definitely increase the cost of it
Time spent to improve the quality and features of
a product
o Definitely improve the value of it
o It is an investment with a return for the
product
o Client may not reluctant to pay the extra cost for extra benefits
Time spent to correct requirement errors
o Does not add value to the product
o It definitely increases cost of the product.
PRACTICAL EXAMPLE
ITERATIVE DEVELOPMENT
A practical alternative
Broken down a large project in to small
pieces
Start testing them each early in the
development life cycle
Since it is a small part of a big project
o Amount of coding is relatively small
o Not much time is required to inspect
o Easy to re-work
Identify requirement errors and correct
them
o Less time is sufficient for re-work
o Relatively less complicated
Group of one or two programmers are sufficient.
CAT-SCAN APPROACH
A medical testing technique like X-ray
X-ray is 2D
Example Pain in your Shoulder
CAT-scan is 3D
It takes many 2D images in different angles
How this may relate to Software Development
We use this approach to improve thoroughness of testing
Each different test angle may reveal something that is missed by any previous test
Lets take a deep look at it.
COST OF FIXING REQUIREMENT ERRORS
Cost of fixing a requirement error in production is much more higher than fixing it
at requirement gathering.
New versions may be on CDs or DVDs
Time spent on uninstalling the earlier version, installing and configuring the new version.
Failures in requirements can cause unrecoverable errors and damage to the goodwill.
o Example Billing system that takes automated backup which never tested for safe
recovery
Loosing customer confident with frequent changes.
TIME VERSUS COST
Spending more time on a product
o Does not add value to it
o It definitely increase the cost of it
Time spent to improve the quality and features of
a product
o Definitely improve the value of it
o It is an investment with a return for the
product
o Client may not reluctant to pay the extra cost for extra benefits
Time spent to correct requirement errors
o Does not add value to the product
o It definitely increases cost of the product.
PRACTICAL EXAMPLE
ITERATIVE DEVELOPMENT
A practical alternative
Broken down a large project in to small
pieces
Start testing them each early in the
development life cycle
Since it is a small part of a big project
o Amount of coding is relatively small
o Not much time is required to inspect
o Easy to re-work
Identify requirement errors and correct
them
o Less time is sufficient for re-work
o Relatively less complicated
Group of one or two programmers are sufficient.
CAT-SCAN APPROACH
A medical testing technique like X-ray
X-ray is 2D
Example Pain in your Shoulder
CAT-scan is 3D
It takes many 2D images in different angles
How this may relate to Software Development
We use this approach to improve thoroughness of testing
Each different test angle may reveal something that is missed by any previous test
Lets take a deep look at it.
COST OF FIXING REQUIREMENT ERRORS
Cost of fixing a requirement error in production is much more higher than fixing it
at requirement gathering.
New versions may be on CDs or DVDs
Time spent on uninstalling the earlier version, installing and configuring the new version.
Failures in requirements can cause unrecoverable errors and damage to the goodwill.
o Example Billing system that takes automated backup which never tested for safe
recovery
Loosing customer confident with frequent changes.
TIME VERSUS COST
Spending more time on a product
o Does not add value to it
o It definitely increase the cost of it
Time spent to improve the quality and features of
a product
o Definitely improve the value of it
o It is an investment with a return for the
product
o Client may not reluctant to pay the extra cost for extra benefits
Time spent to correct requirement errors
o Does not add value to the product
o It definitely increases cost of the product.
PRACTICAL EXAMPLE
ITERATIVE DEVELOPMENT
A practical alternative
Broken down a large project in to small
pieces
Start testing them each early in the
development life cycle
Since it is a small part of a big project
o Amount of coding is relatively small
o Not much time is required to inspect
o Easy to re-work
Identify requirement errors and correct
them
o Less time is sufficient for re-work
o Relatively less complicated
Group of one or two programmers are sufficient.
CAT-SCAN APPROACH
A medical testing technique like X-ray
X-ray is 2D
Example Pain in your Shoulder
CAT-scan is 3D
It takes many 2D images in different angles
How this may relate to Software Development
We use this approach to improve thoroughness of testing
Each different test angle may reveal something that is missed by any previous test
Lets take a deep look at it.
PROACTIVE TESTING LIFE CYCLE
EXPLANATION
Testing starts as early as Feasibility Analysis
phase
Then moves on to system analysis as a whole
Testing activities are in cooperated in most of the
development activity
System design begins right after Acceptance
Criteria is being finalized
System design moves in to development in 2
paths
o Direct
o After High Level / Low level design and after
technical test plans are released.
Testing phase broken in to many steps
o Code level (Debugging/Review)
o Formal review
o Black Box / White Box / Unit Testing
o Integration testing
o System testing
Additional Independent QA test is introduced
o right before the implementation
This will make sure that the right things are
o implemented
o Even after implementation Acceptance testing is introduce to further assure
deliverables.
WHAT IS A VISION
As per the Oxford Vision is imaginative insight
A descriptive aspiration of what an organization would like to achieve or accomplish in the
mid-term or long-term future
It is intended to serves as a clear guide for choosing current and future courses of
action
This is the core purpose of the existence of an organization
A big picture of the future of the Organization.
VISION STATEMENTS
"Mission Statements" and "Vision Statements" do two distinctly different jobs
A Mission Statement defines the organization's purpose and primary objectives
The vision statement communicates both the purpose and values of the
organization
For employees
o It gives direction on how they are expected to behave
o Inspires them to give their best to the Organization
Shared with customers
o It shapes customers' understanding of why they should be with the organization.
SAMPLE VISION STATEMENTS
Dialog
o To be the undisputed leader in the provision of multi-sensory connectivity resulting
always, in the empowerment and enrichment of Sri Lankan lives and enterprises.
DHL
o Customers trust DHL as the preferred global express and logistics partner, leading the
industry in terms of quality, profitability and market share
Toyota
o To become the most successful and respected lift Truck Company in the U.S.
CREATING MISSION STATEMENT
First we look at creating mission statements.
Then we create vision statements.
To create your mission statement, first identify your organization's "winning idea".
This is the idea or approach that will make your organization stand out from its
competitors, and is the reason that customers will come to you and not to your
competitors.
Next identify the key measures of your success.
Make sure that you choose the most important measures and not too many of them.
CREATING MISSION STATEMENT
Combine your winning idea and success measures into a tangible and measurable goal
Refine the words until you have a concise and precise statement of your mission, which
expresses your ideas, measures and desired result
Examples
o To lead in the provision of technology enabled connectivity touching multiple human
sensors and faculties, through committed adherence to customer-driven, responsive and
flexible business processes, and through the delivery of quality service and leading edge
technology unparalleled
by any other, spurred by an empowered set of dedicated individuals who are driven by an
irrepressible desire to work as one towards a common goal in the truest sense of the team
spirit.
CREATING A VISION STATEMENT
Once you've created your mission statement, move on to create your vision
statement
First identify your organization's mission. Then uncover the real, human value in that
mission.
Next, identify what you, your customers and other stakeholders will value most about how
your organization will achieve this mission. Distil these into the values that your
organization has or should have.
Combine your mission and values, and polish the words until you have a vision
statement inspiring enough to energize and motivate people inside and outside your
organization.
WHAT IS A GOAL
As per the Oxford a Goal is object of ambition or effort; destination
Definition
o An observable and measurable end result having one or more objectives to be
achieved within a more or less fixed timeframe
Goal setting is a powerful process for thinking about your ideal future, and for
motivating yourself to turn your vision of this future into reality
The process of setting goals helps you choose where you want to go in life
Goals are of two types.
TYPES OF GOALS
Short Term Goals
o Things that you are planning to achieve in a short period of time
o Time span is short it may be a month or few months
o Example : Passing the end semester examination with good results
Long Term Goals
o Things that you are planning to achieve in a longer period of time
o Time span is longer most probably in years
o Example : Getting graduated with in three years with a better class
WHAT IS AN OBJECTIVE
A specific result that a person or system aims to achieve within a time frame and
with available resources.
In general, objectives are more specific and easier to measure than goals
Objectives are basic tools that underlie all planning and strategic activities
They serve as the basis for creating policy and evaluating performance
Some examples of business objectives include minimizing expenses, expanding
internationally, or making profit maximized.
RELATIONSHIPS
Introduction
How Software is built
What is a process
Software Process models
o Waterfall Model
Classical
Iterative
o Prototyping Model
o Evolutionary Development
o Spiral Model
INTRODUCTION
In this lesson we are going to set
our focus on software development process models
Like any other industry there are standard and non standard processes that we follow in
Software industry
Example
o Lets assume that we have to write a program to add up numbers from 1 to 10
o How many different methods can we follow?
Can I say one is correct and the other one is wrong as long as it produces the required out
put for me correctly.
HOW SOFTWARE IS BUILT
A software is released as a result of series of activities
These activities are collectively called SDLC or Software
Development Life Cycle
These activities are
o Requirement Analysis
o Design
o Implementation
o Testing
o Evolution
Before a software is released it will go through these
steps many times that is why we call it a Cycle.
TYPES OF GOALS
Short Term Goals
o Things that you are planning to achieve in a short period of time
o Time span is short it may be a month or few months
o Example : Passing the end semester examination with good results
Long Term Goals
o Things that you are planning to achieve in a longer period of time
o Time span is longer most probably in years
o Example : Getting graduated with in three years with a better class
WHAT IS AN OBJECTIVE
A specific result that a person or system aims to achieve within a time frame and
with available resources.
In general, objectives are more specific and easier to measure than goals
Objectives are basic tools that underlie all planning and strategic activities
They serve as the basis for creating policy and evaluating performance
Some examples of business objectives include minimizing expenses, expanding
internationally, or making profit maximized.
RELATIONSHIPS
Introduction
How Software is built
What is a process
Software Process models
o Waterfall Model
Classical
Iterative
o Prototyping Model
o Evolutionary Development
o Spiral Model
INTRODUCTION
In this lesson we are going to set
our focus on software development process models
Like any other industry there are standard and non standard processes that we follow in
Software industry
Example
o Lets assume that we have to write a program to add up numbers from 1 to 10
o How many different methods can we follow?
Can I say one is correct and the other one is wrong as long as it produces the required out
put for me correctly.
HOW SOFTWARE IS BUILT
A software is released as a result of series of activities
These activities are collectively called SDLC or Software
Development Life Cycle
These activities are
o Requirement Analysis
o Design
o Implementation
o Testing
o Evolution
Before a software is released it will go through these
steps many times that is why we call it a Cycle.
TYPES OF GOALS
Short Term Goals
o Things that you are planning to achieve in a short period of time
o Time span is short it may be a month or few months
o Example : Passing the end semester examination with good results
Long Term Goals
o Things that you are planning to achieve in a longer period of time
o Time span is longer most probably in years
o Example : Getting graduated with in three years with a better class
WHAT IS AN OBJECTIVE
A specific result that a person or system aims to achieve within a time frame and
with available resources.
In general, objectives are more specific and easier to measure than goals
Objectives are basic tools that underlie all planning and strategic activities
They serve as the basis for creating policy and evaluating performance
Some examples of business objectives include minimizing expenses, expanding
internationally, or making profit maximized.
RELATIONSHIPS
Introduction
How Software is built
What is a process
Software Process models
o Waterfall Model
Classical
Iterative
o Prototyping Model
o Evolutionary Development
o Spiral Model
INTRODUCTION
In this lesson we are going to set
our focus on software development process models
Like any other industry there are standard and non standard processes that we follow in
Software industry
Example
o Lets assume that we have to write a program to add up numbers from 1 to 10
o How many different methods can we follow?
Can I say one is correct and the other one is wrong as long as it produces the required out
put for me correctly.
HOW SOFTWARE IS BUILT
A software is released as a result of series of activities
These activities are collectively called SDLC or Software
Development Life Cycle
These activities are
o Requirement Analysis
o Design
o Implementation
o Testing
o Evolution
Before a software is released it will go through these
steps many times that is why we call it a Cycle.
WHAT IS A PROCESS
It is a series of steps that will result in a final
product
Above example illustrate the process of
producing milk
There are similar processes in software
industry to process modern age software
A process that can result a software as its
product is called software development
process
Why we need a process?
o It will be a guide line
o It help us to plan
o It help us to identify resource requirements and risks.
SELECTING A SUITABLE PROCESS
SOFTWARE PROCESS MODELS
It is a software development
strategy formed by a group of
software engineers in an
organization
This is Also called software
engineering paradigm
It is highly dependent on the
requirement of the organization
There are 4 fundamental
process activities
o Specification
o Development
o Validation
o Evolution
These are common to all software processes.
A WATERFALL
CLASSICAL WATERFALL MODEL
PHASES OF CLASSICAL WATERFALL MODEL
In this model we traverse from one phase to the other in forward direction only
Similar to a water fall this model resembles the flow of a water in a waterfall
Following are the phases of classical waterfall model
o Feasibility Study
o Analysis
o Design
o Implement
o Test
o Maintain
FEASIBILITY STUDY
This help us to determine whether developing the product is functionally and technically
possible to achieve
As a result of a very good feasibility study we can arrive at following
o An abstract definition of the problem
o Formulation of different solution strategies
o Alternative solution strategies
o A cost benefit Analysis
Finally this will tell us whether it is worth while doing this project or not
It will help us to take early decisions.
ANALYSIS
This phase starts with gathering all relevant data regarding the product
Purpose of this phase is to identify requirements and to document them in the form of
specifications
This phase consist of two major activities
o Analyzing requirements
o Defining requirement specification
SRS (Software Requirement Specification) document is prepared at the end of this phase
SRS is also called Black-Box Specification.
DESIGN
To transform the specification into a form suitable for implementation in a programming
language
Design is a creative activity
That is why it is so hard
The software design is derived from the SRS (System Requirement Specification)
document using one of two approaches.
Function Oriented Methods
Structured Analysis & Design (SA/SD)
Object Oriented Methods
IMPLEMENT
In this phase we do coding and unit testing
Each module is implemented independently, as a stand alone unit
o Translation into source code and documentation
o Unit Testing and Debugging
Unit Testing ensures that each module works correctly in isolation
The end result of this phase is a set of Independently tested software modules
TEST
Testing is of Two types
o Integrated testing
To integrate modules in a series of carefully planned steps
Integrating modules one at a time makes error location and correction much easier
At the end of each step incomplete system is re-tested using ALL the test data
o System testing
To ensure that the system meets the requirements in the SRS document
System testing takes place after all the modules have been integrated
The system is delivered to the customer at the end of this phase.
MAINTENANCE
Maintenance is of 3 types
Corrective Maintenance
o To eliminate errors that were not discovered during system development
Perfective Maintenance
o To improve the existing system
Example - Optimizing the implementation or enhancing the functionality
Adaptive Maintenance
o To modify the system for a new or changing environment
To work with a new hardware device, operating system, or tax or law change.
ITERATIVE WATERFALL APPROACH
The classical waterfall model is idealistic
It assumes that no defects are introduced
during any of the development phases
In practice, defects are introduced during every
phase of the software life cycle.
Hence feedback paths must be added to the
classical waterfall model.
The resulting Iterative Waterfall Model is one of
the most widely used process models.
But it is time consuming and expensive.
PROTOTYPING MODEL
Before start developing the actual system, a working model of the system is built
It may have
o Limited Functionality
o Low Reliability (often full of
bugs)
o Inefficient Performance
o Inaccurate Results
User requirements are clarified
and technical difficulties are
resolved
Nevertheless, prototypes help in
developing high quality software
products.
BUILDING A PROTOTYPE
It may not be possible to get
a system right the first time
1. Carry out a quick requirements analysis
2. Carry out a quick design
3. Build a prototype using short-cuts
4. Submit the working prototype to the customer for evaluation
5. Use customer feedback to refine requirements
6. Enhance the prototype with refined requirements
Repeat the phases 2 to 5 until the customer approves the prototype
The final system is then developed using the classical waterfall model.
EVOLUTION
EVOLUTIONARY DEVELOPMENT
EVOLUTIONARY DEVELOPMENT
This is also know as Successive Versions
Entire system is broken in to several modules
Initially delivers to core modules
The system is iteratively improved by adding new functionality
Disadvantages
o Difficulty in to splitting a software into parts that can be delivered incrementally.
o More suitable for very large systems, which has more scope for incremental
development.
SPIRAL MODEL
There are 4 main phases
o Determine objectives, Identify
alternatives
o Evaluate alternatives, identify and
resolve risks
o Develop the next level of the
product
o Customer evaluation of the
prototype
This model consist of
characteristics from all models
that we discussed
Iteration takes place along the
spiral
Uses prototyping as a risk
reduction mechanism
It enables the developer to understand and react to the risk at each evolutionally
level
EVOLUTION
EVOLUTIONARY DEVELOPMENT
EVOLUTIONARY DEVELOPMENT
This is also know as Successive Versions
Entire system is broken in to several modules
Initially delivers to core modules
The system is iteratively improved by adding new functionality
Disadvantages
o Difficulty in to splitting a software into parts that can be delivered incrementally.
o More suitable for very large systems, which has more scope for incremental
development.
SPIRAL MODEL
There are 4 main phases
o Determine objectives, Identify
alternatives
o Evaluate alternatives, identify and
resolve risks
o Develop the next level of the
product
o Customer evaluation of the
prototype
This model consist of
characteristics from all models
that we discussed
Iteration takes place along the
spiral
Uses prototyping as a risk
reduction mechanism
It enables the developer to understand and react to the risk at each evolutionally
level
EVOLUTION
EVOLUTIONARY DEVELOPMENT
EVOLUTIONARY DEVELOPMENT
This is also know as Successive Versions
Entire system is broken in to several modules
Initially delivers to core modules
The system is iteratively improved by adding new functionality
Disadvantages
o Difficulty in to splitting a software into parts that can be delivered incrementally.
o More suitable for very large systems, which has more scope for incremental
development.
SPIRAL MODEL
There are 4 main phases
o Determine objectives, Identify
alternatives
o Evaluate alternatives, identify and
resolve risks
o Develop the next level of the
product
o Customer evaluation of the
prototype
This model consist of
characteristics from all models
that we discussed
Iteration takes place along the
spiral
Uses prototyping as a risk
reduction mechanism
It enables the developer to understand and react to the risk at each evolutionally
level
WHAT HAPPEN IN GENERAL
Initially the customers confident is very high
Months after the project started
o There may not be any tangible output to show the customer
o That makes the customer un-happy
o Decreases the level of confident that the customer had initially
Developers and software product team is still working on the project
Customer can not understand the technical jargons that is tabled at meetings with the
Software development project team.
SUMMARY
INTRODUCTION
The goal of the requirement engineering process is to create and maintain a system
requirements document
It refers to the process of formulating, documenting and maintaining requirements of a
software project
There are FOUR main stages in this process
o Feasibility Study
o Requirement Analysis
o Requirement Definition
o Requirement Specification
Lets have a look at the entire process as a whole.
THE REQUIREMENT ENGINEERING PROCESS
Above picture illustrates the main
activities of Requirement
Engineering process
Main activities are distinguished
with rounded boxes in light blue
It also illustrate relationships
between these activities
It shows documents produced at
each stage of the requirements
engineering process
Lets have a look at each of these
main activities one by one in detailed view
FEASIBILITY STUDY
All new systems Requirement Engineering Process starts with a Feasibility Study
It is an estimation process
This should be Cheap and Quick
o Done at low cost
o In less time duration
o Quality of the study should remain high
Outcomes of a Feasibility Study
o Cost effectiveness of the proposed system
o Can or Can not deliver results with in the given budgetary constraints.
The results of the feasibility study should be a report that recommends whether or not it is
worth carrying on with the requirements engineering and system development process
Questions asked in the study are,
1. Does the system contribute to the overall objectives of the organization?
2. Can the system be implemented using current technology and within given cost and
schedule constraints?
3. Can the system be integrated with other systems which are already in place?
After this we start the Requirement Analysis
REQUIREMENT ANALYSIS
Involve obtaining a clear and thorough understanding of the product to be developed
Done by an observation of the existing system
Interviews with all stake holders
Develop one or more system models
It is easy to automate a manual system to fully functional software system
It is very hard to create something new from the scratch
System prototypes may also developed to understand requirements more precisely.
BASIC GUIDE LINE FOR REQUIREMENT ANALYSIS
What is the problem
o In depth understanding about the problem
Importance of solving the problem
o Understand the impact of the problem to the organization
Possible Solutions
o Formulate alternative solutions
Input and Output Data
o Identify input and output data for the intended system
Complexities which may arise when solving
o How to handle complex situation.
MAIN ACTIVITIES OF REQUIREMENT ANALYSIS
There are two main activities in Requirement Analysis
o Requirements Gathering
Example Gather prices of things that we want to buy for household requirements
o Analysis on gathered requirements
REQUIREMENT GATHERING
Starts with interviewing existing users
It is easy if we have a working system to follow
o Observation may help to identify most of the processes in the manual system.
o Can question users to clarify certain things that are not clear to the analyst.
o Input & output data formats and operational procedures can be easily obtained
immediately.
When we dont have such system
o Lot of imaginations are required.
o Analyst creativity plays vital role.
ANALYSIS OF GATHERED REQUIREMENTS
Main purpose of this is to
o Clearly understand the exact requirement
o Resolve
Anomalies Irregular
Conflicts Clashing of opposed interest
Inconsistencies Firmness (how steady) In gathered requirement
Example of inconsistency
o In a Stock-Controlling system
One user may want to receive email alert when a product reached the re-order level
Another user may want to place an order for that item
Discussions will help the analyst to sort out these
REQUIREMENT DEFINITION
Translate information gathered in the requirement analysis in to a document that defines
set of requirements
This is done in users language with no or very little technical jargons
This should accurately and clearly reflect what customer wants
This document is essential for the understanding between the end user and system
developers
Once requirements are defined and documented the scope will remain unchanged
Otherwise scope may change from time to time
REQUIREMENT SPECIFICATION
A detail and precise description of the system requirement
Act as a contractual document between the client and the software developer
Carried out in parallel with the high-level development of the system
Errors in the requirement definition can be identified at this stage
Engineers who analyze customer requirements and write requirement specification
document are called System Analysts.
SRS DOCUMENT
official statement of what the system developers should implement
Released after complete and precise understanding about the customer requirement
This document is revised many times internally among project team
This internal reviews ensures
o Understandable
o Consistence
o Unambiguous
o Complete
SRS DOCUMENT
After that it is sent for the customer review and acceptance
Future developments will base on this document
This may varied depending on the Analyst and polices of an organization
It should include both the user requirements for a system and a detailed specification of the
system requirements
In some cases, user and system requirements may be integrated into a single description
In other cases, user requirements are defined in introduction to the system
requirements specification
If there are a large number of requirements, the detailed system requirements may
be presented in a separate document
The requirements document has a diverse set of users
o The senior management of the client (Who pays for the software)
o Engineers responsible from both parties
o Developers who develops the software, etc
USERS OF SRS
ORGANIZATION OF SRS DOCUMENT
In general it should consist of following things
o Introduction
Background
Overall description
Environment characteristics
Hardware
Peripherals
People
Interfaces with
Devices
Operating Systems
Databases (If any)
Users
ORGANIZATION OF SRS DOCUMENT
o Functional Requirements
Functional Partitioning
Functional Description
Control description
o Non-Functional Requirements
o Behavioral description
System states
Events and actions
o Validation Criteria
Performance bounds
Classes of Tests
Response to Undesired events
INTRODUCTION
Intended to deliver working software quickly to customers
This allows the development team to focus on the software
itself rather than on its design and documentation.
Agile methods universally rely on an iterative approach to
software specification, development and delivery.
Good for the systems where requirements are usually and
rapidly changed.
Probably the best-known agile method is extreme
programming.
PRINCIPLES OF AGILE METHODS
AGILE METHODS
Extreme programming
Scrum (Schwaber and Beedle, 2001)
Crystal (Cockburn, 2001)
Adaptive Software Development (Highsmith, 2000),
Dynamic Systems Development Method (DSDM)
(Stapleton, 1997)
Feature Driven Development (Palmer and Felsing,
2002)
ORGANIZATION OF SRS DOCUMENT
o Functional Requirements
Functional Partitioning
Functional Description
Control description
o Non-Functional Requirements
o Behavioral description
System states
Events and actions
o Validation Criteria
Performance bounds
Classes of Tests
Response to Undesired events
INTRODUCTION
Intended to deliver working software quickly to customers
This allows the development team to focus on the software
itself rather than on its design and documentation.
Agile methods universally rely on an iterative approach to
software specification, development and delivery.
Good for the systems where requirements are usually and
rapidly changed.
Probably the best-known agile method is extreme
programming.
PRINCIPLES OF AGILE METHODS
AGILE METHODS
Extreme programming
Scrum (Schwaber and Beedle, 2001)
Crystal (Cockburn, 2001)
Adaptive Software Development (Highsmith, 2000),
Dynamic Systems Development Method (DSDM)
(Stapleton, 1997)
Feature Driven Development (Palmer and Felsing,
2002)
ORGANIZATION OF SRS DOCUMENT
o Functional Requirements
Functional Partitioning
Functional Description
Control description
o Non-Functional Requirements
o Behavioral description
System states
Events and actions
o Validation Criteria
Performance bounds
Classes of Tests
Response to Undesired events
INTRODUCTION
Intended to deliver working software quickly to customers
This allows the development team to focus on the software
itself rather than on its design and documentation.
Agile methods universally rely on an iterative approach to
software specification, development and delivery.
Good for the systems where requirements are usually and
rapidly changed.
Probably the best-known agile method is extreme
programming.
PRINCIPLES OF AGILE METHODS
AGILE METHODS
Extreme programming
Scrum (Schwaber and Beedle, 2001)
Crystal (Cockburn, 2001)
Adaptive Software Development (Highsmith, 2000),
Dynamic Systems Development Method (DSDM)
(Stapleton, 1997)
Feature Driven Development (Palmer and Felsing,
2002)
EXTREME PROGRAMMING (XP)
Do you believe that there is a relationship between the above picture and extreme
programming?
No it is not the idea of extreme programming
Then what?
This approach was developed by pushing recognized good practice to extreme levels
Good Practices are
o Iterative development
o customer involvement
Extreme programming (XP) is perhaps the best known and most widely used agile method.
All requirements are expressed as scenarios. This is called user stories
Requirements are implemented directly as a series of tasks
Programmers work in pairs and develop tests for each task even before writing the code
All tests must be successfully executed when new code is integrated into the system
Customers are closely involved in specifying and prioritizing system requirements
Customer becomes the part of development team hence miscommunication is minimized
EXTREME PROGRAMMING RELEASE CYCLE
CHARACTERISTICS OF XP
Incremental development is supported through small, frequent releases of the system
Scenarios or Customer stories are the basis for process planning
Customer involvement is supported through the full-time engagement of the customer in
the development team
Customer representative is responsible for defining acceptance tests for the system.
People, not process, are supported through pair programming.
CHARACTERISTICS OF XP
Collective ownership of the system code
No excessively long working hours
Frequent Changes are supported through regular system releases
Test-first development and continuous integration
Maintaining simplicity is supported through constant refactoring to improve code
quality and using simple designs that do not anticipate future changes to the
system.
EXTREME PROGRAMMING (XP)
Do you believe that there is a relationship between the above picture and extreme
programming?
No it is not the idea of extreme programming
Then what?
This approach was developed by pushing recognized good practice to extreme levels
Good Practices are
o Iterative development
o customer involvement
Extreme programming (XP) is perhaps the best known and most widely used agile method.
All requirements are expressed as scenarios. This is called user stories
Requirements are implemented directly as a series of tasks
Programmers work in pairs and develop tests for each task even before writing the code
All tests must be successfully executed when new code is integrated into the system
Customers are closely involved in specifying and prioritizing system requirements
Customer becomes the part of development team hence miscommunication is minimized
EXTREME PROGRAMMING RELEASE CYCLE
CHARACTERISTICS OF XP
Incremental development is supported through small, frequent releases of the system
Scenarios or Customer stories are the basis for process planning
Customer involvement is supported through the full-time engagement of the customer in
the development team
Customer representative is responsible for defining acceptance tests for the system.
People, not process, are supported through pair programming.
CHARACTERISTICS OF XP
Collective ownership of the system code
No excessively long working hours
Frequent Changes are supported through regular system releases
Test-first development and continuous integration
Maintaining simplicity is supported through constant refactoring to improve code
quality and using simple designs that do not anticipate future changes to the
system.
EXTREME PROGRAMMING (XP)
Do you believe that there is a relationship between the above picture and extreme
programming?
No it is not the idea of extreme programming
Then what?
This approach was developed by pushing recognized good practice to extreme levels
Good Practices are
o Iterative development
o customer involvement
Extreme programming (XP) is perhaps the best known and most widely used agile method.
All requirements are expressed as scenarios. This is called user stories
Requirements are implemented directly as a series of tasks
Programmers work in pairs and develop tests for each task even before writing the code
All tests must be successfully executed when new code is integrated into the system
Customers are closely involved in specifying and prioritizing system requirements
Customer becomes the part of development team hence miscommunication is minimized
EXTREME PROGRAMMING RELEASE CYCLE
CHARACTERISTICS OF XP
Incremental development is supported through small, frequent releases of the system
Scenarios or Customer stories are the basis for process planning
Customer involvement is supported through the full-time engagement of the customer in
the development team
Customer representative is responsible for defining acceptance tests for the system.
People, not process, are supported through pair programming.
CHARACTERISTICS OF XP
Collective ownership of the system code
No excessively long working hours
Frequent Changes are supported through regular system releases
Test-first development and continuous integration
Maintaining simplicity is supported through constant refactoring to improve code
quality and using simple designs that do not anticipate future changes to the
system.
EXTREME PROGRAMMING PRACTICES
Practice description
Incremental planning
Requirements are recorded on Story Cards and the Stories to
be included in a release are determined by the time available
and their relative priority. The developers break these stories
into development Tasks.
Small releases
The minimal useful set of functionality that provides business
values is developed first. Releases of the system are frequent
are incrementally add functionality to the first release.
Simple design
Enough design is carried out to meet the current requirements
and no more.
Test-first development
An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring
All developers are expected to refactor the code continuously
as soon as possible code improvements are found. This keeps
the code simple and maintainable.
Pair programming
Developers work in pairs, checking each others work and
providing the support to always do good job.
Collective ownership
The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all
the code. Anyone can change anything.
Continuous integration
As soon as work on a task is complete it is integrated in to the
whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace
Large amount of overtime are not considered acceptable as the
net effect is often to reduce code quality and medium-term
productivity.
On-site customer
A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programme process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
STORY CARD
Once the story cards have been
developed, the development team
breaks them down into tasks
Then estimates the effort and resources
required for implementation
Prioritization is done by the customer
Unimplemented stories may be changed
or discarded
If changes are required for a system
that has already been delivered, new
story cards are developed
New versions of the software may be
built several times per day
Incremented versions are delivered to customers roughly in every two weeks time
Every new version must be tested with
o All existing automated tests
o Tests for the new functionality
New version is accepted only when all the tests are successfully completed
Story card is not just directly translated to a software to be implemented
Programming team looks for possible improvements to the software and implements them
immediately.
EXTREME PROGRAMMING PRACTICES
Practice description
Incremental planning
Requirements are recorded on Story Cards and the Stories to
be included in a release are determined by the time available
and their relative priority. The developers break these stories
into development Tasks.
Small releases
The minimal useful set of functionality that provides business
values is developed first. Releases of the system are frequent
are incrementally add functionality to the first release.
Simple design
Enough design is carried out to meet the current requirements
and no more.
Test-first development
An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring
All developers are expected to refactor the code continuously
as soon as possible code improvements are found. This keeps
the code simple and maintainable.
Pair programming
Developers work in pairs, checking each others work and
providing the support to always do good job.
Collective ownership
The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all
the code. Anyone can change anything.
Continuous integration
As soon as work on a task is complete it is integrated in to the
whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace
Large amount of overtime are not considered acceptable as the
net effect is often to reduce code quality and medium-term
productivity.
On-site customer
A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programme process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
STORY CARD
Once the story cards have been
developed, the development team
breaks them down into tasks
Then estimates the effort and resources
required for implementation
Prioritization is done by the customer
Unimplemented stories may be changed
or discarded
If changes are required for a system
that has already been delivered, new
story cards are developed
New versions of the software may be
built several times per day
Incremented versions are delivered to customers roughly in every two weeks time
Every new version must be tested with
o All existing automated tests
o Tests for the new functionality
New version is accepted only when all the tests are successfully completed
Story card is not just directly translated to a software to be implemented
Programming team looks for possible improvements to the software and implements them
immediately.
EXTREME PROGRAMMING PRACTICES
Practice description
Incremental planning
Requirements are recorded on Story Cards and the Stories to
be included in a release are determined by the time available
and their relative priority. The developers break these stories
into development Tasks.
Small releases
The minimal useful set of functionality that provides business
values is developed first. Releases of the system are frequent
are incrementally add functionality to the first release.
Simple design
Enough design is carried out to meet the current requirements
and no more.
Test-first development
An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring
All developers are expected to refactor the code continuously
as soon as possible code improvements are found. This keeps
the code simple and maintainable.
Pair programming
Developers work in pairs, checking each others work and
providing the support to always do good job.
Collective ownership
The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all
the code. Anyone can change anything.
Continuous integration
As soon as work on a task is complete it is integrated in to the
whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace
Large amount of overtime are not considered acceptable as the
net effect is often to reduce code quality and medium-term
productivity.
On-site customer
A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programme process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
STORY CARD
Once the story cards have been
developed, the development team
breaks them down into tasks
Then estimates the effort and resources
required for implementation
Prioritization is done by the customer
Unimplemented stories may be changed
or discarded
If changes are required for a system
that has already been delivered, new
story cards are developed
New versions of the software may be
built several times per day
Incremented versions are delivered to customers roughly in every two weeks time
Every new version must be tested with
o All existing automated tests
o Tests for the new functionality
New version is accepted only when all the tests are successfully completed
Story card is not just directly translated to a software to be implemented
Programming team looks for possible improvements to the software and implements them
immediately.
EXERCISE
Create two Story Cards for any of following events
o Pay one of your utility bill through internet banking system
o Download a preferred song from the internet
o Renew your professional membership over the internet.
Guidelines to the exercise
o Write down the steps in point form
o Describe each point as much as possible in your own words
o Read what you have written over to see your idea is clearly stated in the Story Card
TESTING IN EXTREME PROGRAMMING
Important differences between iterative development and plan-based development is in the way
that the system is tested.
XP places more emphasis than other agile methods on the testing process
o This is to avoid some of the problems of testing and system validation.
The key features of testing in XP are
o Test-first development
o Incremental test development from scenarios
o User involvement in the test development and validation
o The use of automated test harnesses.
TEST-FIRST DEVELOPMENT
TESTING IN EXTREME PROGRAMMING
Test-first development and the use of automated test harnesses are major strengths of the XP
approach
Test-first development
o This is also known as test driven development
o This means writing tests before the development
o This is one of the most important innovations in XP
o Implicitly defines both an interface and a specification of behavior for the functionality
o Problems of requirements and interface misunderstanding are reduced
o Avoids the problem of test-lag
Developer of the system works at a faster pace than the Tester
TEST-FIRST PROCESS
SAMPLE TEST CASE
PAIR PROGRAMMING
Another innovative practice
Programmers work in Pairs
One work-station
Same members not always paired
Advantages
o Common ownership of the system. Entire team is responsible for the system defects
o Act as a informal review process
o It supports refactoring - a process to improve software (parts of the code should be
rewritten to improve their clarity or structure)
o Less time is spent repairing bugs discovered during the testing process.
Disadvantage
o Time consuming
RAPID APPLICATION DEVELOPMENT (RAD)
Business systems have been developed iteratively for many years using rapid application
development techniques
Evolved from so-called fourth-generation languages (4GL) in the 1980s and are used for
developing applications that are data-intensive
Usually organized as a set of tools that allow data to be created, searched, displayed and
presented as reports
RAD systems are successful because, there is a great deal of commonality across
business applications
TEST-FIRST PROCESS
SAMPLE TEST CASE
PAIR PROGRAMMING
Another innovative practice
Programmers work in Pairs
One work-station
Same members not always paired
Advantages
o Common ownership of the system. Entire team is responsible for the system defects
o Act as a informal review process
o It supports refactoring - a process to improve software (parts of the code should be
rewritten to improve their clarity or structure)
o Less time is spent repairing bugs discovered during the testing process.
Disadvantage
o Time consuming
RAPID APPLICATION DEVELOPMENT (RAD)
Business systems have been developed iteratively for many years using rapid application
development techniques
Evolved from so-called fourth-generation languages (4GL) in the 1980s and are used for
developing applications that are data-intensive
Usually organized as a set of tools that allow data to be created, searched, displayed and
presented as reports
RAD systems are successful because, there is a great deal of commonality across
business applications
TEST-FIRST PROCESS
SAMPLE TEST CASE
PAIR PROGRAMMING
Another innovative practice
Programmers work in Pairs
One work-station
Same members not always paired
Advantages
o Common ownership of the system. Entire team is responsible for the system defects
o Act as a informal review process
o It supports refactoring - a process to improve software (parts of the code should be
rewritten to improve their clarity or structure)
o Less time is spent repairing bugs discovered during the testing process.
Disadvantage
o Time consuming
RAPID APPLICATION DEVELOPMENT (RAD)
Business systems have been developed iteratively for many years using rapid application
development techniques
Evolved from so-called fourth-generation languages (4GL) in the 1980s and are used for
developing applications that are data-intensive
Usually organized as a set of tools that allow data to be created, searched, displayed and
presented as reports
RAD systems are successful because, there is a great deal of commonality across
business applications
RAD PROCESS
TOOLS IN RAD ENVIRONMENT
A database programming language
o SQL (Structured Query Language) is the standard database programming language
An interface generator
o Used to create forms for data input and display
Links to office applications
o Spreadsheet Analysis and Manipulation of data
o Word Processor Report template creation
A report generator
o Used to define and create reports
RAD ENVIRONMENT
Many business applications rely on structured forms for input and output
RAD environments provides powerful facilities for screen definition and report generation
Screens are often defined as a series of linked forms
Question Is Visual studio a RAD?
Application programmers build the system interactively by defining the interface in terms of
screens, fields, buttons and menus
Visual development systems such as Visual Basic support this approach
VISUAL PROGRAMMING WITH RE-USE
VISUAL BASIC AS RAD ENVIRONMENT
Visual Basic is a very sophisticated example of a scripting language
Scripting languages are type less, high-level languages that are designed to help you
integrate components to create systems
Relatively simple applications can be built with a small team of people
Practical Examples
o Create a Menu
o Set properties of a text box
o Use of data control
o Linking forms
RAD PROCESS
TOOLS IN RAD ENVIRONMENT
A database programming language
o SQL (Structured Query Language) is the standard database programming language
An interface generator
o Used to create forms for data input and display
Links to office applications
o Spreadsheet Analysis and Manipulation of data
o Word Processor Report template creation
A report generator
o Used to define and create reports
RAD ENVIRONMENT
Many business applications rely on structured forms for input and output
RAD environments provides powerful facilities for screen definition and report generation
Screens are often defined as a series of linked forms
Question Is Visual studio a RAD?
Application programmers build the system interactively by defining the interface in terms of
screens, fields, buttons and menus
Visual development systems such as Visual Basic support this approach
VISUAL PROGRAMMING WITH RE-USE
VISUAL BASIC AS RAD ENVIRONMENT
Visual Basic is a very sophisticated example of a scripting language
Scripting languages are type less, high-level languages that are designed to help you
integrate components to create systems
Relatively simple applications can be built with a small team of people
Practical Examples
o Create a Menu
o Set properties of a text box
o Use of data control
o Linking forms
RAD PROCESS
TOOLS IN RAD ENVIRONMENT
A database programming language
o SQL (Structured Query Language) is the standard database programming language
An interface generator
o Used to create forms for data input and display
Links to office applications
o Spreadsheet Analysis and Manipulation of data
o Word Processor Report template creation
A report generator
o Used to define and create reports
RAD ENVIRONMENT
Many business applications rely on structured forms for input and output
RAD environments provides powerful facilities for screen definition and report generation
Screens are often defined as a series of linked forms
Question Is Visual studio a RAD?
Application programmers build the system interactively by defining the interface in terms of
screens, fields, buttons and menus
Visual development systems such as Visual Basic support this approach
VISUAL PROGRAMMING WITH RE-USE
VISUAL BASIC AS RAD ENVIRONMENT
Visual Basic is a very sophisticated example of a scripting language
Scripting languages are type less, high-level languages that are designed to help you
integrate components to create systems
Relatively simple applications can be built with a small team of people
Practical Examples
o Create a Menu
o Set properties of a text box
o Use of data control
o Linking forms
APPLICATION LINKING
APPLICATION LINKING
Advantages
o The main advantage of this approach is that a lot of application functionality can be
implemented quickly at a very low cost
o Users are already familiar with the applications
Disadvantages
o If they do not know how to use these applications, learning may be difficult
o There may also be performance problems
Example
o Word document having hyper links
o At your click respective application is revoked
AGILE & WATERFALL WITH TIME
AGILE VS WATERFALL
APPLICATION LINKING
APPLICATION LINKING
Advantages
o The main advantage of this approach is that a lot of application functionality can be
implemented quickly at a very low cost
o Users are already familiar with the applications
Disadvantages
o If they do not know how to use these applications, learning may be difficult
o There may also be performance problems
Example
o Word document having hyper links
o At your click respective application is revoked
AGILE & WATERFALL WITH TIME
AGILE VS WATERFALL
APPLICATION LINKING
APPLICATION LINKING
Advantages
o The main advantage of this approach is that a lot of application functionality can be
implemented quickly at a very low cost
o Users are already familiar with the applications
Disadvantages
o If they do not know how to use these applications, learning may be difficult
o There may also be performance problems
Example
o Word document having hyper links
o At your click respective application is revoked
AGILE & WATERFALL WITH TIME
AGILE VS WATERFALL
QUICK QUESTIONS
What type of development model is used in Xp out of the models you learned?
o Iterative
What is the advantage of Customer involved in the development process in Xp?
o Saves time
Frequent requirements changes are entertained with Xp (True/False)
o Answer is True
People, not process, are supported through pair programming (True/False)
o True
Changes are not supported through frequent system changes (True/False)
o False
o In Xp, We do not anticipate future changes to the system. Why? What is the reason for
this?
o To maintain Simplicity
o Change of requirements can accommodate in next release.
In Xp testing is done at the end of system development (True/False)
o False