Embed Size (px)
DESCRIPTION
Citation preview
Information Architecture Web Services Methodology
Definition and guidelines document
Document Details
Document name INSITE-SDLC
Author Andy Williamson,
Wairua Consulting
Revision 2.00
Wairua Consulting PO Box 60-517
Titirangi
Waitakere City
Aotearoa/New Zealand
Telephone +64 (0)9 817 1133
Fax +64 (0)9 817 1103
Email [email protected]
www.wairua.com
Legal Notice Copyright © Wairua Consulting 1999-2001. All rights
reserved.
This document and its associated components are provided
under license and remain the property of Wairua Consulting.
Authorised users are granted a non-exclusive license to use
the contents of this document and any associated
documentation and/or intellectual property. The conditions of
this license mean that you must not copy, distribute, sub-
license or resell this product. Wairua Consulting accepts no
responsibility for the direct or indirect consequences of using
this material. E&OE.
Insite Information Architecture Web Services Methodology,
INSITE, Wairua Consulting and the Cabbage Tree logo are the
property of Wairua Consulting and are not to be used without
permission
CONFIDENTIAL
Revision 2.00 i
Contents
Document Details i
Legal Notice i
Introduction 1 Background.......................................................................................................................1 Principles for the New Economy .......................................................................................2 Information Architecture...................................................................................................5 How to use this Document ................................................................................................7
Methodology Overview 8 Scope.................................................................................................................................9 Exclusions ..........................................................................................................................9 Team Building.................................................................................................................11 Client Involvement ..........................................................................................................12
Steering group ..................................................................................................................................12 User and Customer involvement........................................................................................................12 Managing changes and feedback ......................................................................................................13
Stage 1 — Define 14 Clearly Defined Goal ......................................................................................................14 Define the Objectives......................................................................................................14 Ensure the Project is Scoped ...........................................................................................14
Define any Exclusions ........................................................................................................................14 Document all Assumptions ................................................................................................................14 Record Measurable Success Criteria...................................................................................................15
Perform Risk Analysis .....................................................................................................15 Generic Risk Checklist .......................................................................................................................15 Specific Project Risks..........................................................................................................................16
Create a Work Breakdown Structure..............................................................................16 Tasks and Milestones.........................................................................................................................17 Skills/Resources.................................................................................................................................17
Document the Deliverables.............................................................................................17 Create a Project Plan ......................................................................................................17
Stage 2 — Design 18 Information Architecture Document ...............................................................................18
Goal and Objectives..........................................................................................................................19 Audience...........................................................................................................................................20 Use Case ..........................................................................................................................................23 Functional Requirements ...................................................................................................................24 Site Structure.....................................................................................................................................25 Architecture.......................................................................................................................................27 Client Interface .................................................................................................................................29
Project Structure..............................................................................................................31 Estimate ............................................................................................................................................31 Timeline............................................................................................................................................31 Resources..........................................................................................................................................32
Tools for Developing your IAD........................................................................................32 Workshops and Interviews .................................................................................................................32 Data Modelling .................................................................................................................................32 Workflow ..........................................................................................................................................33
External Specifications ....................................................................................................33 Stage 3 — Develop 34
Application Paradigm.....................................................................................................34 Selecting Development Tools..........................................................................................34
CONFIDENTIAL
Revision 2.00 ii
Version Control ...............................................................................................................34 Version Numbering ........................................................................................................35 Release Levels.................................................................................................................35 Architecture.....................................................................................................................36 Testing.............................................................................................................................36
User Acceptance Testing (UAT) ..........................................................................................................36 Test Scripts ........................................................................................................................................38 Error Tracking and Logging ...............................................................................................................39 Error Levels and Acceptable Rate .......................................................................................................39
Stage 4 — Deploy 40 Project Close-out .............................................................................................................40 Post-Implementation Review..........................................................................................40
Financial Review................................................................................................................................40 Project Review ...................................................................................................................................40
Project Management 42 Cost/Benefit Model..........................................................................................................42
Project Reporting 43 Attention Reporting ........................................................................................................43 Project Documentation....................................................................................................44
Quality Assurance 45
Risk Management 46 Identify ............................................................................................................................46 Assess..............................................................................................................................46 Manage...........................................................................................................................47 Product Evaluation..........................................................................................................47
Change Management 48 Documentation................................................................................................................48
Document Management 49 Standard Documents.......................................................................................................49 Non-Standard Documents ..............................................................................................49 Terminology ....................................................................................................................49 Naming Conventions ......................................................................................................50
Project Charter 51 Project Scope ....................................................................................................................................51 Deliverables ......................................................................................................................................52 Milestones.........................................................................................................................................52 Reporting ..........................................................................................................................................52 Quality Assurance .............................................................................................................................52 Methodology.....................................................................................................................................52 External Influences ............................................................................................................................52 Roles and Responsibilities ..................................................................................................................52 Risk Management Approach..............................................................................................................52
Appendices 53 Appendix A – Terminology..............................................................................................53 Appendix B – Test Script..................................................................................................54
Index 56
CONFIDENTIAL
Revision 2.00 iii
Table of Figures
Figure 1 - Four stages of INSITE..........................................................................................................................................8 Figure 2 - Cross-stage processes ........................................................................................................................................9 Figure 3 - INSITE Process Model .......................................................................................................................................10 Figure 4 - Roles and responsibilities..................................................................................................................................11 Figure 5 - Definition of roles.............................................................................................................................................12 Figure 6 - Generic risk Checklist .......................................................................................................................................16 Figure 7 - Specific project risk checklist outline..................................................................................................................16 Figure 8 - Audience map ..................................................................................................................................................21 Figure 9 - Relationship matrix ...........................................................................................................................................23 Figure 10 – Use case example ..........................................................................................................................................23 Figure 11 - Graphical site structure...................................................................................................................................26 Figure 12 - Functionality Matrix ........................................................................................................................................27 Figure 13 - Page layout grid .............................................................................................................................................30 Figure 14 – table of graphical elements ............................................................................................................................31 Figure 15 - Resource requirements ...................................................................................................................................32 Figure 16 - Test cycle........................................................................................................................................................37 Figure 17 - Error levels .....................................................................................................................................................39 Figure 18 - Cost/benefit analysis ......................................................................................................................................42
CONFIDENTIAL
Revision 2.00 iv
Introduction
INSITE is a web services methodology from Wairua Consulting that is based on
the principles of information architecture. INSITE introduces project managers,
web designers and software developers to a simple yet highly effective
methodology. By maintaining design integrity and INSITE helps to minimise
design flaws and human error during the specification, development and
deployment process of web-based services, ranging from simple web sites to
complex transactional platforms. INSITE addresses the often-overlooked issues
of re-usability and maintainability, aiming to introduce best practices to reduce
development cost and effort.
The philosophy behind INSITE is simple: do it quickly but get it right!
Information Architecture delivers real business advantage and improvement
through technology. It permits radical process change to occur accurately, safely
and quickly. It is not the aim of this methodology to tightly define exactly what
must be done, when, how and by whom. Rather, it is the role of the project team
members to work creatively and dynamically to deliver maximum value in the
shortest possible time. The methodology defines guidelines1, rather than
standards2 and remains neutral and unbiased towards specific operational
environments and development tools, since these are changing rapidly and
become quickly outdated. INSITE attempts to define a best practice model for
successful online, collaborative development.
Background
The impact of the Internet on information and communications technology (ICT),
not to mention the commercial world that ICT supports has been both dramatic
and revolutionary. In only a few short years, we have seen a radical change in the
way business and society operates and in the way software is developed. Perhaps
more radical still is the change in user expectations. This is a revolution that is
more than the sum of its technological parts. We stand today at a mid-point in
1 A guideline is a recommendation that indicates a best practice but adherence to this is suggested rather than enforced. 2 A standard is something that, unlike a guideline, you must do.
CONFIDENTIAL
Revision 2.00 1
the transition from the old-world supply-driven economy into the new world,
one which is customer-led and where “markets are conversations”3
The Internet has radically changed the way our society thinks, acts and functions;
it has changed the way people talk to people, businesses talk to each other and
the way citizens talk to government. The speed of change throughout this
revolution has been staggering. One only has to look at the banking industry to
see that the Internet is itself one of a number of catalysts for monumental changes
in business process and the environment in which organisations operate. Banks
entered the 1990s doing more or less what they had done for the last three
hundred years. They exited that decade coming to terms with pervasive
technologies that had eroded their traditional delivery channels and created new
ones, that had started the metamorphosis from a transaction based business into
one focused on customer service. Most importantly of all, banking was no longer
constrained in space and time but could happen anywhere and at any time4. It
isn’t over yet; with the onset of broadband data services, falling costs and
exploding technologies, the next ten years will see an even more dramatic
transformation in the way we use ICT. As Miller5 observed, “few dispute the
likelihood that within 20 years the Internet will become as generalised,
indispensable and taken for granted as today’s phone or electrical networks.”
INSITE does not directly address this revolution; rather it is concerned with
solving the problems that this has caused behind the scenes. To support these
new business modes, tools, applications and projects are transformed in this new
world.
Principles for the New Economy
The key to success in the new online world is the ability to adapt quickly.
Unfortunately, in terms of systems design, this has meant a return to anarchic
development, jettisoning traditional practices for the cut and thrust of a back-of-
a-beer mat specifications, where prototyping becomes little more than a
metaphor for “just do it”. As idyllic, exciting and fun as this might sound, the
Internet is not a giant playing field where anything goes and this approach is not
3 Siegel, D. (1999). Futurize your enterprise: Business strategy in the age of the e-customer. Danvers, MA: Wiley. 4 Darlington, L. (1998). Banking without boundaries: How the banking industry is transforming itself for the digital age. In D.
Tapscott, A. Lowy & D. Ticoll (Eds.), Blueprint to the digital economy . New York, NY: McGraw-Hill. 5 Miller, R. (1998). Cyberspace: The next frontier? In D. Tapscott, A. Lowy, & D. Ticoll (Eds.), Blueprint to the digital economy .
New York, NY: McGraw-Hill. pp.384
CONFIDENTIAL
Revision 2.00 2
a recipe for success. As a result we are seeing many projects delivering software
that is poorly designed, unreliable and inefficient. Ultimately it leaves businesses
with unforeseen expenses for maintenance and enhancements. Part of the
problem is that there has been a failure to develop, adapt and adopt
methodologies that work. Backtracking to the days of traditional development
methodologies is certainly not a realistic option; this would stifle creativity and
slow down the development and delivery cycle, gone are the days when the
technologists can huddle together for six months to develop a specification.
Development schedules today must talk in weeks and months, not months and
years. The second problem with traditional methodologies is that they are
technology-focused and we live in a different reality, one where the boundaries
between technologist, designer and marketer blur uneasily and then evaporate
altogether.
Our new reality is one where the only constant is rapid change and the road to
success is built on three principles:
Get close to your customer
Brand is everything
Technology is part of the problem
We no longer need ICT professionals with time-served apprenticeships in
specific languages and platforms, instead we need flexible, highly talented
individuals who can pick up the next hot tool and make it work. In the new,
networked economy the value proposition changes for both developers and
business, as speed to market becomes crucial and hesitation risks letting someone
else into a valuable market space. But remember that in this age your old
competitors might not be your biggest threat: start-up’s built from the ground up
to function in the new economy can come at established organisations
unexpectedly and the language of the new economy is one of cooperation,
integration and intermediation6.
The project deliverable must be what the customer wants, not what the business,
or worse still, the technologist, thinks the customer needs. Customers are people,
not demographics or abstract concepts. To deal with this, teams in the post-
revolutionary world must be cross functional and non-hierarchical, projects
6 Evans, P., & Wurster, T. (2000). Blown to bits: How the new economics of information transforms strategy. Boston, MA: Harvard
Business School.
CONFIDENTIAL
Revision 2.00 3
require input and skills from many areas, from pure technology through to
business analysis, process modelling and marketing. Teams are no longer tightly
bound units but flexible, adaptive and organic, they are made up of core skills
that can be supplemented by additional resources or specialists as required.
It is imperative that an Internet presence supports and accurately conveys the
organisations brand. This is of vital importance yet all to often website
development is left to ICT professionals who are unfamiliar with the issues
involved in delivering customer-facing applications. On the Internet your brand
is vital simply because of the vastness of cyberspace. It is very easy for your
brand to get lost in the enormity of the Internet and you need to ensure people
know you exist. Evidence is mounting that the best way to do this is actually
through off-web media and that online advertising and in particular banner
advertisements are not particular effective. Ironically, an increasing reliance on
traditional media to promote the online business channel increases the
importance of synergy between traditional and online branding.
The sheer pace of change can lead us to focus on technology but unfortunately
this means taking our eyes off the customer. We are here to solve business
problems and technology must remain an enabler in this process. When the
customer is ignored and technologists take over, technology can become part of
the problem. In all but exceptional circumstances, the customer does not care
about the technology you use, so long as it works and works in a way that works
for them. So, the angst in the backroom over a choice of Active Server Pages,
Cold Fusion or Java Server Pages is more often than not a waste of time and
energy. The real decision is on the overall platform that delivers the best solution
to the customer, and this includes seamless integration with internal legacy
systems and third parties. Trying to offer the latest technology just for the sake of
it is a recipe for failure.
The network is the business but there is more to delivering a service than the
network. An organisation needs to be fully cognisant of what technologies their
customers support and find acceptable, applicable and enjoyable. It is now
imperative that we understand the customer’s relationship with that network in
order to optimise the delivery of products and services.
CONFIDENTIAL
Revision 2.00 4
Information Architecture
A methodology derived from the principles of information architecture differs
fundamentally from traditional models of systems development; this is a
methodology focused on delivering what the customer wants. Traditional
development models focus on a lifecycle of months and years, where toolsets are
established and team members experienced. Traditional systems development
methodologies are about supporting business process. Information architecture
works well where project lifecycles are measured in weeks and months, where
toolsets are constantly changing and your most valuable staff will be the ones
who can adapt quickly. This is a world where systems development no longer
simply supports the business process but is an active ingredient in enabling
change. In a world filled with media, technologies and skills alien to traditional
ICT projects information architecture can provide an appropriate framework.
Whilst this approach has many similarities with prototyping methodologies,
information architecture goes beyond prototyping because of its focus on the
appropriate representation and management of information as well as the system
functionality associated with it.
Developing successful software applications for the Internet means developing
them quickly and deploying them fast. Fortunately, the environment that we
now work in allows us to achieve this by supporting rapid, dynamic projects
within an iterative development framework. Products are developed quickly and
delivered frequently and as a result the way business is transacted changes.
Product life expectancy is reduced as rapid development allows for incremental
releases and easy, centralised upgrade paths. And so it becomes an inherent
philosophy in the organisation that eighty percent of the business need must be
delivered with only twenty percent of the effort, in other words we are no longer
aiming for perfection but measured and measurable success.
Although we have now broken free of the logistical nightmares associated with
rolling out traditional distributed applications or mainframe systems, this has led
to a tendency amongst the developer community to mentally position Internet
development at the informal end of the methodology continuum. In many ways
this can be seen as a valid approach, since traditional methodologies add a level
of complexity and bureaucracy that is simply inappropriate and would stifle
creativity in the dynamic world of the Internet. However, this is a dangerous
approach, our Internet-based applications are often customer-facing, the first
CONFIDENTIAL
Revision 2.00 5
point of contact a potential customer might have with the business and,
increasingly, these systems are fully integrated into the corporate legacy
environment and running mission critical applications. There is simply no longer
any excuse for lax development attitudes in this field. What industry needs is
staff capable of delivering in this new, rapid fire, multidisciplinary environment,
of delivering excellence on a clear process that ensures quality is part of the
equation from day one. What we need are methodologies that are suitable for
delivering high-quality fast-turnaround Internet applications that perform.
It is imperative for designers and developers in the online world to remain
nimble-footed and reactive to customer wants, without being weighed down in a
torrent of formal specifications and change control processes. An approach to
Internet-based development based on information architecture, with its focus on
the user not the technology, offers an appropriate model for project managers,
web designers and software developers. It is an attempt to develop a simple yet
highly effective methodology where the project team is able to maintain design
integrity and hence minimises the flaws in the design process and human errors
during the specification, development and deployment processes. It also
attempts to address the often-overlooked issues of re-usability and
maintainability, aiming to introduce best practices that reduce development cost
and effort and recognising that a component-based architecture minimises
development cost and risk.
Information architecture, with its focus on how we organise, relate and represent
information is appropriate to the online medium and can be an important
building block in successful web site design. The starting point in an information
architecture-based design process is defining the audience (internal and external,
direct and indirect), what relationships exist and what it is this audience wishes
to do. It is the audience map and the user-scenarios that the architect creates that
will drive the development of the application, feeding into the definition of
functionality. Now that the project team understands who the customer is and
what it is they want to do, the architect can develop an organisational metaphor
that maps the virtual model to the physical organisation, and both functional and
visual metaphors to describe what the site will do and the look and feel and
branding needed to anchor the site appropriately online. Behind this front-facing
activity it is important to create good project processes and so a successful
Internet development methodology must also include project management, risk
management and quality assurance.
CONFIDENTIAL
Revision 2.00 6
In the online world, web developers must be user-focused to succeed the
customer-facing applications that we create must enhance existing branding to be
viable. The INSITE information architecture web services methodology from
Wairua Consulting allows organisations, project managers and web developers
to respond creatively, rapidly and with a deep understanding of who the
customer is, leading to the successful of online solutions. Because the Internet is
about delivering the information that your customer wants, when they want it
and how they want it, a flexible user-centric methodology such as INSITE
presents significant advantages over traditional developer-centric and
bureaucratic development methodologies.
How to use this Document
This document describes the full INSITE methodology, however it is not
anticipated that you will require the full methodology for all of your projects.
Ideally, a subset of the methodology can be used and this subset will be relative
to the size and complexity of the project and appropriate to your own toolsets
and organizational culture. Therefore, it is recommended that you use this
document as a detailed reference but not as an exhaustive guide to the exact
process to be followed.
CONFIDENTIAL
Revision 2.00 7
Methodology Overview
The INSITE Information Architecture Web Services Methodology is a four-stage
rapid application development (RAD) methodology for delivering internet-based
applications and services that is flexible, forward looking and cognisant of the
need to interface with legacy applications within an organisation.
The term “Internet-based” is used throughout this document to describe internal
(intranet) or external (Internet or extranet) applications and interfaces that use an
IP-based network as part of a delivery mechanism or channel. This includes web-
based applications, such as HTML, ASP, JSP or ColdFusion, thin client
applications, such as Java, and data-only interfaces and conduits, such as XML,
with third party applications (regardless of their nature of deployment).
Underpinning the success of this methodology are the principles of:
Customer Focus (user-centric model)
High-level specification and modelling
Iterative processes
Re-usability and emphasis on components
The four stages of the methodology are:
Figure 1 - Four stages of INSITE
CONFIDENTIAL
Revision 2.00 8
Five cross-cross stage processes, existing throughout the project life cycle,
support these stages:
Figure 2 - Cross-stage processes
Scope
INSITE is intended for use in planning, developing and implementing Internet-
based applications, their underlying architecture, platform and components,
interfaces (including middleware) between such applications and to/from legacy
or third party applications.
INSITE covers the development of static web-sites through to complex
transactional Internet applications with many interfaces to external and/or legacy
systems. However, to achieve this, the methodology is intended to be applied
with flexibility, using only the parts that are relevant to the current project and
environment.
Exclusions
The methodology does not define standards, guidelines or processes with regard
to the analysis, specification, development or modification of existing legacy or
third party applications, their architecture, platform and components. INSITE is
not toolset or platform specific and is designed to provide best-practice processes
regardless of the environment you choose.
CONFIDENTIAL
Revision 2.00 9
Des
ign
Def
ine
Dev
elo
pD
eplo
y
Cro
ss S
tag
e
Proj
ect
Def
initi
on
Goa
lO
bjec
tives
Scop
eEx
clus
ions
Risk
Info
rmat
ion
Arc
hite
ctur
eD
ocum
ent
Goa
ls a
nd O
bjec
tives
Func
tiona
l Req
uire
men
tsA
rchi
tect
ure
Clie
nt In
terf
ace
Dat
a M
odel
Dat
a de
finiti
ons
Tran
slat
ions
Doc
umen
t Ty
pe D
efin
ition
(D
TD)
Wor
kflo
w
Arc
hite
ctur
e
Proc
ure
Inst
all
Con
figur
e
Dev
elop
men
tTe
stin
gD
eplo
y
Inst
all
Supp
ort
Mai
ntai
n
Post
Impl
emen
tatio
nRe
view
ok
Proj
ect M
anag
emen
t
Cha
nge
Man
agem
ent
Risk
Man
agem
ent
Qua
lity
Ass
uran
ce
Doc
umen
t M
anag
emen
t
impr
ove
feed into IAD
Proj
ect P
lan
(Hig
h Le
vel)
Proj
ect P
lan
(Det
aile
d)Pr
ojec
t Pl
an(U
pdat
e ag
ains
t ac
tual
)
Syst
em t
est
Inte
grat
ion
test
Use
r A
ccep
tanc
e te
st
Cop
yrig
ht ©
200
0 W
airu
a C
onsu
lting
.
Clo
se-o
ut
Proj
ect P
ropo
sal
Proj
ect C
hart
er
Alte
rnat
ivel
y (f
or la
rger
proj
ects
)
Fig
ure 3
- IN
SITE
Pro
cess
Mode
l
C
ON
FID
ENTI
AL
Re
visi
on 2
.00
1 0
Team Building
The heart of any successful project is a team that is both motivated and resourced
to succeed. In the online world, two projects are seldom the same and the ideal
team is one that brings together the right skills at the right time and can learn
new skills together as they progress.
Roles and responsibilities will vary depending on the toolset and architecture
used, the size of the project and the culture of the organisation and INSITE makes
no attempt to prescribe an architecture or toolset to use but attempts to remain
flexible with the best of breed products for the environment that you are in.
There are a number of standard roles and responsibilities that will generally be
expected to exist within a project. This is not an exhaustive list, nor is it expected
that this list should be rigidly adhered to, since the aim of INSITE is to enhance a
team that is co-operative and focused on mutually agreed goals, rather than
prescribe what the team should look like. For example:
Figure 4 - Roles and responsibilities
CONFIDENTIAL
Revision 2.00 11
Where: Key Role
A Project Management
B Business requirements
C Process modelling/workflow
D Information architecture
E Data modelling
F Development
G Testing
H Deployment
I Maintenance
Figure 5 - Definition of roles
Client Involvement
Without the client there’s no project and since eBusiness is about getting close to
the customer (which in this case is both your client and their client!) then it
makes sense that the relationship with your client and their staff is going to be
critical to the success of the project.
Client involvement can occur at many levels, including:
Steering group This is usual the most senior committee within a project and will consist of
project sponsors within the client organization as well as the Project Manager
and other project staff as required. This should be the group of people that can
make decision, sign off on budgets, specifications and changes.
User and Customer involvement Talking with the users and other related people within the client firm is
important for two reasons. Firstly, it will help you to understand the business
problems that you are there to solve and, secondly, as you get to know people
and discuss their work with them, you start to gain an understanding for the
culture, politics and nuances of that organization. When you’re working on
eBusiness solutions, it’s not enough to simply talk to your client’s staff, you also
need to go out and talk to existing or potential customers.
This process of discussing the requirements with the potential end customer can
be a scary one for your client, particularly if they don’t have a close relationship
CONFIDENTIAL
Revision 2.00 12
with their customers. However it is vital that you do this, after all who
understands your requirements best, you or your own suppliers?
Managing changes and feedback One historical problem with any development approach that uses prototyping
and on lots of client involvement is that the client will invariably change their
mind, come up with new ideas and generally cause the project team major
headaches. This is normal and cannot be avoided, however it can be managed
and the reason changes and variations become a problem is because the project
isn’t structured to cope. If you have a clearly defined process of change
management and a clear specification, then it becomes a simple matter to decide
what changes are accepted and which are either postponed to “stage 2” or
rejected completely. One of the benefits of INSITE is that it provides a framework
for managing the team/customer interface and this issue will be addressed
throughout this document.
In the next four sections, each of the project stages is defined in detail and their
constituent parts explained.
CONFIDENTIAL
Revision 2.00 13
Stage 1 — Define
Phase one of the project is to define the project requirements and boundaries, in
terms of the business7. This is communicated through the Project Definition
document. Which will contain the following information:
Clearly Defined Goal
The project goal describes the overall project aim clearly and succinctly, such as
“to enable our customers to do business with us electronically so that it saves
them time and money.”
Define the Objectives
The project objectives describe in more detail what the desired project outcomes
are, in the context of the overall project goal. This is normally expressed in terms
of a deliverable, or deliverables, to the business or to the customer, for example:
To develop an internet-based interface for remote external users to submit
quotations.
Ensure the Project is Scoped
The scope clearly defines the project boundaries, in other words, what is
included within the context of this project. It is important that the scope is clearly
defined to ensure that a clear focus on a deliverable is achieved.
Define any Exclusions Clearly define exclusions and other elements that are outside the scope of the
project.
Document all Assumptions Document all the assumptions that have been made in producing the plan, this
document and in terms of the overall project. 7 This document should not address any technology issues except at a high level and then only where it is the technology that
is the business enabler.
CONFIDENTIAL
Revision 2.00 14
Record Measurable Success Criteria Define specific, tangible factors that can be used to measure the success of the
project. Examples include:
Delivery
Performance and Reliability
Security
User Response and Uptake
Cost reduction
Perform Risk Analysis
Risk Management is not a static function, it flows through the entire project life
cycle as issues arise and problems occur. Further information on the approach to
Risk Management to be used the project should be provided in the Project
Charter.
Generic Risk Checklist Use this generic model to give an overall picture of the project’s risk factors. It
can be used to compare the relative risks to an organisation of a number of
different projects.
Low (Yes) RISK (No) High
0 1 2 3 4 5 6 7 8 9
Inherent Risks
Project Objectives
Is the project small?
Is the project of minor importance to the
business?
Is the project functionally straightforward?
Are several parties able to define the requirements?
Is the subject area well documented?
Are preceding projects well documented?
User Organisation
Does the project maintain existing user procedures?
Is other organisational change unlikely during
the project?
Are the users grouped in one location?
Technology
Is tried hardware being used?
Is tried software being used?
CONFIDENTIAL
Revision 2.00 15
Low (Yes) RISK (No) High
0 1 2 3 4 5 6 7 8 9
Can custom programming being avoided?
Is the project technically straightforward?
Is the quality of existing data good?
Acquired Risks Scope and Approach
Is the project scope well defined and agreed?
Is the project approach well defined and agreed?
Project Organisation
Are people’s roles clearly defined?
Are users committed to the project?
Are staff able to commit sufficient time to the
project?
Are the required skills available?
Does backup exist for all members of the
project?
Are political and personal relationships good?
Is the project independent of third parties?
Can the design be achieved by a small group?
Can a “Big Bang” implementation be avoided?
Experience, Training and Support
Does the IT team know the technology?
Do the users know the technology?
Is the technology well supported?
Figure 6 - Generic risk Checklist
Specific Project Risks Identify specific risks that have been identified with regard to this project in the
following format:
Issue Probability Impact Schedule8 Issue/Action
Direct
Indirect
Figure 7 - Specific project risk checklist outline
See Risk Management on page 46 for more details.
Create a Work Breakdown Structure
Include a work breakdown structure (WBS), preferably in a graphical format.
8 The potential impact on the project schedule.
CONFIDENTIAL
Revision 2.00 16
Tasks and Milestones This tabular work breakdown structure should go to a deeper level and include
project milestones (show in italics) that were omitted from the graphical
representation. It should be supported by a Gantt Chart as an appendix.
Milestones will typically be points in the project that require sign-off to indicate
acceptance and before continuing to the next task, for example:
Definition Sign-off
Design sign-off
Testing Sign-off
Go Live
Full Launch
Skills/Resources Identified skills and resources required for the project. Ensure that this definition
includes skills and experience levels, the duration and quantity required.
Document the Deliverables
Describe the project deliverables, including documentation and services, such as
training.
Create a Project Plan
Create a project plan showing the major deliverables, the resources required and
the time/cost estimates. This plan forms an appendix to the Project Definition and
will be expanded upon to include detailed tasks in Stage 2.
See Project Management on page 42 for more details.
CONFIDENTIAL
Revision 2.00 17
Stage 2 — Design
The design stage enables rapid development of internet-based applications by
clearly identifying the business issues and requirements and then documenting
the technology platform to be used. The aim of this stage is to produce a high
level understanding of the issues and then to develop a road map toward the
solution. Unlike traditional waterfall methodologies, it is not the intention to
produce a highly detailed specification, which is then strictly adhered to. Rather
development takes place iteratively using an evolving prototype where the end
users are as involved in the process as the designer. Having said this, it is
important that sufficient analysis has been undertaken to ensure that workflow,
data mapping requirements and table structures are identified.
Information Architecture Document
Information Architecture describes the business requirements and the business
process and technology changes that are required to achieve that outcome. This is
done by way of the Information Architecture Document (IAD).
The purpose of the IAD is to ensure that:
the business processes are fully defined
the scope of the project is clearly defined and any exclusions have been
documented
the technology/human boundaries are defined and understood
opportunities and threats are identified
Information Architecture brings together four key areas of a successful Internet
project: Internet; IT; user interface design; marketing. The Information
Architecture Document contains the following sections:
Introduction
Goals and Objectives
Goals
Objectives
Scope
Exclusions
CONFIDENTIAL
Revision 2.00 18
Audience
Audience
Scenarios
Relationship matrix
Use cases
Market environment
Functional Requirements
Organisational metaphors
Functional metaphors
Visual metaphors
Business process
Business rules
Functionality Matrix
Content
Architecture
Platforms
Interfaces
Application Development
Client Interface
Navigation
Visual Design
Not every section will be appropriate for every project and it might be necessary
to introduce new sections or sub-sections to meet specific requirements. This
document is intended as a road map, not a detailed and exhaustive specification.
These sections are explained below:
Goal and Objectives This effectively summarise what is contained in either the Project Definition or
the Project Proposal, however, be aware that subtle (or even major) changes
could have occurred during the definition process. The goals and objectives
section lays out the fundamental requirements for the project under
development. It is important here to outline the key business drivers that support
the project in terms of:
CONFIDENTIAL
Revision 2.00 19
Goal
This is the project’s “mission statement” — a short paragraph that encapsulates
what the project is about. This might be: “To provide the widest range of New
Zealand literature online, at low cost to as wide an audience as possible”
Objectives
The objectives are usually a set of bullet points that expand on the goal. For
example:
To carry the widest range of NZ published books anywhere.
To increase the sales of NZ literature outside of New Zealand.
To support local writers and publishers.
To make buying easy.
To provide a range of flexible ordering options.
To build a community of interested people and become the meeting place for
that community.
Scope
Define the scope for the project so that it is unambiguous.
Exclusions
Clearly define any exclusions, such as changes to legacy systems.
Audience Describe and group the target audience or audiences and any other relevant
demographics for this product. This information is vital since who your audience
is will strongly determine the structure, appearance and culture of your site.
Identify your audience in terms of a direct, indirect or remote relationship with
the product. You can also identify a wider societal audience who, whilst not
directly involved as primary or secondary users of the product, might have
issues or influence over it. For example, if you were designing a drive through
service for a restaurant, your audience might look like this:
Direct Counter sales persons Driver
Indirect Car passengers Kitchen staff
Remote Street cleaners
CONFIDENTIAL
Revision 2.00 20
Societal Neighbours Local community
This can also be represented graphically, which has the advantage of allowing
you to define relationships between different audience groups:
Figure 8 - Audience map
When creating your audience list, brainstorm without analysing the list. Assign
categories and eliminate unnecessary detail later.
Scenarios
Scenarios describe realistic situations for a range of sample users (rather than
simply stating the requirements). Choose a range of sample users from the
audience groups defined above and describe the way you expect them to interact
with the product, what they are likely to be interested in, how they might expect
to find information/products/services and what would make them return.
Don’t just select direct audiences, try and create a broad range of scenarios. The
ultimate aim is to look at the product from the perspective of the end customer.
If you are unfamiliar with scenario development then these steps should assist
you (once you are familiar with the process, you will find that much of this
becomes automatic).
CONFIDENTIAL
Revision 2.00 21
Step 1 – Select role-play Be specific, such as “family ordering food for a picnic”.
Step 2 – Create a scenario Develop a complete scenario from beginning to end for the selected role-play.
Step 3 – Context Decide on a context for the scenario, such as “one child under 10 and one under 5” or “a hot, sunny afternoon”.
Step 4 – Create “what ifs” Create a list of possible situations that could arise in the scenario, for example their first order preference is not available or there is a wait on one of the orders.
Step 5 – Profile customer Determine what information you need to know about the customer.
Step 6 – Condense Steps 1 through 5 can be done on a large piece of paper or a whiteboard, once complete and you are satisfied with them, condense the results down into a single paragraph that captures the salient points. You might also like to add a table showing the information to capture.
The initial output from this process tends to be a list, which, for the example
above, might look like this:
Vehicle Driver Does not want to leave the car.
Wants minimum disruption or distraction for children.
Wants to order, pay and collect in a single location.
Has no cash.
Wants food well wrapped so that it doesn’t spill or mark in the car
In Step 6, you combine the key points from your list into a single scenario, which
takes the form a story:
Vehicle driver
Wants to be able to place an order, pay and collect in a single location, without leaving the
vehicle. They have no cash, so you (the vendor) must be able to accept Eftpos. Finally, the vehicle
driver does not want food and drinks spilt over their upholstery or greasy finger marks on the
trim.
Information required: order (items and quantity), payment method.
The story format is used because it lacks the implied priorities of a list and
because a story is a powerful way of conveying meaning. These stories can be the
combination of a number of scenarios of potential audience members. As you can
see from the example above, this process also allows you to determine what
information is required for this process to be carried out.
CONFIDENTIAL
Revision 2.00 22
Relationship Matrix
Now that you understand who your audience is, the next step is to map this
audience to the activities that they are likely to perform on the proposed site. The
purpose of this is to identify user intentionality: mapping business objectives to
the audience requirements and defining the path to best achieve this. This will
assist you in defining the functionality of the site and in understanding potential
options for site navigation.
AUDIENCE
ACTIVITY Visitor Customer
Gather information Product information
Whitepapers
Reviews Search
Order product Availability
Price
Delivery
Delivery status
Return purchase
Support Service levels Existing products
Legacy FAQ
Figure 9 - Relationship matrix
Use Case Use Case diagrams9 are a simple and effective way to graphically describe the
boundaries and interactions for the scenarios that you have identified and can be
used to identify relationships between audience members. For example:
Driver
Drive-thru ordering
Counter staff
Place order
Deliver order
Pay for order
Fulfil order
Figure 10 – Use case example
9 For information about Jacobson Use Cases, see Object-Oriented Software Engineering, by I. Jacobson (Reading, MA:
Addison-Wesley, 1992).
CONFIDENTIAL
Revision 2.00 23
Market Environment
Provide background information on the market conditions and competitive
issues that relate to this product. This section is generic to the marketplace.
Where there is a strong internal focus, describe the potential business
improvement and process improvement opportunities that can be achieved
through this product.
Competitive Analysis
Provide an analysis of a number of competitors in this market. Normally, this
would be competing online organisations but that is not always the case and this
could include competition in traditional “bricks and mortar” markets.
Competitive analysis is used to identify points of difference and opportunities, as
well as to support industry/market norms and expectations that have been
identified in the Market Environment section above. Highlight what works and
what does not work for a competitor and attempt to describe the culture.
Market Environment and Competitive Analysis are similar (although the latter is
more specific and detailed), because of this you might find that you only require one of
these two sections, depending on the nature of your project.
Functional Requirements This section is used to define the functional requirements for the product. It is
not, however, a traditional Functional Specification since the level of detail
required for an IAD is far less, placing a much greater emphasis on prototyping
and evolutionary product development.
Organisational Metaphors
This is mapping the physical organisation to the virtual. However, avoid the
temptation to merely recreate the org chart online as this will often fail. It is
important to understand how the customer would expect to view the
organisation and represent this, not how the organisation views itself.
Functional Metaphors
The functional metaphor relates to what you actually intend to do. This could be
purchase a product, order catalogues or find product information sheets. It is
how you translate physical activities into online actions.
CONFIDENTIAL
Revision 2.00 24
Visual Metaphors
The visual metaphors are the underlying look and feel of your site; the images
used to brand the corporate image online, define product sets and provide
navigation. Good visual metaphors are simple and mean something to the
visitor.
Business Process
This section describes the business processes that relate to this product. Ensure
that you clearly establish whether the process is “as is” or “to be” — since
electronic commerce is about changing business process, it is unlikely that the
process will remain the same after implementation.
Ideally, the business process should be shown diagrammatically.
Business Rules
Clearly describe any business/processing rules that apply to the affected
processes. This section should also address any legislative regulations that might
affect the product, such as minimum age or tax regulations.
Site Structure Developing a site structure listing invariably involves a brainstorming session
where team members can start to create the structure of the site. This might be on
a white board or by using PostIt™ notes (they have the advantage of being easily
movable!). The aim is to develop a directory and page structure that reflects the
organizational and functional metaphors with consideration to internal and
external links, usability and process flow.
A structural listing can be either textual:
Index page: www.house2home.com.au
Shop Floor
Decorating
Interiors
Garden
Timber
Trade
…
Shopping cart
Checkout
Order management
Services
CONFIDENTIAL
Revision 2.00 25
House2Home Professionals
Architects
Builders
Etc…
Or graphical:
www.house2home.co.nzwww.house2home.com.au
House2Home
Productcatalogue andonline sales
Shop floor Services Information About
Architects
Interior designers
Landscapers
H2H Professionals
Trade
Home handyman
MyHouse Projects
H2H Packages
Newsletters
Information sheets
History
People
Branches
Contact
Builders
Plumbers
Glazier
Decorating
Interiors
Outdoor
Garden
Timber
Trade
Checkout
Shopping cart
Order
Q&A
Figure 11 - Graphical site structure
Content Definition
Having defined the structure of the site, start to place more detail on each of the
sections. Define what each section will include, how it is to be maintained, who
has access and how often it will change. For example, here is an extract from an
IAD discussing the requirement for updated news content on the site:
News Stories
To make the site interesting and encourage return visits, the site must be kept up to date
with relevant news stories. The level of information published needs to enhance the visitor
experience and encourage them at the time or in the future to visit other parts of the site. It is
recommended that [company] publish information that is in the public domain or about to
become public and that enhances the reputation of [the company] in terms of implying a
level of expertise in that area.
The News section will contain main headlines (last 30 days) and an archive of previously
published stories. The main section should automatically display the latest headlines and
provide access to an archive page and search facility. A priority in the site design will be
CONFIDENTIAL
Revision 2.00 26
ensuring that stories can be added quickly without the need for HTML coding or site
uploading and that existing stories can be edited. It will also be a requirement to upload and
accurately place graphics with articles.
Functionality Matrix
This visually represents the relationship between audience activity and the
functional areas you defined above. The table below is used to indicate the
closeness of the relationship: a value of 1 means that the user must be able to
directly access this functional area when performing the said activity, 2 means
indirectly and 0 means there is no requirement.
FUNCTIONAL AREA
ACTIVITY Products Publications Ordering Support Search
Product information
1 2 1 1 2
Whitepapers 2 1 2 2 2 Ordering 2 3 1 2 2
Support 2 2 2 1 2
Search 1 1 1 1 1
Figure 12 - Functionality Matrix
The above table shows that when a visitor is in the “Products” area, they must be
able to immediately access product information and that more detailed
information such as a whitepaper or ordering the product must be only a single
click away.
Architecture Up until this point, the IAD has a strong business focus. From this point forward,
the focus shifts to defining the technology and the environment. For a large
project, this could involve creating two documents, however, ideally a single
document is retained for to present a complete picture to all parties.
Where the previous sections defined the reasoning behind the site and the
appearance of it, this section defines the physical site structure and the
technology required to support the site.
Include a systems architecture diagram here.
Platform
Describe the platform or platforms identified in the system architecture diagram
above. These could include:
CONFIDENTIAL
Revision 2.00 27
Application Server
Client (such as minimum browser feature set etc)
Database Server
Legacy Systems
Mail server
Middleware
Web server (including clustering, load balancing, redundancy etc)
Legacy Systems
Modification of legacy systems is usually outside the scope of an INSITE project,
however, the native environment should be described here for completeness.
Platform 1:n
Provide the following information (as appropriate and relevant) for each
platform shown in the architecture diagram:
Availability and Reliability
Connectivity
Extensibility and Flexibility
Maintainability
Performance
Scalability
Security
Systems Management
Network
Describe the network components identified on the System Architecture Diagram
above:
Standards and Protocols
Equipment (such as firewalls, routers etc)
Interfaces
Define all of the system interfaces10 that exist and for each describe:
The interfaces between specific systems. 10 This could include manual interfaces if appropriate.
CONFIDENTIAL
Revision 2.00 28
The interfacing standard and protocols to be used.
Interfaces that exist could include:
Application Server to Client
Application Server to Database Server
Legacy Systems to Middleware
Middleware to Application Server
Application Development
Define the environment(s) for application development. This should include one
section for each environment and should link this environment to platform(s)
and/or interface(s). Examples of application development environments could
include:
Page design tools
Integrated Development Environments (IDE’s)
Databases
AppDev Environment 1:n
For each environment, describe:
Platform(s)
Tools
Components
Standards
Client Interface This section defines the boundaries, visual design and workflow and the image
sets that are to be used for the client-side of the project.
Navigation
Site Navigation
This describes navigation within the site as a whole and includes off-site linking.
This section needs to consider entry points, framing, top level menus, sub-section
navigation and site maps.
CONFIDENTIAL
Revision 2.00 29
Local Navigation
Local navigation describes how a user might navigate within a single section,
page or multi-part document. This might include page forward/back control,
internal hyperlinks and menus and returning to the top of a document.
Visual Design
The Visual Design structure defines the interface rules. This section should define
the standard typefaces, styles, sizes and colours. It also defines basic page and
graphics colours and styles.
Layout Grid
This section should include a layout grid demonstrating the graphical and textual
elements of all standard pages (if there are multiple page styles, develop one
layout grid per style).
Figure 13 - Page layout grid
Formatting Rules
Define any specific formatting rules for text and graphical elements, for example
Tables use <P> text, always align top/left, 0 Border.
CONFIDENTIAL
Revision 2.00 30
Graphics 0 Border , alt tag must be defined for all elements except spacers.
Graphical Elements
Define a list of all standard images that are to be used describing what they mean
and when they are to be used:
Usage Front page logo; all
documentation (including
rate charts and statements).
image/logo_lg.jpg (300 x 80)
Hyperlink /index.html
Usage Page heading on all pages.
image/logo_sml.jpg (175 x 35)
Hyperlink /index.html
Usage Navigate back to previous
page. image/nav_back.jpg (30 x 30) Hyperlink javascript:history.back()
Figure 14 – table of graphical elements
Project Structure
Include in your IAD a definition of the project boundaries, timeframe and
resource requirements, including:
Estimate Define the time and cost estimate. It can be useful to show this as a high, low and
mean by tasks, grouped according to functional areas, although this could
depend on the project and the client’s expectations/practices.
Timeline Define start, milestones and finish dates, based on the elements in the project
time and cost estimate. Once a baseline has been established progress and
variations should be managed against this.
This should take the high level project plan developed in stage 1 and refine it, adding
more detail and reducing contingency.
CONFIDENTIAL
Revision 2.00 31
Resources Identify resources required in terms of numbers, skill set and timeframes.
Role Timeframe Number Skills
Information Architect 1 month from start 1 INSITE, RUP
HTML developer 4 months 2 HTML layout and design
Macromedia Dreamweaver Macromedia Fireworks
Graphic artist 2 months 1 Macromedia Fireworks Adobe Photoshop
ASP developer 2 months 1 Significant ASP experience
Macromedia Drumbeat 2000
Junior ASP
Developer
4 months 1 Some ASP knowledge
Figure 15 - Resource requirements
Tools for Developing your IAD
For the following tools and techniques can be useful when you are developing
and IAD:
Workshops and Interviews Where your customer base is diverse, it can be useful to conduct review sessions
or one-on-one interviews with a range of users. Before carrying out such sessions,
it is important that you clearly understand the objectives and have sufficient
information to present to the participants to stimulate discussion. Since, a key
objective of these workshops is to understand what the customer wants, an
appropriate use of the results is the generation of scenarios.
Data Modelling Modelling structures for database, XML and other interface formats can take the
form of:
Data definition
Document Type Definition
Translation
The resultant Data Model should be included as an appendix in the IAD.
CONFIDENTIAL
Revision 2.00 32
Workflow Workflow can be described either diagrammatically (with use case or swim lane
diagrams) or textually in the form of a table.
The resultant Workflow should be included as an appendix in the IAD.
External Specifications
An external specification is any specification that defines changes that are
required to an application or platform that is outside the scope of this
methodology.
For example, changes to legacy system functionality could be required as part of
the greater scope of a specific phase or project, however, such changes must
follow their own methodology and process, not this one.
Where such specifications do exist, they should be included as an appendix in the
IAD to ensure that there is sufficient visibility of the wider context.
CONFIDENTIAL
Revision 2.00 33
Stage 3 — Develop
Development takes an iterative, prototype approach, where the application is
developed based on the high level definition contained in the IAD and is
regularly reviewed by the target users to assess fit to requirements.
Application Paradigm
Such as:
Thin client application
Web browser
Thick client
Data conduit
Selecting Development Tools
An appropriate business case should be created for each product required. The
choice of development tools will be based on the following selection criteria:
Fit to existing/proposed architecture
Best of breed product
Team experience with product/availability of training
Cost
Version Control
The purpose of version control at the development level is to ensure that:
Development is taking place from a known and controlled starting point.
That starting point can be returned to or compared against.
Copies of the system in testing can be identified and errors attributed to a
particular version.
There is a clear and concise record of what changes have been made, by
whom and when they were released.
CONFIDENTIAL
Revision 2.00 34
Version control will be dependent on the platform and tools selected.
Version Numbering
All system versions will use a three part version numbering convention:
major.minor.maintenance (n.nn.nn)
For example,
Version 1.02.01
The three parts of the version number are defined as follows:
Major Means a significant upgrade to the application where
functionality has been significantly altered. Prior to full release (see definition below), the major version of the system will be 011, when it is first released, the application will be version 1.00.00. Note that when a major release is issued the minor and maintenance release numbers are reset to 0, for example Version 1.04.01 becomes Version 2.00.00.
Minor When modifications are made to existing functionality and new minor functionality is added, the minor release number changes and the maintenance release number is reset to 0. For example from 1.00.02 to 1.01.00.
Maintenance The final number in the version series indicates a maintenance release only.
Release Levels
There are three release levels for applications, indicating the state of
completeness and potential audience:
Alpha Effectively pre-release, this is the earliest version of the
application and likely to be used for prototyping purposes only. Alpha software is not complete, not tested and unsuitable for unsupervised use.
Beta This is the controlled release phase where development is fundamentally complete and some system testing has been carried out. The beta version will be provided to selected users for the purposes of User Acceptance Testing (UAT) (see page 36). It is important to clearly identify whether it is appropriate for a
11 Version 0.xx.yy is effectively used to indicate alpha or beta release status.
CONFIDENTIAL
Revision 2.00 35
beta application to be used in a live environment, operated in parallel or used solely in a user testing environment.
Full Release Full release means the application has been released into a live production environment and changes are now treated as maintenance (see Maintenance Releases on page 40).
Architecture
The systems architecture should be defined in a separate Systems Architecture
document. The systems architecture should be developed to conform with:
Existing organisational standards
Overall strategic direction for IT within the organisation
Organisational standards for eCommerce
Industry best practice and best of breed
A business case should be prepared for all hardware and software expenditure as
per organisational procedure. The detail of this will depend on the strategic
nature (or variance from agreed strategy) and cost of the equipment.
Testing
There are three types of testing that must be carried out:
Unit Testing Forms a part of the development process and is inherent in the
role of the developer. System Testing Is carried out internally within the project team to ensure that the
system is stable and operates correctly within the team’s context of the requirement.
User Acceptance Testing Is where the application is formerly tested by the end user in a realistic work setting. The purpose of UAT is to ensure that the business functionality is correct.
User Acceptance Testing (UAT) UAT puts the developed application through rigorous procedures designed to
replicate the live operation of the system and to verify that all components
accurately perform the required business and control functions. All conditions
and exceptions should be defined and tested for all known operating
environments, including the simulation of any manual procedures.
CONFIDENTIAL
Revision 2.00 36
Prior to commencing UAT, it is important to formally define:
What testing is to be carried out
The environment under which testing is to be carried out
What constitutes acceptance of the application for release
The resources (people and equipment) required
Secondly, a Test Package is created that contains:
A definition of all the tests to be carried out, describing the functional and
technical operation of the application.
Test Cycle
As Test Scripts are executed, errors and exceptions can be recorded on the form.
All errors are then entered into the Fault Tracking System (see Error Tracking and
Logging on Page 39).
Figure 16 - Test cycle
Review Mechanism
The results of UAT Test Scripts should be reviewed on a regular basis. This
review will determine the frequency and nature of errors being logged. Where
testing errors are found and the developer fails to rectify satisfactorily, these
should be referred to the Project Manager for review.
CONFIDENTIAL
Revision 2.00 37
A sign-off meeting should be held to review the acceptance testing and to
confirm that Acceptance Testing requirements have been met.
Testing Summary
There are a number of test approaches that can be undertaken.
Functional Test Functional Testing involves the testing of the various business
functions. It concentrates on ensuring that the system can be used to accomplish these business functions reliably, accurately, in a user-friendly way and in accordance with the IAD or any subsequent changes request.
Error Handling Test Error Handling Testing is used to determine the ability of the system to properly process incorrect transactions and exceptions. For example, audit trails, backup and recovery.
Regression Test Regression Testing is used to verify that no further problems have arisen as a result of changes made to one area of the system.
Integration Test Integration Testing involves the links between different component parts of the application to ensure that the correct data is being passed and returned. The Integration Test must prove that the new system performs according to the IAD and performs effectively in all operating environments. The accuracy of links between all programs in the system and any external interfaces must be verified here. It should be verified that any changes made do not create errors during processing of unchanged programs in external modules.
Stress Test This involves testing the system with large amounts of data that equal the maximum volume of the live data expected. Testing should be applied to many simultaneous users, extensive user sessions and other types of processing intended to stress the system.
Hardware Test This test verifies all the interfaces between the different hardware components of the system.
Documentation Test This defines the testing of any written material that is part of the system, such as data entry forms, user manuals, training instructions and any relevant system related documentation and includes indirect operational tests such as support and call centre.
Application Environment
This section identifies the version and location of the application to be used for
system testing and the exact operating environment or environments in which
testing is to take place.
Test Scripts Test scripts should be created for each specific test to be carried out. Test Scripts
define the purpose and outcome of the test and the exact actions to be taken. The
form allows the tester to record the results and any errors found.
CONFIDENTIAL
Revision 2.00 38
See page 53 for a sample Test Script form.
Error Tracking and Logging If the organization already has a well defined and effective fault tracking and
change request product, this can be employed in the project. Otherwise, a process
should be implemented that provides a simple and usable process for the project
manager, the users and the development team to:
Record faults raised during all phases of testing
Record change requests and modifications
The manage faults and changes through resolution, retest and release
To provide work summaries to development and test staff
Error Levels and Acceptable Rate Different error levels are defined based on their severity and on their impact on
the ability of the system to operate. For each of these levels, there is an acceptable
threshold of outstanding errors and recurrence that must be reached or exceeded
before the product can be considered for release.
Error Level Definition Outstanding12 New errors13
1 – Roadblock A critical error that means the user cannot
continue their task.
0 0
2 – High An error that stops the system performing
according to its requirement but for which there
is a sufficient workaround.
TBD TBD
3 – Medium An error that does not stop the system
performing but which impacts on the integrity of
the data or the output.
TBD TBD
4 – Low A minor or cosmetic error TBD TBD
Figure 17 - Error levels
With the exception of category 1 errors, these figures should be defined on a per-
project basis in consultation with the project sponsor, stakeholders and the team.
12 The maximum number of outstanding errors in this category allowed before release. 13 The maximum number of new errors in this category logged in the last week of testing. As testing progresses the number of
new errors should reduce dramatically, this column defines a level at which new errors being found is acceptable to release the product.
CONFIDENTIAL
Revision 2.00 39
Stage 4 — Deploy
The following components of the deployment stage are defined on a per-project
basis to ensure that the deployment is appropriate to the project, the technology
and the organisational culture:
Release Procedures
Sign-off
Rollout
Maintenance Releases
Project Close-out
The second part of the deployment stage is the project close-out. This is the
conclusion of the project and involves:
Successfully planned re-integration of internal staff back into client
organization.
Timely and appropriate release of project team.
Payment of all outstanding invoices and confirmation of all deliverables.
Project sign-off by stakeholders/project sponsor (as required).
Post-Implementation Review
Having completed and formally closed the project, the only task that remains is
to review the project to ensure that all possible lessons have been learnt and fed
back into the processes and methodology. Review can take two forms:
Financial Review Financial review can take place immediately and looks at the financial
performance of actuals versus estimates to determine the accuracy of the
estimating techniques, both within the project and amongst external suppliers.
Project Review This should be held over until the product has been live for a reasonable period
of time (normally three to six months but can be less). The purpose of this review
CONFIDENTIAL
Revision 2.00 40
is to validate that what was supposed to happen has happened, to obtain actual
cost savings and operational expenses and assess whether the project achieved its
objectives and why.
CONFIDENTIAL
Revision 2.00 41
Project Management
This section defines the processes for developing time and cost estimates, for
ensuring that time and cost spend is accurately recorded and for project reporting.
Cost/Benefit Model
The prototyping approach to development means that there is not a clear deliverable;
rather, once a time estimate has been developed, functionality is developed in order
of priority until that project window is either exhausted or extended. This means that
it is important to determine the relative importance and complexity of the proposed
functionality. To do this it is necessary to identify the tangible and the intangible
business benefits and complexity (cost):
Figure 18 - Cost/benefit analysis
A requirement to the left of the diagonal line indicates that the benefit exceeds the
cost (and it is therefore worth considering for inclusion).
Focus on delivering functionality that is low in complexity and high in benefit
first (area 1 above).
CONFIDENTIAL
Revision 2.00 42
Project Reporting
A project consists of two documentation and reporting types: Attention Reports These reports are produced regularly and represent a snap-shot
of the project in order to report progress or identify issues.
Project Documentation During the life of the project, a number of formal documents are produced. These are part of the formal life cycle and sign-off process of the project.
Attention Reporting
Initial Project Plan Created during the project definition stage, this high-level plan defines the timeframes, high-level resourcing and project integration needs.
Detailed Project Plan This plan is developed initially on completion of the project definition stage, at which time the Initial Project Plan is used to create a detailed project plan for the Design Phase. On completion of the Design Phase, the project plan is again refined to incorporate information gained during this stage and to show sufficient detail for the Project Manager to manage and report against for the remainder of the project. The Project Plan will be updated on a weekly basis to reflect time and cost spent and will be resource driven. A revised project plan will be presented to the Project Steering Committee (or equivalent) at each meeting.
Financial Analysis A summary of actual costs against budget. Maintained by the Project Manager, this report will be presented to the Project Steering Committee.
Risk Analysis A risk analysis model should be maintained and proactively managed by the Project Manager throughout the life of the project.
Issues Register Maintained by the Project Manager, this living document will list all issues raised during the life of the project. Cleared issues will be shown as such but will remain on the report. This report is presented to the Project Steering Committee.
Change Register This report will list requests modifications to any document or specification that has been signed off.
5/15 Report14 The Project Manager will be responsible for preparing a brief weekly report for the Project Sponsor, showing:
Comments
Work completed in last period
Work in progress
Work due to start next period
Issues (active subset of issue register)
14 This weekly report should take a maximum of fifteen minutes to write and five to read.
CONFIDENTIAL
Revision 2.00 43
Project Documentation
In addition to the above reports, the following project documentation will be
produced:
Phase Document
Project Definition or
Project Proposal
Define
Project Charter
Design Information Architecture Document
Test Plans
Test Scripts
User Documentation
Develop
Help Documentation
Deploy Marketing Material
CONFIDENTIAL
Revision 2.00 44
Quality Assurance
Whilst quality systems can be built, documented and managed, real quality is
achieved when it is inherent in the process and clear, effective communication
exists between all team members. Best quality practices should consist of peer-
reviews, mentoring and a commitment to delivering a quality product.
Formal Quality Assurance (QA) practices can and should be applied at all stages
of the project. QA takes the form of regular peer review sessions, the purpose of
which is to maintain an independent and objective perspective of the project so
as to offer advice and mentorship for the project team. For larger projects, an
external reviewer who is not otherwise engaged in the project can be used to
administer and facilitate the QA function and to add a fresh perspective to
potential issues.
CONFIDENTIAL
Revision 2.00 45
Risk Management
High level project risks are defined in the Project Proposal and it will be the role
of the Project Manager to identify and assess ongoing and additional risks prior
to and during each stage of the project. Whilst the Project Manager is expected to
be reasonably risk averse, this is difficult in an environment such as the Internet
and it is, therefore, expected that risk management within the project will be pro-
active and use the following three-stage approach:
Identify
Identify all the risks that could potentially influence the project outcome and
categorise:
Direct risk A risk that you have control over.
Indirect risk A risk that you do not have control over.
Assess
Having identified a risk, it must be quantified in the context of the project. To do
this, determine the probability of that risk occurring and the impact that it would
have on the project if it did occur. These are rated from 1 to 5, where:
Level Definition
1 Low
2 Minor
3 Moderate
4 Significant
5 High
CONFIDENTIAL
Revision 2.00 46
This simple scale is used because risks are always intangible to a greater or lesser
degree – you cannot define the chance of occurrence or the impact in absolutes15.
Once probability and impact have been determined, it is also important to
understand the impact that the risk will have on the project schedule and/or
budget, should it occur. The standard risk analysis template uses an xy graph to
represent probability and impact:
Manage
Once a risk has been identified, a policy or strategy needs to be defined to ensure
that it is kept under control. The key strategies for dealing with risk are:
Risk avoidance Change the project so that it is no longer impacted by the risk.
Risk transfer Change the project so that the risk becomes someone else’s (this could mean that all you have done is changed a direct risk into an indirect risk).
Risk acceptance Live with the risk by taking steps to reduce the probability or the impact of the risk (mitigation) and/or by determining a course of action to take should the risk be realised (contingency).
Do nothing None of the above strategies are available, appropriate or necessary. This is not the same as ignoring the risk, since it has already been identified and assessed.
Product Evaluation
Although not strictly risk analysis, a product evaluation matrix can be used to
identify the key requirements and then determine the “best fit” solution. A
product evaluation template exists that can be customised to suit your exact
requirements.
15 Rather, the cost to the project of determining absolutes outweighs the value of knowing.
CONFIDENTIAL
Revision 2.00 47
Change Management
This describes how changes to the project are managed and recorded. It covers all
the stages and includes both documentation and development.
Documentation
Documents, such as the Project Definition or the Information Architecture
Document (IAD), should contain a “Revision History” section that records the
releases of the document and a summary of the changes made. Documents such
as the IAD, which can change substantially during the life of a project, should
also contain a detailed change summary in the appendix. This should describe
the detail of the changes made to each version so that a full audit trail of the
documents history is available.
CONFIDENTIAL
Revision 2.00 48
Document Management
This section describes standard templates, naming and storage conventions for
project documentation.
Standard Documents
A number of standard document templates have been created and should be
used where appropriate, these include:
MS-Word
Project proposal
Project charter
Information architecture Document
INSITE Quick Map
MS-Excel
Risk analysis
MS-Project
Default plan
Visio
AudienceMap
SiteMap
Non-Standard Documents
Document templates have been set up so that you can create documents with a
consistent look and feel.
To mimic a formal document (such as this), use: Wairua/Document
To create an informal document, such as a brief report or discussion
document, use: Wairua/Informal
Terminology
The language used in this document and in other project documents can have
specific meaning in both a technical and a business context. It is often advisable
CONFIDENTIAL
Revision 2.00 49
to create a project glossary to define terminology and acronyms to ensure that
when an expression is used, it’s meaning is clear and unambiguous.
This document should contain both business and technical terms and, because it
is important that words are used appropriately, correctly and consistently, the
glossary should contain not only a definition but also an explanation of any rules
governing when and how the term can be used, for example:
ASP Application Service Provider
An organisation that hosts applications on an Internet accessible server on
behalf of clients. Spell out first time and beware of potential confusion with
Active Server Pages (ASP), Microsoft’s server based scripting environment.
Naming Conventions
All clients/projects will have their own shared workspace. This can be further
broken down into phased or topical subdirectories.
Directories should be named in a meaningful way to reflect the project and the
purpose, for example, the HNB Website rebranding project might look like:
HNB
Rebranding
Documents
Planning
Graphics
Development
Documents should be given consistent and meaningful names, such as:
Project charter.doc
IAD.doc
Client, project and phase identifiers can also be used, if you choose to use them
then they should be used for all documentation:
HNB_REBRAND_P1_Detail.mpp
HNB_REBRAND_P1_IAD.doc
HNB_REBRAND_P1_Site structure.vsd
CONFIDENTIAL
Revision 2.00 50
Project Charter
The Project Charter document can be used to define roles and responsibilities,
reporting requirements and project metrics for a project or group of projects. For
small to medium sized projects, it is usually acceptable to miss out this document
and instead include such information in an Information Architecture document,
in fact with smaller projects these issues are often ignored. It is also possible that
your client will already have a formal project framework, a project office or other
processes that will be used be default, again making the Project Charter
unnecessary.
Where a Project Charter is useful is in ring-fencing the work being undertaken to
ensure that everyone involved in the project at every level is clear about what
will is to happen and what their roles and responsibilities are. It is a particularly
useful document when working on a number of closely related projects,
especially if different teams area involved.
All of the information that is normally included in the Project Charter has already
been discussed, the purpose of this document is to place it all in a single centrally
located document that can be formally agreed upon and signed off before work
commences, that way ensuring that the project structure and aims are clear.
The Project Charter defines the deliverables, identifies the roles and
responsibilities and clearly states the overall project structure, reporting
requirements and management practices under which the project will operate.
Where a Project Definition (created at stage 1 of INSITE) defines what is to
happen, the Project Charter defines how it will happen and who is responsible
for making it happen. It contains the following sections:
Project Scope Re-iterate the project scope for completeness (do not assume that this document
will be read in conjunction with a Project Definition nor that the audience is the
same).
CONFIDENTIAL
Revision 2.00 51
Deliverables Re-iterate the project deliverables.
Milestones Define the key project milestones. Typically these will be points in the project
that require sign-off to indicate acceptance and before continuing to the next task,
for example:
Definition Sign-off
Design sign-off
Testing Sign-off
Go Live
Full Launch
Reporting Define the project reporting that will be used (based on the standards in this
document).
Quality Assurance Define how quality assurance is to be performed.
Methodology Define the methodology (this will INSITE).
External Influences Describe any external factors that could impact on the project in any way, what
that impact could be and how these will be managed.
Roles and Responsibilities Define all the roles along with responsibilities, reporting lines and signing
authorities, as appropriate. The clearer this section is, then the less confusion is
likely to arise during the project.
Risk Management Approach Define the risk management approach to be used (normally based on this
standard).
CONFIDENTIAL
Revision 2.00 52
Appendices
Appendix A – Terminology
Phase A project can consist of multiple phases. The term “phase” is used
here to define a complete iteration of INSITE, rather than the
component parts of the methodology, which are referred to as
“stages”.
Project A project encapsulates the four stages of INSITE into a single entity
that has a clearly defined purpose and identifiable completion point.
Stage One of the four parts of INSITE Methodology, such as Definition,
Design, Develop or Deployment
INSITE The Information Architecture/Systems Development Life Cycle
methodology as defined by Wairua Consulting.
CONFIDENTIAL
Revision 2.00 53
Appendix B – Test Script
PROJECT NAME
Test Script
Functional Area Test name Test ID
Page in Test Plan Purpose
Outcome
Actions
Action Option/Keystroke Expected Result � 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 28 19 20
Errors Encountered
Description of error Pty FTS # Re-tested (pass/fail)
Use additional paper if necessary (identify with Test # and date)
Comments and Observations
Testing Summary
CONFIDENTIAL
Revision 2.00 54
The tests described above were carried out and; ____ Passed ____ Passed with reservations ____ Failed Reservations/Reasons for failure
Tested by: _______________________________ Date: ________________________
CONFIDENTIAL
Revision 2.00 55
Index
CONFIDENTIAL
Revision 2.00 56
