Development Tasks, Part 4

This is the fourth part of a series describing the development tasks for a software
project. See Software Development Process and Development Methodology for the
context of this topic.

Implementation

Fill in the details of each method, and add test cases to the test harness to
exercise any that are non-trivial.

The coding should be guided by a set of coding standards. You should include
error handling from the first cut of the code so you can tell if its working
correctly. My usual approach is to start with a simple error message with file
name and line number to the console on the first cut and then add more
sophisticated error handling in subsequent rounds of development.

The code should be reviewed by other team members. This provides a mechanism to
spread the knowledge of how the system works across a broader cross section of
the team.

Documentation

Typical documentation includes on-line help (including tool-tips), user
manuals, and installation guides. You may also need to provide administration
guides if the system is complex.

The design documentation and programmer's guides should also be included in
the document set if the system is to be able to be extended by others.

The project documentation should be kept for reference by the maintenance team.

Use Case Test

We need to be able to demonstrate that the classes have been built correctly.

Interface and Application Integration

The aim is join the separately developed components into a single unified
system.

Combine the application and user interface classes.

Create shell scripts to mediate between executables and set their environments
and parameters. Retest the scenarios using the UI as a driver instead of
the test cases. Use the test plan as a guide to walk through the user transactions
that establish the test pre-conditions, then test the scenarios.

Generalization

The aim is to improve the design using a bit of hindsight.

Examine the class design in the light of implementation to find improved
structures. Review future increments to find potentially reusable classes
and separate out the reusable parts into new abstract classes. Look for
standard design patterns.

It is possible to spend too much time in this phase, finessing the code
without making significant improvements. It is possible to over do the
generalization, making the code harder to understand.

System Integration Testing

Many systems need to interface to other systems. These interfaces need to be
tested. This testing requires a different approach as it usually involves
other organisations.

Liase with the the system administrators of the other systems to organise the
test. Develop the procedures necessary for the systems to interconnect. Put the
remote systems into test mode and pass test data across the connections. Use
the test harness logging to verify that the systems communicate correctly.

Packaging

Once construction has finished, the system has to be packaged so that it can be
easily installed on the client’s machines.

The build script will include a mode that builds the delivery package. Once built
and tested, the files are copied onto the distribution media. Include a script
that will install the package onto the client’s system, possibly replacing the
previous version, and upgrading the client’s data files as necessary. The data
upgrade should be non-destructive so that the client can back out the upgrade
if they so wish.

Acceptance Testing

The client needs to assure themselves that they are getting what they paid
for.

You will need to support their testing by providing an environment that
allows the testing to be performed and the results to be gathered into
a useful format.

You will also need to provide some guidance on what tests to perform. While
the client should design the tests based on their requirements, it is the
development team that really understands what the product can do.

Post Implementation Review

The aim is to identify anything that could have been done better.
A combination of one-on-one interviews and team meetings should be used
to illicit ideas for improvement of the development process and the
product. The use of blogs and wikis by the team members should also be
encouraged as a means of proposing improvements to the process.


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.