Structured Structured development development

processprocess

Wednesday 20 September 2006

Brett Coster

Business Analyst

uniqueworld

brett.coster@uniqueworld.net

Agenda

• Who is this bloke?• Overview of structured process• Obtaining the user’s requirements• Questions to consider• Whose spec? writing for the user, the business and the developer • Case study: Widgets Co• Acceptance testing• Summary• Your questions

Overview of structured processIdentify need

for site

Investigate site requirements

Identify site owner,

stakeholders

Develop and signoff

specification

Develop site

Test siteConduct test group training

Publish site

Review site and training

Conduct user training

Identify the need for the site• Reasons for the site

– What information do we want to make available?

– Who do we expect to read or use the information

– What do we expect people to do with the information?

Overview of structured process

Investigate site requirements• Presentation/s of how SharePoint works and

the process to be followed• Orientation meeting and discussions with

stakeholders and participants• One-on-one interviews, group discussions

and meetings, and workshops

Identify need for site

Investigate site requirements

Identify site owner,

stakeholders

Develop and signoff

specification

Develop site

Test siteConduct test group training

Publish site

Review site and training

Conduct user training

Overview of structured process

Identify site owner, information managers, stakeholders

• Site owner and information managers:– Provide knowledge of the type, extent,

security, and use of the information to be published

– Identify ownership of the data – Identify how it can best be presented to site

users– Identify roles to be used and who they apply

to.• The information managers’ operational

knowledge of the data and how it is used is crucial

• Identify critical metadata to be applied to documents and information

Identify need for site

Investigate site requirements

Identify site owner,

stakeholders

Develop and signoff

specification

Develop site

Test siteConduct test group training

Publish site

Review site and training

Conduct user training

Overview of structured process

Develop and signoff site specification• Build, negotiate and approve a

development plan, specification/s, and schedule

• On business unit signoff, the site is developed and unit tested

Identify need for site

Investigate site requirements

Identify site owner,

stakeholders

Develop and signoff

specification

Develop site

Test siteConduct test group training

Publish site

Review site and training

Conduct user training

Overview of structured process

Develop site• Develop site structure and functionality• Use standard web parts and existing

functionality wherever possible• Configuration• Develop specialised or one-off functionality

where required

Identify need for site

Investigate site requirements

Identify site owner,

stakeholders

Develop and signoff

specification

Develop site

Test siteConduct test group training

Publish site

Review site and training

Conduct user training

Overview of structured process

Testing, training and publishing• Train the core group of business unit testers

to test and evaluate the site – acceptance testing

• Testing may involve refinement and modification of the ‘as built’ site, as user capabilities evolve and active evaluation of how the information is used is revised

• Production data – documents and list items – is populated as part of the testing process

• On completion of the testing process, the site is published

Identify need for site

Investigate site requirements

Identify site owner,

stakeholders

Develop and signoff

specification

Develop site

Test siteConduct test group training

Publish site

Review site and training

Conduct user training

Overview of structured process

Reviewing site and training• Post implementation review

– Does the site do what we set out for it to do?– Are the end users managing the data?– Are they using the site?– What did we do right?– What did we get wrong?– What could be done better?– Where to next?

Identify need for site

Investigate site requirements

Identify site owner,

stakeholders

Develop and signoff

specification

Develop site

Test siteConduct test group training

Publish site

Review site and training

Conduct user training

Obtaining the user’s requirements

• Workshops– Pros:

• Get lots of differing viewpoints• Often allows ideas to be tested, explored and decided on• Can identify commonality of processes• Can determine terminology for metadata• Can get consensus on big picture and way ahead

– Cons• Can degenerate into chaos• One or two dominant people could inhibit or direct discussion• Hard to get everyone into same place at same time• May not be able to go as deep into tasks, information, processes

Obtaining the user’s requirements

• Interviews– Pros

• Often get deeper access to individual’s view of information and processes• Can follow up threads to get clearer view• Sets up personal relationship, know who to contact when questions or more

information arise

– Cons• Can be time consuming• Lots of similar ground covered• Can get bogged down in detail

Obtaining the user’s requirements

• Documentation– Pros

• Available to people outside original group• Shows decisions made

– Cons• Does anyone actually read it?• Can become task in itself

Questions to consider

• Site content– What types of documents?– How many?– Who owns, approves or controls the documents?

• Do we need approval process?• Do we need version control?• Who’ll manage old versions?

– Who updates the information?– Where are the people who use the information?

• Are there bandwidth constraints?• Do remote users update information or only need access?

– How long should it remain?– Is archival process needed?

Questions to consider

• Site structure– Where is the information now?

• On network?• Personal drives?• Existing intranet/internet pages?

– How is the information organised and categorised?– Can this structure be used as metadata?– What other metadata do we need?

• Site management and maintenance– Who will be the site owner?– Do we need local administrators?– Who will manage the site and its content?– Should everyone be able to add/change information?– Who/how many should be approvers?

Whose spec? Writing for the user, the business and the developer

• Use templates– Consistent document structure– Consistent format

• Let Word do the work for you!• Styles• Autotext

– Change record sheets– Looks professional – Is professional!

• Separate business information from the technical information• Provide page mockups

– Show people what they will be getting

• Tell the reviewers what part of the document you want them to review– Not everyone needs to read the techie stuff!

Widgets Co – Case Study

Widgets Co – Case Study

Widgets Co – Case Study

Widgets Co – Case Study

Widgets Co – Case Study

Widgets Co – Case Study

Widgets Co – Case Study

Widgets Co – Case Study

Acceptance testing

• Train the testers• Outline the testing process

– Goals– What to look for– Emphasise they cannot break the site

• Play first, get comfortable, then use real data– Only when start using real data that really get feel for how site will

work– Use it day to day

• Accommodate tweaks and new features– But have a line drawn as to what is modification and what is new

development

• Finish with populating live data

Summary

• Overview of structured process– Identify need, key stakeholders, site owner, information managers– Specification must address business, users and developers– Get users to use real data in testing

• Obtaining the user’s requirements– Combination of workshops and interviews

• Questions to consider– Who will use information? Why? What for?– Who will manage the information? How much?– What metadata do we need?– Where is the information now?

• Whose spec? write for the user, the business and the developer

Questions?

• Brett.coster@uniqueworld.net