1.1. Developing Software Products Figure 1-1 shows the different activities that are generally involved in creating a software product, though it's only a loose description of what really happens when developing software. The activities probably don't occur in the same order in your experience, and each one is often repeated many times as a product is developed and maintained. You can probably also add some other arrows from experience with different projects that you've worked on. Some projects may not even have had all their activities connected, which is one of the things that a good development environment can help you with. Figure 1-1. Typical activities involved in creating software products 
Large or small, formal or more relaxed, open or closed (see Section 1.2, later in this chapter), all software projects have activities that resemble those shown in Figure 1-1. A short description of each activity follows:
Product marketing -
This goes by many names, but whatever it is called, it always involves creating the ideas for the product. A subtle blend of technical knowledge about what has been done and what might be possible is combined with some imaginative flair for what might actually be wanted by potential customers. This is different from general marketing, which is described below.
Gathering requirements -
The process of collecting information to clearly communicate to everyone in the project exactly what the product is supposed to do. Some different ways that this information can be described include documents, prototypes, and examples of how the product would be used.
Writing functional specifications -
Functional specifications describe how the product can be created to fulfill the requirements.
Implementation -
The gritty edge, where the product is actually created. A surprisingly small amount of the total time to develop a product is usually spent here.
Testing -
This is where the implementation is compared with the requirements. A surprisingly large amount of the total time to develop a product is usually spent here, and yet this is commonly the first thing removed from busy schedules.
Documentation -
Documentation describes how to use the product. Internal documentation may also describe how to maintain the product for future developers. Often written by a group called something like Technical Publications.
Release -
The process of shipping the product to customers and making sure that the product will work properly outside the environment in which it was developed.
Marketing -
Creating and controlling the market for the product. It also involves changing the product to suit the market, which connects back to the product marketing stage.
Sales -
Persuading customers to use the product, often with the expectation that they will pay money for it.
Support -
Helps the customers use the product when the documentation doesn't answer their questions. Support also provides a contact point for any licenses needed to use the product, and may cover training as well.
Maintenance -
If the product is commercial or is widely used, then as the world around it changes, the product will need work to keep it functioning properly and hence producing more revenue and happy customers.
End of support -
Eventually no one wants to buy or use the product, not even the developers. Customers need to be told when product support will end, and the whole development environment and source files need to be carefully archived.
Some projects have particularly small or nonexistent activities, or the different activities may be connected very differently. For instance, the requirements document in a small startup company can often be the result of a late-evening "wouldn't it be cool if..." session. A large project with hundreds of developers may have rigid requirements, with regular quarterly meetings to discuss changes to the design documents. Some activities not mentioned above include those performed by management, IT staff, and the legal departmentall necessary overhead. |
