• Process Standards obviously specify a process. In most of the cases we are concerned with, process standards are either all-encompassing lifecycle development processes or hierarchies of related processes, each tailored to a specific niche. There are four main sources for Process standards:
• Organizations such as IEEE, ANSI and ISO. These standards tend to span industries, both commercial and non-commercial and do so by being one-size-fits-all.
• End Users such as the DOD, FAA, FCC, FDA, Boeing and Sacramento County. There seems to be a trend here, but that is more due to the nature of the end users than otherwise. What is important is that if you want to develop product for these end users, you will use their standard. They tend to be big enough to say, "Do it my way or don't bother to bid."
• Academic standards from such institutions as the SEI. These standards are put forth from an academic background after much study and refinement. Initially they tend to be too large or require too much documentation, but they are good starting points for refinement. It is not uncommon for individual companies to use an academic standard as a guideline in creating their own internal standard.
• Internally developed standards are where each organization takes what they feel is "a good idea" from other standards and craft something that matches the way they either currently do business or intend to do business in the future.
• Documentation Standards specify what documents are required and/or how the documents should be formatted. It is not uncommon for Documentation standards to also specify how and when they are reviewed, by whom they will be reviewed, and what the approval and distribution procedures are. These standards often specify a corporate look-and-feel for all internal and/or customer-facing documents. Which documents are required could be specified by another standard. Examples of documentation standards include the MLA (Modern Language Association) Style Guides and the Chicago Manual of Style.

• Features Standards specify what features are required in a product, sometimes down to the look-and-feel level. Generally associated with GUI development, Features standards also apply to device drivers, boot scripts, POST diagnostics and other more esoteric development efforts.
• Interface Standards specify what interfaces exist and how to use them. Examples include APIs, database schemas, hardware and public library routines. Obviously there are two classes represented here: Internal and External. External interfaces must be documented to a much more detailed level so that users not familiar with the entity being interfaced to are able to understand and use the interface. Internal interfaces often have an implied user understanding of both sides of the interface and tend to be much less formally documented.

• Reducing risk
• Reducing confusion
• Increasing consistency
• Generalizing data collection and/or reporting

• They are required. Standards may be mandated by customers, governmental agencies, regulatory bodies, etc. In some cases such as ISO-9001, the specific standards are not specified, just that you must have some standards, abide by them and document your compliance to them. In other cases, such as DOD contracts, the specific standards are mandated by the DOD. In the case of DOD-related subcontracts, the standards are mandated by both the DOD and the prime contractor.
• The organization has determined that they need to solve one or more of the problems listed above. Overall, management likes to reduce risk without incurring costs. Standards have tended to be implemented so as to do this with a minimum of cost overhead, though the application of the wrong standard may cause unacceptable levels of cost, schedule extension and risk.
  

• They seem like a good idea. Sometimes the decision to adhere to a standard is because someone in power has done so in the past with good results. Sometimes is it because no one has done this before and a standard seems like a good way to give a project a framework that others have found successful in the past. Regardless, compliance to a standard in this case is not required, so it must seem like a good idea to someone in a position of power.
• As mentioned above, when an organization is new to a problem and wants to minimize risk of failure, management tends to select a Process, a Methodology, a set of Procedures and, yes, one or more Standards to follow. Sometimes the correct ones are selected, sometimes a custom set is created from material found on-line or recommended by consultants and sometimes the wrong ones are picked because they sound good. This last is the most risky and it is often near the end of a project when everything is behind and over budget that it is noticed that the selections cause too much overhead for little or no return on investment.
  
  Why inappropriate choices are made is more of a psychological discussion than a technical one, but the simplest reason is that the standard(s) selected only have a positive ROI on the second or third project to adhere to them. If you are not going to have multiple iterations, it is easy to choose something that requires too much boilerplate to be created.
• CYA. This is more of a personal choice by one or more managers in larger organizations as a way of deflecting failures. If one adheres to a known good set of standards, then the failure must be due to either those downstream (developers not performing to expectations) or upstream (an unrealistic delivery date was mandated). This is not a good reason, and it is not one that actually performs the desired function (CYA) from really savvy top management, but it is all too commonly the reason behind standards selection.
  

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment