If your organization doesn’t have a set of software standards, ask yourself or your IT Managers the following questions to begin documenting:
- What software is mandatory (business critical or daily driver)?
- What software is required for a particular job or business unit?
- What software is completely optional?
- Who determines which software is used in each of the above categories?
- How is software customized, configured, or installed?
- How is software distributed?
- How often do software requirements change?
- How do you upgrade existing software?
- How is new software tested or evaluated?
Another way to separate software standards is by deployment. Consider the following setup of computers within your organization:
- A standardized configuration of the operating system (basic drivers, network shares, Windows security settings).
- A minimum number of installed corporate-standard applications (MS Office, Adobe Acrobat, etc.).
- Additional software needed to perform job duties (Adobe Dreamweaver, Corel Paint Shop Pro, etc.).
- The ability or inability to allow additional applications and features. Additional software installations could either be only on an approval basis, frowned upon, or forbidden.
- Procedures to obtain permissions, access, and/or procurement of additional software or licenses.
Once the answers needed to develop software standards are determined, you need to make a conscious decision on how to describe your current software. Depending on your organization it may not be wise to disclose your exact version of applications and operating systems. This could be for security reasons, but it’s mostly due to updating your software standards as your organization adopts new software. For some organizations, it’s as simple as the release of new software. For others, upgrading software may be as rare as an eclipse.
For example, we’ll use the Windows operating system. Think of the distinction of Windows 7 Professional x64 versus a supported version of Windows x64. The level of detail will all depend on how often your software changes and of course, how detailed you want the software standards document to be.
Source
Idea modeled from the old software standards found on page Defining Software Standards at Microsoft TechNet.
Are your software standards generic or specific? Why?
