Project Managing Small Web Applications Dr Lisa Wise

1
Project Managing Small Web Applications Dr Lisa
Wise
2
Outline

• Project Management overview
• Web architecture overview
• Understanding what clients want
• Establishing business rules and process
• Developing web application requirements
• Project managing a web project

3
Project management overview

• Variety of methodologies
• Monash ITS uses Thomsett methodology
• Identify Project Roles
• Sponsor / Client / Key User Groups
• Project Manager, Tech Lead, Site Architect
• Documentation
• Vision / Objectives / Desired Outcomes / Risks
• Requirements (Functional, Technical, Usability)

4
Software Development Methodology

• There are a range of iterative software
  development models including
• Heavyweight methodology
• Rational Unified Process (RUP)
• Lightweight (agile) methodology
• User-Centred Design (UCD)
• Extreme Programming (XP)
• Weight tends to reflect process vs coding

5
Manifesto for Agile Software Dev

• http//www.agilemanifesto.org/
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• While there is value in the items on the right,
  agile developers value the items on the left more

6
Process is not a dirty word

• Developers want to be creative / adaptive
• Managers and sponsors need projects to
• be predictable
• provide visible progress indicators
• meet schedule, budget and other targets
• Process allows managers to manage and programmers
  to program within a common framework of goals and
  objectives

7
Process as framework not overhead

• All methodologies should have in common
• defining project vision and scope
• identification of project risks and constraints
• consultative specification of requirements
• business, user, technical, security, privacy
• specific process for change management
• system architecture and detailed design
• testing of product against requirements

8
Outline

• Project Management overview
• Web architecture overview
• Understanding what clients want
• Establishing business rules and process
• Developing web application requirements
• Project managing a web project

9
Web Architecture Overview

• Technical Architecture
• Webserver, Scripting engine, Database
• PHP, Perl, Coldfusion, Java, Oracle, MySQL
• Information Architecture
• Domain knowledge
• Content categorisation
• Navigation
• Content / purpose drives website structure

10
Web architecture (cont)

• Project team needs to understand broad technical
  and information architecture as an essential
  precursor to site design
• Major communication issue to ensure that all team
  members understand the architecture model for
  website
• Only technical team needs to understand detailed
  technical architecture for website

11
This diagram is at a level where all team
members should be able to understand how the
components of the system fit together and
what dependencies are present
12
This use case diagram should allow the project
team to understand what tasks and functions
are performed by the website, allowing managers
to see which components depend on others, and how
much coding a simple function requires.
13
This sequence diagram is a diagram for
the technical team to use, not for the whole
project team to understand.
14
Diagrams such as this describe the major planned
paths through website interactions. In contrast,
user interface prototypes show how site will
appear to users and allow testing of how users
really will navigate through the site
15
Outline

• Project Management overview
• Web architecture overview
• Understanding what clients want
• Establishing business rules and process
• Developing web application requirements
• Project managing a web project

16
Understanding what clients want

• Find comparable web sites
• Make prototype of site (paper or coded)
• Fully describe desired functionality
• Clients should NOT determine technical
  requirements for site because they
• give incomplete or inaccurate information
• dont fully understand technical terminology
• Prototype code is never part of real code !!

17
Understanding what users want

• User interface prototype developed with client
  should be tested with website users
• Users and clients are not the same people
• Users and marketing target audiences may not be
  the same people
• Market research, user needs analysis and business
  needs analysis have very different emphases

18
Your client is not the websites client

• Business needs
• encapsulate what the organisation wants to
  achieve via their website
• Market needs
• identify potential users of your website
• User needs
• analyse how people actually use your website or
  services and what they want to be able to do

19
Whose needs are most important?

• All web projects have conflicting needs
• If your business needs do not meet a market need,
  your project will fail
• If your target audience cannot use your website,
  your project will fail
• If your target market differs from your user
  base, and your users are not relevant to your
  business, your project will fail

20
Outline

• Project Management overview
• Web architecture overview
• Understanding what clients want
• Establishing business rules and process
• Developing web application requirements
• Project managing a web project

21
Business Rules for Websites

• Business rules describe what can and cannot be
  done when interacting with a website
• Who can access the site?
• What information is available to them?
• What can they do?
• What is required of them?
• Need to understand business context

22
Business Process

• What processes are currently in place?
• How does the web development affect existing
  processes?
• Does the web application change who is
  responsible for different aspects of the business
  process?
• Does the web application affect security, privacy
  or record-keeping practices?

23
Business Analysis

• Interview clients about their business
• What do they do?
• How do they do it?
• Describe tasks performed by people
• Describe functions of system components
• Collect user stories / scenarios
• Set of scenarios should capture all user and
  functional requirements

24
Outline

• Project Management overview
• Web architecture overview
• Understanding what clients want
• Establishing business rules and process
• Developing web application requirements
• Project managing a web project

25
Web Project Requirements

• Requirements arise from
• Constraints (including security, privacy)
• User Interface specifications
• Business needs / Functional considerations
• Technical considerations
• Staged requirements are signed off
• by sponsor, client, tech lead, user groups
• Changes only via change control process

26
Risk Management

• Prepare risk management document
• Provide budget for risk resolution
• Maintain a list of major risks for your project
  and keep this updated
• risks are assessed in terms of impact and
  likelihood and change over project duration
• risks must be identified without fear
• identified risks must be openly managed

27
Potential Constraints

• Economic / Political Constraints
• Technical / System Considerations
• licencing, restricted platforms
• compatability with existing systems
• supported platforms for users
• Environmental Constraints
• legal, standards compliance, security
• Scheduling / Resource Issues

28
Website Development Plan

• Website development planning requires
• clear unambiguous realistic vision statement
• business case with measurable benefits
• user interface prototype which vividly
  demonstrates all functionality of system
• clear detailed written specification of what
  services the website will provide
• group of users who have been consulted and will
  continue to be consulted throughout project

29
Outline

• Project Management overview
• Web architecture overview
• Understanding what clients want
• Establishing business rules and process
• Developing web application requirements
• Project managing a web project

30
Detailed Development Plan

• Website Development Plan includes
• detailed written architecture and design docs
• detailed written quality assurance (test) plan
• detailed staged delivery plan for feature set
• technical documentation plan (training, support
  and on-going site and code maintenance)
• Project plan (schedule) should include
• realistic time for other duties, annual leave etc

31
Detailed Design

• Each agreed requirement will be addressed in the
  detailed design
• Each feature in feature set should be derived
  from a requirement
• Each requirement should have an agreed testable,
  measurable acceptance criterion
• Acceptance is binary, not incremental
• requirement is satisfied or not satisfied

32
Basic Test Plan for Website

• User stories / scenarios provide test cases
• can users complete tests?
• do they make errors / take too long ?
• Content and links should be checked
• code reviews should enforce coding standards
• Acceptable response times and errors should be
  specified
• are error messages appropriate for users?

33
Ongoing Review Process

• Schedule and budget should be reviewed at
  designated milestones
• Cannot do accurate schedule and budget prior to
  clear requirements specification
• Can have firm schedule and budget targets, or a
  firm feature set but not both
• Need to set sliders on schedule, budget, features
  and quality

34
Ongoing Review (cont)

• Need real agreement by all parties on
  requirements and sliders
• Understand that requirements and sliders may
  change during course of project
• Change control procedures allow projects to be
  flexible without being unmanageable
• At each milestone, reevaluate and update project
  risks and risk mitigation strategies

35
Ongoing Review (cont)

• Set project milestones (binary done or not)
• Prioritise requirements (staged release, criteria
  for reducing feature set if required)
• Review project at each milestone and set next
  group of mini-milestones
• Current documentation should be readily available
  to all project team and stakeholders

36
Post Implementation Review

• Project is complete when requirements have been
  met
• All team members should be asked to complete a
  post-implementation review
• Project review should include ongoing evaluation
  of site by users including site maintainers

37
Some Resources

• Steve McConnell, Software project survival guide,
  Microsoft Press 1998
• Jim Conallen, Building web applications with UML,
  Addison Wesley, 2000
• Louis Rosenfeld and Peter Morville, Information
  archictecture for the World Wide Web, OReilly,
  1998 (new edition coming in Sep 2002)
• Jim Sterne, Web metrics - proven methods for
  measuring website success, Wiley, 2002
• http//www.martinfowler.com/articles/newMethodolog
  y.html
• A paper on agile (lightweight) methodologies and
  their benefits
• http//www.extremeprogramming.org/
• Outlines XP methodology
• http//www.uml.org/
• describes unified modelling language