Reducing Software Product Size

The most significant way to improve affordability and return on investment (ROI) is usually to produce a product that achieves the design goals with the minimum amount of human-generated source material. Component-based development is introduced here as the general term for reducing the "source" language size necessary to achieve a software solution. Reuse, object-oriented technology, automatic code production, and higher order programming languages are all focused on achieving a given system with fewer lines of human-specified source directives (statements). This size reduction is the primary motivation behind improvements in higher order languages (such as C++, Ada 95, Java, Visual Basic, and fourth-generation languages), automatic code generators (CASE tools, visual modeling tools, GUI builders), reuse of commercial components (operating systems, windowing environments, database management systems, middleware, networks), and object-oriented technologies (Unified Modeling Language, visual modeling tools, architecture frameworks).

One caveat is warranted when discussing a reduction in product size. On the surface, this recommendation stems from a simple observation: Code that isn't there doesn't need to be developed and can't break. But this is not entirely the case. The reduction is defined in terms of human-generated source material. In general, when size-reducing technologies are used, they reduce the number of human-generated source lines. However, all of them tend to increase the amount of computer-process-able executable code. So the first part of the observation is true, but the second part is not necessarily true. The bottom line, as experienced by many project teams, is that mature and reliable size reduction technologies are extremely powerful at producing economic benefits. Immature size reduction technologies may reduce the development size but require so much more investment in achieving the necessary levels of quality and performance that they have a negative impact on overall project performance.

3.1.1 Languages

Universal function points (UFPs) are useful estimators for language-independent, early life-cycle estimates. The basic units of function points are external user inputs, external outputs, internal logical data groups, external data interfaces, and external inquiries. SLOC metrics are useful estimators for software after a candidate solution is formulated and an implementation language is known. Substantial data have been documented relating SLOC to function points [Jones, 1995]. Some of these results are shown in Table 3-2.

The data in the table illustrate why people are interested in modern languages such as C++, Ada 95, Java, and Visual Basic: The level of expressibility is very attractive. However, care must be taken in applying these data because of numerous possible

Table 3-2. Language expressiveness of some of today's popular languages

language

sloc per ufp

Assembly

Was this article helpful?

+2 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

Post a comment