Oranizational Processes and Standards

I've tried to get the processes and standards i put together into a diagram to better visualize them and the relationships between them:


I've also written little overviews of each element:

Development Process

The development process is that that is used in order to stream line and organize the development effort from the start of a project till the end. Its goal is to help developers repeatedly produce quality software that meets user expectations. It will be made up of a number or other processes, practices and standards which may consist of traditional waterfall approach methods such as a sequence of analysis, requirements engineering, UML designs etc or it may use agile methods such as user stories, pair programming and continuous integration among others.

Coding Standards

Coding standards are qualities of code that must be adhered to by developers. They may include the following:
• What are, how and where to use Assertions
• What is, how and where to use Tracing
• Where to catch and throw Exceptions
• How much and what code should contain comments.
• How to deal with Compiler Warning
• Code metrics: what, how and why
• Globalizing code
• Naming conventions for variables, classes, operations etc.
Coding standard relate to Quality Management in that they define attributes of code that are believe to give it quality value.

Documentation

Documentation should be performed during the development process to give a high level explanation of what the software is meant to do and how it does it. Standards relating to what should be documented and how it should be documented must be defined and documentation should adhere to these. Documentation should be drafted, reviewed and published according to the organizations Document Management processes.

Document Management

Document management defines how documents should be created, reviewed, published, consumed and disposed. It usually included a document workflow and a system for storing and searching for documents.

Peer Review Process

Peer reviews are a quality control process that aim to informally check that code and document standards are being maintained. It involved a developer’s code and documentation being reviewed by a peer. This activity will also encourage better communication, team working and sharing of ideas and technical expertise between peers.

Work Logging

Work logging is the informal practice of developers logging the work they have done, issues they have encountered, solutions they have found and work they must do in order to help them deal with a faster pace of development, documentation and memory loss.

Configuration Management/ Source Control

These are two interrelated issues. Source Control involve being able to keep all code and resources that make up a project in a common location accessible to all developers. It enables many developers to work on the same source using either an optimistic or pessimistic strategy. Source control also involves keeping a history of all the changes made to source code in an efficient manner.
Configuration Management relates to the ability of identifying various versions of the software which has been released to customers and managing them with respect to future versions. Usually a source control tool is used to enable configuration management.

Unit Testing

Unit testing involves writing test fixtures side by side with code being developed. This way as code is changed, if a change breaks existing code it is detected immediately when tests are run. Unit testing aims at having a high code coverage meaning that when tests are run a high percentage of code has been executed. This is something that is very difficult to achieve with manual testing. Manual testing should be used on main use cases and to identify usability and business issues on a project level.

Continuous Integration

Continuous Integration (CI) aims at identifying issues caused when many developers working on the same project work with slightly different versions of the source code. When it comes to integrating, issues that are timely to fix usually occur. Continuous integration involves continuously integrating code, and immediately identifying such issues. A CI server is usually set up to monitor for changes in source code and given various triggers perform a build of the code. It will usually also run unit tests and inform the various stakeholders on the results.

Release Process

Identifying which version of code has gone in which release given for testing or to a client is important for both development and support. A release process is aimed at enabling this. Usually it involves giving the released software a version based on the versioning strategy and tagging a particular version of the code in the source control tool. The release process should be the process by which software is released for quality control via the Issue tracking system so that each issue in the issue tracking system can be pinned to a particular version of software.

Versioning Policy

Versioning software is not a trivial task. A policy must be decided where by the build, release, minor and major version of the software carry some form or meaning, and so that future releases can be made base on past versions. For example if version 1.0.0.0 is release to clients followed by version 1.0.0.1. Then if some clients require some of the new features in 1.0.0.1 but not all of them, then there is no version available to cover the fact that this new version is in between version 1.0.0.0 and version 1.0.0.1. The versioning policy must take this into account.

Issue/ Work Tracking Process

The issue tracking process is a particularly important one. It brings the whole of the organization together. It involves a workflow for issues that go through the various areas of the company (e.g. support, development and quality assurance).

Process Reviews

The various processes within the organization are there to assist developers in developing quality software and meeting business needs. They are not there to restrict them and stagger their creativity. As such each process should be reviewed and refined to the needs of the developers working within a project, during the course of the project and from project to project. This involves various reviews of the processes during the course of the projects and between them.