Natural Order Development

Vision Statement

Create a project management site that will enable rapid professional development of software projects by providing transparently integrated services for source code management, automated continuous integration, automated publications, and trouble ticket tracking.

Epic Requirements

Transparent integration, for the purposes of this project, is defined as one or more services which are configured to tie-in with each other, as well as other external systems such that appropriate publication and client access of the related services appears to be dealing with a single service. The transitions between modules or systems is as seamless as possible with the goal of making the transitions undetectable.

1. Source Code Repository

Source code control is a common requirement in all software development projects. The basic requirements are well understood as:

1. provide mechanisms for checking source code in and out of a central repository
2. allows multiple developers to work on the same project
3. mitigate the risk of lost code or overwritten changes
4. provide version control management of files through the development life cycle keeping track of:
   

   1. which changes were made
   2. who made them
   3. when they were made
   4. why they were made

5. enable version control of a group of files as a single release
6. maintain multiple active releases concurrently (branching)
7. enable joining different releases (merging).

2. Build Service

A build service provides an automated feedback system (i.e. continuous integration) which ties into a Source Code Repository for one or more specific development projects. Specifically the build service is an automated system with the ability to compile/build, test, package, report, and track the quality of changes made to projects. A build service enhances the core abilities of build-tools such as make, Ant, Maven, or MSBuild, and then enabling continuous integration. The build service should:

1. automatically compile projects into functional artifacts such as JARs, WARs, EARs, PDFs, xDocs, executable binaries, etc.
2. automatically execute programmer tests such as xUnit based testing
3. generate project documentation (compile Xdocs to PDFs, create html pages for web publication, etc.)
4. generate distribution artifacts (zip, RPM, Windows MSI files, etc.)
5. create reports and trends for detected errors, code quality, test reports, etc.
6. deploy generated distribution artifacts into integration testing environments and perform automated integration testing (aka smoke testing).
7. deploy successful distribution artifacts and documentation to one or more publicatio0n services

3. Publication Services

A primary key to improving the quality of a project is insuring sufficient, clear-to-read, up-to-date, and easy-to-access documentation. A project documentation system should:

1. Apply the principles of modern production enabling project contributors to create information in small, reusable components that can be automatically assembled for different purposes;
2. Be capable of automatically publishing to multiple types of media, including:
   

   1. Print (PDF),
   2. Web (HTML), and
   3. Other forms.

3. Establish a documentation style that enables post processing for publications.
4. Provide citation management.
5. Automatically generate API documentation from source.

4. Trouble Ticket Services

Trouble ticket (sometimes called a trouble report) is a mechanism used in an organization to track the detection, reporting, and resolution of some type of problem. The Internet Engineering Task Force's Network Working Group specified requirements for a trouble ticketing system in RFC 1297 (NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist). In the RFC document, the author compares the trouble ticket to a patient's hospital chart, because both define a problem and help to coordinate the work of several different people who will work on the problem at different times. The core requirements are that a Trouble Ticket service should provide:

1. Ticket lifecycle management
2. Separation of work groups/units
3. Authorization, i.e. definition of who can access which ticket groups
4. Ticket update and re-assignment functionality
5. Automated email correspondence to ticket groups enabling tracking of updates