Unit 1 Software Engineering Fundamentals

Learning Objectives
After reading this unit, you should appreciate the following: y y y y y y y y Top Software Before 1970, very few people knew what "computer software" meant. But now a days, professionals and many members of the public at large understand what the software means. If we think about the description of software, it will take the following form: Software is (1) basically instructions, (computer logical programs) that when these instructions are executed then we can perform desired functions and maintain the performance, (2) data structures that enable the programs to adequately manipulate information for the required results, and (3) documents that describe the operation and use of the programs for the better understandability of the user of the program. Top Software Engineering Concepts Software Software Engineering Concepts Software Characteristics Software Applications Software Metrics Size Metrics Halsteads Theory Function Point Analysis

The era of electronic computers started in 1940s. The initial efforts of improvement were mainly focused on hardware. With the improvement in the field of electronics, hardware became very effective by 1960s. At this time, programming techniques available were not very effective and so, we were not exploiting hardware capabilities fully. The software development techniques were adhoc and programming-centered. These adhoc or programming-centered approach may work for small problems, but for the large and complex problems/projects, these techniques generally do not work. As a result of this, computing world found itself in a crisis, which is known as software crisis. If we have to control this software crisis, some scientific and systematic approach is needed for software development. To overcome this problem of software crisis, NATO science committee held two conferences in the 1960s in Europe. This is where the term software engineering was coined. Software engineering is defined as the systematic and scientific approach to develop, operate, maintain and to retire the software product. Software product means software for a large/medium size and complex problem. We get the real advantage of software engineering when it is applied to a project. Though it can also be used for the development of programs/small assignments. Another definition of software engineering may be: Software engineering is the application of science and mathematics, by which the computer hardware is made useful to the user via software (computer programs, procedures, and associated documentation). The main objective of software engineering is to produce good quality software with minimum cost and within the limited allowed time period. The discipline of software engineering provides methodologies, which make software development process closer to the scientific method and away from being an art. That is, these methodologies are repeatable. It means that if different people with the same requirements apply the methodology, similar software will be produced. The phrase useful to user emphasizes the needs of the user and the software's interface with the user. It means that user needs should be given due importance in the development of software, and the final software product should give importance to the user interface. Software Characteristics For a better understanding of the software, it is important to examine the characteristics of software that make it different from other things that human beings build. When hardware is built, the human creative process (analysis, design, construction, testing) is ultimately translated into a physical form. If we build a new computer, our initial sketches, formal design drawings, and bread boarded prototype evolve into a physical product (chips, circuit boards, power supplies, etc.).

Since software is purely logical rather than a physical system element, it therefore, has characteristics that are entirely different than those of hardware: 1. Software is developed or engineered but it is not manufactured in the classical sense: Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both activities are dependent on people, but the relationship between people applied and work accomplished is entirely different. Both activities require the construction of a "product" but the approaches are different. Software costs are concentrated in engineering. This means that software projects cannot be managed as if they were manufacturing projects. Software doesn't "wear out."

Figure 1.1:Hardware Failure Curve Figure 1.1 shows failure rate as a function of time for hardware. The relationship, often called the "bathtub curve," indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative affects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out. Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the "idealized curve" shown in Figure 1.2. Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected (ideally, without introducing other errors) and the curve flattens as shown. The

idealized curve is a gross over-simplification of actual failure models for software. However, the implication is clear, software doesn't wear out. But it does deteriorate! This seeming contradiction can best be explained by considering the "actual curve" shown in Figure 1.2. During its life, software will undergo change (maintenance). As the changes are made, it is likely that some new defects will be introduced, causing the failure rate curve to spike as shown in Figure. Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to rise-the software is deteriorating due to change. Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. If any software fails then it indicates an error in design or an error in the process through which design was translated into machine executable code then it means some compilation error. So it is very much clear that, software maintenance involves more complexity than hardware maintenance or we can say that software maintenance is a more complex process than hardware maintenance.

Figure 1.2: Software Idealized and Actual Failure Curves 2. Consider the manner in which the control hardware for a computer-based product is designed and built: The design engineer draws a simple schematic of the digital circuitry, does some fundamental analysis to assure that proper function will be achieved, and then goes to the shelf where catalogs of digital components exist. Each integrated circuit (called an IC or a chip) has a part number, a defined and validated function, a well-defined interface, and a standard set of integration guidelines. After each component is selected, it can be ordered off the shelf.

According to the standard engineering discipline, a collection of standard design components is created. Standard screws and off-the-shelf integrated circuits are only two of thousands of standard components that are used by mechanical and electrical engineers as they design new systems. The reusable components have been created so that the engineer can concentrate on the truly innovative elements of a design, that is, the parts of the design that represent something new. In the hardware world, component reuse is a natural part of the engineering process. In the software world, it is something that has only begun to be achieved on a broad scale. In the end, we can say that software design is a complex and sequential process. A software component should be designed and implemented so that it can be reused in different programs since it is a better approach, according to finance and manpower. In the 1960s, we built scientific subroutine libraries that were reusable in a broad array of engineering and scientific applications. These subroutine libraries reused well-defined algorithms in an effective manner but had a limited domain of application. Today, we have extended our view of reuse to encompass not only algorithms but also data structure. Modern reusable components encapsulate both data and the processing applied to the data, enabling the software engineer to create new applications from reusable parts. For example, today's graphical user interfaces are built using reusable components that enable the creation of graphics windows, pull-down menus, and a wide variety of interaction mechanisms. The data structure and processing detail required to build the interface are contained with a library of reusable components for interface construction. Top Software Applications Software may be applied in any situation for which a pre-specified set of procedural steps (i.e., an algorithm) has been defined. Information content and determinacy are important factors in determining the nature of a software application. Content refers to the meaning and form of incoming and outgoing information. For example, many business applications use highly structured input data (e.g., a database) and produce formatted "reports." Software that controls an automated machine (e.g., a numerical control) accepts discrete data items with limited structure and produces individual machine commands in rapid succession. Information determinacy refers to the predictability of the order and timing of information. An engineering analysis program accepts data that have a predefined order, executes the analysis algorithm(s) without interruption, and produces resultant data in report or graphical format. Such applications are determinate. A multi-user operating system, on the other hand, accepts inputs that have varied content and arbitrary timing, executes algorithms that can be interrupted by external conditions, and produces output that varies as a function of environment and time. Applications with these characteristics are indeterminate.

System software: System software is a collection of programs and utilities for providing service to other programs. Other system applications (e.g., operating system components, drivers, telecommunications processors) process largely indeterminate data. In either case, the system software area is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces. Real-time software: Software for the monitors/analyzes/controls real-world events as they occur is called real time. Elements of real-time software include a data-gathering component that collects and formats information from an external environment, an analysis component that transforms information as required by the application, a control/output component that responds to the external environment, and a monitoring component that coordinates all other components so that real-time response can be maintained. Business software: Business information processing is the largest single software application area. In a broad sense, business software is an integrated software and has many components related to a particular field of the business. Discrete "systems" for example, payroll, accounts receivable/payable, inventory have evolved into management information system (MIS) software that accesses one or more large databases containing business information. Applications in this area restructure existing data in a way that facilitates business operations or management decisionmaking. In addition to conventional data processing application, business software applications also encompass interactive computing. Engineering and scientific software: Engineering and scientific software have been characterized by "number crunching" algorithms. Applications range from astronomy to volcano logy, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. However, modern applications within the engineering/scientific area are moving away from conventional numerical algorithms. Computer-aided design, system simulation, and other interactive applications have begun to take on real-time and even system software characteristics. Embedded software: Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. Embedded software can perform very limited and esoteric functions (e.g., keypad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems). Personal computer software: The personal computer is the type of computer, which gave revolution to the information technology. The personal computer software market has burgeoned over the past two decades. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business

financial applications, external network, and database access are only a few of hundreds of applications. Web-based software: The Web pages processed by the browser are the software that incorporates executable instructions (e.g., CGI, HTML, PERL, or Java), and data (e.g. hypertext and a variety of visual and audio formats). In essence, the network becomes a massive computer providing an almost unlimited software resource that can be accessed by anyone with a modem. Artificial intelligence software: Artificial intelligence (AI) software is the software, which thinks and behaves like a human. AI software makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Expert systems, also called knowledge-based systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing are representative of applications within this category. Software Metrics Without software, computer hardware is of no use. A major share of the computing budget is incurred on software development or its purchase, by each organization. So, software systems are very precious and important products for both software developers and users. Software is not a single attribute product but it has many characteristics, which one can measure. For example, the size in lines of code, the cost of development and maintenance in rupees, the time for development in person months, the size of memory required in bytes, and so on. Still, it is quite obvious that different observers of the same computer program may get different results, even when the same characteristic is measured. For example, consider the lines of code property of a computer program. One observer may count all the lines present in the program including blank lines and comments. Another observer may drop comments and blank lines from the count by realizing that these do not affect the performance of the program. Therefore, a standard and precise definition of the line of code metric is required, so that for the same program, different persons may get identical counts. Only under such standard, identical and homogenous conditions, we can compare the results of empirical studies conducted by different people at different times or places. From time-to-time, different software metrics have been developed to quantify various attributes of a software product. Broadly speaking, these may be grouped into two categories. These are: i. ii. Product metrics Process metrics

The software metrics, like size, which can be derived from the software itself, are called product metrics. While, all those measurements of a software product which depend upon the development environment are called process metrics. Such metrics do not require the analysis of the program itself and are related to the development process. For example, measurement of the time required by a programmer to design, code and test a program is a process metric. This metric depends upon many things including the complexity of the problem, the knowledge and ability of the developer, the type of algorithm used, and the availability of the computer time during the development process etc. Therefore, if one computer program is to be developed by different programmers under different conditions, then their development time (for the same program) cannot be identical. Such metrics, like development time and effort estimation, may not be reproducible exactly. But, it does not mean that these are not useful and informative. In fact, these are the most important, useful, informative and interesting software metrics. Top Size Metrics For solving different problems on computer, programs are developed, written and implemented by different programmers. For achieving different objectives, programs are written in different programming languages. Some programs are written in C, C++, few in Pascal and FORTRAN, some in COBOL, while others in C++, VB, VC++, Java, Ada languages and so on. Some programs are of good quality, well documented and written with latest software engineering techniques. While others are written in a quick-and-dirty way with no comments and planning at all. Despite all these, there is one common feature which all programs share - all have size. Size measure is very simple, and important metric for software industry. It has many useful characteristics like: y It is very easy to calculate, once the program is completed.

y It plays an important role and is one of the most important parameter for many software development models like cost and effort estimation. y y Productivity is also expressed in terms of size measure. Memory requirements can also be decided on the basis of size measure.

The principal size measures, which have got more attention than others, are: 1. 2. Lines of Code (LOC) Token count

3.

Function count

Lines of Code It is one of the earliest and the simplest metric for calculating the size of a computer program. It is generally used in calculating and comparing the productivity of programmers. Productivity is measured as LOC / man-month. Among researchers, there is no general agreement what makes a line of code. Due to lack of standard and precise definition of LOC measure, different workers for the same program may obtain different counts. Further, it also gives an equal weightage to each line of code. But, in fact some statements of a program are more difficult to code and comprehend than others. Despite all this, this metric still continues to be popular and useful in software industry because of its simplicity. The most important characteristic of this metric is its precise and standard definition. There is a general agreement among researchers that this measure should not include comment and blank lines because these are used only for internal documentation of the program. Their presence or absence does not affect the functionality, efficiency of the program. Some observers are also of the view that only executable statements should be included in the count, because these only support the functions of the program. The predominant definition of LOC measure used today by various software personnel is: Any line of program text excluding comment or blank lines, regardless of the number of statements or parts of statements on the line, is considered a line of code (LOC). It excludes all lines containing program headers, declarations, and non-executable statements and includes only executable statements. Token Count The drawback in LOC size measure of treating all lines alike can be solved by giving more weight to those lines, which are difficult to code and have more stuff. One natural solution to this problem may be to count the basic symbols used in a line instead of lines themselves. These basic symbols are called tokens. Such a scheme was used by Halstead in his theory of software science. In this theory, a computer program is considered to be a collection of tokens, which may be classified as either operators or operands. All software science metrics can be defined in terms of these basic symbols. The basic measures are: n1 = count of unique operators n2 = count of unique operands N1 = count of total occurrences of operators

N2 = count of total occurrences of operands An operator can be defined as a symbol or keyword, which specifies an action. Operators consist of arithmetic, relational symbols, punctuation marks, special symbols (like braces, =), reserve-word/keywords (like WHILE, DO, READ) and function names like printf (), scanf () etc. A token, which receives the action and is used to represent the data, is called an operand. Operands include variables, constants and even labels. In terms of the total tokens used, the size of the program can be expressed as: N = N1 + N 2 At present, there is no general agreement among researchers on counting rules for the classification of these tokens. These rules are made by the programmer for his/her convenience. The counting rules also depend upon the programming language. Function Count The size of a large software product can be estimated in a better way, through a larger unit called module, than the LOC measure. A module can be defined as segment of code, which may be compiled independently. For large software systems, it is easier to predict the number of modules than the lines of code. For example, let a software product require n modules. It is generally agreed that size of the module should be about 50 - 60 lines of code. Therefore, size estimate of this software product is about n x 60 lines of code. But, this metric requires precise and strict rules for dividing a program into modules. Due to the absence of these rules, this metric may not be so useful. A module may consist of one or more functions. In a program, a function may be defined as a group of executable statements, which performs a definite task. The number of lines of code for a function should not be very large. It is because human memory is limited and a programmer cannot perform a task efficiently if the information to be manipulated is large. Top Halsteads Theory Researchers generally agree that simple size measures like lines of code (LOC) are not adequate for determining software complexity and development effort. They are of the view that, for this purpose, a programming process model is needed. This model should be based upon manageable number of factors, which affect the complexity and quality of the software systems. A number of researchers including Halstead, McCabe have attempted to define such programming models.

Halsteads model also known as theory of software science is based on the hypothesis that program construction involves a process of mental manipulation of the unique operators (n1) and unique operands (n2). It means that a program of N1 operators and N2 operands is constructed by selecting among n1 unique operators and n2 unique operands. By using this model, Halstead derived a number of equations related to programming such as program level, the implementation effort, language level and so on. Also, it is one of the most widely studied theories and has been supported by a number of empirical studies. An important and interesting characteristic of this model is that a program can be analysed for various features like size, effort etc. by simply counting its basic parameters n1, n2, N1 and N2. Program vocabulary is defined as N = n1 + n2 And program actual length as N = N1 + N2 One of the hypotheses of this theory is that the length of a well - structured program is a function of n1 and n2 only. This relationship is known as length prediction equation and is defined as Nh= n1 log2 n1 + n2 log2 n2 This length equation estimates the size of the program from the counts of unique operators (n1) and unique operands (n2). If the actual length (N) agrees well with the estimated value (Nh), then the program is considered as well structured. Program Volume (V) The programming vocabulary n = n1 + n2 (set of unique operators and operands) used in writing a program, leads to another size measure which may be defined as V = N log2 n It is called as the volume of the program. It may be interpreted as the number of mental comparisons needed to write a program of length N. The unit of measurement for program volume, V, is binary digit i.e. bit. Thus, total number of bits required to represent a program of length N would be N. log2 n. It is assumed that during programming process, the human mind follows binary search technique in selecting the next token from the vocabulary of size n.

Potential Volume (V*) It is clear that an algorithm can be implemented through many different but equivalent programs. Out of these programs, one, which has the minimum size, is said to have the potential volume ( V*). It may be defined as: V* = (n1 * + n2 * ) log2 (n1 * + n2 * ) Where n1 * is the minimum number of operators and n2 * is the minimum number of operands for an implementation. Minimum number of operators, n1 *, for any procedure is twothe procedure name and a grouping symbol that separates the procedure name from its parameters. So, for any procedure V* = (2 + n2 * ) log2 (2 + n2 * ) The minimum number of operands, n2 *, is the number of unique input and output parameters. For small, simple programs, it can be calculated easily but for large, complex programs like compiler, operating system, it is difficult to compute. Program Level (L) An algorithm may be implemented in many different but equivalent ways. But, it is the level of the program, which makes two implementations different and is defined as L = V* / V The maximum value for program level, L, is 1. A program with L = 1 is said to be written at the highest possible level (i.e. with minimum size). Because, it is very difficult to determine potential volume (V*), so Halstead gave an alternate formula for program level as: L = ( 2 n2 ) / ( n1 N2 ) Programming Difficulty (D) The difficulty involved in writing a program can be defined as the inverse of the program level (L) and can be expressed as: D=1/L

For a program, as the volume V increases, the program level L decreases and the difficulty D increases. Programming Effort (E) As already stated, the total number of mental comparisons required for writing a program of length N is N.log2 n. Further, for one mental comparison, the human mind has to perform a number of elementary mental discriminations (e.m.d.). Therefore, the effort required to implement a computer program increases as the size of the program increases. The programming effort E measure can be defined as: E = V/L The unit of measurement of E is e.m.d. (Elementary Mental Discriminations). It is clear that more effort is required to implement a program at a lower level (higher difficulty) than another equivalent implementation at a higher level (lower difficulty). Programming Time (T) According to John Stroud [3,36], human mind can make a limited number of elementary mental discriminations per second. Halstead called this number as Stroud number and denoted it as B. Stroud claimed that the value of B ranges between 5 and 20. By using this number, time taken by a programmer to complete a programming task can be estimated in seconds as T=E/B Generally, the value of B is taken as 18, since this number has given the best results for Halsteads earlier experiments. Language Level (L) At present, a number of programming languages are being used. Therefore, a software measure is required that expresses the power of the language. For this purpose, another metric, called language level is defined by Halstead as L = L V* = L2 V This metric is based on the hypothesis that for a given programming language, as V* increases, L decreases in such a way that LV* remains constant. For the validation of Halsteads software metrics, it is necessary that programs should be devoid of any kind of impurity or redundancy. Impurities in an implementation may

be incorporated due to poorly designed, poorly structured, lengthy and complex module. In a program, the following types of impurities may be included [15, 36]: y y y y y y y y Complementary Operations Ambiguous Operands Redundant Conditions Dead Code Synonymous Operands Common Sub-expressions Unwarranted Assignment, and Unfactored Expressions.

It is important that a program should not be just a working program, but it must be a good quality program. Earlier, we have explained various characteristics of a good quality program and devoid of impurities is another step for it. Though, the theory of software science metrics is very useful for the quantification of various aspects of a program. These metrics have, also, been supported by many experimental studies. But, it reflects only one type of program complexitysize. It does not take into account the structure properties of the program or the modular interactions of the program. Therefore, it cannot be used to measure the overall complexity of a program. McCabes Cyclomatic Complexity Metric The basis of this measure is the control flow graph of a program. Due to its simplicity, it is one of the most useful and accepted metric. McCabe interprets a computer program as a set of strongly connected directed graph. Nodes represent parts of the source code having no branches and arcs represent possible control flow transfers during program execution. The notion of program graph has been used for this measure and it is used to measure and control the number of paths through a program. The complexity of a computer program can be correlated with the topological complexity of a graph. McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software complexity. The cyclomatic number is equal to the number of linearly independent paths through a program in its graph representation. For a program control graph G, the cyclomatic number, V (G), is given as:

V (G) = E- N + P Where E: The number of edges in graph G, N: The number of nodes in graph G, and P: The number of connected components in graph G. For a strongly connected graph G, the value of P = 1. A graph G is said to be strongly connected if its each node is reachable from the every other node. It can be easily shown that the cyclomatic complexity measure, V (G), can be calculated by the number of control structures (like if.then.else, while.do etc.) plus 1. Due to its ease of computation, it is one of the simplest, and the most widely accepted measure. Besides its simplicity, this measure has several other important features as described below: y y y y y y It is independent of program size. It depends only on decisions. V (G) >= 1. V (G) = 1 for a linear sequence of code of any length. It is equal to the maximum number of linearly independent paths in graph G. V (G) is unaffected by adding or deleting non-branching statements.

The cyclomatic number, V (G), can also be computed just by knowing the number of decision structures involved in the source code. It is intuitive that number of errors is correlated to the number of control structures included in a software module. So, this measure may also be used for the estimation of errors (faults) in a computer program. As stated earlier, due to its simplicity, McCabes V (G) is one of the most widely accepted complexity measures. However, it is not entirely convincing as a program complexity measure. One of its important shortcomings is the failure to account for the complexity due to unconditional GOTOs. Because no decision is involved, so these are not counted. It, also, does not take into account the complexity due to linear sequence of statements and the nesting of control structures. So, several researchers [46-50] have suggested modifications to the use of this measure. McCabes measure, V (G), depends upon the flow of control only and is insensitive to other parameters of program complexity such as size. McCabe observed that if the

value of V (G) for a module becomes more than 10, then that module is more likely to be unreliable. So, such a module should be broken further to keep its V (G) <= 10. This upper bound for V (G) for controlling the complexity of module seems reasonable, but it needs further empirical verification.

Function-Point Analysis Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value. Since 'functionality' cannot be measured directly, it must be derived indirectly using other direct measures. Function-oriented metrics were first proposed as a measure called the function point. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity. Function points are computed by completing the table shown in Figure 1.3. Five information domain characteristics are determined and counts are provided in the appropriate table location. Information domain values are defined in the following manner: Number of user inputs: Each user input that provides distinct applicationoriented data to the software, is counted. Inputs should be distinguished from inquiries, which are counted separately. Number of user outputs: Each user output that provides application- oriented information to the user is counted. In this context, output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately. Number of user inquiries: An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted. Number of files: Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted. Number of external interfaces: All machine-readable interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted. Once these data have been collected, a complexity value is associated with each count. Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex. Nonetheless, the determination of complexity is somewhat subjective.

Weighting factor Measurement parameter Count Simple Average Complex

Number of user inputs

Number of user outputs

Number of user inquiries

Number of files

10

15

Number of external interfaces

10

Count total

Figure 1.3: Computing function points To compute function points (FP), the following relationship is used: FP = count total x [0.65 + 0.01 sum [Fi]]

Where count total is the sum of all FP entries obtained from Figure 1.3. The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions:

1. 2. 3. 4. 5. 6.

Does the system require reliable backup and recovery? Are data communications required? Are there distributed processing functions? Is performance critical? Will the system run in an existing, heavily utilized operational environment? Does the system require on-line data entry?

7. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8. 9. 10. 11. 12. 13. 14. Are the master files updated on-line? Are the inputs, outputs, files, or inquiries complex? Is the internal processing complex? Is the code designed to be re-usable? Are conversion and installation included in the design? Is the system designed for multiple installations in different organizations? Is the application designed to facilitate change and ease of use by the user?

Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). The constant values in Equation (4.1) and the weighting factors that are applied to information domain counts are determined empirically. Once function points have been calculated, they are used in a manner analogous to LOC, as a way to normalize measures for software productivity, quality, and other attributes: y y y y Errors per FP. Defects per FP. Rs per FP. Pages of documentation per FP.

FP per person-month.

Student Activity 1.4 Answer the following questions. 1. 2. Describe Halsteads Theory. What is function point analysis?

Summary y Software engineering is the systematic approach to the development, operation, maintenance, and retirement of software. y Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware. y A software component should be designed and implemented so that it can be reused in many different programs. y Modem reusable components encapsulate both, data and the processing applied to the data, enabling the software engineer to create new applications from reusable parts y Within the software engineering context, a measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process. Measurement is the act of determining a measure. The metrics is a quantitative measure of the degree to which a system, component, or process possesses a given attribute. y Project metrics are used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks. They are also used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality. y Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced. y Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value.

y Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity. y Complexity metrics can be used to predict critical information about reliability and maintainability of software systems from automatic analysis of source code or procedural design information. Complexity metrics also provide feedback during the software project to help control the design activity. Self-assessment Questions Solved Exercise I. True or False

1. Function point and LOC measurements for the size of software are not correlated. 2. 3. 4. 5. II. 1. 2. In todays computer systems, hardware is much costlier than software. Both, McCabe and Halstead metrics, measure complexity of a program. Software becomes old or aged without being worn out. Artificial intelligence softwares make use of numerical algorithms. Fill in the blanks. A _________ system is heavily constrained on time of execution. ________ is an example of private metric.

3. Minimum number of bits necessary to represent a program is known as __________ of the program. 4. FP per month may be used as a metric for _________ of a programmer.

5. The number of statements between two successive references of a variable is known as _______. Answers I. 1. True or False. False

2. 3. 4. 5. II. 1. 2.

False True True False Fill in the blanks. real-time defect-rate/module

3. Volumes 4. 5. productivity span

Unsolved Exercise I. True or False.

1. Information determinacy refers to the predictability of the order and timing of information. 2. 3. 4. 5. Function point metric is an absolute measure of a software characteristic. McCabe metric is an absolute measure of a software complexity. Software product and software process are two names for the same thing. Variable span and program complexity are directly proportional to each other.

II. 1. 2.

Fill in the blanks. A _________ software usually resides in the ROM of the memory. Ease of reading or writing is defined as (n1 * N2)/(2 * n2), where n1, n2 and N2 are _________, __________ and _________ respectively. A variable between its first and last reference is known as __________ variable.

3.

4. 5.

There are _ numbers of complexity adjustment factors in FP calculation. The maximum adjusting factor in an FP count can be ________.

Detailed Questions 1. 2. a. b. c. 3. 4. Describe software metrics & different types of metric models. Define the following: Size metric Complexity metric Function point analysis Describe software characteristics. Describe Halsteads theory in details and use in software engineering.

5. What are size metrics? How is function point metric advantageous over LOC metric? Explain. 6. What is Halsteads theory of software science? For a given program having number of operators, n1 = 16 and number of operands n2 = 32 determine the following: i. ii. iii. iv. v. Program length (through estimator) Program volume Program level Language level Effort and time