DSS 12 S4 03 Risk CheckList
of 8
Transcript of DSS 12 S4 03 Risk CheckList
-
7/29/2019 DSS 12 S4 03 Risk CheckList
1/8
School of Computer Science & Software Engineering
Bachelor of Computer Science (Digital Systems Security)
CSCI321- Project
Risk Check List - 27 February 2013
Group: SS12/4B
Khoo Jun Xiang 4000766 [email protected]
Ang Wencan Stephen 4194032 [email protected]
Goh Kheng Siang Joel 4187490 [email protected]
Lim Sing Hui 4185948 [email protected]
Low Jia Hui 4186448 [email protected]
Supervisor: Mr Sionggo Jappit
Assessor: Mr Tan Kheng Teck
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected] -
7/29/2019 DSS 12 S4 03 Risk CheckList
2/8
Design Specification [SS12/4B]
Page 2 of8
Document Control
Title: Risk Check List
Document Name: Risk Check List
Owner Current VersionLast Change on
Approved byDate Time
Khoo Jun Xiang V0.3 27-Feb-
2013
8PM Project Manager
Distribution List
Name Title/Role Where
Mr Sionggo Jappit Supervisor SIM-UOW
Mr Tan Kheng Teck Accessor SIM-UOW
Khoo Jun Xiang Project Manager SIM-UOW
Low Jia Hui Software
Architect
SIM-UOW
Goh Kheng Siang Joel Test Designer SIM-UOW
Lim Sing Hui UI Designer SIM-UOW
Stephen Ang DatabaseDesigner
SIM-UOW
Record of Revision
Revision Date DescriptionSection
Affected
Changes
Made by
Version after
Revision
10/01/2012 Document Creation- Briefing
and assign tasks
All Khoo
Jun
Xiang
0.1
23/02/2012 Finalized on document ALL ALL 0.2
27/02/2013 Update on final document ALL ALL 0.3
-
7/29/2019 DSS 12 S4 03 Risk CheckList
3/8
Design Specification [SS12/4B]
Page 3 of8
Contents............................................................................................................................................................ 1Document Control................................................................................................................................ 21. Release Information ...................................................................................................................... 42. Records and Measures .................................................................................................................. 43. General Contigency ...................................................................................................................... 44. Major Risk .................................................................................................................................... 55. Minor Risk List ............................................................................................................................. 66. Risk Values................................................................................................................................... 87. Risk Checklist ............................................................................................................................... 8
-
7/29/2019 DSS 12 S4 03 Risk CheckList
4/8
Design Specification [SS12/4B]
Page 4 of8
1.Release InformationProject: DB-Wrapper
Internal Release Number: V1.1Related Documents: Design Specification
Requirement Specification
Project Document
2.Records and MeasuresThe severity of a risk is its likelihood multiplied by its impact. Risks are classified as minor if they
have low likelihood, negligible impact, or medium likelihood and marginal impact.
Mitigation Plan Measures carried out now to reduce the likelihood and/or impact of the
risk. Alternatively, risk could be accepted.
Indicator A sign monitored to determine if the risk is beginning to have an impact
on the project.
Contingency Plan What to do if the risk does arise. General contingency plans are being
specific
3.General ContigencyCatastrophic Risk If a catastrophic risk occurs we will make an
honest reassessment of the viability of the projectand notify the relevant project stakeholders
Risk that consume development resources The project has a fixed deadline and presentationdate. The requirements are prioritized. If we delay
our project completion time, we will reduceproject scope.
The features specified are mostly essential If welose time, we will delay delivery.
If we lose time, we will make time estimates for
the remaining features, and meet with the
customers to reconsider scope and delivery date.
-
7/29/2019 DSS 12 S4 03 Risk CheckList
5/8
Design Specification [SS12/4B]
Page 5 of8
4.Major RiskName Description Likelihood Impact Plan Status Owner
Requirements Requirements areonly partly known
at project start.
Stakeholders may
not approve our
proposal.
Medium Critical toCatastrophic
Requirementsare prioritizeaccordingly.
Indicator:Track the raterequirements
are discovered.
Contingency:
Communicate
with client
regularly
Amber RequirementLead
Communication Communicationproblems indevelopment
team.
They might have
problem
expressing their
ideas/views
Medium Critical Development
team could
repeat what
the other
member has
mentioned to
prevent
miscommunic
ation.
Green Team Leader
Acceptance Stakeholders mayaccept sub-
standard product,
or product that
exceed our level
of capabilities .
Medium Critical Customers areasked to
declare
acceptance
criteria as each
release is
planned.
Green Client
Scope The total features
requested may be
beyond what the
development team
can deliver in the
time available.
High Marginal Assign levels
of important to
the use cases.
Review of
project scope
after 6 months.
Green Client
-
7/29/2019 DSS 12 S4 03 Risk CheckList
6/8
Design Specification [SS12/4B]
Page 6 of8
5.Minor Risk ListName Descripti
on
Likelihood Impaction MitigationStrategy
Status Owner
Estimate Thedevelopmentteam might
not be ableto estimatethe worktime.
Medium Marginal The development teamwill gain experience inestimating the work,
and deliver the firstestimates after 3months. We willcompare estimatedwork to actual work.
Green Project
Manager
Correctness The systemas delivered
may havelow take-up
because of alack of
confidencein its
correctness.
Low Catastrophic Contingency: stopdevelopment of new
features until thequality of the existing
code is assured.
Green Team
Leader
Usability The systemas deliveredmay havelow take-up
because ofpoorusability.
Low Critical Produce a UserManual to guide End-Users on using the
product.
Green UI
Designer
Desire The statedrequirementsmight notmatch thestakeholders'desires andambitions forthe system.
Low Critical Incremental deliveryof versions will
provide experience ofusing the system,which will help thecustomers to identifythe real requirements.
Indicator:Developer misleadingthinks that they knowwhat the stakeholder issaying
Stakeholder sayingDevelopers know whatthey mean
Contingency: RequestStakeholder to reviewrequirements regularly.
Green Client
-
7/29/2019 DSS 12 S4 03 Risk CheckList
7/8
Design Specification [SS12/4B]
Page 7 of8
Changes Afterrequirementshave beendocumented
and agreed,development
activitiesbegin to
based onthem, first
design thenimplementati
on.
If therequirements
changes thenprevious
effort iswasted.
Low Critical A change controlprocedure is required,so changes are onlymade when the cost is
worthwhile.
Indicator: Comparecost of change to new
development.
Contingency: Requeststakeholders review of
requirements regularly.
Green Project
Manger
Process Somedevelopersmay notagree onsomestandards
Low Critical Discussions indevelopment teammeetings to change thestandard or the actual
practice asappropriate.
Green LeadDeveloper
Maintainability The systemas deliveredmight behard tomaintain.
Low Marginal Review of code formaintainability.
Green LeadDeveloper
-
7/29/2019 DSS 12 S4 03 Risk CheckList
8/8
Design Specification [SS12/4B]
Page 8 of8
6.Risk ValuesRed Serious Impact
Amber Marginal Impact
Green No / Little Impact
7.Risk ChecklistDo the plans provide an indicator to detect
each of the risks becoming active?
Yes, if all activities are carried out as planned, we
will know if any of the risks is maturing.
No, some risks could creep up on us.
Correct "risk owners" assigned to monitor the
risks?
Yes, for each risk the assigned owner can detect
the indicator, can launch the contingency plan,
and is the person who will suffer by the risk.
Does each risk have a mitigation strategy, or is
the risk acceptable?
Yes, we have plans to control some risks, and
have accepted others.
Does each risk have a contingency plan? Yes, for each risk there is a contingency plan
above.
Has this Risk Control Plan been communicated
to the development team and other
stakeholders?
Yes, this document is being posted to the project
website. It will also be discussed at an early team
meeting, and discussed with the customers before
the commit to the project.
In the light of these risks, is the project worth
carrying out?
Yes, it is a low risk project.
