Please enable JavaScript.

Coggle requires JavaScript to display documents.

SWEN90016 - Coggle Diagram

- - - - Documents are relevant at the time and created as needed
  - - - Technical Project Manager; Aware of the project and drives change
- - - - Build the right system (for stakeholders)
    - - Build a functional system the right way
  - - - Informal
        
        Drawback - not efficient, lack of procedures and not comprehensive
        
        Impromptu; Low cost
      - Formal
        
        Walkthrough
        
        Coding Inspections
        
        Code Review
        
        Code Audit
    - - Looking at system as a whole from a high level
      - In order to move to the next of the process
      - Stakeholders, Project Managers, Lead Tech, Team
    - - Reviewing the Scope, Schedule, Budget, Personnel
      - Against a baseline plan to benchmark test
  - - - How you should record documents / artefacts
    - - Initial
      - Repeatable
      - Defined
      - Manage
      - Optimising
- - - - Constrained - depends on another task
      - Unconstrained - can start whenever
  - - - It means that a delay in any of the activities means a delay in the project
      - Same time as project path time
      - Slack of 0
      - Other activities NOT on the critical path are flexible in when they can start
    - - Monitors progress to replan
      - Better resource allocation for the organisation
    - - Start with tasks with no dependencies, usually either 0 or the earliest finish of the
    - - Earliest Finish = Duration + Earliest Start
    - - Latest Start = Latest Finish - Duration
    - - Work backwards from completion of project, and is usually the earliest of the latest starts from dependent tasks
  - - - Calculate past project performance in order to predict future project performance
- - - - Has to do with the process, team, resources; planning of the project - scope, personnel, budget, schedule
    - - Affects the economic success of the project
    - - Affect final quality of product delivered
  - - - Pondering
      - Interviewing
      - Brainstorming
      - Delphi Technique
      - SWOT Analysis (Strengths, Weaknesses, Opportunities, Threats
      - Checklist
        
        Industry standard; From past projects?; Workshops led by PO
    - - Analysis is Qualitiative
        
        Impacts (1-5) [up to 10]
        
        Likelihood (1-99) [estimate]
        
        Exposure = P * I where P = probability of likelihood and I = Impact
        
        Identifying the root cause -> All risks can be managed under a single root cause if there is one present or identified
      - Assessment is Quantitative
        
        Out of scope of our class (Decision Tree Analysis, Simulation, Sensitivity Analysis); Mathematical Techniques
        
        Risk Matrix
        
        X axis = likelihood, Y axis = Impact
        
        Scale of low - high
    - - Risk Review
      - Risk Status Meeting
    - - Actions towards Opportunities
        
        Exploit
        
        Share
        
        Enhance
        
        Accept
      - Actions Towards Threats
        
        Mitigate
        
        Making actions to reduce impact of the risk
        
        Accept
        
        Ignore
        
        Avoid
        
        Making actions to reduce probability of the risk occurring
        
        Transfer
    - - Break down into manageable, singular risks; Incorporate into each of the Agile ceremonies
- - - - Documents need to track
        
        Identify items affected by change
    - - Variants
      - Tracking, Rollback, Reproducibility
      - Release Management
    - - Affect multiple configurations; Initiating - Evaluating - Executing (Making the change)
        
        Evaluating
        
        Benefits
        
        Cost of Change
        
        Impact (on others)
        
        Risks
        
        Dependencies
        
        Scheduling
        
        Who is Managing this
        
        Notified?
        
        Definition of it being completed
      - Change Management Plan
        
        Baseline
        
        One stable artefact and compare change to this artefact
        
        Reviewed and agreed by everyone
        
        Which means it can be developed on
        
        We can use it as a rollback target because it's proven working
        
        To change the baseline, a formal process to ensure integrity
  - - - Reporting to stakeholders, progress of the project
        
        Retrospectively keep track of the status/progress
- - - - 'Super Scrum Master'
    - - Responsible for features and prioritisation
    - - Procides technical and architectural alignment across organisation teams
    - - Understand business value of the project and ensure value is delivered
  - - - First two sprints more detailed planning to ensure alignment and dependencies
      - Program Backlog
    - - RTE facilitates this
      - SMs from each team, RTE
      - System Architect, Tech Leads to resolve blockers
      - Share progress from each of the teams, align priorities, risk management, raise blockers
    - - All teams' completed functionality at the end of each iteration
    - - Large scaled Retrospective
      - All teams are present
      - Both product and process at ART level reflections
      - Work completed; Systemic issues at the ART level
- - - - Learn as we go; Anticipating changes to environment; Short Dev Cycles
    - - High volatility in environment; Constant requirement changes
  - - - Fixed sequence of steps -> Given the same input, we should produce the same output every time
    - - Stable environment; Not much change to requirements
  - - - Scrum
      - Kanban
      - eXtreme Programming
      - Assumptions
        
        Small team; 7 +- 2, all can fit in a single office in a single location
        
        Simple project
        
        Non critical/disregards little consideration to non func reqs