|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 7
When all the parties involved get together and try to write down the requirements of a software project, it forces an exploration of the problem domain. The problem domain is the end product described in a human (not computer programming) language. The same end product expressed in a computer language is the solution domain. In the course of exploring the problem domain, many ambiguous details can be identified and discussed, and disagreements can be resolved right from the beginning.
A good specification gives you a well-defined target to aim for as you develop. But it doesn't guarantee that the target won't move. Some adjustments in the vision of the end product are almost inevitable during the design and implementation phases; however, a good specification can help reduce the magnitude of such adjustments. Skipping the specification phase, or not covering the details sufficiently, can lead to the same kind of misunderstanding between parties that can occur with an oral contract. Thus, having a good specification first helps advance the subsequent design and implementation phases to a successful conclusion.
Once you have a written specification that everyone involved agrees to, you are ready for what I call the design phase -- the process of planning, and in some way documenting, the architecture of your solution domain. I include many activities under the name "design," including:
Defining the system:
Building user interface prototypes:
Doing object-oriented design:
Defining the system
As a first step in the design phase, you must partition your system into its component parts. For example, you may require
several processes at various places on a network. You may have some applets and some applications. Some components of the
system may be destined to be written in Java and others not. If you want to use JDBC, you may need to select a third-party
JDBC library that will enable you to access the database of your choice. All these decisions must be made before you can begin
any object-oriented designs of the individual programs in the system.
As you define the system, you will likely want to document your work in one or more technical specifications. Documentation allows you to communicate the design to other interested parties in the organization and to get their feedback. You can pass out the specification, call a design review meeting, then present the system design at the meeting. The group can discuss your design and hopefully find any problems and make suggestions. Getting feedback -- and making adjustments to your system design as a result of the feedback -- is an example of iteration in the process of software development.