First, look at what effort goes into a software product. Figure 2.1 identifies a few of the abstract pieces that you may not have considered.
Final Product Software Architecture
Oh yeah, don’t forget the Software
Code
Design Documents
Schedules
Feedback from Previous Versions
Competitive Information
Look and Feel Specifications Product
Reviews
Test Plans Customer Surveys
Usability Data Product
Specification
Final Product
FIGURE 2.1 A lot of hidden effort goes into a software product.
So what are all these things, besides the actual code, that get funneled into the soft- ware? At first glance they probably seem much less tangible than the program listing a programmer creates. And they definitely aren’t something that can be viewed directly from the product’s CD-ROM. But, to paraphrase a line from an old spaghetti sauce commercial, “they’re in there.” At least, they should be.
The term used in the software industry to describe a software product component that’s created and passed on to someone else is deliverable. The easiest way to explain what all these deliverables are is to organize them into major categories.
Customer Requirements
Software is written to fulfill some need that a person or a group of people has. Let’s call them the customer. To properly fill that need, the product development team must find out what the customer wants. Some teams simply guess, but most collect detailed information in the form of surveys, feedback from previous versions of the software, competitive product information, magazine reviews, focus groups, and numerous other methods, some formal, some not. All this information is then studied, condensed, and interpreted to decide exactly what features the software product should have.
PUT YOUR FEATURES IN PERSPECTIVE WITH FOCUS GROUPS
A popular means to get direct feedback from potential customers of a software product is to use focus groups. Focus groups are often organized by independent survey companies who set up offices in shopping malls. The surveyors typically walk around the mall with a clipboard and ask passers-by if they want to take part in a study. They’ll ask a few questions to qualify you such as “Do you have a PC at home? Do you use software X? How much time do you spend online?” And so on. If you fit their demographic, they’ll invite you to return for a few hours to participate with several other people in a focus group. There, you’ll be asked more detailed questions about computer software. You may be shown various software boxes and be asked to choose your favorite. Or, you may discuss as a group features you’d like to see in a new product. Best of all, you get paid for your time.
Most focus groups are conducted in such a way that the software company requesting the information is kept anonymous. But, it’s usually easy to figure out who they are.
Specifications
The result of the customer requirements studies is really just raw data. It doesn’t describe the proposed product, it just confirms whether it should (or shouldn’t) be created and what features the customers want. The specifications take all this infor- mation plus any unstated but mandatory requirements and truly define what the product will be, what it will do, and how it will look.
The format of specifications varies greatly. Some companies—especially those devel- oping products for the government, aerospace, financial, and medical industries—use a very rigorous process with many checks and balances. The result is an extremely detailed and thorough specification that’s locked down, meaning that it can’t change except under very extreme conditions. Everyone on the development team knows exactly what they are creating.
There are development teams, usually ones creating software for less-critical applica- tions, who produce specifications on cocktail napkins, if they create them at all. This
has the distinct advantage of being very flexible, but there’s lots of risk that not everyone is “on the same page.” And, what the product finally becomes isn’t known until it’s released.
Schedules
A key part of a software product is its schedule. As a project grows in size and complexity, with many pieces and many people contributing to the product, it becomes necessary to have some mechanism to track its progress. This could range from simple task lists to Gantt charts (see Figure 2.2) to detailed tracking of every minute task with project management software.
3/1/2006 4/1/2006 5/1/2006 6/1/2006 7/1/2006 Task 1
Task 2 Task 3 Task 4 Task 5
FIGURE 2.2 A Gantt chart is a bar chart that shows a project’s tasks against a horizontal timeline.
The goals of scheduling are to know which work has been completed, how much work is still left to do, and when it will all be finished.
Software Design Documents
One common misconception is that when a programmer creates a program, he simply sits down and starts writing code. That may happen in some small, informal software shops, but for anything other than the smallest programs, there must be a design process to plan out how the software will be written. Think about this book, which required an outline before the first words were typed, or a building, which has blueprints drawn before the first concrete is poured. The same planning should happen with software.
The documents that programmers create vary greatly depending on the company, the project, and the team, but their purpose is to plan and organize the code that is to be written.
Here is a list of a few common software design documents:
• Architecture.A document that describes the overall design of the software, including descriptions of all the major pieces and how they interact with each other.
• Data Flow Diagram.A formalized diagram that shows how data moves through a program. It’s sometimes referred to as a bubble chartbecause it’s drawn by using circles and lines.
• State Transition Diagram.Another formalized diagram that breaks the soft- ware into basic states, or conditions, and shows the means for moving from one state to the next.
• Flowchart.The traditional means for pictorially describing a program’s logic.
Flowcharting isn’t very popular today, but when it’s used, writing the program code from a detailed flowchart is a very simple process.
• Commented Code.There’s an old saying that you may write code once, but it will be read by someone at least 10 times. Properly embedding useful comments in the software code itself is extremely important, so that programmers assigned to maintain the code can more easily figure out what it does and how.
Test Documents
Test documentation is discussed in detail in Chapters 17–20 but is mentioned here because it’s integral to what makes up a software product. For the same reasons that programmers must plan and document their work, software testers must as well. It’s not unheard of for a software test team to create more deliverables than the
programmers.
Here’s a list of the more important test deliverables:
• The test plandescribes the overall method to be used to verify that the software meets the product specification and the customer’s needs. It includes the quality objectives, resource needs, schedules, assignments, methods, and so forth.
• Test caseslist the specific items that will be tested and describe the detailed steps that will be followed to verify the software.
• Bug reportsdescribe the problems found as the test cases are followed. These could be done on paper but are often tracked in a database.
• Test tools and automationare described in detail in Chapter 15, “Automated Testing and Test Tools.” If your team is using automated methods to test your software, the tools you use, either purchased or written in-house, must be documented.
• Metrics,statistics, and summariesconvey the progress being made as the test work progresses. They take the form of graphs, charts, and written reports.