Information Architecture Web
Services Methodology

Definition and guidelines document
Document       Document name            INSITE-SDLC
                                             Author                   ...
Contents
Document Details                                                                                                 ...
Version Control .............................................................................................................
Table of Figures

Figure 1 - Four stages of INSITE...........................................................................
Introduction
                INSITE is a web services methodology from Wairua Consulting that is based on
                ...
the transition from the old-world supply-driven economy into the new world,
                one which is customer-led and ...
a recipe for success. As a result we are seeing many projects delivering software
                that is poorly designed,...
require input and skills from many areas, from pure technology through to
business analysis, process modelling and marketi...
Information Architecture
A methodology derived from the principles of information architecture differs
fundamentally from ...
point of contact a potential customer might have with the business and,
increasingly, these systems are fully integrated i...
In the online world, web developers must be user-focused to succeed the
customer-facing applications that we create must e...
Methodology Overview
    The INSITE Information Architecture Web Services Methodology is a four-stage
    rapid applicatio...
Five cross-cross stage processes, existing throughout the project life cycle,
support these stages:




                  ...
Define                              Design                                                 Develop                        ...
Team Building
The heart of any successful project is a team that is both motivated and resourced
to succeed. In the online...
Where:
                       Key   Role
                        A    Project Management
                        B    Busi...
with their customers. However it is vital that you do this, after all who
understands your requirements best, you or your ...
Stage 1 — Define
               Phase one of the project is to define the project requirements and boundaries, in
        ...
Record Measurable Success Criteria
Define specific, tangible factors that can be used to measure the success of the
projec...
Low (Yes)                     RISK            (No) High
                                                                  ...
Tasks and Milestones
This tabular work breakdown structure should go to a deeper level and include
project milestones (sho...
Stage 2 — Design
    The design stage enables rapid development of internet-based applications by
    clearly identifying ...
Audience
           Audience
           Scenarios
           Relationship matrix
           Use cases
           Market en...
Goal
This is the project’s “mission statement” — a short paragraph that encapsulates
what the project is about. This might...
Societal              Neighbours
                                    Local community


This can also be represented graphi...
Step 1 – Select role-play                    Be specific, such as “family ordering food for a picnic”.
Step 2 – Create a s...
Relationship Matrix
               Now that you understand who your audience is, the next step is to map this
            ...
Market Environment
Provide background information on the market conditions and competitive
issues that relate to this prod...
Visual Metaphors
The visual metaphors are the underlying look and feel of your site; the images
used to brand the corporat...
House2Home Professionals
                           Architects
                           Builders
                       ...
ensuring that stories can be added quickly without the need for HTML coding or site
      uploading and that existing stor...
Application Server
                      Client (such as minimum browser feature set etc)
                      Database S...
The interfacing standard and protocols to be used.


Interfaces that exist could include:


   Application Server to Clien...
Local Navigation
Local navigation describes how a user might navigate within a single section,
page or multi-part document...
Graphics                            0 Border , alt tag must be defined for all elements except spacers.


Graphical Elemen...
Resources
Identify resources required in terms of numbers, skill set and timeframes.


 Role                    Timeframe ...
Workflow
Workflow can be described either diagrammatically (with use case or swim lane
diagrams) or textually in the form ...
Stage 3 — Develop
    Development takes an iterative, prototype approach, where the application is
    developed based on ...
Version control will be dependent on the platform and tools selected.



                 Version Numbering
              ...
beta application to be used in a live environment, operated in
                            parallel or used solely in a us...
Prior to commencing UAT, it is important to formally define:


   What testing is to be carried out
   The environment und...
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Insite
Upcoming SlideShare
Loading in …5
×

Insite

860 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
860
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Insite

  1. 1. Information Architecture Web Services Methodology Definition and guidelines document
  2. 2. Document Document name INSITE-SDLC Author Andy Williamson, Details Wairua Consulting Revision 2.00 Legal Notice Copyright © Wairua Consulting 1999-2001. All rights reserved. This document and its associated components are provided Wairua Consulting under license and remain the property of Wairua Consulting. PO Box 60-517 Authorised users are granted a non-exclusive license to use Titirangi the contents of this document and any associated Waitakere City documentation and/or intellectual property. The conditions of Aotearoa/New Zealand this license mean that you must not copy, distribute, sub- Telephone +64 (0)9 817 1133 license or resell this product. Wairua Consulting accepts no Fax +64 (0)9 817 1103 responsibility for the direct or indirect consequences of using Email info@wairua.com www.wairua.com 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Define Design Develop Deploy improve Information Post Implementation Project Definition Architecture Development Testing ok Deploy Review Document Goal Goals and Objectives System test Install Objectives Functional Requirements Integration test Support Scope Architecture User Acceptance test Maintain feed into IAD Exclusions Client Interface Architecture Close-out Risk Procure Alternatively (for larger Install projects) Data Model Configure Project Proposal Data definitions Translations Document Type Definition (DTD) Project Charter Workflow Cross Stage Project Management Project Plan Project Plan Project Plan (High Level) (Detailed) (Update against actual) Change Management Risk Management Quality Assurance Document Management Copyright © 2000 Wairua Consulting. Figure 3 - INSITE Process Model CONFIDENTIAL Revision 2.00 1 0
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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 Delivery status Price Return purchase Delivery 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: Drive-thru ordering Place order Pay for order Driver Counter staff Fulfil order Deliver 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
  29. 29. 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
  30. 30. 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
  31. 31. House2Home Professionals Architects Builders Etc… Or graphical: House2Home www.house2home.co.nz www.house2home.com.au Shop floor Services Information About Contact Product catalogue and online sales Decorating H2H Professionals Newsletters History Architects Interiors Information sheets People Interior designers Landscapers Q&A Branches Outdoor Builders Garden Plumbers Glazier Timber H2H Packages Trade Trade Home handyman MyHouse Projects Shopping cart Checkout Order 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
  32. 32. 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 1 2 1 1 2 information 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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). Hyperlink /index.html image/logo_lg.jpg (300 x 80) Usage Page heading on all pages. Hyperlink /index.html image/logo_sml.jpg (175 x 35) 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
  37. 37. 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 4 months 1 Some ASP knowledge Developer 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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

×