|
|
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 2 of 7
Besides being chaotic, the software development process also tends to be rather iterative. As a software product is developed, it continuously evolves based on feedback from many parties. This iterative process works from release to release (each release is one iteration) and within the development cycle of a single release. From release to release, for example, the feedback of customers with the current version indicates which bug-fixes and enhancements are most important to make in the next version. Within the development cycle of a single release, the vision of the end target is continuously adjusted by forces within the company as development progresses.
Despite the chaos and iteration, however, I have found that most development teams try to enforce some structure on their development efforts. For the purposes of this column, I'll loosely divide the software development process of a single release cycle into these four phases:
With these four phases I intend to capture a structure that I have observed in most software development projects. Because each company is different, each team is different, and each project is different, these four phases form only a rough outline of a typical development cycle. In practice, some phases may be skipped or may happen in a different order. And because the iterative nature of software development tends to bubble up through any imposed structure, these phases may to some extent overlap or bleed into one another.
When I talk about design in the Design Techniques column, I am talking about the activities that take place during step two of the above list. To give you a better idea of what I mean by each phase, I describe each individually in the next four sections.
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.