Transcript Systems Analysis I Prototyping & XP ISYS 200 Glenn Booker ISYS 200 Week #3 Prototyping   Prototyping is often a good tool for clarifying requirements of a system,

Systems Analysis I
Prototyping & XP
ISYS 200
Glenn Booker
ISYS 200
Week #3
1
Prototyping


Prototyping is often a good tool for clarifying
requirements of a system, and/or resolving
risks associated with developing a system
It generally helps determine the functional
requirements for users, especially associated
with the user interface
ISYS 200
Week #3
2
Prototyping

There are four major types of prototype




ISYS 200
Patched-up prototype
Nonoperational prototype
First-of-a-series prototype
Selected features prototype
Week #3
3
Patched-up Prototype



This is a functional prototype, but it works
very crudely or inefficiently
Based on the proof of concept prototype –
slap something together quickly that will
work well enough to tell if the idea is
technically feasible
Also can be used to determine if a given
technology is compatible with the system
ISYS 200
Week #3
4
Nonoperational Prototype


This is using a prototype more like a
storyboard
The interfaces are developed, but there’s
no actual code behind them


Like the façade of a building used on a movie set
Only helps with functional requirements, and
the general look and feel of the system
ISYS 200
Week #3
5
First-of-a-series Prototype



This is the development of a fully functional
pilot version of the system, in the hopes that
it will be close to the final product
Based on this prototype, the system is refined
and then produced en masse
Might be helpful for a physical installation,
such as a MAC terminal or information kiosk
ISYS 200
Week #3
6
Selected Features Prototype



The last kind of prototype is used to
completely develop a portion of the system
This avoids over committing to the design
before a user can approve its approach
Works well with an iterative life cycle


ISYS 200
Develop the core of the system with a couple
of working features
Then see if the users like it before the rest of
the system is added
Week #3
7
Prototyping

Notice for two kinds of prototype, the
prototype is not like the final product



Patched-up prototype
Nonoperational prototype
The other two kinds of prototype are
similar to the final product


ISYS 200
First-of-a-series prototype
Selected features prototype
Week #3
8
Prototyping vs. the SDLC


Some propose that prototyping can replace
the development life cycle
This isn’t practical in most cases, because



ISYS 200
Developing a First-of-a-series prototype is about
the same effort as following the SDLC to create
the same thing
Prototypes often use impromptu designs, which
couldn’t meet nonfunctional system requirements
Prototyping may stop the design process
prematurely
Week #3
9
Prototyping Guidelines

Guidelines for developing a “Selected
features prototype” include





ISYS 200
Estimate costs for creating the desired parts
of the system
Work in manageable modules
Build the prototype quickly
Modify the prototype iteratively; minimize coupling
Focus on the user interface; or users will hate
the system from the beginning
Week #3
10
Prototyping Disadvantages

It can be hard to distinguish between
finishing prototyping, and starting
development of the real system



Need to make sure the scope of prototyping
is clear
Users may view the prototype as the
end product
Users may wonder why the real system
takes so much longer than the prototype
ISYS 200
Week #3
11
Prototyping Advantages


Prototyping gives an opportunity to ensure
that the users’ needs are clearly translated
into system requirements
Prototyping helps clarify if the project is
reasonably close to the intended scope


Can stop funding the project if it isn’t fixable
Prototyping gives visibility into the
developer’s design concept, which
is often reassuring to the customer
ISYS 200
Week #3
12
Prototyping with COTS

COTS (Commercial, Off-The-Shelf) products
are used in almost every information system


ISYS 200
You don’t design custom motherboards, operating
systems, database management systems, etc. –
instead you use a commercially available product
Though an extreme example, even ERP
applications such as SAP and PeopleSoft could
be considered COTS products, even though they
are heavily customized
Week #3
13
Users and Prototyping


Analysts need honest, realistic involvement
from users, or prototyping will have no benefit
Users play a key role in prototyping



ISYS 200
Users should experiment with the prototype
Give qualitative feedback – do they like it,
and why or why not?
Give quantitative feedback – what features
are missing, hard to use, counter-intuitive,
not needed, etc.? Don’t ask for the impossible!
Week #3
14
Rapid Application
Development (RAD)



RAD is another method for speeding
development time, this time using
specialized development tools
Often used when time to market is critical
RAD uses three phases



ISYS 200
Requirements Planning Phase
RAD Design Workshop
Implementation
Week #3
15
Requirements Planning Phase



Users and analysts identify the objectives
of the system, and use that to determine
the information requirements
May involve high level business managers,
e.g. a CIO, as well as users and analysts
Focus is on solving the business problems
to meet goals
ISYS 200
Week #3
16
RAD Design Workshop

This is highly iterative between two activities



Work with users to design the system
Build the system
This may involve prototyping to build part of
the actual system, and refine it from user
feedback (selected features prototyping)

ISYS 200
Then repeat for all parts of the system
Week #3
17
RAD Implementation



Implementation here means putting the
system into operational use
Often RAD projects have no legacy system,
so there is no conversion strategy needed
If system features are sufficiently modular,
parts of it can be implemented when
completed, instead of waiting for the entire
system to be ready
ISYS 200
Week #3
18
RAD Tools


Most RAD tools are object oriented
Choice of tool may depend on the need
for client/server support



Microsoft Access doesn’t
Microsoft Visual Studio does
Often RAD applications are relatively
small and not mission critical
ISYS 200
Week #3
19
RAD vs. the SDLC

RAD has fewer management controls over a
project than a typical development life cycle



A key tradeoff is the opportunity for development
speed, versus the higher risk
RAD has less systematic validation of the
solution, so there is higher risk of missing
a key requirement, or using a weak design
RAD has little documentation, making the
application harder to maintain
ISYS 200
Week #3
20
When RAD is Good

RAD works well when




ISYS 200
Your developers are experienced using it
There are critical business reasons for
speeding development
Users can support the development process
The possible gains are worth the additional risks
Week #3
21
Extreme Programming (XP)

Extreme Programming is one of a family of
“agile” development methods which includes




Scrum
DSDM
Evo
And others
Please note that the linked file has copyright by the Software Productivity Consortium.
ISYS 200
Week #3
22
Extreme Programming (XP)

Agile projects



ISYS 200
Attack small but complex problems
Must balance cost and time-to-market against
product features and design robustness
Operate in poorly defined, dynamic markets
Week #3
23
Extreme Programming (XP)



Extreme Programming tries to accelerate
the development life cycle through rapid
feedback and incremental development
XP allows and encourages changes to occur
Four values and five principles define the
foundation of extreme programming
ISYS 200
Week #3
24
Four XP Values




Open communication to identify and fix
problems as early as possible
Strive for simplicity, both in design, and in
the approach to defining tasks (KISS)
Encourage clear, specific feedback
Have the courage to admit mistakes, and
follow your instincts
ISYS 200
Week #3
25
Five XP Principles


Provide rapid feedback (sound familiar?)
Assume the simplest solution




Contradicts normal practice to plan for future
enhancements
Accept incremental change, hence avoid
sweeping changes
Embrace change as a good thing to help
the project adapt
Perform quality work
ISYS 200
Week #3
26
Four XP Activities

XP includes activities you’d expect from
any software life cycle




Design – here, evolutionary design is normal
Code
Test – here, automated testing is assumed
But it also includes listening, to help
overcome the relative lack of documentation

ISYS 200
Listen to other developers, and the customer
Week #3
27
Four XP Resource Controls

XP has the same kinds of resources any
other project has:





Time (schedule)
Scope of the product (its features)
Cost (related to the amount of effort)
Quality
Planning for XP development needs to
balance these resources to meet the project’s
needs and customer’s wishes (we hope)
ISYS 200
Week #3
28
Four XP Core Practices

XP is best known for its core practices




Short releases – some features now, others later
Forty-hour workweek – don’t burn out
your developers!
Onsite customer – to make all that
communication possible
Pair programming – develop code in pairs, so
everyone can quickly have peer reviews

ISYS 200
Change pairs frequently to keep objectivity intact
Week #3
29
XP Development Process

XP has a life cycle (p. 77), with these phases





ISYS 200
Exploration the concept
Planning
Conduct many iterations until you get to the first
release
Productionizing – build the rest of the system in
more iterations
Maintenance – leading back to planning
improvements
Week #3
30
XP Stories


XP captures requirements in oral stories
Each story describes a type of user activity
which the system will need to support




ISYS 200
Also known as scenarios
They are used as the basis for estimating the
project resources needed
Stories are simplified “use cases”, which you’ll
see expressed in much more detail in ISYS 355
A system may have dozens or 100’s of stories
Week #3
31
XP vs. RUP

XP has many similarities to the Rational
Unified Process (RUP), which is covered
in ISYS 420



ISYS 200
Both develop the system architecture and
implement high risk features first, then mass
produce the low risk features
Both are iterative and use short release cycles
Both try to speed development compare to a
traditional life cycle (SDLC)
Week #3
32
XP Tools

XP was originally developed in a Smalltalk
tool called SUnit


Now a Java equivalent exists, JUnit, and other
variants like DUnit (for Borland’s Delphi)
XP was designed to be independent of its
development environment, since tools
change quickly

ISYS 200
See sourceforge.net for open source
development tools
Week #3
33