Software Development Taxonomy

Software is not all alike nor is all software written for the same purpose. To understand the issues in software development we need to first identify the different categories of software that might be developed. The following list is a taxonomy based on how each type of software affects the development process.

  • Applications
    • Individual
    • Organization
  • Product
    • System
      • Operating System
      • Utilities
      • Libraries
      • Tools
      • Application Enabler
    • Consumer
    • Productivity
    • Entertainment
  • Internal
    • Demonstration Prototype
    • Feasibility Prototype
    • Test Jig
    • Throw-away

Each of these classifications has its unique problems for the developer.For the remainder of this chapter, I will collapse this taxonomy into the two main types, applications and products, and show how the difference affects various aspects of software development.

Two Basic Categories

Application software is a software system that is designed and written for a limited number of clients. It may be an in-house project that creates a one-of-a-kind data processing system. It may be a system written by a consulting or contracting company that will be installed at several locations, but is not made available for direct sale to anyone else.

A software product is a software system that is designed and written for a large number of customers. Generally, a software product is "shrink-wrap" software and is also referred to as packaged software. Software products can be further divided into several sub-categories. Among these are general-purpose software (e.g. word processor, spreadsheet), application development tools, general-purpose programming tools and libraries, and system software.

Although there are many similarities between the two classes of software, there are significant differences that will affect the organization of the software development organization, development process, and funding. The following table shows some of these differences.

Attribute Application Product
Primary Contract Code
Customer Single or few Many
Key Personnel Project Manager, Analyst Programmer, Q/A, Support
Project Management Strict Flexible
Specialist (contractor) High Low
OTS Software integration High Low
Schedule Fixed by contract Flexible, fixed by market opportunity
Funding Milestone payment Capital, existing product

It is vitally important to a software development organization that it determines which type of software it will produce and to then design its processes and hire personnel appropriately. Many application development organizations attempt to shift to product development at some time. This can be very difficult if the organization does not understand the differences between the two types of development and the changes that may be necessary. Similarly, a product development organization that wants to also provide integration services must divide the two types of development into separate functional organizations.

This diagram shows the relationship of application software to software products. In essence, applications are built most efficiently using software products as the base.

Applications are constructed from general-purpose programming tools and libraries, application development tools and general purpose programs.

Primary Attribute

The most important attribute of application development is "the contract." A list of specific requirements is created, both parties agree to the specification, and then the developer produces and delivers the software to the customer. At that point the software is complete, although a new contract may be created to add more functions or adapt the system for some reason. There is a start--work--finish timeline to the project. The software developer must have specific, detailed requirements to know when the project is complete, and to determine the cost to the customer for the software. Creation and management of the contract are the most critical activities for this type of development.

For software product development, the most important attribute is "the source code." The product must evolve over time, must be built and distributed in an on-going basis. As computer technology changes, the software must be constantly adapted to meet the current state of the art. If the source code is not carefully managed and maintained, it will be impossible to continue the product over a long period of time. The timeline for product development is a process of develop-distribute-enhance-distribute in a never-ending cycle.

Customer

Application software is designed and written for one or a very few customers. The deliverable software is specific to the customer and is specified through the contract.

Product software is designed and written for a large number of customers. The deliverable software is generic in functionality and attempts to incorporate a combination of features that will reach the largest number of customers.

Personnel

The key personnel in an application software development organization are the project managers and analysts. Due to the strict contractual requirements of this type of software, it is important that the development be tightly managed. The software must be delivered to the schedule defined by the contract, within the budget, and with all the features in the specification. Systems analysts play a vital role in discovering and documenting the customers' requirements. If the requirements are not correct, are vague or not what the customer really needs, the software project will not succeed.

Programmers and testers are of secondary importance in application development. In many cases, programmers can be hired on an as-needed basis to staff the project. The number and skills of the programmers must be matched to the requirements stated in the contract. Thus, it is not wise, or necessary to have a large number of programmers as permanent members of the organization. Since the source code will be used to create and deliver a single system, it is not as important to retain the people who developed the system. Maintenance and enhancements can be done as a new project with the costs of learning how to modify the system covered by the new contract.

The software architect is important to application development, but not as critical as for product development. The architect must design a structure that will meet the customer's requirements, but does not need to develop a system that can cover a wide range of applications.

The key personnel in a product software development organization are the programmers, Q/A and "builders". Because product development is on going, it is important for the organization to be able to constantly evolve, adapt, and otherwise modify the source code to meet changing customer demand. Much of the work on software products is done in response to technology changes. For example, a new communications protocol becomes standard and the software product must be adapted to use that protocol. It is vital that the organization has a detailed, in-depth knowledge of the source code so that it can quickly and safely modify the source code. If the programmers who have detailed knowledge of the source code are not retained, the cost of making enhancements to the software must include time for the programmers to learn the software before making significant changes.

The software architect is probably the most important programmer on the product development team. This person must insure that the basic design of the system is flexible enough to withstand modifications over a long period of time.

Q/A personnel play an equally vital role. Q/A is not simply involved in testing the running system against a fixed specification. Instead, Q/A must constantly perform regression tests to insure that modifications to the product do not break existing customers' installations.

Finally, the Builder is perhaps the most important person of all. The Builder is the person or persons responsible for compiling the source code and producing a stable, installable system. Unless the product can be built consistently and reliably, the product will never succeed. (If you don't know what you built, then you don't know what you are testing, fixing, and shipping to the customer.)

Because of the dynamic, constantly evolving nature of software products, project management is much more flexible than in the case of application software development. In many cases, the project manager can also be a programmer (a kind of "player-coach"). However, as the development organization gets larger and the size of the product increases, project management becomes more important.

Project Management

Project management for application development must be rigorous. Unless the schedule and requirements are met, the development organization will not be successful. The project managers for an application must carefully select the personnel needed to meet the contract. This will most likely involve hiring contract programmers and specialists, or choosing carefully from among the permanent employees, giving them a specific task, and insuring that that task is completed on time.

Management of software products must be flexible. The product will constantly change in response to expanding markets, customer needs and technology changes. It must be possible to change priorities in response to the constantly shifting requirements.For product development, the managers must build a team that can work cooperatively over a long period of time. This means, more than anything else does, that the manager must insure the programmers develop trust and respect for each other.

Specialists

A specialist is a consultant, designer or programmer with specialized knowledge. For example, some programmers concentrate on, and become expert in, database design and programming. This type of programmer is extremely useful to application development organizations since their existing knowledge allows for a lower cost and quicker time to completion for the application. Often the specialist is hired only for a short time on a fixed contract that runs concurrently with the application development. Since the next customer and project may not require the specialized knowledge, it is not necessary to retain the specialist in-between projects.

In the case of product development, specialists are of more limited usefulness. The programmers working on a software product need to be able to work on all (or at least most) of the code in the system. This allows shifting personnel to the most time critical parts of the development project. Programmers working on product software must also be able to quickly acquire a basic knowledge of new technologies. They do not necessarily need to become an expert in those technologies, but must instead be able to quickly grasp how the technology can be adapted and integrated into the software product.

Off-the-shelf Software Integration

For application development, there is a high use of off-the-shelf software. The more the system can be built by combining existing software pieces, the quicker and cheaper the software can be built. The cost of purchasing the OTS software can be factored into the contract with the customer.

For product development, use of OTS software should be low. The more third party software is incorporated into the product, the less control the organization has over the architecture and functionality of the resulting system. More importantly, it may be very difficult, and expensive, to modify the OTS software in a way that it matches the product. In the worst case, the vendor of the OTS software may go out of business, making it impossible for the product development organization to continue to update the product. Finally, the cost of licenses can quickly eat into the profits of the product. In general, product development should only use well-documented libraries and components where source code can be obtained at a reasonable cost. Major functions should not be purchased unless the organization is ready and willing to spend months (or even years) overhauling the purchased software.

Schedule

For application development, the schedule is determined by contract. The schedule may be open-ended, but will almost always include some specific milestones that must be met. Changes to the schedule will require a re-negotiation of the contract and payments.

Product development schedules are notoriously flexible. Shifts in customer demand, technology changes, etc. can cause a corresponding shift in priorities and what was initially scheduled must change. A product's features are also less well defined at the beginning of the project than the more strict requirements of an application. Often, when developing a new product, the needed features have to be discovered by trial and error. A prototype system is built, presented to a potential customer for comments, and then revised on the basis of those comments. With this type of development, the schedule for delivery will expand and contract over time.

Funding

Application development is funded either from existing cash or from milestone payments by the customer. Even with limited cash, an application development organization can often get started and only hire on programmers as needed. This reduces the cash flow requirements such that the project is paid for piece by piece. If properly managed, there is little risk of going broke on one singe project.

Product development must be funded "up-front" from either existing cash or revenue from existing products. Because of this requirement, product development by new companies is often funded from venture capital. Until the product is complete and shipped to a large customer base, there is a constant risk of lack of funding. Furthermore, if the product misses its market, all the investment will be lost. In short, software product development is a high-risk enterprise operating in a highly competitive market. The rewards can be enormous, but most product companies never make it or go broke after about 5-10 years.

 

Links: