Sponsored Link •
Phase 1: Specifying the problem domain
The specification phase of a software project involves bringing together all the concerned parties to discuss and define the end product of the software development process. During specification, you define "the vision" -- the target you will aim at for the remainder of the project. The deliverable that should come out of the specification phase is a written document that defines the requirements of the software system.
The requirements specification is much like a contract. It is a contract between all the concerned parties, but most importantly from the developer's perspective, it is a contract between the developer and whatever party desires the end product in the first place: perhaps a client, a customer, management, or the marketing department. When a specification is agreed to in spoken terms but is not written down, it is basically an oral contract. Although an oral contract is legally binding, in many cases not having something written down is a recipe for trouble. Different people tend to have different recollections of oral agreements, especially when it comes to details. A disagreement on details is even more likely if the details were never discussed as part of the oral agreement in the first place, which is a common feature of oral contracts.
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.
Phase 2: Designing the solution domain
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.
Building user interface prototypes
Building a user interface prototype is often a valuable activity during the design phase. Once the user interface prototype is completed, the parties that agreed to the specification can gather together again to review the preview version. Having a prototype gives the parties another chance to visualize and discuss the end target. By requiring everyone who agreed to the specification to review and sign off on a user interface prototype, you help ensure that all parties have compatible expectations for the end product. With the visual tools available today for the development of Java-based user interfaces, developing a user interface prototype can be very fast, and the end result is a framework of Java code that you can then endow with functionality during the implementation phase.
Note that the process of demonstrating a user interface prototype is a prime example of the iterative nature of the development process. When the interested parties (who have all agreed on a written specification) actually see user interface prototypes, they often have new ideas, or a better understanding, or a more detailed understanding -- in other words, a clearer vision -- of the end product. During the demonstration, some adjustments may be made to the specification. By this time, however, hopefully the adjustments will be minor.
Doing an object-oriented design
As you design a Java program, you must think in terms of all the programming technologies offered by the Java language, including multithreading, garbage collection, structured error-handling, and object orientation. Yet, because the dominant architectural characteristic of the Java programming language is object orientation, a Java program design phase is fundamentally a process of object-oriented design.
Doing an object-oriented design involves creating inheritance hierarchies and designing the fields and methods of individual classes and interfaces. Three basic categories of classes that you will come up with in a design are:
User interface classes are those that compose the program's
user interface, such as classes that represent windows and dialogs.
Problem domain classes are those that represent objects that
you identified in the problem domain. For example, if your problem
domain involved elevators, you might have an
class in your solution domain. Data management classes are
those that you create to manage objects or data. Neither user interface
classes nor data management classes have corresponding objects in the
Phase 3: Implementation
Implementation is coding. Writing for loops, if statements, catch clauses, variables, and comments; compiling; unit testing; bug fixing -- that's implementation: the stark act of programming.
Phase 4: Integration and test
During the integration and test phase, the members of the project team, each tasked with building a specific part of the whole, meet and try to get all the pieces of the software system to work together. During this phase the team members find out how well the interfaces between the individual system components were defined and communicated during the system partitioning phase. The coding that takes place during this phase should primarily be bug fixing.