V-Shaped SDLC Model

• A variant of the Waterfall that emphasizes the verification and validation of the product.
• Testing of the product is planned in parallel with a corresponding phase of development

​

V-Shaped Steps

• Project and Requirements Planning – allocate resources

​

• Product Requirements and Specification Analysis – complete specification of the software system

​

• Architecture or High-Level Design – defines how software functions fulfill the design

​

• Detailed Design – develop algorithms for each architectural component

• Production, operation and maintenance – provide for enhancement and corrections

​

• System and acceptance testing – check the entire software system in its environment

​

• Integration and Testing – check that modules interconnect correctly

​

• Unit testing – check that each module acts as expected

​

• Coding – transform algorithms into software

​

V-Shaped Strengths

• Emphasize planning for verification and validation of the product in early stages of product development
• Each deliverable must be testable
• Project management can track progress by milestones
• Easy to use

V-Shaped Weaknesses

• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in requirements
• Does not contain risk analysis activities

When to use the V-Shaped Model

• Excellent choice for systems requiring high reliability – hospital patient control applications
• All requirements are known up-front
• When it can be modified to handle changing requirements beyond analysis phase
• Solution and technology are known

​

Protoyping: Basic Steps

• Identify basic requirements
• Including input and output info
• Details (e.g., security) generally ignored
• Develop initial prototype
• UI first
• Review
• Customers/end –users review and give feedback
• Revise and enhance the prototype & specs
• Negotiation about scope of contract may be necessary

Dimensions of prototyping

• Horizontal prototype
• Broad view of entire system/sub-system
• Focus is on user interaction more than low-level system functionality (e.g. , databsae access)
• Useful for:
• Confirmation of UI requirements and system scope
• Demonstration version of the system to obtain buy-in from business/customers
• Develop preliminary estimates of development time, cost, effort

Dimensions of Prototyping

• Vertical prototype
• More complete elaboration of a single sub-system or function
• Useful for:
• Obtaining detailed requirements for a given function
• Refining database design
• Obtaining info on system interface needs
• Clarifying complex requirements by drilling down to actual system functionality

Types of prototyping

• Throwaway /rapid/close-ended prototyping
• Creation of a model that will be discarded rather than becoming part of the final delivered software
• After preliminary requirements gathering, used to visually show the users what their requirements may look like when implemented
• Focus is on quickly developing the model
• not on good programming practices
• Can Wizard of Oz things

Fidelity of Protype

• Low-fidelity
• Paper/pencil
• Mimics the functionality, but does not look like it

​

Fidelity of Protype

• Medium to High-fidelity
• GUI builder
• “Click dummy” prototype – looks like the system, but does not provide the functionality
• Or provide functionality, but have it be general and not linked to specific data

​

• http://www.youtube.com/watch?v=VGjcFouSlpk

​

• http://www.youtube.com/watch?v=5oLlmNbxap4&feature=related

​

Throwaway Prototyping steps

• Write preliminary requirements
• Design the prototype
• User experiences/uses the prototype, specifies new requirements
• Repeat if necessary
• Write the final requirements
• Develop the real products

Evolutionary Prototyping

• Aka breadboard prototyping
• Goal is to build a very robust prototype in a structured manner and constantly refine it
• The evolutionary prototype forms the heart of the new system and is added to and refined
• Allow the development team to add features or make changes that were not conceived in the initial requirements

Evolutionary Prototyping Model

• Developers build a prototype during the requirements phase
• Prototype is evaluated by end users
• Users give corrective feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype code is brought up to the standards needed for a final product.

​

EP Steps

• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements specification
• A prototype is built with basic and critical attributes
• The designer builds
• the database
• user interface
• algorithmic functions
• The designer demonstrates the prototype, the user evaluates for problems and suggests improvements.
• This loop continues until the user is satisfied

EP Strengths

• Customers can “see” the system requirements as they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates awareness of additional needed functionality

​

Incremental prototyping

• Final product built as separate prototypes
• At the end, the prototypes are merged into a final design

Extreme Prototyping

• Often used for web applications
• Development broken down into 3 phases, each based on the preceding 1
1. Static prototype consisting of HTML pages
2. Screen are programmed and fully functional using a simulated services layer
• Fully functional UI is developed with little regard to the services, other than their contract
3. Services are implemented

Prototyping advantages

• Reduced time and cost
• Can improve the quality of requirements and specifications provided to developers
• Early determination of what the user really wants can result in faster and less expensive software
• Improved/increased user involvement
• User can see and interact with the prototype, allowing them to provide better/more complete feedback and specs
• Misunderstandings/miscommunications revealed
• Final product more likely to satisfy their desired look/feel/performance

Disadvantages of prototyping 1

• Insufficient analysis
• Focus on limited prototype can distract developers from analyzing complete project
• May overlook better solutions
• Conversion of limited prototypes into poorly engineered final projects that are hard to maintain
• Limited functionality may not scale well if used as the basis of a final deliverable
• May not be noticed if developers too focused on building prototype as a model

Disadvantages of prototyping 2

• User confusion of prototype and finished system
• Users can think that a prototype (intended to be thrown away) is actually a final system that needs to be polished
• Unaware of the scope of programming needed to give prototype robust functionality
• Users can become attached to features included in prototype for consideration and then removed from final specification

Disadvantages of prototyping 3

• Developer attachment to prototype
• If spend a great deal of time/effort to produce, may become attached
• Might try to attempt to convert a limited prototype into a final system
• Bad if the prototype does not have an appropriate underlying architecture

Disadvantages of prototyping 4

• Excessive development time of the prototype
• Prototyping supposed to be done quickly
• If developers lose sight of this, can try to build a prototype that is too complex
• For throw away prototypes, the benefits realized from the prototype (precise requirements) may not offset the time spent in developing the prototype – expected productivity reduced
• Users can be stuck in debates over prototype details and hold up development process

Disadvantages of prototyping 5

• Expense of implementing prototyping
• Start up costs of prototyping may be high
• Expensive to change development methodologies in place (re-training, re-tooling)
• Slow development if proper training not in place
• High expectations for productivity unrealistic if insufficient recognition of the learning curve
• Lower productivity can result if overlook the need to develop corporate and project specific underlying structure to support the technology

Best uses of prototyping

• Most beneficial for systems that will have many interactions with end users
• The greater the interaction between the computer and the user, the greater the benefit of building a quick system for the user to play with
• Especially good for designing good human-computer interfaces

AGILE SOFTWARE DEVELOPMENT LIFE CYCLES

Agile SDLC’s

• Speed up or bypass one or more life cycle phases
• Usually less formal and reduced scope
• Used for time-critical applications
• Used in organizations that employ disciplined methods

​

Some Agile Methods

• Rapid Application Development (RAD)
• Incremental SDLC
• Scrum
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)
• Crystal Clear
• Dynamic Software Development Method (DSDM)
• Rational Unify Process (RUP)

Agile vs Waterfall Propaganda

• http://www.youtube.com/watch?v=gDDO3ob-4ZY&feature=related

RAPID APPLICATION DEVELOPMENT (RAD) MODEL

Rapid Application Model (RAD)

• Requirements planning phase (a workshop utilizing structured discussion of business problems)
• User description phase – automated tools capture information from users
• Construction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”)
• Cutover phase -- installation of the system, user acceptance testing and user training

Requirements Planning Phase

• Combines elements of the system planning and systems analysis phases of the System Development Life Cycle (SDLC).
• Users, managers, and IT staff members discuss and agree on business needs, project scope, constraints, and system requirements.
• It ends when the team agrees on the key issues and obtains management authorization to continue.

User Design Phase

•  Users interact with systems analysts and develop models and prototypes that represent all system processes, inputs, and outputs.
• Typically use a combination of Joint Application Development (JAD) techniques and CASE tools to translate user needs into working models. 
• A continuous interactive process that allows users to understand, modify, and eventually approve a working model of the system that meets their needs.

JAD Techniques

• http://en.wikipedia.org/wiki/Joint_application_design

​

CASE Tools

• http://en.wikipedia.org/wiki/Computer-aided_software_engineering

​

Construction Phase

•  Focuses on program and application development task similar to the SDLC.
• However, users continue to participate and can still suggest changes or improvements as actual screens or reports are developed.
• Its tasks are programming and application development, coding, unit-integration, and system testing.

Cutover Phase

• Resembles the final tasks in the SDLC implementation phase.
• Compared with traditional methods, the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner.
• Tasks are data conversion, full-scale testing, system changeover, user training.

RAD Strengths

• Reduced cycle time and improved productivity with fewer people means lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs
• Focus moves from documentation to code (WYSIWYG).
• Uses modeling concepts to capture information about business, data, and processes.

​

RAD Weaknesses

• Accelerated development process must give quick responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

​

When to use RAD

• Reasonably well-known requirements
• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized