Analysis

The Analysis phase of the software development project is concerned with establishing what is required of the system. This phase usually starts with a brief discussion with management personnel, the marketing staff, etc. -- whomever originated the idea. These discussions are oftentimes verbal and describe what the system is to do in rather abstract terms.

A team of developers and potential users of the system should be identified early. It is important that the team include "user gurus" -- persons within the organization who are familiar with existing systems and will possibly be using the system once it is implemented. The team will conduct detailed interviews to establish input, processing, and reporting requirements for the system.

Early in the analysis phase, several documents should be produced. A Preliminary System Description document should briefly outline the expectations of what the system will do, data sources, output reporting, departments involved, etc. It should be a page or less in length and approved by all the "stakeholders" in the system. Such a document can be very helpful in avoiding scope creep as the system is developed.

Design

When the development of the system moves into the System Design phase, it marks a transition from a focus on the problem to a focus on creating the solution. This is not a distinct and separate phase – much of the formation of a system solution has been forming in the minds of the developers throughout the earlier stages of development. Information system design is essentially a process of working backwards. Developers start with the sketches and report layouts developed with customer personnel during the systems analysis process and work “backwards” to identify potential temporary and permanent data entities that will need to be stored. From this process comes the database design.

The processes required for data transformation are separated into a hierarchy of logical “chunks” to handle the flow of information through the system. The chunks represent the highest level of abstraction of the system as a mathematical model; these chunks become modules in the system design. The modules are divided into logical sub-modules, each sub-module representing a more concrete component of the higher-level module. Using Structured Design principles, individual modules are designed to be cohesive (all parts of the module contributing to a single purpose); relationships between modules are designed to make modules loosely coupled (modules do not interfere with the contents or operations of other modules). We have found that the design process can be communicated well to users via the HIPO technique, a highly graphical means of representing the system design in terms of its Hierarchy plus Input, Processing, and Output. Here again, Data Flow diagrams are a useful means of describing system concepts to users.

Coding

During the coding phase, computer modules are written in a high-level language such as C# using Structured Coding principles. The processes required for system flow described earlier are translated into instructions the computer can process in the form of sequences, selections, and iterations. We often use a top-down coding approach where the coding process starts with programming and testing of the highest level modules first with calls to “stubs” representing lower level modules. As these higher level modules are tested, coding is then begun on lower level, more detailed modules.

Testing and Deployment

During the coding phase, emphasis is placed on the rapid development of prototypes. These prototypes can be refined in the repetitive cycles of Agile Development: coding, exposing prototypes to user experiences, feedback from users, coding revision of modules, and then a repeat of the cycle. The emphasis here is to find out what works best for the user’s environment, not to develop elegant code. Once the system is nearing completion, it is helpful to run a Pilot Test, particularly when the system involves several different departments within the organization. It is important that the development team continue to focus on finding errors, easing the flow of information, and the overall experience of the use of the system within the organization -- not to “bend the organization” to fit the new system.

Support

Since the system has been developed in a collaborative and visible manner, much of the resistance to introducing something “new” into the organization will be overcome. We have found that a “kick-off” presentation, either formal or informal, confirms management’s support for the system. Important considerations are the production of user manuals, training videos, and user training meetings.

Since “the only constant is Change”, new possible features for the system may soon be identified. Or sometimes the internal or external environment may change, placing new requirements on the system. For this reason, it is a good idea to maintain the relationships with and within the development team for quick fixes when an unanticipated problem arises and to evaluate (and implement) new or refined aspects of the system.