M3IO Software Development Standards

Contents

REVIEW
CODING
General
Fortran
C/C++
Scripts

Introduction

This document started as the set of standards for the EPA Models-3 project, and was continued by the author while at the North Carolina Supercomputing Center, then at Baron Advanced Meteorological Systems, LLC. [BAMS], and now at UNC's Institute for the Environment. It is the software development standard under which the Models-3 I/O API, the MAQSIP air quality model, the NCSC/BAMS operational-forecast tools and models, and various other software systems were and are maintained. It is offered here for use with such other projects as may find it useful.

(There are still some "dangling" BAMS references, e.g., to the Chief Architect, Chief Operations Officer, test vs production repositories, etc. These give some level of recognition to the importance of the items that reference them.)


REVIEW

Review processes are envisioned as a mechanism providing control and feedback into the analysis, design, implementation, testing, and use of software and data. It is expected that the scope and extent of the review processes will be highly dependent upon the size and complexity of the software being reviewed.

The resources required are mostly the time of the personnel involved, and should usually amount to about 10 - 20 % of the man-hours required for the initial software development.

It should be recognized that the review processes should not only result in higher quality in the software developed, but also in the increased communication and software development expertise of the personnel involved.

At the present time, review shall require design and/or code walk through that involves the Chief Architect and the Chief Operations Officer or his designate.

Design review objectives include the following:

Code review objectives include the following

An especially important aspect of design and code is that of interfaces.
Interfaces include:

Good design, with modularity and flexibility, is largely the art of finding that separation of software into components which yields the best and simplest set of interfaces, where each task is internally cohesive, and produces internally consistent objects that are then inputs to other processes.

Generally, interfaces should be kept as simple--and as standardized--as possible. For example:

General Requirements

Back to Contents


Coding

General

Back to Contents


Fortran

Back to Contents


C/C++

Back to Contents


Scripts


UP: I/O API home page

$Id: STANDARDS.html 75 2018-01-12 15:48:16Z coats $