Project Phases [1]

• Inception: Establish the project’s scope and boundary, find the critical use cases, exhibit a candidate architecture, estimate the overall cost and schedule for the whole project, with details for the elaboration phase, and estimate risks.
• Elaboration: Define and validate the architecture, baseline a detailed plan for the construction phase
• Construction: Achieve useful versions (alpha, beta…), achieve adequate quality.
• Transition: Achieve final product baseline, achieve stakeholder concurrence of completeness

Project Disciplines [1]

Process Disciplines

• Business Modeling
• Requirements
• Analysis & Design
• Implementation
• Testing
• Deployment

Support Disciplines

• Configuration Management
• Change Management
• Project Management
• Environment

Architecture [1]

• The set of views, for the architecturally-significant components, of requirements, analysis, design, implementation, testing, and deployment.
• Similar to a blue print

Requirements Gathering [1]

• Gather all stakeholders
  • an individual or group of individuals with a common interest in the software
  • there may be conflicting interests among stakeholders!
  • can be customers, consumers, owners, partners, funders,subcontractors, internals, society, etc…
• Achieve sufficient requirements
  • Avoid designs details
  • Avoid implementation details
  • Cover only the functions that the software must provide
  • At this stage, don’t be concerned with how the functions are provided
• Use notations to capture requirements (ex: UML)
  • Don’t just talk about the software, but capture things on paper

<insert info on UML, show user case diagrams>

Use Case Scenarios [1]

• One or more user scenarios are written down for each use case
  • a lot of ambiguities are resolved at this stage
  • still lots of details remain and are avoided

Ex: Use case: show profile

1. START: user activates the show profile feature
2. software asks user to specify profile parameters
3. software retrieves parameters for database and displays them to the user
4. FINISH: user cancels the feature

Non-Functional Requirements [1]

• Captured as part of requirements gathering stage

Ex: (the software should answer queries within 3 seconds)

Requirements Document [1]

• Includes functional and non-functional requirements
• Must be signed off by stakeholders

Goal, Objective and Scope [1]

• Goal: must be defined crisply and clearly
• Objectives: for a specific target
  • SMART: Specific, Measurable, Achievable, Realistic, Time-Bound.
• Scope: boundaries of the project: does and does not list
  • not to be confused with features or requirements

Project Charter [1]

• A document that formally recognizes the existence of a project
• Provides the project manager with the authority to apply organizational resources to the project: what the project manager can and cannot do.
• Defines the project goal, scope, and objectives
• Details the level of quality to be expected
• Validates the business justification
• highlights the risk
• It is the contact: if anything needs resolution, this should specify it
• when in doubt, read the charter
• Also specifies the following:
  • what to do if there is a conflict
  • management reconciliation
  • scope change management
  • knowledge transfer
  • training approach
  • anything else…

Sample Charters:

• Eclipse Project Charter
• Treasury Board of Canada Secreteriat
• Projectability Charter

—[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 3