Upload
bradley-leatherman
View
213
Download
1
Tags:
Embed Size (px)
Citation preview
Structured Structured development development
processprocess
Wednesday 20 September 2006
Brett Coster
Business Analyst
uniqueworld
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?