Section 4 Size and Complexity Drive Development Strategies Before discussing the selection of a computer language in which to develop a software system, it is necessary to discuss the size and expected use of the system in question. Small systems developed for personal use certainly do not need the scrutiny of large systems that are an integral part of the business process. For our purpose, approximate sizes in terms of lines of code (LOC) will be used to estimate the size and complexity of a software system, with the understanding that this is only a very broad generalization. In the first place, it is impossible to project the exact size of a system that does not yet exist. Second, different computer languages have different amounts of expressiveness, so 10,000 LOC, for example, could do much more "work" in one language than another. Third, two software systems with the same size in LOC can have different properties of complexity, depending on the particular applications. Nevertheless, LOC is a well-understood means of measurement, and it serves the purpose of approximating size and complexity in software systems. This physical size estimate is a reasonably good indicator of the potential complexity of the system, the number of people required to complete the work, the amount of communication involved, the expected lifetime of the product, and other issues that determine the necessity of using a solid, software engineering process. For the size and complexity discussion, the following approximations are used: < 10,000 LOC is small and not complex between 10,000 and 50,000 LOC is medium and moderately complex between 50,000 and 1,000,000 LOC is large and very complex > 1,000,000 LOC is very large and immensely complex With knowledge of the proposed system’s size and complexity characteristics, an organization can begin to formalize a strategy for creating new systems. An effective part of any development strategy is to look for solutions that already exist in the marketplace. It is usually more cost-effective to purchase a product (assuming a quality product that satisfies system requirements exists) than to develop one. No matter how simple or small the development of a system appears to be, it is almost always more involved than anticipated. The true costs, in terms of time and other resources over the entire lifetime of the product, are not easy to see at first. Buying a suitable product is an option that must be seriously considered. With larger systems and ones supporting specialized requirements, it is less likely that a single COTS product exists to satisfy the entire set of system requirements. However, commercial products should always be investigated first, regardless of the expectation of finding something suitable. A mix of COTS products and developed subsystems integrated together can also provide a complete system solution at a fraction of the cost of a total system development. If it is recognized from the outset that a software system will be at least medium-sized and/or long-lived, then the assumption must be that its size will continue to grow indefinitely. This demands that the development strategy consider the ramifications of anticipated future maintenance for the system. A medium-sized system will perform reasonably complex work. It will undoubtedly be expanded, and it may later be desirable to integrate it with other systems. An organization cannot afford to waste the time and effort used to develop a system of this size by making it impossible to modify and expand it. Good, solid engineering practices must be used. It should go without saying that systems that are recognized as being large or very large from the outset need to be developed using good engineering practices. The concern here becomes how to manage the complexity inherent in such systems, particularly the very large ones. Techniques must be considered from the outset which can partition the system into isolated subsystems, where these subsystems communicate with each other in only very well-defined ways. This is one of the important advantages to current object-oriented analysis techniques. They facilitate this type of partitioning, an absolutely necessary step in establishing and maintaining the usefulness of very large software systems. Table 1 summarizes the decision process that determines appropriate methods and languages for various projected sizes of software systems. The key is to establish business practices that make the software investment most cost-effective. Purchasing a suitable product is often the most cost-effective practice and should always be considered first. However, once COTS possibilities have been exhausted, in-house development is required (this includes contracting with an outside source to develop a system for in-house purposes). When the investment is small, reaccomplishment is affordable. However, the larger the investment, and the more it becomes dependent on other software (making the investment much larger), the less affordable simple practices (leading to complete reaccomplishment) become. Management must take control of significant software development. It should be emphasized that COTS software should always be considered first. However, COTS is not a panacea. Using a COTS product establishes a commitment to a product and a vendor for the life of the system. In some cases, this can prove to be very expensive in the long run [Houser 95]. An organization may consider attempting to perform in-house maintenance on a COTS product to overcome the problem of relying on a particular vendor. However, this will almost invariably end up being more expensive than developing the system in-house in the first place. Maintenance of someone else’s product is extremely difficult and time-consuming, and maintenance is responsible for the majority of a system’s expense. Hence, COTS decisions must be made carefully. It should also be emphasized that a well-defined development process must be the basis for any decisions made from these tables. Where such a process does not already exist, it must be defined first [Humphrey 89]. If an organization does not know how to begin to develop one, then it should look for outside help from qualified software engineers. Table 1: Relationship of Size and Complexity to Development Process Projected Software Size and Complexity Development Process Considerations Small and not complex Buy an appropriate existing commercial product Otherwise, an individual can develop it Use a 4/5GL for this specific type of application if available Otherwise, use existing resources or purchase an inexpensive development environment Expect software to remain stand-alone and to become obsolete within a few years Medium and moderately complex Includes small projects that will grow into larger projects Consult organization’s business plan to ensure compatibility of software decisions Consider COTS products If reasonable expectation that a developed system will be replaced with existing COTS product (not "vaporware") before becoming obsolete, then determine language and development method from current resources Otherwise, use engineering practices described below for larger systems Large and very complex Includes medium-sized projects that will grow into large systems Consider COTS products for satisfying some part(s) of the system requirements Use good, solid engineering practices Consult organization’s business plan Select appropriate language using Tables 2 and 3 Select appropriate product(s) using Tables 4 and 5 Very large and immensely complex Includes large projects that will grow into very large systems Consider COTS products for satisfying some part(s) of the system requirements Use good, solid engineering practices Consult organization’s business plan Select appropriate language using Tables 2 and 3 Select appropriate product(s) using Tables 4 and 5 Control immense complexity from the outset Consider defining separate subsystems that can each function as a stand-alone system When considering various language characteristics, it is important to make a distinction between those characteristics inherent to a language (because of the language definition) and those characteristics of products that implement and support the language (compilers and related tools). Most "language wars" tend to mix these two together, and they end up basing arguments on comparisons between "apples and oranges." In the following guidelines, language is considered first, independent of specific products. However, issues relating to the availability of development tools are considered in the language selection process, along with many other software engineering factors affecting an organization. The selection of specific development products follows the language choice.

Sections

1

2

3

4

5

6

7

Appendices

A	B	C	D	E	F	G	H	J
K	L	M	N	P	Q	R	S