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

SSooffttwwaarree DDeevveellooppmmeenntt pprraaccttiicceessWHAT 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 endo 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 buildingover 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 Communicationo Understandingo Documentationo Developingo Testingo 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 don’t 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 developer’s 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 realistic… Good 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 / Customero Business Analystso Developero Testero Users

BUSINESS REQUIREMENT What it means?

o What must be delivered to provide value Three most important words to remember in this

definitiono Valueo Whato 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 let’s 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-Offo Requirements “Freezes”

This doesn’t work practically We have got to learn to deliver value

ERROR SOURCE BY PHASE

Who are the stakeholders of a software project?o Client / Customero Business Analystso Developero Testero Users

BUSINESS REQUIREMENT What it means?

o What must be delivered to provide value Three most important words to remember in this

definitiono Valueo Whato 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 let’s 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-Offo Requirements “Freezes”

This doesn’t work practically We have got to learn to deliver value

ERROR SOURCE BY PHASE

Who are the stakeholders of a software project?o Client / Customero Business Analystso Developero Testero Users

BUSINESS REQUIREMENT What it means?

o What must be delivered to provide value Three most important words to remember in this

definitiono Valueo Whato 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 let’s 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-Offo Requirements “Freezes”

This doesn’t 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 “It’s not right”o Which will consume lot of time and energy

Prevent inappropriate coding by using various testing techniqueso Reviewso Static analysis and modelingo Prototyping

Prevent the most waste by using more effective discovery and testing methods to get themore 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 errorso Bugs

It is not aimed at verifying requirements with deliverables Testing is planned and proceed as per the design Let’s 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 codeo 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 programmero Integration testingo 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 existingo May have to add new datao Adding new tableso 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 Architectureo 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 saferecovery

Loosing customer confident with frequent changes.

TIME VERSUS COST

Spending more time on a producto Does not add value to ito It definitely increase the cost of it

Time spent to improve the quality and features ofa product

o Definitely improve the value of ito It is an investment with a return for the

producto Client may not reluctant to pay the extra cost for extra benefits

Time spent to correct requirement errorso Does not add value to the producto 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 smallo Not much time is required to inspecto Easy to re-work

Identify requirement errors and correctthemo Less time is sufficient for re-worko 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 saferecovery

Loosing customer confident with frequent changes.

TIME VERSUS COST

Spending more time on a producto Does not add value to ito It definitely increase the cost of it

Time spent to improve the quality and features ofa product

o Definitely improve the value of ito It is an investment with a return for the

producto Client may not reluctant to pay the extra cost for extra benefits

Time spent to correct requirement errorso Does not add value to the producto 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 smallo Not much time is required to inspecto Easy to re-work

Identify requirement errors and correctthemo Less time is sufficient for re-worko 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 saferecovery

Loosing customer confident with frequent changes.

TIME VERSUS COST

Spending more time on a producto Does not add value to ito It definitely increase the cost of it

Time spent to improve the quality and features ofa product

o Definitely improve the value of ito It is an investment with a return for the

producto Client may not reluctant to pay the extra cost for extra benefits

Time spent to correct requirement errorso Does not add value to the producto 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 smallo Not much time is required to inspecto Easy to re-work

Identify requirement errors and correctthemo Less time is sufficient for re-worko 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

pathso Directo 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 reviewo Black Box / White Box / Unit Testingo Integration testingo System testing

Additional Independent QA test is introducedo right before the implementation

This will make sure that the right things areo implementedo 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 behaveo Inspires them to give their best to the Organization

Shared with customerso 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 resultingalways, in the empowerment and enrichment of Sri Lankan lives and enterprises.

DHLo 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 yourcompetitors.

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 Exampleso To lead in the provision of technology enabled connectivity touching multiple human

sensors and faculties, through committed adherence to customer-driven, responsive andflexible business processes, and through the delivery of quality service and leading edgetechnology unparalleledby any other, spurred by an empowered set of dedicated individuals who are driven by anirrepressible desire to work as one towards a common goal in the truest sense of the teamspirit.

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 yourorganization has or should have.

Combine your mission and values, and polish the words until you have a visionstatement inspiring enough to energize and motivate people inside and outside yourorganization.

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 beachieved within a more or less fixed timeframe

Goal setting is a powerful process for thinking about your ideal future, and formotivating 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 timeo Time span is short it may be a month or few monthso Example :Passing the end semester examination with good results

Long Term Goalso Things that you are planning to achieve in a longer period of timeo Time span is longer most probably in yearso 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 Modelo Evolutionary Developmento 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 10o 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 output 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 Analysiso Designo Implementationo Testingo Evolution

Before a software is released it will go through thesesteps 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 timeo Time span is short it may be a month or few monthso Example :Passing the end semester examination with good results

Long Term Goalso Things that you are planning to achieve in a longer period of timeo Time span is longer most probably in yearso 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 Modelo Evolutionary Developmento 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 10o 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 output 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 Analysiso Designo Implementationo Testingo Evolution

Before a software is released it will go through thesesteps 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 timeo Time span is short it may be a month or few monthso Example :Passing the end semester examination with good results

Long Term Goalso Things that you are planning to achieve in a longer period of timeo Time span is longer most probably in yearso 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 Modelo Evolutionary Developmento 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 10o 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 output 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 Analysiso Designo Implementationo Testingo Evolution

Before a software is released it will go through thesesteps 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 it’s

product is called software developmentprocess

Why we need a process?o It will be a guide lineo It help us to plano 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 ofsoftware engineers in anorganization

This is Also called softwareengineering paradigm

It is highly dependent on therequirement of the organization

There are 4 fundamentalprocess activitieso Specificationo Developmento Validationo 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 Studyo Analysiso Designo Implemento Testo 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 problemo Formulation of different solution strategieso Alternative solution strategieso 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 requirementso 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 documentationo 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 Functionalityo Low Reliability (often full of

bugs)o Inefficient Performanceo Inaccurate Results

User requirements are clarifiedand technical difficulties areresolved

Nevertheless, prototypes help indeveloping high quality softwareproducts.

BUILDING A PROTOTYPE It may not be possible to get

a system right the first time1. Carry out a quick requirements analysis2. Carry out a quick design3. Build a prototype using short-cuts4. Submit the working prototype to the customer for evaluation5. Use customer feedback to refine requirements6. 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 phaseso Determine objectives, Identify

alternativeso Evaluate alternatives, identify and

resolve riskso Develop the next level of the

producto Customer evaluation of the

prototype This model consist of

characteristics from all modelsthat we discussed

Iteration takes place along thespiral

Uses prototyping as a riskreduction 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 phaseso Determine objectives, Identify

alternativeso Evaluate alternatives, identify and

resolve riskso Develop the next level of the

producto Customer evaluation of the

prototype This model consist of

characteristics from all modelsthat we discussed

Iteration takes place along thespiral

Uses prototyping as a riskreduction 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 phaseso Determine objectives, Identify

alternativeso Evaluate alternatives, identify and

resolve riskso Develop the next level of the

producto Customer evaluation of the

prototype This model consist of

characteristics from all modelsthat we discussed

Iteration takes place along thespiral

Uses prototyping as a riskreduction mechanism It enables the developer to understand and react to the risk at each evolutionally

level

WHAT HAPPEN IN GENERAL Initially the customer’s confident is very high Months after the project started

o There may not be any tangible output to show the customero That makes the customer un-happyo 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 Studyo Requirement Analysiso Requirement Definitiono Requirement Specification

Let’s have a look at the entire process as a whole.

THE REQUIREMENT ENGINEERING PROCESS

Above picture illustrates the mainactivities of RequirementEngineering process

Main activities are distinguishedwith rounded boxes in light blue

It also illustrate relationshipsbetween these activities

It shows documents produced ateach stage of the requirementsengineering process

Lets have a look at each of thesemain 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 costo In less time durationo Quality of the study should remain high

Outcomes of a Feasibility Studyo Cost effectiveness of the proposed systemo 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 isworth 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 don’t 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 requiremento Resolve

Anomalies –Irregular Conflicts – Clashing of opposed interest Inconsistencies – Firmness (how steady) In gathered requirement

Example of inconsistencyo 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 user’s 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 Understandableo Consistenceo Unambiguouso 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 partieso 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 DOCUMENTo Functional Requirements

Functional Partitioning Functional Description Control description

o Non-Functional Requirementso 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 DOCUMENTo Functional Requirements

Functional Partitioning Functional Description Control description

o Non-Functional Requirementso 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 DOCUMENTo Functional Requirements

Functional Partitioning Functional Description Control description

o Non-Functional Requirementso 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 extremeprogramming?

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 developmento 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 thesystem.

EXTREME PROGRAMMING (XP)

Do you believe that there is a relationship between the above picture and extremeprogramming?

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 developmento 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 thesystem.

EXTREME PROGRAMMING (XP)

Do you believe that there is a relationship between the above picture and extremeprogramming?

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 developmento 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 thesystem.

EXTREME PROGRAMMING PRACTICESPractice description

Incremental planningRequirements are recorded on Story Cards and the Stories tobe included in a release are determined by the time availableand their relative priority. The developers break these storiesinto development ‘Tasks’.

Small releasesThe minimal useful set of functionality that provides businessvalues is developed first. Releases of the system are frequentare incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirementsand no more.

Test-first developmentAn automated unit test framework is used to write tests for anew piece of functionality before that functionality itself isimplemented.

RefactoringAll developers are expected to refactor the code continuouslyas soon as possible code improvements are found. This keepsthe code simple and maintainable.

Pair programming Developers work in pairs, checking each other’s work andproviding the support to always do good job.

Collective ownershipThe pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers own allthe code. Anyone can change anything.

Continuous integrationAs soon as work on a task is complete it is integrated in to thewhole system. After any such integration, all the unit tests inthe system must pass.

Sustainable paceLarge amount of overtime are not considered acceptable as thenet effect is often to reduce code quality and medium-termproductivity.

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 anextreme programme process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.

STORY CARD Once the story cards have been

developed, the development teambreaks them down into tasks

Then estimates the effort and resourcesrequired 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, newstory cards are developed

New versions of the software may bebuilt 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 testso 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 PRACTICESPractice description

Incremental planningRequirements are recorded on Story Cards and the Stories tobe included in a release are determined by the time availableand their relative priority. The developers break these storiesinto development ‘Tasks’.

Small releasesThe minimal useful set of functionality that provides businessvalues is developed first. Releases of the system are frequentare incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirementsand no more.

Test-first developmentAn automated unit test framework is used to write tests for anew piece of functionality before that functionality itself isimplemented.

RefactoringAll developers are expected to refactor the code continuouslyas soon as possible code improvements are found. This keepsthe code simple and maintainable.

Pair programming Developers work in pairs, checking each other’s work andproviding the support to always do good job.

Collective ownershipThe pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers own allthe code. Anyone can change anything.

Continuous integrationAs soon as work on a task is complete it is integrated in to thewhole system. After any such integration, all the unit tests inthe system must pass.

Sustainable paceLarge amount of overtime are not considered acceptable as thenet effect is often to reduce code quality and medium-termproductivity.

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 anextreme programme process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.

STORY CARD Once the story cards have been

developed, the development teambreaks them down into tasks

Then estimates the effort and resourcesrequired 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, newstory cards are developed

New versions of the software may bebuilt 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 testso 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 PRACTICESPractice description

Incremental planningRequirements are recorded on Story Cards and the Stories tobe included in a release are determined by the time availableand their relative priority. The developers break these storiesinto development ‘Tasks’.

Small releasesThe minimal useful set of functionality that provides businessvalues is developed first. Releases of the system are frequentare incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirementsand no more.

Test-first developmentAn automated unit test framework is used to write tests for anew piece of functionality before that functionality itself isimplemented.

RefactoringAll developers are expected to refactor the code continuouslyas soon as possible code improvements are found. This keepsthe code simple and maintainable.

Pair programming Developers work in pairs, checking each other’s work andproviding the support to always do good job.

Collective ownershipThe pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers own allthe code. Anyone can change anything.

Continuous integrationAs soon as work on a task is complete it is integrated in to thewhole system. After any such integration, all the unit tests inthe system must pass.

Sustainable paceLarge amount of overtime are not considered acceptable as thenet effect is often to reduce code quality and medium-termproductivity.

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 anextreme programme process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.

STORY CARD Once the story cards have been

developed, the development teambreaks them down into tasks

Then estimates the effort and resourcesrequired 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, newstory cards are developed

New versions of the software may bebuilt 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 testso 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 systemo Download a preferred song from the interneto Renew your professional membership over the internet.

Guidelines to the exerciseo Write down the steps in point formo Describe each point as much as possible in your own wordso Read what you have written over to see your idea is clearly stated in the Story Card

TESTING IN EXTREME PROGRAMMINGImportant differences between iterative development and plan-based development is in the waythat the system is tested.

XP places more emphasis than other agile methods on the testing processo This is to avoid some of the problems of testing and system validation.

The key features of testing in XP areo Test-first developmento Incremental test development from scenarioso User involvement in the test development and validationo The use of automated test harnesses.

TEST-FIRST DEVELOPMENT

TESTING IN EXTREME PROGRAMMINGTest-first development and the use of automated test harnesses are major strengths of the XPapproach

Test-first developmento This is also known as test driven developmento This means writing tests before the developmento This is one of the most important innovations in XPo Implicitly defines both an interface and a specification of behavior for the functionalityo Problems of requirements and interface misunderstanding are reducedo 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

Advantageso Common ownership of the system. Entire team is responsible for the system defectso Act as a informal review processo 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.

Disadvantageo 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

Advantageso Common ownership of the system. Entire team is responsible for the system defectso Act as a informal review processo 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.

Disadvantageo 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

Advantageso Common ownership of the system. Entire team is responsible for the system defectso Act as a informal review processo 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.

Disadvantageo 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 datao Word Processor – Report template creation

A report generatoro 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 Menuo Set properties of a text boxo Use of data controlo 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 datao Word Processor – Report template creation

A report generatoro 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 Menuo Set properties of a text boxo Use of data controlo 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 datao Word Processor – Report template creation

A report generatoro 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 Menuo Set properties of a text boxo Use of data controlo Linking forms

APPLICATION LINKING

APPLICATION LINKING Advantages

o The main advantage of this approach is that a lot of application functionality can beimplemented 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 difficulto There may also be performance problems

Exampleo Word document having hyper linkso 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 beimplemented 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 difficulto There may also be performance problems

Exampleo Word document having hyper linkso 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 beimplemented 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 difficulto There may also be performance problems

Exampleo Word document having hyper linkso 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 forthis?

o To maintain Simplicityo Change of requirements can accommodate in next release.

In Xp testing is done at the end of system development (True/False)o False