bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Wiki Markup
Software assurance activities begin during the initiation or pre-award phase of a project (before a Request for Proposal(RFP) is issued), continue through maintenance and retirement, and are performed by persons other than those carrying out the process or creating the product that is being assured.
 
Software assurance includes the disciplines of software quality, software safety, software reliability, software verification and validation (V&V), and independent V&V.  All of these activities work together to ensure high quality products that operate safely. The amount of software assurance required for a project is based on the classification of the software \[TOOL:SWE-020Lee,
Insert proper link here.\] and the safety criticality \[TOOL:SWE-133Lee,
Insert proper link here.\] of the software.
The NASA Software Assurance Standard defines roles, not individuals, so software assurance tasks can be carried out by whoever is assigned to fill the named role.  It is preferable, but not necessary, for a dedicated software assurance group to carry out the software assurance activities.  If such a group does not exist or is not available, the key is to have an organization, group, or person independent (managerially separate) from the organization creating the software "either perform or assure that software assurance activities are performed correctly and to the necessary level, and that records of those activities are created, analyzed, and maintained." (NASA Software Assurance Standard)  More information on the roles and independence required for software assurance can be found in the NASA Software Assurance StandardLee,
This could be set up on the Wiki as this link:
[https://standards.nasa.gov/documents/detail/3315130|https://standards.nasa.gov/documents/detail/3315130] which is also listed in the Resources section below., NASA-STD-8739.8.
To avoid misunderstandings and issues once the project has begun, the following software assurance items should be considered for inclusion in the provider's contractInclude a link to the Acquisition Guidance topic.:

...

  1. Dryden Centerwide Procedure, Code S, Software Assurance, DCP-S-007 Rev. B., Dryden Flight Research Center (DFRC), http://www.nasa.gov/centers/dryden/pdf/87463main_DCP-S-007.pdf
  2. Glenn Procedural Requirements, Software Assurance, GLPR 8739.1, GRC, https://knowledgeshare.grc.nasa.gov/eRoomReq/Files/NASAc1f1/GRCKnowledgeBase/0_d700/GLPR%208739%201.pdf
  3. GSFC Software Assurance website, http://sw-assurance.gsfc.nasa.gov/index.php
  4. ISD Software Quality and IV&V Support Planning Guidelines, 580-GL-030-01, Goddard Space Flight Center (GSFC), http://software.gsfc.nasa.gov/AssetsApproved/PA3.2.1.1.docLee,
    Any of these resources that are approved once this document goes through review are candidates for the NASA PAL, but the links provided here should work until that happens.
  5. NASA Software Assurance Standard, NASA-STD-8739.8, https://standards.nasa.gov/documents/detail/3315130
  6. NASA Software Assurance website, http://www.hq.nasa.gov/office/codeq/software/docs.htm
  7. NPR 7150.2A Handbook, Section 5.3.1 - NASA-STD-8739.8 (Standard for Software AssuranceLee,
    Please insert the link to this section of the handbook Wiki.
    Do we have a standard way of identifying sections in the handbook? If so, please revise this text as appropriate.)
  8. Software Assurance Guidebook, http://sato.gsfc.nasa.gov/guidebook/index.php
  9. Software Process, Process and Product Quality Assurance, GRC-SW-7150.13, GRC, http://software.grc.nasa.gov/processes/SEPG_Processes/Process%20and%20Product%20Quality%20Assurance.pdf
  10. SQA Process, Software Assurance, SEGP-SQA-PRC-1, Glenn Research Center (GRC), httpsNEN Link

Anchor
acronyms
acronyms
Anchor
email
email
Tools

  1. Acquirer Software Assurance Plan template, NEN Link
  2. Checklist for Provider Software Assurance, GRC, http://nensoftware.grc.nasa.gov/webpilot/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499233%2FSoftware.Assurance.pdfLee,
    This is one of those links to hide due to its length. I'm sure you and Jon can work that out on the Wiki.

...

  1. Acquirer Software Assurance Plan template, https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-500056%2FNASA-STD-8739.8%2BAcquirer%2BSoftware%2BAssurance%2BPlan%2Btemplate.doc
  2. Checklist for Provider Software Assurance, GRC, http://software.grc.nasa.gov/pilot/Processes%20and%20Checklists/Checklist%20for%20SA%20Process.pdf
  3. Checklist for Software Assurance, https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499232%2FChecklist%2Bfor%2BSA%2BProcess%2BV1.0.pdf.pdf
  4. Software Assurance Plan template, https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499256%2FSEPGSoftwareAssurancePlanTemplate.doc.doc
  5. Software Quality Activity Matrix, GSFC, http://software.gsfc.nasa.gov/AssetsApproved/PA3.2.1.0.doc
  6. Software Quality Assurance Plan Evaluation Checklist (from the Software Assurance Guidebook), http://sato.gsfc.nasa.gov/guidebook/assets/Assurance_Plan_Evaluation_Checklist.doc
  7. Software Quality Assurance Plan template, GSFC, http://software.gsfc.nasa.gov/AssetsApproved/PA3.2.1.2.docLee,
    All of these that don't have "nen.nasa.gov" in their URLs are candidates for the NASA PAL, but until that happens, these links should work.
    Those that do have the "nen.nasa.gov" are candidates for hiding the links when they are added to the Wiki.
  8. Software Quality Assurance Procedure Evaluation Checklist (from the Software Assurance Guidebook), http://sato.gsfc.nasa.gov/guidebook/assets/Assurance_Procedure_Evaluation_Checklist.doc

Lessons Learned

...

  1. Processes%20and%20Checklists/Checklist%20for%20SA%20Process.pdf
  2. Checklist for Software Assurance, NEN Link
  3. Software Assurance Plan template, NEN Link
  4. Software Quality Activity Matrix, GSFC, http://software.gsfc.nasa.gov/AssetsApproved/PA3.2.1.0.doc
  5. Software Quality Assurance Plan Evaluation Checklist (from the Software Assurance Guidebook), http://sato.gsfc.nasa.gov/guidebook/assets/Assurance_Plan_Evaluation_Checklist.doc
  6. Software Quality Assurance Plan template, GSFC, http://software.gsfc.nasa.gov/AssetsApproved/PA3.2.1.2.docLee,
    All of these that don't have "nen.nasa.gov" in their URLs are candidates for the NASA PAL, but until that happens, these links should work.
    Those that do have the "nen.nasa.gov" are candidates for hiding the links when they are added to the Wiki.
  7. Software Quality Assurance Procedure Evaluation Checklist (from the Software Assurance Guidebook), http://sato.gsfc.nasa.gov/guidebook/assets/Assurance_Procedure_Evaluation_Checklist.doc


Lessons Learned

Wiki Markup
 _Software quality assurance implementation is a balancing activity that must be tailored as project appropriate._ "No project in the history of Software Development at NASA has had "enough" money, especially when it comes to implementing Software Quality Assurance activities. It is not possible to achieve all aspects of quality because of interrelationships. Software Quality Assurance engineers must determine, based on experience, what trade-offs are to be made within the specific project since each project has different objectives. Gilles defined some of these relationships between the quality assurance criteria e.g., an inverse relationship between usability and efficiency; a direct relationship between maintainability and reusability \[TOOL:2\]. To make the best trade-offs, all relationships must be understood and experience used to interpret the impact." (Lesson 2 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Software quality assurance must evaluate the process as well as the products._ "Within NASA, SQA tends to focus on the products produced, such as the requirements documents, design, code listing, and test plans. But the focus of SQA is to monitor continuously throughout the Software Development Life Cycle to ensure the quality of the delivered products. This requires monitoring both the processes and the products. In process assurance, SQA provides management with objective feedback regarding compliance to approved plans, procedures, standards, and analyses. Product assurance activities focus on the changing level of product quality within each phase of the life cycle, such as the requirements, design, code, and test plan. The objective is to identify and eliminate defects throughout the life cycle as early as possible, thus reducing test and maintenance costs." (Lesson 3 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_There must be a software assurance plan._ "Most Project Managers feel they have too many plans, and the suggestion of another one for Software Quality Assurance might be the proverbial straw that breaks the camel's back\! But the success of any undertaking is to know what one is trying to achieve and how one expects to accomplish it, hence, the necessity of a plan for SQA. The plan will specify the goals, what is to be performed, standards against which the development work is to be measured, all relevant procedures, and the organizational structure of the Quality Assurance within the project. At NASA a software assurance plan is required." (Lesson 4 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Software quality assurance must evaluatespan the processentire assoftware welldevelopment aslife the productscycle._  "WithinSoftware NASA,Development SQAstarts tends to focus on at the productsconcept produced,phase suchand ascontinues thethrough requirementsmaintenance. documents,SQA design,activities codeand listing,funding andshould testalso plans.start Butat the focusconcept ofdefinition SQAand iscontinue tothrough monitorthe continuouslyentire throughoutlife thecycle. SoftwareAt Developmenteach Lifephase, Cyclethere toare ensureactivities thethat qualitycould ofbe the delivered productsperformed \[TOOL:4\]. ThisThe requiresproject monitoringand both the processesquality andassurance theoffice products.must Inwork processtogether assurance,to SQAnegotiate provideswhat managementactivities withare objectiveappropriate feedbackat regardingeach compliancephase tobased approvedon plans,risks procedures, standards, and analysesand resources. ProductThe assuranceQuality activitiesAssurance focusPlan onshould theindicate changingwhat levelactivities ofwill productbe qualityperformed, withinthe eachdecision phasebasis, ofand the life cycle, such as the requirements, design, code, and test plan. The objective is to identify and eliminate defects throughout the life cycle as early as possible, thus reducing test and maintenance costs." (Lesson 3 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.trade-offs made." (Lesson 5 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_ThereRequirements mustare bethe abirthplace softwareof assurancesuccessful planprojects._  "MostAlthough ProjectSQA Managersis feelperformed theyacross havethe tooentire manylife planscycle, andsuccess the suggestion of anothera oneproject forcan Softwareoften Qualitybe Assurancedetermined mightby be the proverbialattention strawpaid thatto breaksrequirements. theThe camel's back! But earlier in the successlife ofcycle anypotential undertakingrisks isare toidentified, knowthe whateasier oneit is trying to achieveeliminate andor howat oneleast expectsmanage tothe accomplishconditions it,that hence,introduce thethat necessityrisk. ofProblems anot planfound foruntil SQA.the Thetesting planphase willare specifyapproximately the14 goals,times whatmore iscostly to befix performed,than standardsif againstfound whichand thefixed developmentearlier workin isthe torequirements bephase. measured,The allfirst relevanttangible procedures,representation andof the organizationalcapabilities structureproduced ofis the Qualityrequirements Assurancespecification withindocument, thebe project.they Atsystem, NASAhardware, a software, assuranceor planoperational is requiredrequirements." (LessonThe 4document ofalso 12,serves SoftwareTechto News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Software quality assurance must span the entire software development life cycle._ "Software Development starts at the concept phase and continues through maintenance. SQA activities and funding should also start at the concept definition and continue through the entire life cycle. At each phase, there are activities that could be performed \[TOOL:4\]. The project and the quality assurance office must work together to negotiate what activities are appropriate at each phase based on risks and resources. The Quality Assurance Plan should indicate what activities will be performed, the decision basis, and the trade-offs made." (Lesson 5 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.phpestablish the basis for all the project's engineering management and assurance functions. If the quality of the requirements specification is poor, the project is at risk even before work begins. \[TOOL:7\] Therefore, a specific lesson in SQA is the emphasis on requirements." (Lesson 6 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Software quality assurance does not equal testing._ "Too often project managers assume they have Quality Assurance since they are doing testing already, or believe they don't need quality assurance until testing. These are incorrect assumptions based on lack of experience, understanding and/or knowledge. From the aspect of quality assurance, the purpose of testing is to:

  • Assure problems are documented, corrected, and used for process improvement.
  • Assure problem reports are assessed for their validity.
  • Assure reported problems and their associated corrective actions are implemented in accordance with customer approved solutions.
  • Provide feedback to the developer and the user of problem status.
  • Provide data for measuring and predicting Software Quality and Software Reliability."

Wiki Markup
(Lesson 7 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_RequirementsMetrics are the birthplace of successful projectsa necessity._ "AlthoughSoftware Metrics SQAare isoften performedignored acrossduring the entireearly lifeSoftware cycle,Development successLife ofCycle aphases projectand cannot oftenactively beassociated determinedwith bySQA the- attentionbut paidshould to requirementsbe. TheFor earlierSQA inpractitioners, thewith lifetheir cycleresponsibility potentialfor risksassuring areboth identified, the easierprocesses itand isthe to eliminate or at least manageproducts of the conditionsSoftware thatDevelopment, introducemeasurement thatis riskcritical. ProblemsThroughout noteach foundof until the testinglife phasecycle arephases approximatelymetrics 14have timesproven moreinvaluable costlyin tothe fixevaluation thanof ifthe foundquality andof fixedthe earlierproducts inand the requirements phase. The first tangible representation of the capabilities produced is the requirements specification document, be they system, hardware, software, or operational requirements. The document also serves to establish the basis for all the project's engineering management and assurance functions. If the quality of the requirements specification is poor, the project is at risk even before work begins. \[TOOL:7\] Therefore, a specific lesson in SQA is the emphasis on requirements." (Lesson 6 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Software quality assurance does not equal testing._ "Too often project managers assume they have Quality Assurance since they are doing testing already, or believe they don't need quality assurance until testing. These are incorrect assumptions based on lack of experience, understanding and/or knowledge. From the aspect of quality assurance, the purpose of testing is to:

  • Assure problems are documented, corrected, and used for process improvement.
  • Assure problem reports are assessed for their validity.
  • Assure reported problems and their associated corrective actions are implemented in accordance with customer approved solutions.
  • Provide feedback to the developer and the user of problem status.
  • Provide data for measuring and predicting Software Quality and Software Reliability."

Wiki Markup
(Lesson 7 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.phpprocesses \[TOOL:5\]." (Lesson 8 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Safety and reliability are critical aspects of SQA._ "Safety is a team effort and everyone's responsibility. Software within NASA is a vital part of the system and can impact the safety of the mission. Project managers, Systems Engineers, Software Leads and engineers, Software Assurance or Quality Assurance, and System Safety Personnel all play a part in creating a safe system. Reliability and safety cannot be tested at the end of a project; they must be built in as the software is being Developed.
Reliability impacts safety - a system cannot be deemed safe if it is not reliable." (Lesson 9 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_MetricsIndependent verification areand a necessity._ "Software Metrics are often ignored during the early Software Development Life Cycle phases and not actively associated with SQA - but should be. For SQA practitioners, with their responsibility for assuring both the processes and the products of the Software Development, measurement is critical. Throughout each of the life cycle phases metrics have proven invaluable in the evaluation of the quality of the products and processes \[TOOL:5\]." (Lesson 8 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Safety and reliability are critical aspects of SQA._ "Safety is a team effort and everyone's responsibility. Software within NASA is a vital part of the system and can impact the safety of the mission. Project managers, Systems Engineers, Software Leads and engineers, Software Assurance or Quality Assurance, and System Safety Personnel all play a part in creating a safe system. Reliability and safety cannot be tested at the end of a project; they must be built in as the software is being Developed. 
Reliability impacts safety - a system cannot be deemed safe if it is not reliable." (Lesson 9 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Independent verification and validation (IV&V) is an important tool within SQA._ "NASA defines Software IV&V as a Systems Engineering Process employing rigorous methodologies for evaluating the correctness and quality of the software product throughout the Software Development Life Cycle. Without SQA, IV&V is expensive and often not as effective. SQA is a broad "blanket" across the project, overseeing all process and product activities, including software. IV&V focuses on only those processes and products determined to have the highest risk, doing an in-depth evaluation of them. IV&V should not be used on all projects, but instead as a tool to increase reliability and the probability of mission success! \[TOOL:4\]" (Lesson 10 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Hardware does not equal software!_ "The influence of Hardware Quality Assurance is evident in the Software Quality Assurance practitioner community, where hardware-intensive systems and typical hardware-related concerns predominate. Two issues which dominate discussions about hardware are time and operating conditions. Software however, is built with different constraints and considerations. NASA has grappled with these differences and the best approach for recognizing the differences (yet similarities) of hardware and software quality assurance. At GSFC, and within other NASA Centers, hardware and software QA are in one department. This allows for them to work together, since both are needed for a successful project, yet are still separate in other areas where needed." (Lesson 11 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Risk Management is not optional._ "Risk is a daily reality on all projects, and Continuous Risk Management should become just as routine. It should be ongoing and comfortable and neither imposed nor forgotten. Like any good habit, it should seamlessly fit into the daily work. 
_Software Risk Management is important because it helps avoid disasters, rework, and overkill._ The objectives of Software Risk Management are to identify, address, and eliminate software risk items before they become threats to success or major sources of rework. Good project managers are also good managers of risk. It makes good business sense for all software development projects to incorporate risk management as part of project management." (Lesson 12 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
\\

...

Responsible Org.

...

Milestone Review

...

Software Classes

...

Documents

...

PM
CSMA
HQSMA
CCE
HQCE
SAM
CD
IVV
SRA
MD
CTO

...

MCR
SRR
SwRR
MDR
SDR
PDR
CDR
PRR
SIR
TRR
SAR
ORR
FRR

...

ASC
ANSC
BSC
BNSC
CSC
CNSC
DSC
DNSC
ESC
ENSC
F
G
H

...

Plan
Procedure
Process
Studies
Reports
Analysis
Records
Prod Desc

...

 

...

 

...

 

...

Acquisition

...

 

...

 

...

 

...

Plan
In/Over
SM

...

Product Dev.

...

 

...

 

...

 

...

SSE
SRE
Design
C&I
V&V
PR
Sus Engr

...

 

...

 

...

 

...

 

...

Org. Support

...

Project Mgt.

...

Assets

...

 

...

validation (IV&V) is an important tool within SQA._ "NASA defines Software IV&V as a Systems Engineering Process employing rigorous methodologies for evaluating the correctness and quality of the software product throughout the Software Development Life Cycle. Without SQA, IV&V is expensive and often not as effective. SQA is a broad "blanket" across the project, overseeing all process and product activities, including software. IV&V focuses on only those processes and products determined to have the highest risk, doing an in-depth evaluation of them. IV&V should not be used on all projects, but instead as a tool to increase reliability and the probability of mission success\! \[TOOL:4\]" (Lesson 10 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Hardware does not equal software\!_ "The influence of Hardware Quality Assurance is evident in the Software Quality Assurance practitioner community, where hardware-intensive systems and typical hardware-related concerns predominate. Two issues which dominate discussions about hardware are time and operating conditions. Software however, is built with different constraints and considerations. NASA has grappled with these differences and the best approach for recognizing the differences (yet similarities) of hardware and software quality assurance. At GSFC, and within other NASA Centers, hardware and software QA are in one department. This allows for them to work together, since both are needed for a successful project, yet are still separate in other areas where needed." (Lesson 11 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
_Risk Management is not optional._ "Risk is a daily reality on all projects, and Continuous Risk Management should become just as routine. It should be ongoing and comfortable and neither imposed nor forgotten. Like any good habit, it should seamlessly fit into the daily work.
_Software Risk Management is important because it helps avoid disasters, rework, and overkill._ The objectives of Software Risk Management are to identify, address, and eliminate software risk items before they become threats to success or major sources of rework. Good project managers are also good managers of risk. It makes good business sense for all software development projects to incorporate risk management as part of project management." (Lesson 12 of 12, SoftwareTech News, [https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61|https://softwaretechnews.thedacs.com/stn_view.php?stn_id=8&article_id=61])
\\