dr lisa wise 9/08/2002 project managing small web applications dr lisa wise

Dr Lisa Wise 9/08/2002

Project Managing Small Web Applications

Dr Lisa Wise


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

Outline


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)


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


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 planWhile there is value in the items on the right, agile

developers value the items on the left more


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


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



Outline


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


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


This diagram is at a level where all team members should be able to understand how the components of the systemfit together and whatdependencies are present


This use case diagramshould allow the project team to understand what tasksand functions areperformed by thewebsite, allowing managers to see whichcomponents dependon others, and how much coding a simplefunction requires.


This sequencediagram is a diagram for thetechnical team to use, not forthe whole project team to understand.


Diagrams such asthis describe themajor 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



Outline


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

– don’t fully understand technical terminology

• Prototype code is never part of real code !!


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


Your client is not the website’s 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


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



Outline


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


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?


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



Outline


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


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


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


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


Outline



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


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”


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?


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


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


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


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


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, O’Reilly, 1998 (new edition coming in Sep 2002)• Jim Sterne, Web metrics - proven methods for measuring website

success, Wiley, 2002

• http://www.martinfowler.com/articles/newMethodology.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

dr lisa wise 9/08/2002 project managing small web applications dr lisa wise

Documents

web project outline

website slide

usability slide

present slide

architecture model

process vs coding slide

technical team

common defining project