[Sw_assurance] Help With Software Assurance Scope

[Graham Heyes]

As I have written and said earlier the scope is too broad. I do not  
agree that this should apply to all software development unless it is  
at a level where we basically say " these folks develop software for  
their own use and they do their own Q&A". To be sure for business,  
safety and security systems or systems that deal with motors, high  
power magnets or cryogenics this Q&A makes sense. On the other hand we  
have users and staff who develop systems that have worked well and met  
requirements. They have their own Q&A processes even if that is just  
"I tested it and it does what I want". Imposing a Q&A process that  
adds no value onto these people will only reduce their productivity.

I suggest that we look carefully at where we want to apply more  
rigorous Q&A top down then in less critical areas document what we do.

As far as FPGAs are concerned they should be exempt in everything  
except safety interlocks and systems controlling hardware that would  
cause damage or injury if the FPGA misbehaved.

My 10c worth, regards,

	Graham


On Jul 27, 2009, at 8:48 AM, Kelly Mahoney wrote:

> As some of you know, the QA/CI department is developing a "Software  
> Control" procedure as part of the Lab's overall QA framework.  Many  
> comments on the draft document have to do with the scope.   
> Basically, the document must apply to all JLab software development  
> - everyone needs some form of software assurance with some minimum  
> set of attributes that depend on how important the software is to  
> the lab.  However, we have to use a little common sense and know  
> that not every little piece of software is subject to the QA  
> process.  This makes the definition of the scope of the procedure  
> very important.  I include a copy of the latest draft scope below.
> 1.) If you would, take a look and give me some constructive feedback  
> on how it can be both more succinct and utile to you.
> 2.) How should the scope apply to contractors, users, ...etc?
> 3.) I would like to hear your opinion on the applicability to  
> reconfigurable devices like FPGAs.  (NASA and DOD handle them  
> similarly.)
>
> Thanks,
>
> Kelly
>
> 1Scope
>
> The scope of this procedure compliments the JLab cyber security  
> enclave structure with the addition of Facilities Management and  
> Safety Systems software.  The procedure specifies software assurance  
> activities and requirements for software developed, acquired, and  
> maintained by Jefferson Lab or on behalf of Jefferson Lab. It  
> applies to all JLab projects, programs, facilities and activities  
> that may have an impact on JLab’s mission and goals. This procedure  
> does not specify specific processes or models; rather it provides a  
> set of basic requirements and tools applicable to any lifecycle model.
>
> Individuals responsible for software within each division,  
> department or group that purchases, develops, modifies, or produces  
> software applications that may impact JLab’s mission shall follow  
> the requirements of this procedure. The impact to JLab’s mission and  
> goals is assessed using a software risk assessment tool described in  
> section 4 of this document.
>
>
> This procedure is applicable to all Jefferson Lab software assurance  
> activities during the entire lifecycle of the software developed or  
> acquired including:
>
> ·         internal software development
>
> ·         software used to collect and manage data
>
> ·         startup and configuration scripts
>
> ·         incorporation of open source software
>
> ·      modified off the shelf (MOTS) software used to design,  
> analyze, or control safety or mission essential aspects of JLab  
> operations.
>
> ·    commercial off the shelf (COTS) software used to design,  
> analyze, or control safety or mission essential aspects of JLab  
> operations.
>
> ·         programs and firmware for monitoring or control, including  
> IOCs and PLCs
>
> ·         modifiable embedded software and firmware including PICs  
> and PC104 type SBCs
>
> ·         programs and development software for field programmable  
> integrated circuits such as Field Programmable Gate Arrays.
>
> ·         Other software as defined by the JLab Chief Information  
> Officer.
>
> Generally, this procedure applies to configuration items that may  
> impact Jefferson Lab’s ability to conduct operations safely and  
> effectively.  The impact a software configuration item may have is  
> assessed using the software risk assessment tool referenced in Part  
> 4 of this document.
>
> This procedure only applies to security software configuration items  
> insofar as the impact ineffective security software controls may  
> materially affect operations and safety.
>
>
>
> Exemptions
>
> 1.    This procedure does not apply to unmodified general purpose  
> computing software, unmodified enterprise software, and general  
> purpose desk-top software managed under the IT/CIO Division.   
> Examples include office productivity software, public web pages, and  
> LAN/WAN networking software.
>
> 2.    Other software configuration items as excluded in writing by  
> the Jefferson Lab Chief Information Officer (CIO).
>
>
> <mahoney.vcf>_______________________________________________
> Sw_assurance mailing list
> Sw_assurance at jlab.org
> https://mailman.jlab.org/mailman/listinfo/sw_assurance

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/sw_assurance/attachments/20090727/f5ec1832/attachment-0001.html