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,
Download
Report
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