1. Dr Lisa Wise 9/08/2002 Project Managing Small Web Applications Dr Lisa Wise

2. Dr Lisa Wise 9/08/2002 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

3. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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

9. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 This sequence diagram is a diagram for the technical team to use, not for the whole project team to understand.

14. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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

16. Dr Lisa Wise 9/08/2002 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 !!

17. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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

19. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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

21. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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

25. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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. Dr Lisa Wise 9/08/2002 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