UNOFFICIAL
Source code should reside in some sort of Source Control System - if it
is not, your software developers are doing things the hard way... Point
your developers to
http://www.troyhunt.com/2012/09/life-without-source-control-share-your.h
tml for information. That way, they cannot be intermingled with anything
else. The version control functionality will also protect the
'recordness' of the code.

Someone mentioned that source code should be retained for the life of
the system. I think that is too short a period - especially if the
software has anything to do with business information.

Source code should be retained for at least as long as the information
needs to be kept.

If you do not have access to the source code, there is a real risk that
information can become irretrievable. Inspection of the source code can
also help to prove the integrity of the information.

The National Archives of Australia requires source code (as well as most
application development documentation - business rules, functional
requirements, data dictionaries, system documentation, etc) for software
developed in-house by Federal Government Agencies to be retained for '5
years after (sub)system is defunct and any data supported is either
migrated or destroyed' [disposal class 2086 in the Administrative
Functions Disposal Authority
http://www.naa.gov.au/Images/AFDA_technology_tcm16-44444.pdf (sorry for
the pdf link)]

The rationale for this is to ensure ongoing access to the information
any system manages for as long as it is needed and enables code to be
reused in other applications if necessary. No use wasting the
"Intellectual Property" investment.

I don't think that it would be necessary to retain any 'applications'
files or installers for any significant length of time, because they can
relatively easily be recreated from the source. I would consider those
to be 'convenience copies'. Naturally, copies of the application on
working systems shouldn't be inadvertently destroyed. Also, of course,
this does not apply to any externally developed software - you should
keep the installers for as long as required. If you use Open Source
software, you would be permitted to retain the source code for your own
use, but that might not always be necessary.

Note: These are my own views, but I am fairly certain in this case they
reflect the views of my employer (mainly because I was involved in the
development of the disposal class in question many years ago)

John

John Lovejoy
[log in to unmask]


-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On
Behalf Of Brian Tuemmler


OK, a slightly tangential take...

Source code is, in my mind, a record, but a very different kind of
monster:
- There are three flavors of each piece of source code: the code, the
applications compiled from that code, and the install files created to
put that application somewhere.  (Huge quantities of duplicate files)
For RM purposes, code should probably reside on something OTHER than a
shared network drive because:
	* The files created as a result of the development effort should
be managed and retained as a single unit, because if you purge one wrong
thing, the whole set is useless.  
	* A revision to one piece of the set of files represents a
change to the version and therefore retention of all the files.
	* Access to these files should be severely restricted, compared
to most other content.
	* If these files are intermingled with business records such as
contracts, memos, claims, etc.  Retention of those files will become
just that more difficult. 
	* None of these files will provide any business value if stored
within a document management system, since they would all need to be
checked-out in order to function. SharePoint, by default, blocks many of
these files from ever being loaded in the first place. 

Hopefully some practical thoughts...

Brian Tuemmler
Director, Gimmal
[log in to unmask]
(925) 253 5689

UNOFFICIAL

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]