Term Paper of Principles of Software Engg

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 14

Term Paper

Of

Principles of Software Engg.

TOPIC: SOFTWARE PROTOTYPING

Submitted To- Submitted By-

Mr. Kirandeep singh Fairy

Roll no- 02

Sec- D2702
Reg no- 3470070011

ACKNOLEDGEMENT

I PAY MY GRATITUDE TOWARDS MY TEACHER Mr. DEEPAK VISHWAKARMA


WHO HAD GIVEN ME THE WORK TO MAKE TERM PAPER. WITHOUT HIS
CONSTANT PERSUASION IT COULD NOT HAVE BEEN POSSIBLE FOR ME TO
MAKE THE TERM PAPER.

LAST BUT NOT LEAST I AM VERY THANKFUL TO MY


FRIENDS AND MY TEACHER WHO REALLY COOPERATE ME AND HELP ME.THIS
PROJECT WITHOUT THEIR CONSTANT PERSUASION IT COULD NOT HAVE BEEN
POSSIBLE FOR ME TO COMPLETE THIS PROJECT.

THANKS TO ALL...........
Index

• Introduction

- What is Software Prototyping

- Types of Software Prototyping

- Benefits of Software Prototyping

• Further Research

- Software Prototyping

- Approaches to Prototyping

- Evolutionary Prototyping

- Prototypes as specifications

- Dimensions of Prototyping

- Methods
• Bibliography

INTRODUCTION

What Is Software Prototyping?

The idea behind software prototyping is to allow people who have some stake or interest in a
system to test drive designs, rather than having to interpret those designs based on some other
means. Though not all prototypes are interactive, but the most useful application of
prototyping is based upon providing a similation of some behaviour and functionality.
Types of Software Prototyping:-

There are many different approaches to prototyping, from the very simple sketches-on-a-post-
it to rich, fully interactive software simulations. However, we can classify these into three
main categories:

Wireframes/Paper Prototypes

Wireframes and Paper Prototypes are useful early-stage techniques, though limited in as
much as they are non-interactive and usually very broad. If our project were to be painting a
landscape, you might think of wireframes and paper prototypes as the early sketches on a
notepad, or some under-painting. In other words, suggesting the basic shape but not saying
much about the details. Though often simplistic, this style of prototype is useful because they
can be very quick to create and don't require so much technical expertise to put together.

Visual Prototypes

These often come in the form of screen mock-ups, perhaps in a paper form or created using a
graphics tool such as Adobe Photoshop. They offer an opportunity to prototype the look and
feel of a system design, though not normally any functionality or operational flows. They are
often visual mock-ups rather than true prototypes, in as much as they represent a useful tool
to demonstrate potential appearances and layouts. These typically come from a designer's
viewpoint rather than a business or software expert.

Interactive Prototypes

These are far more useful, though require an increased investment in time to create. They aim
to model a system design more faithfully, and represent actual paths through that system.
They generally will combine the visual aspects of a static prototype with a certain degree of
interactive functionality. This might mean navigation, or the use of real web controls, or even
mock data processing. As a platform for demonstrating a system, these are the richest, most
useful types of prototype, although the slowest to create.

We are advocates of Interactive Prototyping, especially in combination with business analysis


and user feedback sessions. However, there are times when the use of alternative approaches
makes more sense.

Benefits of Software Prototyping:-

The main benefit of software prototyping is in obtaining feedback on a proposed design at an


early stage in a project. This feedback can be used to help refine project requirements
specifications, establish usability and gain stakeholder support. Used properly, prototyping
provides a platform from which to base more accurate estimates for the subsequent phases of
a software development project.

Visualisation of a design is another benefit. We all know how difficult it is to picture an end-
product from a paper specification. By creating prototype models and simulations we can
improve our understanding of what is to be developed. Once a prototype has been created for
a project, it is easy for everyone to gain a 'sneak preview' of what the end system will look
like and what it will do. This is a very productive process as problems with a design are
usually much more obvious when a prototype is created, and can be addressed long before the
costly development phase starts.
FURTHER RESEARCH

Software Prototyping

Rapid software development to validate requirements

Objectives:

• To describe the use of prototypes in different types of development project


• To discuss evolutionary and throw-away prototyping
• To introduce three rapid prototyping techniques - high-level language development,
database programming and component reuse
• To explain the need for user interface prototyping

Prototyping is the rapid development of a system. The principal use is to help customers and
developers understand the requirements for the system

o Requirements elicitation – Users can experiment with a prototype to see how


the system supports their work
o Requirements validation – The prototype can reveal errors and omissions in
the requirements

Prototyping can be considered as a risk reduction activity.

Approaches to prototyping
Evolutionary Delivered
prototyping system
Outline
Requirements
Throw-away Executable Prototype+
Prototyping SystemSpecification

Evolutionary prototyping

• Must be used for systems where the specification cannot be developed in advance
o E.g., AI systems and user interface systems
• Based on techniques which allow rapid system iterations
• Verification is impossible as there is no specification
• Validation means demonstrating the adequacy of the system

Develop abstract Build prototype Use prototype


specification system system

Deliver YES System


system adequate?

• Specification, design and implementation are inter-twined


• The system is developed as a series of increments that are delivered to the customer
• Techniques for rapid system development are used such as CASE tools and 4GLs
• User interfaces are usually developed using a GUI development toolkit

Prototypes as specifications

• Some parts of the requirements may be impossible to prototype


o E.g., safety-critical functions
• An implementation has no legal standing as a contract
• Non-functional requirements cannot be adequately tested in a system prototype

Dimensions of prototypes

Horizontal Prototype

A common term for a user interface prototype is the horizontal prototype. It provides a
broad view of an entire system or subsystem, focusing on user interaction more than low-
level system functionality, such as database access. Horizontal prototypes are useful for:

• Confirmation of user interface requirements and system scope


• Demonstration version of the system to obtain buy-in from the business
• Develop preliminary estimates of development time and cost

Vertical Prototype

A vertical prototype is a more complete elaboration of a single subsystem or function. It is


useful for obtaining detailed requirements for a given function, with the following benefits:

• Refinement database design


• Obtain information on data volumes and system interface needs, for network sizing
and performance engineering
• Clarifies complex requirements by drilling down to actual system functionality

Methods

There are few formal prototyping methodologies even though most Agile Methods rely
heavily upon prototyping techniques.

Dynamic systems development method


Dynamic Systems Development Method (DSDM) is a framework for delivering business
solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001
approved. It expands upon most understood definitions of a prototype. According to DSDM
the prototype may be a diagram, a business process, or even a system placed into production.
DSDM prototypes are intended to be incremental, evolving from simple forms into more
comprehensive ones.

DSDM prototypes may be throwaway or evolutionary. Evolutionary prototypes may be


evolved horizontally (breadth then depth) or vertically (each section is built in detail with
additional iterations detailing subsequent sections). Evolutionary prototypes can eventually
evolve into final systems.

The four categories of prototypes as recommended by DSDM are:

• Business prototypes – used to design and demonstrates the business processes being
automated.
• Usability prototypes – used to define, refine, and demonstrate user interface design
usability, accessibility, look and feel.
• Performance and capacity prototypes - used to define, demonstrate, and predict
how systems will perform under peak loads as well as to demonstrate and evaluate
other non-functional aspects of the system (transaction rates, data storage volume,
response time, etc.)
• Capability/technique prototypes – used to develop, demonstrate, and evaluate a
design approach or concept.

The DSDM lifecycle of a prototype is to:

1. Identify prototype
2. Agree to a plan
3. Create the prototype
4. Review the prototype

Operational prototyping

Operational Prototyping was proposed by Alan Davis as a way to integrate throwaway and
evolutionary prototyping with conventional system development. "[It] offers the best of both
the quick-and-dirty and conventional-development worlds in a sensible manner. Designers
develop only well-understood features in building the evolutionary baseline, while using
throwaway prototyping to experiment with the poorly understood features."

Davis' belief is that to try to "retrofit quality onto a rapid prototype" is not the correct
approach when trying to combine the two approaches. His idea is to engage in an
evolutionary prototyping methodology and rapidly prototype the features of the system after
each evolution.

The specific methodology follows these steps:

• An evolutionary prototype is constructed and made into a baseline using conventional


development strategies, specifying and implementing only the requirements that are
well understood.
• Copies of the baseline are sent to multiple customer sites along with a trained
prototyper.
• At each site, the prototyper watches the user at the system.
• Whenever the user encounters a problem or thinks of a new feature or requirement,
the prototyper logs it. This frees the user from having to record the problem, and
allows them to continue working.
• After the user session is over, the prototyper constructs a throwaway prototype on top
of the baseline system.
• The user now uses the new system and evaluates. If the new changes aren't effective,
the prototyper removes them.
• If the user likes the changes, the prototyper writes feature-enhancement requests and
forwards them to the development team.
• The development team, with the change requests in hand from all the sites, then
produce a new evolutionary prototype using conventional methods.

Obviously, a key to this method is to have well trained prototypers available to go to the user
sites. The Operational Prototyping methodology has many benefits in systems that are
complex and have few known requirements in advance.

Evolutionary systems development


Evolutionary Systems Development is a class of methodologies that attempt to formally
implement Evolutionary Prototyping. One particular type, called Systemscraft is described by
John Crinnion in his book: Evolutionary Systems Development.

Systemscraft was designed as a 'prototype' methodology that should be modified and adapted
to fit the specific environment in which it was implemented.

Systemscraft was not designed as a rigid 'cookbook' approach to the development process. It
is now generally recognised[sic] that a good methodology should be flexible enough to be
adjustable to suit all kinds of environment and situation…

The basis of Systemscraft, not unlike Evolutionary Prototyping, is to create a working system
from the initial requirements and build upon it in a series of revisions. Systemscraft places
heavy emphasis on traditional analysis being used throughout the development of the system.

Evolutionary rapid development:-

Evolutionary Rapid Development (ERD) was developed by the Software Productivity


Consortium, a technology development and integration agent for the Information Technology
Office of the Defense Advanced Research Projects Agency (DARPA).

Fundamental to ERD is the concept of composing software systems based on the reuse of
components, the use of software templates and on an architectural template. Continuous
evolution of system capabilities in rapid response to changing user needs and technology is
highlighted by the evolvable architecture, representing a class of solutions. The process
focuses on the use of small artisan-based teams integrating software and systems engineering
disciplines working multiple, often parallel short-duration timeboxes with frequent customer
interaction.
Key to the success of the ERD-based projects is parallel exploratory analysis and
development of features, infrastructures, and components with and adoption of leading edge
technologies enabling the quick reaction to changes in technologies, the marketplace, or
customer requirements.
To elicit customer/user input, frequent scheduled and ad hoc/impromptu meetings with the
stakeholders are held. Demonstrations of system capabilities are held to solicit feedback
before design/implementation decisions are solidified. Frequent releases (e.g., betas) are
made available for use to provide insight into how the system could better support user and
customer needs. This assures that the system evolves to satisfy existing user needs.

The design framework for the system is based on using existing published or de facto
standards. The system is organized to allow for evolving a set of capabilities that includes
considerations for performance, capacities, and functionality. The architecture is defined in
terms of abstract interfaces that encapsulate the services and their implementation. The
architecture serves as a template to be used for guiding development of more than a single
instance of the system. It allows for multiple application components to be used to implement
the services. A core set of functionality not likely to change is also identified and established.

Why prototyping is fundamental:-

 The prototype provides a vehicle for systems engineers to better understand the
environment and the requirements problem being addressed.
 A prototype is a demonstration of what's actually feasible with existing technology, and
where the technical weak spots still exist.
 A prototype is an efficient mechanism for the transfer of design intent from system
engineer to the developer.
 A prototype lets the developer meet earlier schedules for the production version.
 A prototype allows for early customer interaction.
 A prototype demonstrates to the customers what is functionally feasible and stretches
their imagination, leading to more creative inputs and a more forward-looking system.

 The prototype provides an analysis test bed and a vehicle to validate and evolve system
requirements.
BIBLIOGRAPHY

WEB SITES:

 www.google.co.in
 www.wikipedia.com
 www.wisegeek.com
 www.softpanorama.org
 http://woorisol.kyungpook.ac.kr/lab/prof/SoftEng/ch8.htm
 www.reynardthomson.com

OTHERS:

 Principles of software Engg. , Pressman


 Software Engg., Ian Somerville
 Software Prototyping, Reynard Thomson

You might also like