Chapter 1

An Introduction to Software Engineering



e are all aware that software has become a part and parcel of our daily life in ones own way. It has become the key element in the evolution of computer-based systems and products. Today, software takes on a dual role. It is a product, and at the same time, the vehicle for delivering a product. As a product, it delivers the computing potential embodied by computer hardware. Whether it resides within a food processor or a washing machine or a cellular phone or operates inside a computer, software is an information transformer – producing, managing, acquiring, modifying, displaying or transmitting information that can be as simple as a bit or as complex as an image. As a vehicle used to deliver a product, software acts as the basis for the control of the computer (operating systems), the communication of information (networks), and the creation and control of other programs ( software tools and environments). Today, software is working both explicitly and behind the scenes in virtually all aspects of our lives, making it more comfortable and effective. For this reason, software engineering is more important than ever. Good software engineering practices must ensure that the software makes a positive contribution towards the role of our lives.

At the end of this chapter you should be able to answer these questions:

   

What software is, its important characteristics, its components and applications ? What is software engineering? Is it possible to have a generic view of software engineering ? What is the importance of software process models ?


Chapter 1 - An Introduction to Software Engineering


Chapter 1 - An Introduction to Software Engineering

Benefits and limitations of some of the major software process models ?

Software is a set of instructions or computer programs that when executed provide desired function and performance. It is both a process and a product. To gain an understanding of software, it is important to examine the characteristics of software, which differ considerably from those of hardware.

1.2.1 Software Characteristics
1. Software is developed or engineered, it is not manufactured. Unlike hardware, software is logical rather than physical. It has to be designed well before producing it. In spite of availability of many automated software development tools, it is the skill of the individual, creativity of the developers and proper management by the project manager that counts for a good software product. 2. Software does not “wear out”. As time progresses, the hardware components start deteriorating – they are subjected to environmental maladies such as dust, vibration, temperature etc. and at some point of time they tend to breakdown. The defected components can then be traced and replaced. But, software is not susceptible to the environmental changes. So, it does not wear out. The software works exactly the same way even after years it was first developed unless any changes are introduced to it. The changes in the software may occur due to the changes in the requirements. And these changes may introduce some defects in it thus, deteriorating the quality of the software. So, software need to maintained properly. 3. Most software is custom-built, rather than being assembled from existing components.
Most of the engineered products are first designed before they are manufactured. Designing includes identifying various components for the product before they are actually assembled. Here several people can work independently on these components thus making the manufacturing system highly flexible. In software, breaking a program into modules is a difficult task, since each module is highly interlinked with other modules. Further, it requires lot of skill to integrate different modules into one. Now a days the term component is widely used in software industry where object oriented system is in use.

BSIT 44 Software Engineering


1.2.2 Software Components
The wide spread use of object-oriented technology has resulted in the creation of software components. A software component is essentially a software module or a class of objects. It should be designed and implemented so that it can be reused in many different programs. The advantage with software reuse is that , it allows for faster software development and higher-quality programs. Modern reusable components encapsulate both data and the operations that manipulate the data into one unit. Software components are built using a programming language.

1.2.3 Software Applications
Software may be applied in any situation for which a predefined set of procedures (algorithms) has been defined and exist. System software, real-time software, business software, embedded software, personal computer software etc., are some of the software areas where potential applications exists.

Software engineering is a discipline. It uses the existing tools and methods of software development and systematizes the entire process of software development. There are a number of formal definitions for software engineering, given by experts in the field. However for the purpose of understanding, we shall see some of them. “Software engineering is the establishment and use of sound engineering principles in order to obtain economical software that is reliable and works efficiently on real machines” – definition according to a scientist Fritz Bauer. “Software engineering is the application of science and mathematics by which the capabilities of computer equipment are made useful to man via computer programs, procedures and associated documentation “ – definition according to a scientist Barry Boehm. According to IEEE, Software engineering is defined more comprehensive as “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.”

To engineer software, a software development process must be defined. The software engineering as such can be categorized into three generic phases, regardless of application area, project size or complexity. The three generic phases of software engineering include

it is likely that the original environment ( eg. This type of maintenance extends the software beyond its original functional requirements. CPU. So. A number of different process models for software engineering have been proposed. This development strategy is often referred to as a process model or software engineering paradigm. Prevention – Computer software deteriorates due to changes. how design will be translated into a programming language. The development phase focuses on how. how function is to be implemented as a software architecture. operating system. and the controls and deliverables that are required. code generation and software testing. The four main changes that are encountered during this phase are: Correction – It is likely that the customers will find errors or defects in the software in spite of the quality assurance activities. and what validation criteria are required to define a successful system. a software engineer attempts to define how data are to be structured. 1.4    The definition phase The development phase The maintenance phase Chapter 1 . This phase includes three main tasks : system or information engineering. the methods and tools to be used. how testing will be performed etc. what interfaces are to be established. business rules. A process model for software engineering is chosen based on the nature of the project and application. The maintenance phase focuses on change that is associated with the software.). Corrective maintenance changes the software to correct defects. the software developer attempts to identify what information is to be processed. Adaptive maintenance results in modification to the software to accommodate changes to its external environment. often called software reengineering must be conducted in order to make changes to the computer software more easily.An Introduction to Software Engineering The definition phase focuses on what. methods and tools for the development of computer software. what design constraints exist. each . Adaptations – As time progresses. That is. This phase includes three main tasks : software design. external product characteristics etc. Enhancement – As software is used. That is during definition. preventive maintenance. software project planning and requirements analysis. for which the software was developed is likely to change. what system behavior can be expected. how procedures are to be implemented.5 THE SOFTWARE PROCESS MODELS Software engineering is a discipline that integrates process. the customer will recognize the need for additional functional requirements that will benefit him. during the software development. what function and performance are desired.

but all having a series of generic phases in common. Test report and Manuals Installation report Installation Operations and maintenance Figure 1. In the next sub section that follow.BSIT 44 Software Engineering 5 exhibiting strengths and weaknesses. let us see some of the important software process models. System feasibility Feasibility report Requirements Analysis & project planning validation validation Requirements document & project plan System design System design document Detailed design Verification Detailed design document Coding Programs Verification Testing and integration Verification Test plan.1 The waterfall model .

6 1. when the product will be delivered. the requirements analysis and project planning begins. On successfully demonstrating the feasibility of a project. the system is installed.1 The Waterfall Model Chapter 1 . a project begins with the feasibility analysis. it requires a complete set of user requirements before the commencement of design. And the prototype is developed based on the currently known requirements.1. On successful completion of testing. The important characteristics of this model are            the process of software development consists of a linear set of distinct phases requirements analysis project planning system design detailed design coding and unit testing system integration and testing Each phase is distinct and is mandatory for every project irrespective of project size Every phase has a well defined entry and exit criteria.2 The Prototype Model The aim of this model is to overcome the limitations of the waterfall model that is.5. the regular operation and maintenance of the system takes place. Which is difficult to give since requirements keep changing according to needs and time. After this. The weakness with this model is that. which helps in correction of errors. and at what cost. In a typical waterfall model. Linear ordering of these activities are shown in the figure 1. This model is . instead of freezing the requirements before the design or coding phase a throw-away prototype is built to help understand the requirements. The design starts after completing the requirements analysis and coding starts after completing the design phase.An Introduction to Software Engineering It is the simplest and the widely used process model for software development. The importance of this model is that it allows for communication between the customer and the software developer and specifies what. Here the phases involved in the software development are organized in a linear order.  1. At every phase there is a provision for verification and validation.5. On completing the coding phase. testing is done.

the developer incorporates the suggested changes to the system and gives the modified system to the client’s use.2 The Prototyping model The development of the prototype starts when the preliminary version of the requirements specification document has be developed. in-order for it to be feasible The development approach followed is “quick and dirty”. the cost of the requirements analysis must be must be kept low. After the prototype has been developed. The important characteristics of this model are:      For prototyping. The process model of this approach is shown in figure 1. At this stage. Based on the client’s feedback. This cycle is repeated until the client has no modifications on the system. there is a reasonable understanding of the system and its needs. the focus is on quicker development rather than on the quality Only minimal documentation is required because it is a throw away prototype model This model is very useful in projects where requirements are not properly understood in the beginning It is an excellent method for reducing some types of risks involved with a projects .2 Requirements analysis Design Design Code Test Code Test Figure 1.BSIT 44 Software Engineering 7 very attractive for the customers. And this model is very well suited for complicated and large systems for which there is no manual process or existing system that can be used to determine the requirements. since they get an actual feel of the system that they indent to use. the clients are permitted to use the prototype system. coding and testing. at which stage the final requirements specification is ready for further processes like designing.

Based on the result of use and/or evaluation. Increment 1 System Engineering analysis design code test Delivery of 1st increment Increment 2 analysis design code test Delivery of 2nd increment Increment 3 analysis design code test Delivery of 3nd increme nt calendar time Figure 1. Such models are termed as evolutionary models. so as to meet the better needs of the customer and the delivery of additional features and functionality. The first increment is often a core product.An Introduction to Software Engineering 1. So . But the problem with this method is that the iterations may never end and the user may never really get the final product.8 Chapter 1 . And each linear sequence produces a deliverable “ increment “ of the software. 1. where the basic requirements are addressed.3. Evolutionary models are engineers need a process model that can take care of software products that evolves over time. evolves over a period of time.1 The Incremental Model It is also known as the iterative enhancement model.3 The Evolutionary Software Process Model Software like any other system. until the complete product is produced. It is an evolutionary model.3 This model applies linear sequences with reference to time. It combines elements of the waterfall model with the iterative philosophy of the prototype model. spiral model.5. The plan addresses the changes of the core product. This process is repeated following the delivery of each increment. Some examples of this model are the incremental model.3 The incremental model . a plan is developed for the next increment. This approach is advantageous for an in-house software development. concurrent development model and the component assembly model.5. The incremental model is shown in figure 1. This core product is used by the customer.

Each cycle here begins with the identification of objectives for that cycle. each quadrant representing a major activity like planning. and uses various development strategies that resolve the uncertainties and risks. Typically.BSIT 44 Software Engineering 9 1. which actually involve the development of the software.5. It incorporates the elements of both the prototype approach along with the classic software lifecycle. bench marking etc. The last phase is the customer evaluation phase. there is a risk assessment phase to evaluate the development effort and the associated risk involved for that particular iteration.3. The spiral model is shown in figure 1. the alternatives and constraints associated with that objective.4 This model has been divided into four quadrants. The second quadrant is associated with risk analysis activity. The activities in this model can be organized like a spiral. the inner cycles represent the early phases of requirement analysis along with the prototyping and the outer spirals represent the classic software lifecycle.2 The Spiral Model This model is relatively a new model. It used to evaluate different alternatives that are based on the objectives and constraints listed in the first quadrant. it has some problems associated with it like. risk analysis. proposed by Barry Boehm. Based on the outcome of the development step the next phase is planned. engineering and customer evaluation. risk analysis is a major phase in this model and assessment of risks involve a greater technical expertise. . It involves a review of the preceding development stage. that has many cycles. Some important characteristics of this model are:     It uses an iterative approach and with in each iteration it introduces a phase of risk analysis to accommodate for the changing environment It allows the usage of prototyping at any stage to be able to further refine requirements and therefore reduce risk element It maintains a systematic approach as in the case of waterfall model Although this model is quite flexible. The importance of evaluation is that. It may include some activities like simulation. The software process cycle begins with the planning activity represented by the first quadrant of this model (upper-left quadrant). The third quadrant is about engineering activity.

10 Chapter 1 . benchmarks life cycle plan of operation S/W requirements Product design Detailed Development Requirement design Code plan validation Integration and test plan Unit test Design Integration V&V Acceptance test Service Determine objectives. . constraints Opera tional prototype Proto Proto 3 2 Plan next phase Figure 1. It is both a process and a product. methods of engineering it in this unit.4 The spiral model 1. models. And you have learnt some of the important aspects of software. resolve risks Proto 1 Requirements plan Concept Simulations. constraints Risk Analysis Risk Analysis Risk Analysis REVIEW Risk An.An Introduction to Software Engineering Determine objectives. A number of process for software engineering have been proposed each with its own strengths and weaknesses.5 SUMMARY Software is a set of instructions or computer programs that when executed provide desired function and performance. identify. Software engineering is a discipline that integrates process. alternatives. Evaluate alternatives. methods. and tools for the development of computer software. test alternatives. You will be reading more on the generic phases involved in the development of software in the subsequent chapters.

4. software project planning and ————————— —————————————— results in modification to the software to accommodate changes to its external environment. 7. What is Software. 5. Software engineering is a —————————— The definition phase of software engineering includes tasks such as system engineering. 6. 8. Software is a set of ————————— that when executed provide desired function and performance. The development approach followed in prototype model is ——————————— The ——————————— method is also known as the iterative enhancement model. the phases involved in the software development are organized in ———————————. Software is a process and ——————————. 2. What is software engineering paradigm ? What are the limitations of Waterfall model ? What is a throw away prototype ? What is evolutionary software process model ? What are the drawbacks of Spiral model ? . 7. Give the IEEE definition of software engineering Name the three generic views of software engineering. 10. What is the advantage of software reusability ? Briefly list out the major application areas of software . 2. 3. 8.BSIT 44 Software Engineering 11 1. In Water fall model.6 SELF CHECK EXERCISE I Fill in the blanks: 1. List out the important characteristics of software. 4. 9. 5. 3. 6. II (a) Answer the following questions in one or two sentences: 1.

An Introduction to Software Engineering II (b) Answer the following questions in details: 1. I Answers for the in the blanks. 5. 4. Roger S. 8. Explain the spiral model with neat diagrams. Explain the waterfall model with neal diagrams.8 REFERENCES 1. product discipline requirements analysis adaptive maintenance linear order quick and dirty incremental 1. Narosa publishing house . Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition McGraw-Hill 1997. An Integrated approach to Software Engineering (second edition). 2. 3.12 Chapter 1 . 1. Explain the compments of software. 6. 7. 2. 3. instructions or computer programs 2. Pankaj Jalote.

we will see some of the ways of analyzing the problem and explore the characteristics of requirements. understanding the system is through what is known as requirements capturing and analysis.1 OBJECTIVES At the end of this chapter you should be able to      Appreciate the importance of capturing requirements Discuss the requirements process Answer the question “ What is software requirements specification ?” Document the requirements Understand the importance of validating requirements BSIT 44 Software Engineering 13 . In this chapter.Chapter 2 System Analysis and Requirements Specification 2. Thus. 2. We shall also see how to document the requirements for use by the design and test teams. the stages of system development and also some of the important process models were discussed.0 INTRODUCTION I n the previous chapter. Each process model of software development process includes a set of activities aimed at capturing requirements : understanding what the customers and users expect the system to do.


Chapter 2 - System Analysis and Requirements Specification

According to IEEE definition, a requirement is (1) a condition of capability needed by a user to solve a problem or achieve; (2) a condition or a capability that must be met or possessed by a system…, to satisfy a contract, standard, specification or other formally imposed document…..[IEE87]. The software requirements deal with the requirements of the proposed system and produces a document at the end of the requirements phase of software development cycle. And this document is known as the Software Requirements Specification (SRS). SRS completely describes what the proposed software system should do without describing how the software will do it.

2.2.1 Need for SRS
SRS is a medium through which the client and the user needs are accurately specified, it actually forms the basis of software development. An SRS is basically an organization’s understanding (in writing) of a customer or potential client’s system requirements and dependencies at a particular point in time, prior to any actual design or development work. It’s a two-way insurance policy that assures that both the client and the organization understand the other’s requirements from that perspective at a given point in time. The SRS is often referred to as the “parent” document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It’s important to note that an SRS contains functional and nonfunctional requirements only; it doesn’t offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer’s system requirements to be. SRS is typically developed during the first stages of “Requirements development,” which is the initial product development phase in which information is gathered about what requirements are needed. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client’s current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed. In short, a requirements-gathering team consisting solely of programmers, product marketers, systems analysts/architects, and a project manager runs the risk of creating a specification that may be too heavily loaded with technology-focused or marketing-focused issues. A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer’s assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.

BSIT 44 Software Engineering


It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

2.2.2 Requirement Process
A requirement is a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose. It is an important activity in the software development life cycle, since the client or the customer has some notion of the system that need to be built, either by replacing the existing system or extending the existing system. So, the process of determining requirements for a system shown in figure 2.1 is an important activity, and has two phases namely, requirements elicitation and analysis requirements definition and specification

The requirements elicitation and analysis phase is an important part of the software development process. Here we work with our customers to get the requirements, by asking questions, demonstrating similar systems, or even developing prototypes of all or part of the proposed system. It has three parts : 1. 2. 3. problem analysis which answers the question “have we captured all the user needs?” problem description which answers the question “are we using the right techniques or views ?” prototyping and testing which answers the question “is the function feasible?”

Next is the requirements definition and specification phase. We capture those requirements in a document or database and validate it for completeness, correctness and consistency. This is done with he documentation and validation part, which answers the question “have we captured what the user expects?”


Chapter 2 - System Analysis and Requirements Specification

requirements elicitation and analysis

requirements definition and specification

Problem analysis

Problem description

Prototyping and testing

Documentation and Validation

Figure 2.1 the process of determining requirements

The basic purpose of problem analysis is to understand the problem and its constraints. Its main aim is to understand the needs of the clients and the users, what they want from the system. Analysis leads to the actual specification. It involves interviewing the clients and the end users. The existing documents, clients and end users become the main source of information for the analysts. There are a number of methods to problem analysis. And we will discuss a few among them like informal approach, structured analysis, prototyping.

Informal approach This approach has no defined methodology. The information about the system is obtained by interaction with the client, end users , study of the existing system etc.. It uses conceptual modeling. That is, the problem and the system model are built in the minds of the analysts and it is directly translated to SRS. Once the initial draft of the SRS is ready, it may be used in further meetings. Structured analysis This method focuses on the functions performed in the problem domain and the data input and output by these functions. It is a top-down refinement process, it helps an analyst to decide upon the type of information to be obtained at various stages of analysis. This technique mainly depends on two types of data representation methods, the data flow diagram (DFD) and data dictionary.

g. Function) Depending on the level of the diagram it may represent the whole system as in a Context (level 0) diagram or a business area.. Terminator) A person or group which interacts with the system. It is simple and easy to understand by users and can be easily extended and refined with further specification into a physical version for the design and development teams. Together with these. Supplier. e. in lower levels.g. Customer. In the physical model. Usually external to the business or system but may be internal (e. In the physical model. Symbol: rectangular box which may be shaded. etc. for understanding a system. etc. It is not a user. etc. Government Agency. Symbol: Two parallel lines (Yourdon notation). function. it has limited usability. The different versions are Context Diagrams (Level 0). It is easily integrated with data modeling. Symbol: Circle (Yourdon notation). process (activity). In the logical model. it is a useful and easy to understand modeling tool. the process and Data Stores. or a Rounded Rectangle (Gane & Sarson notation). Used effectively. It shows the flow of data through the system it does not represent procedural information. In the .BSIT 44 Software Engineering 17 Data Flow Diagrams Data Flow Diagrams also called data flow graphs are commonly used during problem analysis. It has broad application and usability across most software development projects. Partitioned Diagrams (single process only — one level). Marketing Dept). and textual specs. Sink. Something outside the system. The Human Resources System. or an open ended rectangle (G&S notation) Data Flows The directional movement of data to and from External Entities. this represents a file. Activity. Data Store A repository of information.e. a data store is an object or entity. It is still considered one of the best modeling techniques for eliciting and representing the processing requirements of a system. however.e. Description Process (i. Alone. it provides analysts and developers with solid models and specs. Source. The DFD is an excellent communication tool for analysts to model processes and functional requirements. leveled sets of Data Flow Diagrams. Accounting Department.. It views a system as a function that transforms the inputs into desired outputs. Any complex system can be broken down into a system with a series of simple data transformations. table. External Entity(s) (i. a program label is identified in the bottom of the symbol. Functionally decomposed. workflow modeling tools.

display. as well as the structure of files. And the cost of developing and running a prototype can be around 10% of the total development cost of the software. it means a write. a partial system is constructed. delete. The components in the structure of a data flow may also be specified in the data dictionary. There are two approaches to this methods: throwaway and evolutionary prototyping.18 Chapter 2 . select types of transaction. An example of DFD for an employee payment system is shown in figure 2. Throwaway prototyping In this approach. mean read. its cost must be kept low. update. Prototyping In this method of problem analysis. Evolutionary prototyping In this approach. etc. . Flows out of Data Stores. which is used by the client and the developers to have a better understanding of the problem and the needs. the prototype is built with an idea that it will later be converted into the final system. when it flows into a data store. Symbol: Solid line with arrow. query. In order for prototyping for requirements analysis to be feasible.System Analysis and Requirements Specification physical model. It states the structure of each data flow in a DFD.2 Data Dictionary The data dictionary is a repository of various data flows defined in a DFD. Each data flow is identified with a descriptive name that represents the information (data packet) on the data flow. The notations used to define the data structure are: + ( plus ) represents a sequence or composition | (vertical bar) represents selection means one OR the other and * represents repetition means one or more occurrences. the prototype is constructed with an idea that it will be discarded after the completion of analysis and the final system will be built from the scratch.

BSIT 44 Software Engineering 19 Overtime rate Employee record Get employee file Pay rate * Regular Hours Pay Weekly pay * * Overtime pay Overtime Hours Regular Hours Total pay Net pay Company Records Employee ID Issue paycheck Worker Deduct taxes check Company Records Tax rates Worker Figure 2.2 DFD for an employee pay system .

Accurate .4 REQUIREMENTS SPECIFICATION This is an activity that is carried on in parallel with the problem analysis. as well as how it interfaces and interacts with it. etc. Table-1 SRS Quality Characteristic Complete Consistent What It Means SRS defines precisely all the go-live situations that will be encountered and the system’s capability to successfully address them. SRS precisely defines the system’s capability in a real-world environment. reliability.3 gives the data dictionary associated with the DFD of an employee payment system. For example.3 Data Dictionary 2. although it has to be after the problem analysis.4.) do not negate those capability functions.System Analysis and Requirements Specification The following figure 2. we shall discuss the characteristics of an SRS. Requirement specification yields an SRS as the final document. the only electric hedge trimmer that is safe is one that is stored in a box and not connected to any electrical cords or outlets. and the required quality features (security. 2. Weekly timesheet = Employee_name + Employee_id + [Regular_hours + Overtime_hours] * Pay_rate = [hoursly | daily | weekly] + dollar_amount Employee_name = Last + First + Middle_initial Employee_id = digit + digit + digit + digit Figure 2. components associated with it and specification languages. This aspect of requirements is a significant problem area for many SRSs. SRS capability functions and performance levels are compatible.1 Characteristics of an SRS The table–1 shown below gives the fundamental characteristics of a quality or good SRS.20 Chapter 2 . which is very essential for satisfying the basic goals of the system. Next.

security. government requirement. perceived ease/difficulty of implementation. While many quality attributes of an SRS are subjective.4.2 Designing an SRS Several standards organizations (including the IEEE) have identified nine topics that must be addressed when designing and writing an SRS: . and precisely defined in such a way that leaves no other interpretation or meaning to any individual requirement. Ranked Testable Traceable Unambiguous Valid Verifiable What makes an SRS “good?” How do we know when we’ve written a “quality” specification? The most obvious answer is that a quality specification is one that fully addresses all the customer requirements for a particular product or system.BSIT 44 Software Engineering 21 Modifiable The logical. hierarchical structure of the SRS should facilitate any necessary modifications (grouping related issues together and separating them from unrelated issues makes the SRS easier to modify). 2. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present. This is one of the main reasons SRSs are written using natural language. This is another area that creates significant problems for SRS development because of the use of natural language. A “strong” SRS is one in which the requirements are tightly. accept. etc. unambiguously.) SRS must contain requirements statements that can be interpreted in one way only. An SRS must be stated in such a manner that unambiguous assessment criteria (pass/fail or some quantitative measure) can be derived from the SRS itself. A verifiable SRS is consistent from one level of abstraction to another. or other parameter that helps in the design of that and subsequent documents. industry standard. A valid SRS is one in which all parties and project participants can understand. analyze. Individual requirements of an SRS are hierarchically arranged according to stability. or approve it. we do need indicators or measures that provide a sense of how strong or weak the language is in an SRS. Each requirement in an SRS must be uniquely identified to a source (use case.

3.22 1. 2. as given below: 1. without ambiguity. 9. Here. A template A method for identifying requirements and linking sources Business operation rules A traceability matrix The first and biggest step to writing an SRS is to select an existing template that you can fine tune for your organizational needs (if you don’t have one already). There’s not a “standard specification template” for all projects in all industries because the individual requirements that populate an SRS are unique not only from company to company. 6. . 2. 4. It should posses many desired qualities of an SRS. 8. and other project documents are what drive the development of the final product. does an SRS document include? How is it structured? And how do you get started? An SRS document typically includes four ingredients. specifically. Unlike formal language that allows developers and designers some latitude. and precise because the design specification. 4. Interfaces Functional Capabilities Performance Levels Data Structures/Elements Safety Reliability Security/Privacy Quality Constraints and Limitations Chapter 2 . 5. The natural language of SRS must be exact.3 Specification Languages Requirements specification necessitates the use of some specification language. statement of work. 3. how do these general topics translate into an SRS document? What. 7. 2. but also from project to project within any one company. we will see some of the commonly used languages for requirements specification.System Analysis and Requirements Specification But. and then adapt it to meet ones needs. The key is to select an existing template or specification to begin with.4.

BSIT 44 Software Engineering 23 Structured English Natural languages have been widely used for specifying requirements since they have an advantage that it easily understood both by the client and the developer. 5 C1 C2 C3 Y conditions actions The decision table has two parts. The top part specifies different conditions. closure are used in regular expressions. The use of natural language has some problems associated with it. So. the natural language is used in a structured manner. They can be considered as grammar for specifying the valid sequences in a language and can be processed automatically. Regular Expressions Regular expressions can be used to specify the structure of symbol strings formally. However. and the bottom part specifies different actions. to define many data streams. composition. “should”. If English is used as a natural language. table-based notation that can be used to check the qualities like completeness and lack of ambiguity in requirements specification. They are helpful in specifying complex decision logic. To reduce these problems. “perhaps”. Some basic constructs like atoms. Written requirements become necessary as the system become more and more complex as against the requirements conveyed verbally. alternation. Some insist on using words like “shall”. analysts are making an effort to move from natural languages towards formal languages for requirements specification. using the natural language for smaller systems. . written requirements are imprecise and ambiguous. Decision Tables It is formal. and try to restrict the use of common phrases in order to improve precision and reduce ambiguity. requirements are broken into sections and paragraphs and paragraph further into subparagraphs.

4 Structure of an SRS Chapter 2 .1 3.1 System feature A .5 1. Purpose Document conventions Intended audience Additional information Contact information/SRS team members References Overall Description 2.6 2.4 1.System Analysis and Requirements Specification The table-2 below shows what a basic SRS outline might look like.5 2.4.6 2. External Interface Requirements 3.4 2.2 2.2 1.2 3.4 User interfaces Hardware interfaces Software interfaces Communication protocols and interfaces 4. Introduction 1. This example is an adaptation and extension of the IEEE Standard 830-1998: Table-2 A sample of a basic SRS outline 1.1 1.3 3.3 1.7 Product perspective Product functions User classes and characteristics Operating environment User environment Design/implementation constraints Assumptions and dependencies 3. System Features 4.1 2.3 2.24 2.

a team of people consisting of a representative from the client.3 Functional requirements 4. Checklists are often used in such review meetings to focus on the reviews and to ensure that no major source of errors is over looked by the reviewers.BSIT 44 Software Engineering 25 4.5 VALIDATING REQUIREMENTS It is important that that final requirements be validated before the next phase of software development . reading. A number of methods exist for requirements validation such as automated cross-referencing. review etc.2 5.2 5.1 5.2 Action/result 4. are involved in the review process to find errors and discuss the requirements specification of the system. But.. prototyping. .6 Performance requirements Safety requirements Security requirements Software quality attributes Project documentation User documentation 6. among them the most commonly used method is requirement review. Other Requirements Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined 2.3 5.5 5. System feature B Other Nonfunctional Requirements 5.1 Description and priority 4. the author of the requirements starts. In this technique. a person from design team etc.1.4 5.1.1.

———————— are often used in review meetings to focus on the reviews and to ensure that no major source of errors is over looked by the reviewers. 5. . A ———————— SRS is one in which the requirements are tightly. the software is likely to not meet the user’s requirements.26 2. If this is done.System Analysis and Requirements Specification Requirements collection is crucial to the development of successful information systems. The document produced at the end of the requirements phase of software development cycle is known as ———————————————— The process of determining requirements for a system has two phases namely. the system meet the user’s needs. To achieve a high level of IS quality. it is essential that the SRS be developed in a systematic and comprehensive way. and precisely defined in such a way that leaves no other interpretation or meaning to any individual requirement. Writing top-quality requirements specifications begins with a complete definition of customer requirements. unambiguously. and will lead to user satisfaction.7 SELF CHECK EXERCISE I Fill in the blanks 1. In the next chapter we will see how to transform these requirements analyzed into design. and natural language use are in the best position to create and add value to such critical project documentation. this information will help you get started when you are called upon—or step up—to help the development team. 4. Hopefully. Coupled with a natural language that incorporates strength and weakness quality indicators— not to mention the adoption of a good SRS template—technical communications professionals well-trained in requirements gathering. 6. 7. even if the software conforms with the specification and has few defects. 2. There’s so much more we could say about requirements and specifications. requirements elicitation and analysis and ————————— Structured analysis mainly depends on data flow diagrams and —————— An external entity is represented using ————————— in a DFD. template design.6 SUMMARY Chapter 2 . 3. 2. If it is not done. The software requirements deal with the ————————of the proposed system.

An Integrated approach to Software Engineering (second edition). 7. 1. Requirements 2. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. Narosa publishing house Ian Sommerville. What is problem analysis? explain the medel to problem analysis. 1996. 5. 7. Explain How to diagram an SRS? What are Specification in languages? Explain Give the outline structure of SRS I Answers for fill in the blanks. 8. What is data dictionary?Explain. Give the IEEE definition of software requirements analysis. What is DFD? Explain DFD for an emplayee pay slm. What are the goale of SRS? Explain.8 REFERENCES 1. 3. Briefly explain the requirement process. 6. Addison-Wesley publications. 4. Software engineering.5 . 3. 5. 6. What are the characteristics of SRS? Explain.BSIT 44 Software Engineering 27 II (a) Answer the following questions in one or two Sentences : 1. Software Requirements Specification (SRS) Requirements definition and specification Data dictionary Rectangle Strong Checklists 2. 4. II (b) Answer the following questions in details: 2. Pankaj Jalote. ed. 9. 10. 3. 2. Roger S.

3. This serves two purposes : one for the customer to capture their needs and the other for the designers to explain the problem in technical terms.0 INTRODUCTION I n the last chapter.System Design .Chapter 3 System Design 3. In this chapter we will see what to do and how to do it. we learned how to work with the customers to determine what they want out of the proposed system.1 OBJECTIVES At the end of this chapter you should be able to         know the process of designing a software describe the different types of design document the design specifications say what coupling is and name the different types of coupling say what cohesion is and mention the different types of cohesion appreciate the importance of various design notations give the main objective of transform analysis and transaction analysis give the necessary steps involved in transform analysis as well as transaction analysis 28 Chapter 3 . The outcome of requirements analysis and specification phase was a system requirements specification document. The next step in development is to translate those desires into a solution: a design that will satisfy the customers’ needs.

The goal of the design process is to produce a model of the system. The design should be traceable to the analysis model – since the design needs to satisfy multiple requirements of a problem.BSIT 44 Software Engineering 29 3. This phase begins when the requirements document for the system to developed is available. the modules in the design represent data abstraction. The design process for the software has two levels: 1. which can be used later to build that system. This type of design essentially expands the system design to contain more detailed description of the processing logic and data structures so that the design is sufficiently complete for coding. A design can be object-oriented or function-oriented. The design process is a set of iterative steps that enable the designer to describe all aspects of the software to be built. 2. The model thus produced is called the design of the system. Detailed design Using this.2 THE DESIGN PROCESS The software design is an activity which is after the requirements analysis activity. Design is an important phase in the software development life cycle. with each module supporting a functional abstraction. the internal design of the modules are decided or how the specifications of the modules can be satisfied are decided. resources available and the design concepts.  . The basic design principles enable the software engineer to proceed with the design process.3 DESIGN PRINCIPLES Software design is both a process and a model. it is necessary to have a means of tracking the requirements. the specifications of these modules and how these modules need to be connected are also decided. In object-oriented design. it bridges the requirements specification and the final solution for satisfying the requirements. In function-oriented design. the modules that are needed for the system are decided. 3. system design or top-level design detailed design or logic design System design Using this. Here are some software design principles suggested by Davis:  The design process should not suffer from “tunnel vision” – a good design should consider alternative approaches based on the requirements of the problem. the design consists of module definitions.

speed. The design should exhibit uniformity and integration – a design is uniform if it appears that one person developed the entire thing.4 DESIGN CONCEPTS The design concepts provide basic criteria for design quality. 3. software architecture. External quality factors are those properties of the software like. or operating conditions are encountered Design is not coding. The design should be reviewed to minimize conceptual errors – major semantic errors like omissions. The design should “ minimize the intellectual distance” between the software and the problem as it exists in the real world – the structure of the software design should reflect the structure of the problem domain.       When the design principles described above are properly applied. information hiding. . data structure. If the interfaces are well defined for the design components then the design is said to be integrated. style etc. Internal quality factors are those that lead to high quality design software. There are a number of fundamental design concepts that has been of interest: Abstraction. have to be addressed by the designer before dealing with the syntax of the design model. the software engineer creates a design that exhibits both internal and external quality factors. The design should be structured to accommodate change The design should be structured to degrade gently. format. structured partitioning. In order to achieve this. not after the fact – a number of design concepts and design measures are available and can be used to access quality of the software. refinement. inconsistency etc. the design rules.30   Chapter 3 . correctness etc. ambiguity. software procedure. coding is not design – design model has a higher level of abstraction than the source code. modularity. the designer must understand the basic deign concepts. will have to defined for the design team before design work begins. In order to achieve internal quality factors. The design should be assessed for quality as it is being created.System Design The design should not reinvent the wheel – design time should be used for representing new ideas and integrating the already existing design patterns instead of going for reinvention. that can be readily observed by the users. even when aberrant data. reliability. control hierarchy.. events. Major decisions are at design phase and only small decisions are taken at the implementation phase.

a solution is stated in broad terms using the language of problem environment. weight. Example: ON interrupt DO save STACK_A and call Exception_handler_a.2 Stepwise Refinement Stepwise refinement is a top-down approach where a program is refined as a hierarchy of increasing levels of detail. Here the word “open” is an of example of procedural abstraction. hold the door-knob. The process of refinement may start during the requirements analysis and conclude when the detail of the design is sufficient for conversion into code. at an appropriate level of detail.BSIT 44 Software Engineering 31 3. exception handling. door type etc. co-routines. or structured. 3. stating the desired effect without stating exact mechanism of control.  Control abstraction : It implies a program control mechanism without specifying internal details.. turn the knob and pull the door.4. that describe the door.  Data abstraction : A data abstraction is a named collection of data that describes abstract data types. move away from the door. the data associated with the tasks may have to be refined. As tasks are refined. decomposed. At the lower levels of abstraction. more procedural details are given. The word “door” is an example of data abstraction. objects. operations on objects by suppressing the representation and manipulation details. There are three important levels of abstraction  Procedural abstraction : A procedural or functional abstraction is a named sequence of instructions that has a specific and limited function. which implies a long sequence of procedural steps like: walk to the door. That is. And processing procedures and data structures are likely to be refined in parallel. .4. “open the door”. It causes the designer to elaborate on the original statement. Consider an example sentence. At the highest level of abstraction.1 Abstraction Abstraction is a means of describing a program function. It deals with problems at some level of generalization without regard to irrelevant low level details. which has certain attributes like dimensions. providing more and more details at end of each refinement step.

architectural design should have the ability to reuse architectural building blocks.3 Software Architecture Chapter 3 . Notations like Warnier-Orr notation. Extra-functional properties This describes about the manner in which the design architecture achieves requirements for system characteristics like performance. The properties associated with an architectural design are:  Structural properties This defines the components of the system (such as modules. These models use ADL (architectural description language) for describing the system components and the interconnections among them. Program structure is usually expressed as a simple hierarchy showing super-ordinate and subordinate relationships of modules.4.      Structural models represent architecture as an organized collection of program components Framework models increase the level of design abstraction by identifying repeatable architectural design frameworks or patterns that are encountered in similar type of applications. The architecture of the procedural and data elements of a design represents a software solution for the real-world problem defined by the requirements analysis. represents the hierarchy of control with out regard to the sequences of processing and decisions.32 3. also called as control hierarchy. Jackson notation. architecture is about structure of software. adaptability etc Families of related system The design of similar systems usually encounter similar design patterns. tree-like diagrams etc. the way these components are grouped and interact with one another. Process models deals with the design of the technical process that the system must accommodate.   There are a number of architectural design models that is based on the above said properties. So.. objects).4. The tree-like . capacity. security. A set of architectural patterns enable a software engineer to reuse the design level concepts. Functional models can be used to represent the functional hierarchy of a system 3.System Design While refinement is about the level of detail.4 Program Structure The program structure. are used to represent control hierarchy. It refers to the overall structure of the software and the ways in which that structure provides the conceptual integrity for a system. reliability. Dynamic models address the behavioral aspects of program architecture. indicating how the system configuration may change as a function of external events.

5 Data Structure Data structure is a representation of the logical relationship among the individual elements of data. width. Fan-in . Fan-out is a measure of the number of modules that are directly controlled by another module. Depth refers to the number of levels of control .1 control hierarchy 3.BSIT 44 Software Engineering 33 diagram ( as shown in figure 3. The terms like depth.1) is the most common structure followed. degree of i r width Figure 3. Fan-in indicates how many modules directly control a given module. Fan-out are usually associated in describing and measuring the program structure. and processing alternatives for . which represents hierarchy of modules. And a module controlled by another is said to be subordinate to the controller.4. M depth a b Fan-out c d f g e h j k m n o p q Fan. The relationship between modules is said to be either super-ordinate or subordinate. Width refers to the overall span of control. It represents the organization. methods of access. A module that controls another module is said to be super-ordinate to it.

System Design problem-related information. Modular composability If a design method enables the existing design components to be assembled in to a new system. 2. or other criteria. Modular continuity If any small changes to the system requirements result in changes to individual modules. along with program structure. it will produce a modular solution for the problem. it will reduce the complexity of the over all problem. 4. implementation considerations. and data structures. Modular decomposability If a design method provides a systematic way for decomposing a problem into sub problems. it will be easier to build a module and make changes easily. Module segments can be used by invoking a name and some parameters. Can be included in a program. Modular understandability If a module can be understood as a single unit without referring to other modules. sequential. n-dimensional. Modularity is a logical partitioning of the software design that allows complex software to be manageable for purposes of implementation and maintenance. rather than system-wide changes. . 3. 5. 2. data links. linked-list. makes up the software architecture.4. the impact of change induced on it will be minimum. The logic of partitioning may be based on related functions. and hierarchical. 3. Data structure. there by achieving an effective modular solution. Contains instructions. There are five important criteria for defining an effective modular system that enable us to evaluate a design method: 1. Modularity does imply interface overhead related to information exchange between modules and execution of modules. Can be separately compiled and stored in a library. Classic data structures include scalar. processing logic. 3.6 Modularity A module is a named entity that: 1. Modules can use other modules. 4.34 Chapter 3 . Modularity derives from the architecture.

5 EFFECTIVE MODULAR DESIGN Among the several fundamental design concepts discussed earlier.8 Information Hiding Information hiding is an adjunct of modularity. a modular design reduces complexity. 3.4. facilitates changes and results in easier implementation of programs. including sequence of events. exact decision points. Data abstraction criterion — modules hide representation details of major data structures behind functions that access and modify the data structure. and data organization. Since. A procedure representation of software is layered. Modular protection If an aberrant condition occurs with in a module and its effects are constrained within that module. repetitive operations.BSIT 44 Software Engineering 35 5. . the impact of error induced on it will be minimum. Coupling and cohesion — system is structured to maximize the cohesion of module elements and minimize coupling between modules. Information hiding simplifies testing and modification by localizing these activities to individual modules. Some of the criteria used to guide modularization       Conventional criteria — module is a processing step in execution sequence. Levels of abstraction — modules provide hierarchical set of increasingly complex services. Problem modeling — modular system structure matches the problem structure (data structures match the problem structure and visible functions manipulate the data structures.7 Software Procedure Software procedure provides a precise specification of the software processing. 3. modularity is the most important one. 3.4. Information hiding criterion — modules hide difficult or changeable design decisions. It permits modules to be designed and coded without concern for the internal details of other modules. Processing defined for each module must include references to all subordinate modules identified by the program structure. Only the access protocols of a module need to be shared with the implementers of other modules.

e. information hiding and abstraction. 3. Coincidental cohesion (no apparent relationship among module elements). objects). 7.e. Functional cohesion (all elements relate to performance of a single function). In software design. Strength of coupling depends on interface complexity. weakest cohesion (1) is least desirable. 5. Communication cohesion (all elements are executed at one time and also refer to the same data. A cohesive module must perform a single task within a software procedure.3 Coupling Coupling is a measure of the relative interdependence among modules.5.g. concrete realization of data abstraction. It is an extension of information hiding concept.36 Chapter 3 . e.1 Functional Independence The functional independence is a direct outgrowth of concepts like modularity. several related functions. 3. e. Independence is measured using two qualitative criteria namely. math library) Temporal cohesion (elements are usually bound through logic (2) and are executed at one time. Sequential cohesion (output of one element is input to the next. i.System Design or modules form a network of communicating processes. I/O module). Strongest cohesion is most desirable (7).2 Cohesion Cohesion is a measure of the relative functional strength of a module. .g. The functional independence is very important since software with effective modularity (i. requiring little interaction with procedures that are performed in other parts of a program. e. Information cohesion (complex data structure with all its functions/operators.g. independent modules) is easier to develop and maintain.5. initialization module).5. model structure bears close resemblance to the problem structure or procedure). Logical cohesion (some inter-element relationships exist. 6. same invocation of the module. 4. type of connections and communication between modules. 1. Cohesion may be represented in various levels ranging from low measure to high measure. cohesion and coupling 3. 3. each process corresponds to a problem entity). 2.

Data objects and resultant data structures B. 4. 2. logical structure b. Data coupling (parameter lists are used to pass/protect data items). The strongest (1) is least desirable. C. 3. 3. file and data cross reference . External file structure a. global data 3. the weakest (5) is most desirable. Design specification outline I Scope A. File and database structures 1. Shown below are the different types of module coupling. module controls sequencing of processing in another module). System objectives Major software requirements Design constraints. Simple connectivity among modules results in software that is easier to understand and less prone to error propagation in the system.BSIT 44 Software Engineering 37 we look for the lowest possible coupling. limitations II Data design A. logical record description c. Common coupling (global data cross coupling). access method 2. Content coupling (cross modification of local data by other modules). B.6 DESIGN DOCUMENTATION The document shown below can be used as a template for a design specification. Control coupling (control flag etc. 5. Stamp coupling (selective sharing of global data items). 1.

Test guidelines Integration strategy Special considerations VIII Special notes .38 III Architectural design A. E. B. D. Interfaces to external systems or devices D. Internal interface design rules V Procedural design For each module: A. Processing narratives Interface description Design language description Modules used Internal data structures Comments/restrictions/limitations VI Requirements Cross-reference VII Test provisions 1. Human-machine interface specification Human-machine interface design rules External interface design 1. B.System Design IV Interface design A. F. C. 2. Derived program structure Chapter 3 . C. Interfaces to external data 2. 3. Review of data and control flow B.

Data design is involved with the organization. Design Fundamentals Three distinctive aspects of an information system are addressed during the software design. internal data structures and a cross reference that connects data objects to specific files. This section covers the nature of software design in more detail. and a historic perspective on design. . Much of the information is derived from the SRS. Section VI contains a requirements cross-reference. comments associated with each and every modules is described. memory management ). Along with it. 3. internal data structures. external data bases. indicating how the program architecture has been derived from analysis model. access methods. integration strategy. Section VII is about the Verification which includes testing guidelines. Section IV describe the interface design. design’s role as a representational model. and processing alternatives of the system’s data. Procedural (detailed) design uses the products of the data and architectural design phases to describe the processing details of the system — module internals. describing the external file structures. It defines the fundamentals which software design should adhere to.7 DESIGN METHODS Each software design method has as its goal to provide the software designer with a blueprint from which a reliable system may be built. or modules. Architectural (preliminary) design defines the components. The purpose of this is to establish all requirements are satisfied by the software design and to indicate which modules are very important to the implementation of specific requirements. high-speed constraints. each module is described with an English language processing narrative. associativity. major software functions. of the system and the relationships that exist between them.BSIT 44 Software Engineering 39 IX Appendices Section I gives the overall scope (overview of system objective. emphasizing on the human-machine interface specifications and design rules. Section II gives the data design. the interface description. interfaces. major constraints) of the design effort. Here. Section V is about procedural design. Section III gives the architectural design. special considerations ( physical constraints. Section VIII and IX is on notes and appendices.

review and specify the functional requirements and preliminary design. The systematic analysis principles applied to function and behavior should also be applied to data – representations of data objects. Low-level data design decisions should be deferred until late in the design process – the overall data organization may be defined during requirements analysis. A set of useful data structures and the operations that may be applied to them should be developed – data structures and operations are the important resources for the software design. content should be developed and reviewed. A data dictionary should be established and used to define both data and program design – A data dictionary represents the relationships among data objects and the constraints on the data elements of a data structure. In other words. 6. the choice of the data structure depends on the attributes of the data objects. Data structures can be designed for reusability. All data structures and operations to be performed on each should be identified – the design of an efficient data structure must take the operations to be performed on the data structure into account.1 Data Design Data design is the first method that is conducted during the software engineering activity. However. the relationship between these data objects and their use with in the program. 5. 3. 3. also alternative data organizations should be considered in a similar way that we derive. it translates the data objects defined in the analysis model into data structures that reside with in the software. 4.7. And a set of data structure templates help to reduce both the specification and design effort for data. 2.40 Chapter 3 . Following are some of the principles that need to be followed for data design approach: 1. data flows. relationships. . The main activity during this design method is to select logical representations of data objects or data structures which are identified during the requirements definition and specification phase. The representation of data structures should be known only to those modules that must make direct use of data contained within the structure – this indicates the importance of information hiding and the concept of coupling. refined during preliminary design and specified in detail during the later design process.System Design Software design methods attempt to help the designer in the following aspects:    they assist in partitioning the software into smaller components and reducing complexity they help to identify and isolate data structures and functions they attempt to provide some measure of software quality.

2 Architectural Design The main objective of architectural design model is to develop a modular structure and represent the control relationships between modules. information shown on a computer display etc. and reduced procedural complexity. (4) control hierarchy is defined by factoring. information must enter and exit software in an “external world” form. A data flow diagram is mapped into program structure using one of the following mapping approaches – transform mapping and/or transaction mapping. A software design and programming language should support the specification and realization of abstract data types – the implementation and the corresponding design of a sophisticated data structure can be made very difficult if direct specification of the structure does not exist. So. (5) the resultant structure is refined using design measures and heuristics. Transform flow In the fundamental system model (context level DFD). (2) flow boundaries are indicated. This method uses information flow (represented as a data flow diagram) characteristics to derive the program structure. 3.BSIT 44 Software Engineering 41 7. (3) the DFD is mapped in to program structure. The data entered through a keyboard. a well designed data can lead to better program structure and modularity.7.. are examples external world information . The transition from information flow to program structure is accomplished as a five step process: (1) the type of information flow is established.

the flow along one of many action paths is initiated. The transaction flow is characterized by data moving along an incoming path that converts external world information into a transaction. When a segment of a DFD shows these characteristics we say transform flow is present.System Design External data representation Incoming flow Transform flow Outgoing flow Information Internal data representation Time Figure 3.2 Representation of flow of information The external data that enters the system must be converted in to an internal form for processing. The transition form external to internal data form occurs at the kernel of the software.2.3. the transaction is evaluated and based on its value. The incoming data moves through the transform center and from this it moves out of the software through the paths called outgoing flow. When the external information enters the transaction center. Transaction flow The information flow in a system is characterized by a single data item called a transaction.42 Chapter 3 . . the over all flow of data occurs in a sequential manner. A transaction triggers other data flow along one of many paths as shown in figure 3. This is shown in figure 3. The center of information flow from where many actions paths start is called a transaction center. The information that enters the system along the paths that transform external data into an internal form is known as incoming flow.

3 Transaction flow 3. when a transaction characteristic is encountered it can be represented as a transaction flow. Determine whether the DFD has transaction or transform flow characteristics – depending on the nature of the DFD. 2. This type of mapping is applied to an information flow that exhibits distinct boundaries between incoming and outgoing data. and output along three separately factored module hierarchies.1 Transform Mapping Transform mapping is a set of design steps that allows a DFD with transform flow characteristics to be mapped into predefined template for program structure. the type of information flow can be found out. Review the fundamental system model – context level or 0 level DFD. Review and refine data flow diagrams for the software – the information obtained from analysis phase through the software requirements specification is refined to get more details. 3. In general.2.7. processing. However. Let us list out the design steps for performing the transform mapping. information flow within a system can always be represented as a transform flow. The DFD is mapped into a structure that allocates control to input. . 1.BSIT 44 Software Engineering 43 Transaction T Action paths Transaction center Figure 3.

Review and refine data flow diagrams for the software 3.e.44 4. 7. Chapter 3 .7.7. Determine whether the DFD has transform or transaction characteristics 4. Perform the “second level factoring” Refine the first iteration program structure using design heuristics for improved software quality 5. (2) the design of interfaces between the software and other external entities ( i.2. Factor and refine the transaction structure and the structure of each action path 7. and outgoing is the vice-versa. Review fundamental system model 2. It encompasses internal and external program interfaces and design of the user interfaces. . non-human producers and consumers of information) (3) the design of the interface between the user and the computer. Map the DFD to a program structure amenable to transaction processing 6.Factoring is the process of decomposing a module into main and subordinate modules.2. Transaction Mapping Transaction mapping is applied when a single information item causes flow to branch along one of many paths. Perform the “first level factoring” . The DFD is mapped into a structure that allocates control to a substructure that acquires and evaluates a transaction. The internal and external design are guided by the information obtained from analysis phase. Identify the transaction center and flow characteristics along each action path 5. Refine the first iteration architecture using design heuristics for improved software quality 3. 6. The design steps for transaction mapping include: 1. Another substructure controls all potential processing actions based on a transaction.System Design Separate the transform center by specifying incoming and outgoing flow boundaries – incoming flow is a path in which information is converted from internal form to external form. 3.3 Interface Design The interface design focuses on three important areas: (1) the design of interfaces between software modules.

Design issues There are four design issues that need to be addressed while designing an interface. that a check is made to ensure that data conform to the boundaries set during the requirements analysis phase. knowledgeable. User model . also called inter-modular interface design is driven by the data that flows between the modules and the characteristics of the programming language in which the software is to be built. This model depicts the profile of end user of a system. System perception model or user’s model . This model incorporates data. So. which describes the system syntax and semantics. Here again. It is the time that is measured form the time the user performs some control action like hitting a key or clicking the mouse until some desired output or . 3.the software engineer establishes this model.the software engineer creates this model. There are four Interface design models that provides a human-computer interface (HCI). External design interface The external design interface evaluates each of the external entity represented in the DFD of the analysis phase.BSIT 44 Software Engineering 45 Internal Design interface The internal design interface. Design model . The data and control requirements of these external entities are determined before going in for this design. An end user can be a novice. Human-computer interface design The overall process model for designing a user interface begins with different models of the system functions. intermittent user or knowledgeable.  System response time This is an important issue that need to be addressed. the design must support data validation and error handling algorithms with in a module. 1.this model combines the look and feel of the computer based system with the supporting information available. frequent user. 4. User interface design The user interface design process begins with task analysis and modeling. System image model . Architectural and procedural description of the software. 2.this depicts an image of the system that is carried by the end users. This design must support data validation and error handling algorithms with in a module. The task analysis and modeling is a design activity that can be applied to understand the tasks and actions the user performs using either a elaborate approach or object-oriented approach.

 Error information handling Error messages or warning messages are produced by interactive system when ever something wrong has occurred. even though users are after window-oriented. enabling the user to select from those topics that are relevant to the actions currently being performed. the typed command was the most common type of interaction the user used to have with the system. . still many users are after the command-oriented interaction.46 Chapter 3 . should carry audio or visual clues the message wordings should never blame the user  Command labeling Earlier. error handling is an important design issue that need to be addressed. point and pick interfaces.  User help facilities Help facilities are very essential for any user interactive. there are two types of help facilities: integrated help facility and add-on help facility. and it is often context sensitive. Every error message or warning produced by an interactive system should exhibit characteristics like: the message should describe the problem in a proper form that can be understood by the user the message should provide positive. constructive ideas so as to encourage the user to recover from the error the message. ^D) Can commands be customized ? etc.System Design action is given out by the software. Integrated help facility – is designed to into the software from the beginning. some design issues that correspond to the command mode interaction need to be addressed: Will every menu option have a corresponding command ? What forms will commands take ? (i. It is an online user’s manual with limited query capabilities. Usually. since it enables any user to solve a problem without leaving the interface. care must be taken to reduce the likely hood of mistakes. The system response time depends on two factors : length of the response time and variability. It provides a very quick help for the user. In order to have a better quality software. And on-line help is the most thought of. computer-based system. So. the deviation from average response time. Now-a days.e. a typed key or function keys or control sequence such as ^P . Add-on help facility – this facility is added to the software after system has been built. So .

BSIT 44 Software Engineering


Design evaluation The user interface prototype once created after the design has to be evaluated to check whether it meets the user requirements. And the design evaluation cycle is shown in figure 3.4
The user interface evaluation cycle begins with the creation of a first level prototype soon after the preliminary design is over. This prototype is evaluated by the user and the comments about the interface is passed on to the interface designer. The designer then studies the evaluation report and performs modifications to the design thus creating a next level of prototype. The evaluation process continues until no further modifications to the interface design are suggested.

Interface design guidelines In-order to have a good interface, some design guidelines need to be followed for general interaction, information display and data input.
Here are some guidelines that focus on general interaction:

     

Use consistent format for menu selection, command input and data display Provide the user with meaningful feedback with audio and video support Ask the user for verification of any important destructive action. Eg. if a user wants to delete a file then use reconfirmation like “are you sure you want to delete ? “ Give the user with the functions like UNDO or REVERSE for easy reversal in interactive applications Provide context sensitive help facility for the user The user should not be expected to remember a list of names or numbers so that he can reuse them in subsequent functions i.e. minimize the amount of information that must be memorized between actions


Chapter 3 - System Design

Preliminary design

Build prototype #1 interface

Build prototype #n interface Design modifications are made User evaluates interface

Evaluation is studied by designer Interface design is complete

Figure 3.4 The interface design evaluation cycle

Here are some guidelines that focus on information display:

  

Display only the relevant information pertaining to the current context Use graphs or charts as presentation formats instead of voluminous tables Use consistent labels, standard abbreviations and appropriate colors

BSIT 44 Software Engineering


 

Produce meaningful error messages Allow the user to maintain visual context – if graphical representations are scaled up or down, the original image should be constantly displayed

Here are some guidelines that focus on data input:

    

Minimize the number of input actions required by the user – use mouse to select from predefined sets of input instead of using the keyboard Maintain consistency between information display and data input Allow the user to customize inputs Deactivate commands that are not appropriate in the context of current action Provide help to assist with all input actions

3.7.4 Procedural Design
The procedural design is carried out after the completion of data, architectural and interface design. It transforms structural elements of the program architecture into the procedural description of software components. The information obtained from process specification, control specification and state transition diagram of analysis phase serve as the basis for the procedural design. The design notation, along with structural programming concepts enable the designer to represent procedural details that can be effectively translated into code. The design notation can be in graphical or tabular or textual form. Structured Programming
Structured programming is an important procedural design technique. It refers to the use of a set of existing logical constructs from which any program could be formed. The constructs fundamental to structured programming are sequence, condition and repetition. Sequence – it implements processing steps that are essential in the specification of any algorithm. Condition – provides the facility for selected processing based on some logical occurrence. Repetition – provides looping. Graphical Design Notation
Flow charts and Box diagrams are very popular graphical design notations that readily depict procedural details.


Chapter 3 - System Design

Flow Charts Prior to the structured programming revolution, flowcharts were the predominant method of representing program logic. Flowcharts are limited by a physical view of the system that is improperly applied before overall logical requirements are understood. Figure 3.5 illustrates the three structured constructs : sequence, repetition and selection.
Sequence : If-then-else:

F First task Else part Next task

condition T Then part

Selection :


F T Case condition F T Case part


Figure 3.5

.BSIT 44 Software Engineering 51 Repetition : (a) Do-While (b) Repeat-Until Loop condition Loop T F task Loop task Loop condition T F Box diagram It is an another graphical tool which can be used to develop procedural design. The fundamental element of this tool is a box. The graphical representation of structural constructs are shown in figure 3.6. It is also known as N-S charts or Nassi-Shneiderman charts.

52 Chapter 3 .while part Loop condition (a) Do-While (b) Repeat-Until .System Design Sequence : If-then-Else: First task Next task Condition F T Else part Next + 1 task Then part Repetition: Loop condition Repeat -Until Part Do .

4.7.6 3. The organization of a decision table is given below: Example: A limited-entry decision table (2N entries.BSIT 44 Software Engineering 53 Selection: Case condition Value Value Value Case Part Case part Figure 3. It has a list of conditions and actions. The actions are based on the combinations of conditions. And the occurrence of any action depends on the decision rules .3 Tabular Design Notation Here are a few Tabular Design Tools that are used in designing a procedure.    Decision Tables Detailed State Diagrams and Tables Karnaugh map Decision tables They provide a notation that translates actions and conditions in to a tabular form. among them decision table is the popular one. N is the number of conditions) .

or structured English. A basic PDL syntax should include constructs for subprogram definition. e. PDLs were first proposed as a replacement for flowcharts.g. is a pidgin language which uses vocabulary of one language (i. repetition construct and I/O constructs. condition construct. They express the logic of a program in narrative form (in English). Let us consider an example of PDL. structured programming language). ‘i’ is character representation of letter i) Declare Value to be passed back via the function Pointer to string that is being converted Sign of value being converted .4 Program Design Language Program design languages (PDLs).e.e.7. English) and the overall syntax of another (i. A PDL is principally applied during the detailed design phase and it is best used to describe algorithms and specify interfaces between modules. Example Function parameter is string containing value to be converted into an integer (single characters are enclosed in single quotation marks.4.54 Chapter 3 . PDLs impose a language syntax upon their users that makes it possible to use automated tools for validity checking. interface description. and data declaration. where a string variable is converted in to an integer. also called pseudocode.System Design Rule numbers Condition 1 Condition 2 Condition 3 Action 1 Action 1 Action 1 Action 1 R1 Y Y Y x R2 N N N x Decision Rule R3 R4 R5 R6 R7 Y N N Y N N Y N N Y N N Y Y Y x x x x x x R8 Y Y N x 3.

BSIT 44 Software Engineering 55 Initialise variables(return value. change sign Return summed value to caller EndFunction . While(current string_character is a number) Convert to integer (remember string is read left to right) Endwhile Endwhile If the number is negative.sign remembering the first one. pointer to the value of the character being pointed to in the string) Begin Conversion loop While(current string_character is NOT end_of_string) While(current string_character is EQUAL blank OR tab_character OR end_of_line_character) Increment pointer to skip over white space */ Endwhile Skip over the leading + or .

coupling.56 3. we will see how to translate the design into implementation. When you build a system. 4. The three important levels of abstraction are procedural abstraction. 3. The constructs fundamental to structured programming are sequence. 2. PDL stands for ——————————— II a) Answer the following questions in one or two Sentences : 1. prototyping etc. ———————— and repetition. We have also seen that software design process involves four distinct but interrelated activities. data design. 1. and you should be able to come out with a design document at the end of a design process. levels of abstraction. we have looked at what it means to design a system.9 SELF CHECK EXERCISE I Fill in the blanks : 1. interface design and procedural design. Why is design an important phase in software development life cycle ? Explain II b) Answer the following questions in detail 2. 4. In the next chapter. 8. . In object-oriented design. ——————— and coupling The weakest coupling that is most desirable is ——————————————— A data flow diagram is mapped into program structure using transform mapping and/or ——————————— ——————— type of mapping is applied to an information flow that exhibits distinct boundaries between incoming and outgoing data.System Design In this chapter.8 SUMMARY Chapter 3 . architectural design. data abstraction and ————————The functional Independence is measured using two qualitative criteria namely. you should keep in mind several important characteristics such as modularity. What are the software design principle suggested by Davil? explain 3. Explain the model of architectural design. cohesion. What is abstractions? explain the levele of abstraction. 3.. the modules in the design represent ————— 2. 3.

Narosa publishing house Ian Sommerville. 7.10 REFERENCES 1. 15. 6.e. 4. 16. 13. 2. ed. 8. 10.5 . control abstraction cohesion data coupling transaction mapping. Software engineering. 8. 11. 7. 3. 14. 9. 12. Roger S. Addison-Wesley publications. data abstraction. focused? explain Name the four interface design models that provided a human computer interface ( HCI ) Explain the interface design evaluation cycle Explain the difference between integrated help and add-on halp What is structured programming? explain Explain any two graphical design notations used in procedural design I Answers: 1. 6. What are the five criteria used in evaluating modularity design method? explain Explain the criteria used to guide modularization Explain the concepts of Cohesion & Coupling Explain the design documentation Explain the principal for data design approach Explain the design steps for performing the transform mapping What are the three main a real where interface design i. 5. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997.BSIT 44 Software Engineering 57 5. transform mapping condition program design language 3. 3. 2. Pankaj Jalote. An Integrated approach to Software Engineering (second edition). 1996.

Internal and external documentation Understand the use of programming tools 4. Even when writing the code. we must focus on implementing the solution as software. there are many ways to implement a design. several types of jobs are required to be performed by the team. it explains some of the software engineering practices that you need to follow when you write the code. Even though.Software Coding . In-order to generate a quality product. many people 58 Chapter 4 . we must write the programs that implement the design. That is. and many languages and tools that are available. we will look at      Standards of programming Guidelines for programming Appreciate the importance of documentation with respect to programming Types of documentation .0 INTRODUCTION S o far.2 CODING STANDARDS AND PRACTICES Most of the software is developed by a team of people. we were able to understood the user’s problem. Now. 4. in the form of requirements and the way of addressing them in the form of design to get a high-level solution.Chapter 4 Software Coding 4.1 OBJECTIVES In this chapter. this chapter does not teach you how to program rather.

No matter what language is used. Some procedures involve methods of documenting your code so it is clear and easy to follow. However. test and modify. Let us look at some of the guidelines that are applicable here:     The code shall be written in such a way that it can be read easily from top-down The concept of modularity need to be followed in-order to hide the implementation details and to make the code more understandable.BSIT 44 Software Engineering 59 are generally involved. By structuring code according to standards. Standards and procedures can help you to   organize your thoughts and avoid mistakes. And the given design is translated in to code. each program component involves at least three important aspects: control structures. control depends on the structure of the code it self. easy to understand. it is very important for others to understand not only what you have written. Good programming involves a great deal of creativity. easy to test and maintain Use parameter names and comments to exhibit coupling among code components Instead of commenting the code with Re-estimate TAX . Control structures Many of the control structures for a program component are given by the architecture and design of a system. In procedural designs. but also why you have written it and how it fits in their work. The design or requirements specification may suggest a programming language for use. irrespective of the design type. Good programming is a practice independent of target programming language. it is important that the program structure should reflect the design’s control structure. such as implicit invocation and object-oriented design. Translate designs to code. control is based on the system states and changes in variables. algorithms and data structures. it is a skill that can only be acquired by practice. Thus. it is possible to maintain the correspondence between design components and code components. For these reasons. In case of some architecture. and a great level of cooperation and coordination is required.3 PROGRAMMING GUIDELINES The primary goal of coding phase is to translate the given design into source code in a given programming language. one must know the organization’s standards and procedures before beginning to write code. so that the code is simple. 4. We will see them in more detail here.

elseif (age < 65) Benefit = minimum + Bonus. Goto C. If (age < 65) Goto B. Benefit = Benefit * 1. a programmer has lot of flexibility . Benefit = maximum. B: if (age < 55) Goto C. Even though. elseif ( age < 75) Benefit = minimum * 1. Algorithms The program design often specifies a class of algorithms to be used in coding.5 + Bonus . making it difficult to follow: Benefit = minimum. C: Next statement. If (age < 75) Goto A. Goto C. so that it helps in better understanding Consider an example.5 + Bonus.5 . Benefit = Benefit * 1. the design may tell the programmer to use binary search technique. else Benefit = maximum. The same piece of program can be restructured for better understanding : if (age < 55) Benefit = minimum.60 Chapter 4 . For example. If (age < 55) Goto C. A: if (age < 65) Goto B. here the control skips around among the program’s statements.Software Coding It is better to write Re-estimate TAX based on values of GROSS_INCOME and DEDUCTIONS  Restructure the code as far as possible.

it is desirable to localize these sections in components separate from rest of the code Pseudo-code can be used for transforming the design to code through a chosen programming language.BSIT 44 Software Engineering 61 in converting the algorithm to code. Data structures In writing programs. There are two kinds of program documentation :   Internal documentation External documentation . In general. the data structure must be very carefully considered while deciding the language for implementation. code can be rearranged and restructured with a minimum rewriting Revise the design and rewrite the code until one is completely satisfied with the result Reuse code components if possible    4. It is so designed that it contains structures that make it much easier for handling lists than other languages. By adopting constructs and data representations without becoming involved immediately in the specifics of each command. LISP is a language for list processing. one should format and store data in such a manner that the data management and manipulations are straight forward. General guidelines There are several strategies that are useful in preserving the design quality of a program. In this way. the program sections performing input and output functions are sometimes difficult to test.4 DOCUMENTATION Documentation is an important activity in the implementation phase. one can experiment and decide which implementation is most desirable. In general. For example.  Localizing input and output – those parts of a program that read input or generate output are highly specialized and must reflect characteristics of the underlying hardware and software. it can even influence the choice of programming language. In some cases. it depends on the constraints of the implementation language and hardware. The program documentation is a set of written descriptions that explain to a reader what the programs do and how they do it. Therefore. data structures can influence the organization and flow of a program. Because of this dependency. The program’s design may specify some of the data structures that can be used in implementing functions.

The information contains a description of data structures. The header comment block acts as an introduction to the program. Providing comments for modules in a program are very useful. if any Global variables accessed and/or modified in the module Comments have a place even in clearly structured and well-written code. Since. Meaningful variable names and statement labels Appropriate names for variables and statements that reflect their use or meaning need to be chosen in a program. It has the following information for each of the code component : what is the name of the component who wrote it where does the component fit in the general system design when was the component written and revised why the component exists how the component uses its data structures. Comments. if properly written and kept consistent with the code. helping them to understand how the intentions described in the header are implemented in the code.62 Chapter 4 . It contains information directed at some one who will be reading the source code of the program. It is bad practice to choose cryptic . this information is placed at the beginning of each component in a set of comments called the header comment block. can be invaluable during maintenance. Although code clarity and structure minimize the need for other comments. And the comments for a module are often called prologue for the module. algorithms and control flow. Comments enlighten the readers as they move through the programs. It is very important that the comments need to be updated to reflect changes whenever the code is revised. It is desirable that prologue contains the following information :     Module functionality Parameters and their purpose Assumptions about the inputs. Usually. it is considered as a good style of programming. algorithms and controls Program comments Comments in a program are textual statements that are meant for program readers and are not executed. additional comments are useful whenever helpful information can be added to a component. at a level appropriate for a programmer.Software Coding Internal documentation Internal documentation is a descriptive material written directly with in the program.

result = 4. Simple_Interest = (Principle * Time * Rate) / 100.0 Proper formatting enhances easier understanding When the code is properly formatted. elseif (slope1 < slope2) result = 3.BSIT 44 Software Engineering 63 names or totally unrelated names. elseif ( slope1 > slope2) result = 2. else result = 1. elseif ( xcoord == ycoord ) if (slope1 > slope2) result = 0. else result = 1. . the same code can be formatted for clarity by using proper indentation and spacing : if ( xcoord < ycoord) result = -1. The indentation and spacing of statements are very important and can reflect the basic control structure of a program. Notice how unintended code looks like : If ( xcoord < ycoord ) Result = -1. elseif ( xcoord == ycoord) if ( slope1 > slope2) result = 0.0 Makes more sense to the reader than writing the statement C = ( A * B * C) / 100. that code can easily be read and understood. Writing.

once when the existence of the component is clear. elseif (slope1 < slope2) else result = 4.  Data description This describes the flow of data at the component level. Usually. It explains things more broadly then that of program’s comments.5 USER DOCUMENTATION In the implementation phase.Software Coding Documenting data When a system handles many files of different types and purposes. data flow diagrams along with data dictionaries are used in the form of references. . a data map is very essential to document data. proper communication in the form of user document becomes very essential. Based on the following factors. The external code documentation contains the following description :  Problem description It explains what problem is being addressed by the component. External documentation It is a part of overall system documentation. And the users have to be extensively trained for it. Chapter 4 . 4. when the component is invoked and why it is needed.  Algorithm description Addresses the choice of the algorithms. So. It explains each algorithm used by the component. its complexity. it is possible to decide on the type of user documents:  The nature of software.64 elseif (slope1 > slope2) result = 2. documentation assumes a very important role. The nature and number of user documents usually vary across applications and organizations. along with flags and passed parameters. boundary conditions etc. It is intended to be read by those people who may never look at the actual code. result = 3. it is in this phase that the skills need to be passed from the development team to the users. including formulae. So. it is very difficult for program readers to understand the way in which data is structured and used. Because. interfaces etc.

11.BSIT 44 Software Engineering    65 User groups. Any user document would generally consists of the following components: 1. 5. 9. 5. 8. conventions followed etc. This generally include: 1. 4. 3. user manual. error message manual etc. procedure manual. Title page Restrictions Warranties Table of contents List of illustrations Introduction Body of document Error conditions and recovery Appendices Bibliography Glossary Index The introduction would generally give an idea of the intended users for whom the document is addressed. depending on the nature of usage. the documentation set could consists of installation manual. 3. 12. the main idea here is to ensure that the users have complete documentation on how to install. reference mode or both Generally. how to use it. 10. operations manual. use and manage the software. whether it has to be an instructional mode. information on other related documents. 2. 4. their exposure and training levels of users Volume of information presented Document usage mode. 2. 7. 6. However. Scope Prerequisites for usage Preparatory instructions Cautions and warnings Description of each task giving . The body of the document gives the main contents of the document.

these relate to the editing of source code browsing tools. Testing tools help in tracing the code errors. concept of code re-usability. Executable code tools Tools that are required for working with executable codes. Debugging tools help in debugging the code. there are tools available that help to reduce the amount of time spent on the development of programs.7 SUMMARY In this chapter.Software Coding Information on associated tasks and limitations 4. debugging and testing. we will discuss the way of testing the code and how to make the software a quality software. align variable declarations and format comments. incorporation of systemwide error-handling strategy and proper program documentation. It helps in code creation. . code generators and macro-preprocessors.6 PROGRAMMING TOOLS Today. we have looked at the several guidelines for implementing programs. helps to view the source code The source-code beautifiers and templates not only makes a program look consistent but also standardize indentation styles. Source-code tools There are two commonly used source-code tools editing tools.66     6. and also address some of the important issues in implementing the design to produce high quality software. It is necessary that certain points need to be considered while writing the programs by the programmer. code libraries. such as organizational standards and guidelines to be followed. What user is expected to do What function is to be invoked Possible errors and how to avoid them Expected results Chapter 4 . In the subsequent chapters. 4. Let us see some of the popular one. Code creation has four major tools which help the developer in converting the source code into executable code : Linker. We were able to see the importance of programming tools.

BSIT 44 Software Engineering


I Fill in the blanks: 1. A program component involves three important aspects: control structures, —————— ———— and data structures
2. 3. 4. 5. The two kinds of program documentation are internal and ———————————— Comments in a program are —————————— that are meant for program readers and are not executed ————————— helps to view the source code ——————————————tools helps in code creation, debugging and testing.

II a) Answer the following questions in one or two sentences : II b) Answer the following questions in detail 1. What are programming guidelines? explain
2. 3. 4. 5. Explain the type of documentation Write a short note on user documentation What are programming tools? explain What are source code tools? explain

I Answers for fill in the blacks 1. algorithms
2. 3. 4. 5. external textual statements browsing tools executable code

1. 2. 3. 4.

Chapter 4 - Software Coding

Shari Lawrence Peleeger, software engineering theory and practice, Pearson education, 2001, ed. 2 Roger S. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. Pankaj Jalote, An Integrated approach to Software Engineering (second edition),Narosa publishing house Ian Sommerville, Software engineering, Addison-Wesley publications, 1996, ed.5

Chapter 5

Software Testing



oftware testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. In the process of software development, errors can occur at any stage and during any phase. The errors encountered during the earlier phases of software development life cycle (SDLC) such as requirements, design phases are likely to be carried to the coding phase also, in addition to the errors generated at the coding phase. This is particularly true because, in earlier phases most of the verification techniques are manual and no executable code exists. Because code is the only product that can be executed and its actual behavior can be observed, testing is the phase where errors remaining from all the phases must be detected. Hence, testing performs a very critical role for quality assurance and for ensuring the reliability of software. In this chapter, we discuss software testing fundamentals, techniques for software test case design and different strategies for software testing.

At the end of this chapter you should be able to

    

Say what software testing is State testing objectives Understand the basic principles behind testing Differentiate white-box from black-box testing method Derive test cases using white-box or black-box methods

BSIT 44 Software Engineering


By contrast. software can fail in many different ways. If any of these parts is faulty.Software Testing Discuss unit testing. behavior. Obviously the benefit of the entire software testing process is highly dependent on many different pieces. and (2) reliability estimation. not their absence (unless the testing is exhaustive). Most physical systems fail in a fixed (and reasonably small) set of ways.70     Give the importance of different testing strategies Chapter 5 . this is computationally infeasible. the mechanism used to determine whether program output is correct (known as an oracle) is often impossible to develop. Where software differs is in the manner in which it fails.but how? That’s where software testing techniques enter the picture. . validation testing and system testing and their importance Come out with a test plan Describe reliability. These techniques provide systematic guidance for designing tests that: (1) (2) exercise the internal logic of software components. as an important metrics for testing software 5. It is commonplace to attempt to test as many of the syntactic features of the code as possible. the entire process is compromised. software must be tested to uncover (and correct) as many errors as possible before delivery to the customer. Software is not unlike other physical processes where inputs are received and outputs are produced. Techniques that do not consider the code’s structure when test cases are selected are called black-box techniques. The problem of applying software testing to defect detection is that software can only suggest the presence of flaws. integration testing. and exercise the input and output domains of the program to uncover errors in program function. The problem of applying software testing to reliability estimation is that the input distribution used for selecting test cases may be flawed. The goal is to design a series of test cases that have a high likelihood of finding errors .2 FUNDAMENTALS OF SOFTWARE TESTING Software testing is the process of testing the functionality and correctness of software by running it. and performance. Techniques that try to exercise as much of the code as possible are called white-box software testing techniques. In both of these cases. Once source code has been generated. Detecting all of the different failure modes for software is generally infeasible. The key to software testing is trying to find the modes of failure — something that requires exhaustively testing the code on all possible inputs. For most programs. Software testing is usually performed for one of two reasons: (1) defect detection.

3. 2. testing is a process of executing a program with the intent of finding error a good test case is one that has a high probability of finding an as-yet undiscovered error a successful test is one that uncovers as-yet undiscovered error. Testing principles Here are some basic principles that are applicable to software testing. that need to be followed before applying methods to design test cases:       All tests should be traceable to customer requirements Tests should be planned long before testing begins The Pareto principle ( implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program modules) applies to software testing Testing should begin “in small “ and progress towards testing “in large”. design and coding phase. Test Case Design Any engineered software product can be tested in two ways: . so that testing will be very effective 5. Testing cannot show the absence of defects it can only show the presence of errors. Exhaustive testing is not possible The tests should be conducted by an independent third party. from module level testing towards entire system testing.BSIT 44 Software Engineering 71 Testing objectives The following statements serve as the objectives for testing : 1.3 SOFTWARE TESTING TECHNIQUES It is an important element of Software Quality Assurance activity and it is the ultimate review of specification. Testing function will find errors in software It will show that the software functions appear to be working according to the specifications Indicates software reliability and software quality as whole But.

Guarantee that. Equivalence partitioning method White Box Testing : It is also known as structural testing. . . . . Knowing the specified function that the product has been designed to perform. 3. Knowing the internal working of product. tests can be conducted to demonstrate that each function is fully operational Examples: Boundary value analysis. test can be conducted to ensure that all internal operations perform according to specification that all internal components have been adequately used.Box Method White-box method is also known as glass-box testing.e. . . 4. Example : Basis path testing 5. 3. It is a test case design method or this testing method is used for designing test cases. 2. for i = 1 to 10 boundaries 4. . Using this method the software engineer derive the test cases that : 1.9 Internal bound Use internal data structure to assure then validity. Use of decisions which are based on true and false value or user decisions based on true and false values. all independent paths with in a module have be used at least once. It uses control structures of procedural design to derive the test cases.1 White . 2.3. Execute all the loops at their boundaries and within their internal bound i.72 1. White-Box Testing Black-Box Testing Chapter 5 . 5. White-box testing handles errors such as logical errors and typographical errors Basic path Testing It is a White-box testing technique This method enables the test-case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining the basis set of execution paths . 2.Software Testing Black Box Testing : It is also known as functional testing.

as shown in figure 5. we will consider the procedural design representation and it is represented as a flow chart. called edges or links. represents one or more procedural statements.3 maps the flowchart into a corresponding flow graph.2. Each circle. . Figure 5. The arrow on the flow graph. Areas bounded by nodes and edges are called regions.BSIT 44 Software Engineering 73 Sequence if while Figure 5. a flow chart is used to depict program control structure.1 To illustrates the use of flow graph. called a flow graph node. Here.1 - Uses flow graphs for representing the control flow or logical flow. as shown in Figure 5. A sequence of procedure boxes and decision box can map into a single node. represent flow of control.

Software Testing 1 2 3 6 4 5 7 9 10 8 Figure 5.N + 1 This number defines the number of independent paths in the basis set of a program and also gives the upper bound for the number of tests that can be conducted so that all statements have been executed at least once.2 Flow Chart Cyclomatic complexity is a software measure. Cyclomatic Number = E . . it give a number called cyclomatic number.74 Chapter 5 . that provides a quantitative measure of logical complexity of a program When used in basis path method.

BSIT 44 Software Engineering 75 1 2.3 Flow Graph Set of Independent path A path in program that introduces at least one new condition or one new set of processing statements.11 * Path 2 : 1-2-3-4-5-10-1-11 Path 3 : 1-2-3-6-8-9-10-11 Path 4 : 1-2-3-6-7-9-10-11 * 1-2-3-4-5-10-11-1-2-3-6-8-9-10-1-11-1-2-3-6-7-9-10-11 .3 6 4.5 Nodes 7 8 9 Region 10 11 Edge Figure 5. Path 1 : 1.

This is performed is later stages of testing.N + 2 = 11 – 9 + 2 = 2 + 2 = 4 V(G) = 3 + 1 = 4 This V(G) gives the upper bound for the number of independent paths that form the basis set. Chapter 5 . 2. 2. paths 1-2-3 and 4 form the basis set for the flow graph. Cyclomatric complexity (CC) can be computed in 3 ways: 1. 4. and N = number of nodes. Example: 1. like : 1. It focuses on the functional requirements of the software.Software Testing The number of regions of a flow graph correspond to cyclomatic complexity Cyclomatic complexity V(G) for a flow graph G is defined as V(G) = E . It purposely discards control structures and focuses on information domain.2 Block Box Testing Black. CC = 4 (because. The engineer can derive sets of input conditions that satisfy all the functional requirements of a program. there are 4 regions) V(G) = E . The cyclomatic complexity V(G) for a flow graph G is defined as V(G) = P + 1 where P is the number of predicate nodes contained a flow graph.N + 2 where E = flow graph testing is also known as behavioral testing or partition testing. 3.3. 3. 5. 3. 2.76 Here. . 5. Incorrect or missing functions Interface errors Errors in data structures or external data base access Performance errors Initialization and termination errors Graph based testing method A Graph representation is used for this Software testing begins by creating a graph of important objects and their relationships and devising a series of tests that will cover the graph so that each object and relationship is exercised and errors are uncovered. It finds different class of errors.

link weights should be established. Once nodes have been identified. Timing modeling etc.4 Graph notation In order to accomplish these steps. A test case will handle each class of data and produce different classes of errors. reflexive and symmetric. links that represents relationship between objects. a software engineer begins by creating a graph . the symbolic representation of a graph is shown in figure 5.4. node weights that describe the properties of node and link weights that describe some characteristics of a link. Equivalence partitioning It is a block box testing method. symmetric relation. Test case design for equivalent partitioning is based on the evaluation of equivalence classes for input condition. Equivalence class equivalence class of objects are present if the set of objects have relationships like transitive.BSIT 44 Software Engineering 77 Object #1 Directed link Object #2 Undirected link Object #3 Parallel links Figure 5. reflexive relation. links. Graph . Each relationship is studied separately like transitive relation. The Input domain of a program is taken and it is divided into classes of data from which test cases can be derived.a collection of nodes that represents objects.Based testing method is used by Transaction flow modeling Data flow modeling Finite state modeling. .

set . “deposit “.Software Testing represents a set of valid or invalid states for input conditions.6 character string Command : Input condition.values defined between 100 & 999. a range of values. Prefix : Input condition. a set of related values.78 - Chapter 5 .specified values > 200 with no 0 digits. Input conditions being: specific numeric value. Boolean . value .4 digit length Password : Input condition. etc. Boolean . Input conditions for each data element : Area code : Input condition. Equivalence classes may be defined according to the following guidelines: Input condition specifies Range of values A numeric value Set of values Boolean value Equivalence classes defined 1 valid and 2 invalid 1 valid and 2 invalid 1 valid and 1 invalid 1 valid and 1 invalid Example: Automated banking application Data is accepted in the form: Area code : blank or 3 digit numbers Prefix Suffix Password : 3 digit numbers not beginning with 0 : 4 digit number : 6 digit alphabetic numeric Commands : “check”.area code may or may not be present. value .may or may not be present Input condition. . range . Input condition range .containing commands as said above. Suffix : Input condition. and Boolean conditions.

4 SOFTWARE TESTING STRATEGIES A strategy for software testing integrates software test case design methods into a well planned series of steps that result in successful construction of software. the test cases are selected at the “edges” of the class. 2. Boundary Value Analysis (BVA) It is a testing technique meant for testing the boundaries of the input domain for errors.1 Guide lines for BVA: Input Conditions defined 1. Table 5. Here. A strategic approach to software testing Testing is a set of activities that can be planned in advance and conducted systematically.BSIT 44 Software Engineering 79 Next equivalence classes are derived using guidelines for input conditions. quality assurance team and the customer. BVA derives the test cases from the output domain. Internal data structures Note: guidelines 1 and 2 are applicable to output conditions also. 3. A range of values (say bounded between a & b) A numeric value Test Case designed is designed with values a & b. values that are just above and just below maximum and minimum. It is a test case design technique. For this reason a template. a set of steps into which specific test case design methods can be fitted. a strategic approach can be used to provide templates for software testing. The guide lines for BVA is shown in table 5. are some important characteristics for this approach:   Testing begins at the module level and works “outward” toward the integration of the entire computer-based system Different testing techniques are appropriate at different points in time . for which text cases are developed and executed. just above and just below a & b respectively use maximum and minimum numbers. It provides a roadmap for the software developer. boundary testing is followed.1 5. So. It is a complement of equivalence partitioning method. is required.

Validation .1 Unit Testing Concentrates on functional verification of a module Using procedural design description as a guide. . with the following types of testing: Unit testing Integration testing Validation test System test 5. with the following activities: System engineering.80   Chapter 5 . is traceable to the customer a set of activities that ensures that the software correctly implements a specified function. Verification . important control paths are tested to find out the errors within the boundary of the module. Requirements analysis Design Coding A strategy for software testing may also be viewed as a spiral. Software Engineering process may be viewed as a spiral. but debugging must be accommodated in any testing strategy Verification & validation ( V & V) V & V are Software Quality Assurance activities.4. It is white-box oriented The functional verification can be done in parallel for multiple modules.a set of activities that ensures that the software that has been built.Software Testing Testing is conducted by the developer of the software and an independent test group Testing and debugging are different activities.

Incorrect comparisons or improper control flow . But these two software are overhead. So. . Local data structure Boundary conduction Independent paths Error handling paths 1) 2) 3) 4) 5) First the module interface is tested to ensure that information properly flows into and out of the program unit under test. Each test case is coupled with a set of expected results.BSIT 44 Software Engineering 81 Steps involved in unit testing are : 1.e. 5. below. incorrect logical operations or precedence. etc. at. mixed mode operations.comparison of different data types.e. driver and / or stub software must be developed for each unit test. A module in unit test is not a standalone program. Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing. All Independent paths (basis paths) through the control structure are executed to ensure that all statements in a module have been executed at-least once. Finally.5 shows a unit testing environment. all error handling paths are tested. (i. Unit testing is normally associated with the coding step i. So. the maxima and minima. reviewed. The local data structure is examined to ensure that data stored temporarily maintains its integrands during all steps in an algorithm’s execution. they are developed but not delivered with the final software product) figure 5. Interface 2. after the source code has been developed. improper loop termination etc. 4. verified only then the test case design begins.Incorrect arithmetic precedence. Boundary values just above. Test cases are so designed to uncover errors due to: erroneous computations . 3.

It does minimal data manipulation.2 Intergration Testing It is a systematic technique for constructing the program structure while constructing tests to find errors associated with interfacing.82 Chapter 5 . that replaces the modules that are subordinate to the module to be tested. passes it to the module to be tested and prints the relevant results. and build a program structure that has been dictated by design. Unit testing is advantages when a module to be tested defines only one function.Software Testing Driver Interface Local data structures Boundary conditions Independent paths Error handling paths Module to be tested stub stub Test Cases results Figure 5.4. There are two categories of Integrated testing : . 5. a driver is a software or “main program” that accepts test case data. and that the number of test cases are reduced which in turn makes error handling easier. A module with high cohesion simplifies unit.5 Unit testing environment In most applications. A stub is a “dummy sub program”. prints verification of entry and returns. The objective is to take modules which are unit tested.

BSIT 44 Software Engineering 83 1. 3. Top-down Integration 2.6 Depth-first integration .6. modules m1. Bottom-up integration Sandwich testing 1. m2. And the entire program is tested as a whole. Errors are more and difficult to isolate and correct. Incremental Integration : The program is constructed and tested in small segments where errors are easier to isolate and correct. Depth-First Integration: this would integrate all modules on a major control path of the structure. Example: Selecting left hand path. All modules are combined in advance. However. 2. Then central and right hand control paths are built. m1 m2 m3 m4 m5 m6 m7 m8 Figure 5. next either m8 or M6 would be integrated. Incremental Integration strategies: 1. Modules subordinate (and ultimately sub ordinate) to the main control module are incorporated in to the structure in either a depth-first or breadth-first manner. the major control path can be arbitrarily selected and it depends an application specific characteristics. Non-incremental integration: It uses a “Big bang” approach to construct the program. and m5 would be integrated first. The depth-first integration is shown in figure 5. Top Down Integration: Is an incremental approach to the construction of program structures Modules are integrated by moving down ward through the control hierarchy. beginning with the main control module (main program). Interfaces are more likely to be tested completely and a systematic test approach is applied.

m5.overhead 2. Disadvantages: Need for stubs . Tests are conducted as each module is integrated. 2. and stubs are substituted for all modules directly subordinate to the main control module. Top-down Integration is performed with the following steps: 1.Software Testing Breadth First Integration : Incorporates all modules directly subordinate at each level. The tester is left with 3 choices: 1. 2. but in practice has several logistical problems. Bottom-up Integration : The modules at the lowest levels in the program structure are constructed and tested. Integrate the software from the bottom of the hierarchy upward – bottom-up testing. The main control module is used as a test driver.workable but leads to significant overhead as stubs become more and more complex. The most common of these problems occurs when processing at low levels in the hierarchy is required to adequately test upper levels. The process continues from step 2 until the entire program structure is built. moving across the structure horizontally. Stubs replace the low level modules at the beginning of top-down testing therefore no significant data can flow upward in the program structure. This approach verifies major control or decision points early in the test process. Develop stubs that perform limited functions that simulate the actual module . 4.7 . Here need for stub is eliminated.84 Chapter 5 . another stub is replaced with the real module. On completion of each set of tests. Figure 5. Though this approach sounds relatively simpler. m6 and so on. Delay many tests until stubs are replaced with actual modules . 3. Stub is a module directly subordinate to main control module. Regression testing may be conducted to ensure that new errors have not been introduced. modules m2. 3. From figure 5. A test driver is a main control module. m3 and m4 are integrated first.6 . 5. next control level. Depending on the Integration approach (either depth-first or breadth-first) subordinate stubs are replaced one at a time with actual modules.this leads to the difficulty in determining the cause of errors and tends to violate the highly constrained nature of the top down approach. Advantages : Testing of major control functions early.

Similarly.BSIT 44 Software Engineering 85 Steps required for implementing bottom-up integration strategy : 1. Now.7. Drivers are removed and clusters are combined moving upward in the program structure. Then ultimately modules ma & mb are integrated with module mc. A driver (a control program for testing) is written to co-ordinate test case input and output.7 Bottom-up integration . driver D3 of cluster 3 is removed and then cluster 3 is integrated to module mb. Driver D1. Low level modules are combined into clusters (sometimes called builds) that perform a specific software sub function. The cluster is tested. 2. D2 are removed and the cluster 1. 4. Modules in clusters 1 and 2 are subordinates to ma.2 & 3. modules are combined to form clusters 1. 2 are interfaced directly to ma. 3. mc ma mb D1 D2 Driver D3 Cluster 3 Cluster 1 Cluster 2 Figure 5. According to figure 5. Each cluster is tested using a driver (dashed box).

86 Chapter 5 . Regression Testing: Is an activity that helps to ensure that changes that often take place. selection of an integration strategy depends upon software characteristics and sometimes project schedule. In general.4. Tests that focus on the software components that have been changed. It uses a top-down strategy for upper levels of the program structure. that are likely to be affected by the change. new input may occur and new control logic is invoked. These software changes do occur every time a new module is added as part of integration testing . - The regression test suite contains three different classes of test cases: 1) A representative sample of tests that will exercise all software functions. So. do not introduce additional data paths are established. coupled with a bottom-up strategy for subordinate levels. Sandwich testing : A best compromise between two methods. This testing may be conducted manually. 2) 3) Additional tests that focus on software functions. a combined approach called as sandwich testing is used that takes characteristics of both approaches.Software Testing Advantages: This method is very simple. 3. by re-executing a subset of all test cases using automated capture play back tools (these tools enable the software engineer to capture test cases and results for subsequent playback and comparison) Focuses on critical module function.3 Validation Testing Focuses on requirements Here validation criteria stated in requirements are tested. Substantial decrease in the number of drivers if the top two levels of program structure are integrated top-down Lack of stubs easier test case design. 5. behavioral and performance requirements . This gives a final assurance that the software meets the functional. Disadvantages : Program as an entity does not exist until the last module is added.

4. It is a ‘live” application of the software in an environment. Usually the developer keeps track of working of the software. Customer records all the problems (real or imagined) that are encountered and reports to the developer at regular intervals.BSIT 44 Software Engineering 87 - Black box testing is exclusively used. The function or performance characteristics conform to specification and are accepted. one of the two possible conditions exists: 1. And a test procedure defines specific test cases that will be used to find errors. database etc. The Alpha Test : is conducted at the developer’s site by a customer. A classic system testing problem is “finger pointing” this occurs when an error is uncovered and each system element developer blames the other for the problem. they are not in the controlled environment. Beta Test: is conducted at one or more customer sites by the end user(s) of the software. information. So. 5.. So. The software developer is generally not present. Validation test criteria is based on test plan and test procedure. alpha tests are conducted in a controlled environment. It is actually a series of different tests whose main purpose is to fully exercise the computer based system. are catalogued and detailed to support the maintenance phase of software life cycle. This is done to ensure that all elements of the software configuration have been properly developed.. A test plan outlines the classes of tests to be conducted. 2. Alpha and Beta Testing: Are tests conducted to find out errors at the customer side.4 System Testing This testing verifies that the system performs well with other system elements like hardware. records errors etc. . A deviation from specifications is uncovered and a deficiency list is created. Configuration Review: It is also termed as audit It is an input element of the validation process. After each validation test case has been conducted.

4. Stress Testing: It is designed to confront programs with abnormal situations. the tester plays the role of the individual who desire to penetrate the system. 5. data recovery. It is often combined with stress testing. (i. a process that results in the removal of errors occur. for revenge. A variation of stress testing is called sensitivity Testing. Performance Testing : It is mainly used for testing real-time and embedded systems.Software Testing Recovery Testing: Is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. check pointing mechanisms. a system failure must be corrected within a specified period of time). If automatic. the system designer has to make the penetration cost greater than the value of the information to be obtained.5 Debugging It occurs as a consequence of successful testing. . then debugging. When a test case uncovers an error. Security Testing: It attempts to verify that protection mechanisms built into a system will in fact protect it from improper penetration (like hackers attempt to penetrate systems for sport. During this testing. So.e. Recovery can be automatic or manual. and restart are each evaluated for correctness. This testing executes a system in a manner that demands resources in abnormal quantity. the meantime to repair is evaluated to determine whether it is within acceptable limits. frequency or volume. for illicit personal gain etc). If recovery requires manual intervention.88 Types of system testing: 1) Recovery Testing 2) 3) 4) Security Testing Stress Testing Performance Testing Chapter 5 . It is designed to test run -time performance of software within the context of an integrated system. re-initialization.

We even know that. It is applied when all else fails. regression testing is done. the source code is traced backward (manually) until the site of course is found. In regression testing. In order to validate that a change has not affected some old functionality of the system. 5. Backtracking: fairly common. . Brute force method : it is the most common and least efficient method. Cause elimination: uses the concept of binary partitioning “A cause hypothesis” is devised and data related to the error occurrence are used to prove or disprove the hypothesis. 2. software typically undergoes changes even after if has been delivered. old test cases are executed with the expectation that the same old results will be produced. But this testing adds on additional requirements on the testing phase. beginning at the site where symptom has been found. can be successfully used in small programs. 3. before the software product is developed.BSIT 44 Software Engineering 89 - Debugging process begins with the execution of test cases There are three debugging approaches commonly used : 1.5 TESTING PROCESS        Comparison of different Techniques Levels of Testing Test plan Test case specifications Test case execution and analysis Reliability models Source code metrics Testing is the last phase in the life cycle of the software product.

3. And testing cannot be done all a sudden. it has to be done efficiently. It is good for input errors and data handling errors. So. computational errors and Interface errors. Does not require test case planning. test case generation or test case execution. Features to be tested Approach for testing Test deliverables Schedule Personnel allocation. 2.90 Chapter 5 . is best for testing the entire program or system. . The testing process focuses on how testing proceed for a particular project.Box Testing).6 TEST PLAN It is a general document for the entire project that defines the scope.Software Testing Testing is the costliest activity in the software development. 5. approach to be taken and the schedule of testing. The inputs for forming the test plan are:1. Is best suited for testing only one module (and not for entire program therefore it is difficult to generate test cases to get the desired coverage) It is good for detecting logic errors. Here faults are found directly. Functional Testing (Black . Code Reviews: Cost effective method of detecting errors. This plan can be prepared before actual testing begins and can be done in parallel with the coding and design phases. test deliverables and the personnel responsible for different activities of testing. Project plan Requirements document System design document A test plan containing the following: Test unit specification. Structural testing (White Box testing) . Code is reviewed by a team of people in a formal manner. a careful planning is required and the plan has be executed properly.

It specifies the levels of testing and the units that need to be tested. Test deliverables: List of test cases that were used Detailed results of testing Test summary report Test log Data about code coverage In general. The testing process usually begins with a test plan which is the basic document guiding the entire testing of the software. (i. Testing criterion for evaluating the set of test cases should be specified. integration testing etc. Schedule Specifies the amount of time and effort to be spent on different activities of testing and testing of different units that have been identified. it is input to look for “testability” of a unit. design constraints and attributes.e. a test case specification report .BSIT 44 Software Engineering 91 Test unit specification: An important activity of the test plan is to identify the test units. performance. Personnel allocation: Identifies the persons responsible for performing different activities. different levels of testing are also specified like unit testing. a unit should be tested early or it should be possible to form meaningful test cases and execute the unit without much effort with these test cases) Features to be tested: Includes all software features and its combinations to be tested. A test unit is a set of one or more modules together with data. test summary report and test log should be supplied as deliverables. These features are the ones specified in requirement or design documents like functional. Approach for testing: Specifies the overall approach to be followed in the current project. For each of . While forming “test units”. Along with identification of test units.

then during the test case execution phase. The main outputs of the execution phase are: The test log. To assess the reliability of software.8 It is given by the equation:  (U) = 0 (1. the test summary report and the error report. Failure intensity = number of failures / unit time In basic model. the test cases are executed and various reports are produced for evaluating testing.7 METRICS FOR SOFTWARE TESTING The important metrics used during testing is reliability.U/V 0) . Most widely used model This is an execution time model. the failure intensity decreases with a constant rate with the number of failures. it is assumed that. It assumes that the failure intensity decreases with time. Its predictive value has generally been found good This model focuses on failure intensity while modeling reliability.Software Testing the different units.92 Chapter 5 . 5. first the test case specification are given and renewed. See fig 5. Most of these reliability models are based on the data obtained during the system and acceptance testing. reliability models are used. Data about time between failures observed during testing are used by these models to estimate the reliability of software. The reliability of software depends on the faults in the software. MUSA Model (Musa’s basic execution time model) Simplest model proposed for software reliability assessment. Simple to understand .

V0 is the total number of failures that would occur in infinite time.BSIT 44 Software Engineering 93 Intensity Execution time Figure 5.8 failure intensity with time Where  0 is the initial failure intensity at the start of execution. .  0 . V 0 whose values are used to predict the reliability of the given software. U is the expected number of failures by a given time t. Failure intensity Total failures Reliability has two parameters.

4. The important metrics used during testing is —————————— . White-box method focuses on the program control structure where as black-box method focuses on finding errors in functional requirements. metrics related to software testing have been discussed in this unit. design and coding. 3. 6. the test plan specification. A thoroughly tested software maintains quality. Equivalence class of objects are present if the set of objects have relationships like ——— —————. we also have the different strategies for software testing. 5. white-box and black-box testing. ——————————— is a software measure. We shall look into quality and its related concepts in the subsequent units. The main objective for test case design is to derive a set of tests that can find out errors in the software. 2. that provides a quantitative measure of logical complexity of a program.Software Testing Software testing is an important phase in the software development life cycle. Others concepts like. Apart from knowing the test case design approaches. the art of debugging. A quality product is what every one wants and appreciates.8 SUMMARY Chapter 5 . The two categories of Integrated testing are incremental and —————————— A —————— outlines the classes of tests to be conducted. It represents the ultimate review of specification. 5.9 SELF CHECK EXERCISE I Fill in the blanks : 1. This can be achieved through the help of two test case design approaches namely.94 5. ———————— is mainly used for testing real-time and embedded systems. reflexive and symmetric. 7. ———————————— is also known as functional testing.

BSIT 44 Software Engineering 95 IIa) Answer the following questions in one or two sentences : 1. Addison-Wesley publications. What is software testing ? II b) Answer the following question in detail 1. Pankaj Jalote. Explain white box testing. An Integrated approach to Software Engineering (second edition). explain its types 12. Give explain 4. test plan 6. Explain the steps involved unit testing 9. Explain the strategic approached to software testing 7. non-incremental 5. What is testing process? explain 14. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. What is validation testing? explain 11. Explain the factors contained in test plan 15. 2000. Explain the material for software testing I Answers for fill in the blanks 1. transitive 4. What is debugging? explain its approaches 13.10 REFERENCES 1. Software testing in the real world. Define system testing. Black-Box Testing 2.1 . 3. Write short note on BVA 8. Roger S. What is integration testing? explain the categories of integration 10. Narosa publishing house Edward Kit. 2. Explain the testing objectively & testing principal 2. What are the techniques of software testing? explain 3. performance testing 7. Explain black box testing 6. reliability 5. cyclomatic complexity 3. What is cycloramic complexity? explain with Flowchart 5. ed.

risk analysis. In this chapter.1 OBJECTIVES At the end of this chapter you should be able to     know the importance of managing people. process and project describe the different types of team structuring say what project planning is discuss planning with respect to resources 96 Chapter 6 . So. how much effort. proper management controls are very essential in controlling the developments ensuring quality. in the context of set of resources. 6. In the subsequent units.0 INTRODUCTION S oftware development is an umbrella activity with various phases involving several resources. how many resources. we shall discuss on software configuration management. The most important resources being the man power and money. Software Quality Assurance and Software Configuration Management. attempt to determine how much money. scheduling.Software Project Management . The software development is a lengthy process which may take months or even years for completion. Project management includes activities such as project planning. quality assurance. planning involves estimation . staffing and risk management. In order for the project to successfully get completed. we shall see the major activities addressed by project management such as cost estimation.Chapter 6 Software Project Management 6. However. and how much time it will take to build a specific softwarebased system or product. the large workforce has to be properly organized so that they contribute very efficiently and effectively towards the project. project scheduling.

the people must be organized into effective teams. and coordinated to achieve effective communication. an appropriate software engineering paradigm is applied. The software team Since a variety of people belonging to different categories are involved in the software development process. partitioned into several parts. A common process framework is selected. 3. The software process or project is usually populated with several people. how it is managed say. For an efficient and easier management. motivated to do high-quality work. and coordinated to achieve effective communication. The people must be organized into effective teams.2 MANAGING PEOPLE. Project managers. End users. organize. 5. People The people are the backbone for software development. Practitioners. who define the business issues that often have more influence on the project. it is very important to manage them. who deliver the technical skills that are necessary to engineer a product. who specify the requirements for the software to be developed. motivate. So. who interact with the software once it is released for production. and allocated for work by software team. The process must be adapted to the people and the problem. and control the practitioners who do software work. what is risk . The problem must be communicated from the customer to the developer. who plan. 4. 2. the structure of the team has a direct impact on the product quality and project productivity.BSIT 44 Software Engineering       97 appreciate the importance of software project estimation discuss various estimation models differentiate different kinds of COCOMO estimation models use COCOMO as an estimation model say. Senior managers. who can be categorized as follows: 1. what is the necessity of project scheduling and tracking 6. problem and process. . motivated to do high-quality work. and a set of work tasks is chosen to get the job done. PROJECT AND PROCESS Effective software project management focuses on the three P’s : people. Customers.

program librarian. and programmers the backup programmer helps the chief in making decisions and takes over the role of chief in absence of the chief programmer . He also does most of the design activities and allocates coding part to each and every member of the team under him.Software Project Management Democratic decentralized It consists of ten or few number of programmers the goals of the group are set by consensus every member is considered for taking major decisions group leadership rotates among group members the structure results in many communication paths between people as shown in figure 6.98 Chapter 6 .1 Democratic team structure Controlled centralized it consists of a chief programmer. who is responsible for all the major technical decisions of the project. he has a backup programmer.1 Figure 6.

A proper understanding of the problem helps to prepare quantitative estimates and thus avoids several issues .2 Chief programmer Backup programmer Librarian Programmers Figure 6.2 Controlled centralized team structure Controlled decentralized team it combines the strengths of the democratic and chief programmer teams it consists of a project leader who has a group of senior programmers under him and a group of junior programmers under a senior programmer the communication between the senior and junior programmers are like ego-less team and the communication between different groups is through the senior programmers and they in turn communicate with project leaders this structure is best suited for very simple projects or research-type works - Project The problem or project under consideration need to be well thought of at the beginning. The structure is shown in figure 6.BSIT 44 Software Engineering 99 - the program librarian is responsible for maintaining the documents and other communication related work this team structure exhibits considerably less inter-personnel relationship.

which can be easily managed. a complete plan showing the work tasks required for process framework activities is discussed in project scheduling activity. . then the problem is decomposed into a set of smaller problems. determining the scope of the problem must be established since.3 SOFTWARE PROJECT PLANNING The software management consist of activities like project planning. Lack of proper planning leads to schedule slippage. The basic goal of software planning is to look into the future. Among these activities. Process Deciding about a process model is very important for a project manager. Software project planning includes activities such determining the scope of the software and estimation of resources to accomplish the software development effort. and then allocated for work by software team. then define a preliminary plan based on the set of common process framework activities. project monitoring and control. That is.100 Chapter 6 . and plan the schedule and resources. The decomposition approach can be seen from two view points:   decomposition of the problem decomposition of the process Software estimation is a form of problem solving. So.e. identify the activities that need to be done to complete the project successfully.Software Project Management related to it. Estimation makes use of one or both of the above approaches of decomposition. The software scope must be unambiguous and understandable at the management and the technical levels. 6. process decomposition begins. in terms of developing cost and effort estimation). poor quality and high maintenance costs for software. and project termination. He must decide the most appropriate model for the project. Once the preliminary plan is ready. cost over-runs. If the problem to be solved is quite complex to be considered in one piece ( i. it has to be performed before the development work and all other management phases depends on this very much. since there are a number of process models. it marks the beginning activity of the software project management. It must address the following context information objectives function and performance In order to make the problem easily manageable. the problem must be communicated from the customer to the developer and partitioned or decomposed into several parts. project planning is very important since.

People Reusable software components Hardware / Software tools Figure 6. . constraints. The software scope describes function. The most commonly used communication technique between the customer and the developer to derive at the scope of the problem. The functions and performance allocated to software during system engineering is assessed to establish the project scope. So. reusable software components and people are shown in figure 6. Software and People The second task of software planning is estimation of resources required to accomplish the software development effort. But. applying an appropriate software cost estimation technique is very essential. And one such software function is to prepare the software estimates using one or more techniques such as decomposition and empirical modeling.3 Resources 6. and reliability. a large cost estimation error can make a lot of difference. leading to cost overrun for the developer. So. 6. The main resources are the hardware and software tools. It constitutes the software building blocks that can reduce the development costs and speed up the delivery. the foundation or base of the pyramid which provides the necessary infrastructure to support the development effort. interfaces. any small discrepancy in estimation of software cost had relatively little impact.3.BSIT 44 Software Engineering 101 6. the cost of the software was just a small fraction of the overall cost of a computer-based system. The project planner then examines the statement of the scope and extracts all the important software functions. is to conduct a preliminary meeting or interview. And. The scope of the project must be very clear and understandable. The hardware/software tools make up the development environment. today software is the most expensive one in a computer-based system.4 SOFTWARE PROJECT ESTIMATION In early days of computing.3. performance. The top most part of the pyramid is the main resource. The middle layer in the pyramid is the reusable software components layer.1 Software Scope This is the first activity in software project planning. the people.2 Resources – Hardware.3.

The LOC and FP data are used in two ways during software project estimation: 1.102 Chapter 6 . process based estimation begins with a delineation of software functions obtained from the project scope. cost estimation models have matured considerably and generally give fairly accurate estimates. As the cost of the project depends on the nature and characteristics of the project.4. 6. Despite the limitations. There is a great deal of uncertainty about the actual specifications of the system. As we specify the system more fully and accurately. Most cost estimates are determined in terms of person-months (PM). B. A typical estimation model which is derived on the data collected from the past projects. and most cost estimation procedures focus on this aspect. the uncertainties are reduced and more accurate cost estimates can be made. the accuracy of the estimate will depend on the amount of reliable information we have about the final product. can be written as E = A + B * (ev)C Where. as an estimation variable that is used to estimate the size of the software as baseline metrics collected from past projects and used along with the estimation variables to develop cost and effort projections An another most common method for estimating a project is the process-based technique.Software Project Management Cost in a project is due to the requirements for software. hardware and human resources. A.1 Estimation Models The line of code ( LOC ) and function points ( FP ) are the two problem-based techniques. at any point. When the project is being initiated or during the feasibility study. Here. the basic measures from which productivity metrics can be computed. 2.4. the major functionality of the system. and C are empirically derived constants. 6. The bulk of the cost of software development is due to the human resources needed. the process is decomposed into a relatively small number of tasks and the effort required to accomplish each task is estimated. we have only some idea of the data the system will get and produce.2 Empirical Estimation Models An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC or FP. Like the problem based techniques. E is the effort in persons-months and ev is the estimation variable ( either in LOC or FP ) .

Equation 1 gives a measure of the effort and equation 2 gives the development time. The product is relatively small. personnel. Ab . and project attributes. E = number of person-month (=152 working hours). stable environment. hardware. one of the most important factors contributing to a project’s duration and cost is the Development Mode. In the COCOMO model. Model 1 : The Basic COCOMO model computes software development effort (and cost ) as a function of program size expressed in estimated lines of code. The COCOMO model predicts the effort and duration of a project based on inputs relating to the size of the resulting systems and a number of “cost drives” that affect productivity. Embedded Mode: The project is characterized by tight. but its accuracy is necessarily limited because of its lack of factors which have a significant influence on software costs. and requires little innovation. Every project is considered to be developed in one of three modes: Organic Mode: The project is developed in a familiar. Model 3 : The Advanced COCOMO model incorporates all the characteristics of the intermediate COCOMO with an assessment of the cost driver’s impact on each step of the software engineering process. inflexible constraints and interface requirements.BSIT 44 Software Engineering 103 6.1 The Cocomo Model The COnstructive COst MOdel (COCOMO) is the most widely used software estimation model in the world. the number of delivered lines of code for the project ( expressed in thousands ). E = Ab * (KLOC)Bb (person-months) ——— Equation 1 Where. The Basic COCOMO Model Basic COCOMO model estimates the software development effort using only a single predictor variable (size in DSI) and three software development modes. and the Detailed model. The basic equations for the COCOMO model is about the effort estimate in Person-Months required to develop a project and the KLOC or KDSI. It was developed by Barry Boehm.2. the Intermediate model.4. . Bb = constants. Model 2 : The Intermediate COCOMO model computes software development effort as a function of program size and a set of “cost drivers” that include subjective assessments of product. rough order of magnitude estimates of software costs. An embedded mode project will require a great deal of innovation. Basic COCOMO is good for quick. COCOMO is defined in terms of three different models: the Basic model. and the product is similar to previously developed products. early. Semidetached Mode: The project’s characteristics are intermediate between Organic and Embedded.

Bb.6 * (KDSI)1.20 TDEV = 2.4 * (KDSI)1. D = Cb * (E) Db ———————————————— Equation 2 Where.5 * (Effort)0.5 0.5 * (Effort)0. and the exponents Cb and Db are given in Table 1 below : Software project Ab Bb Cb Db Organic 2.12 2.35 TDEV = 2. Cb .0 * (KDSI)1.5 0.104 Chapter 6 .4 1.20 2.05 Effort = 3. Db = constants The values of the coefficients Ab.Software Project Management KLOC = thousands of lines of code or thousands of “delivered source instructions “ (DSI) or KDSI.32 Semidetached: Embedded: .0 1. D = development time in chronological months E = number of person-month (=152 working hours).5 0.6 1.35 Embedded 3.05 2.12 Effort = 3.38 Semidetached 3.38 TDEV = 2.5 * (Effort) 0.32 Table 2 : Effort Equations for three development Modes in Basic COCOMO Model Development Mode Organic: Basic Effort equation Basic Schedule Equation Effort = 2.

COCOMO can estimate the staffing. DSI values and Cost Drivers can be chosen for individual components. The intermediate COCOMO equation takes the form : E = Ai(LOC) Bi * EAF Where.05 1. or apply it at the software product component level for more accurate cost estimation in more detailed stages. The Intermediate model produces better results because you supply settings for 15 Cost Drivers that determine the effort and duration of software projects.20 . particularly in detailed cost estimates for large software projects:   Its estimated distribution of effort by phase may be inaccurate. instead of for the system as a whole.8 Bi 1. Table 3 : Software Project Organic Semidetached Embedded Ai 3. E is the effort applied in persons-months LOC is the estimated number of delivered lines of code for the project.12 1.0 2. The Effort adjustment Factor is simply the product of the Effort Multipliers corresponding to each of the cost drivers for your project.2 3.BSIT 44 Software Engineering 105 The Intermediate COCOMO Model The Intermediate model use an Effort Adjustment Factor (EAF) and slightly different coefficients for the effort equations than the Basic model. which may become significant. One can apply Intermediate COCOMO across the entire software product for easily and roughly cost estimation during the early stage. and “Use of Software Tools”. The Cost Drivers include factors such as Product Complexity. The Intermediate model also produces better results than the Basic model because the system can be divided into “components”. Bi are the coefficients whose values are given in table 3. Programmer Capability. There are two primary limitations. Ai. It can be very cumbersome to use on a product with many components. and duration of each of the components — allowing you to experiment with different development strategies. to find the plan that best suits your needs and resources. cost.

35 TDEV = 2. Product Attributes RELY — Required Software Reliability.2 * (KDSI)1. personnel attributes. The level of complexity of the product to be developed. and project attributes.5 * (Effort)0.5 * (Effort) 0. The extent to which the software product must perform its intended functions satisfactorily over a period of time.0 * (KDSI)1.8 * (KDSI)1.38 TDEV = 2. computer attributes.20 Basic Schedule equation TDEV = 2.106 Chapter 6 . The degree of the total amount of data to be assembled for the data base. These cost drivers are grouped into four categories: software product attributes. and to compress a number of factors which tend to be highly correlated on projects into a single factor.32 There are many candidate factors to consider in developing a better model for estimating the cost of a software project.Software Project Management Table 4. COCOMO model uses 15 cost drivers based on these principles. CPLX — Software Product Complexity. There are two principles to reduce the large number of candidate factors to a relatively manageable number of factors for practical cost estimation: · · General Significance: this tends to eliminate factors which are significant only in a relatively small fraction of specialized situations. Effort Equations for Three Development Modes in Intermediate COCOMO Model Development mode Organic: Semidetached: Embedded: Basic Effort equation Effort = EAF * 3. Independence: this tends to eliminate factors which are strongly correlated with product size.12 Effort = EAF * 2. .5 * (Effort) 0. DATA — Data Base Size.05 Effort = EAF * 3.

. PCAP — Programmer Capability The level of capability of the programmers working on the software product VEXP — Virtual Machine Experience The level of virtual machine experience of the project team developing the product. AEXP — Applications Experience The level of applications experience of the project team developing the software product. STOR — Main Storage Constraint The degree of main storage constraint imposed upon a software product.BSIT 44 Software Engineering 107 Computer Attributes TIME — Execution Time Constraint The degree of the execution constraint imposed upon a software product. TURN — Computer Turnaround Time The level of computer response time experienced by the project team developing the product. VIRT — Virtual Machine Volatility The level of the virtual machine underlying the product to be developed. LEXP — Programming Language Experience The level of programming language Project Attributes MODP — Use of Modern Programming Practices The degree to which modern programming practices ( MPPs ) are used in developing software product. Personnel Attributes ACAP — Analyst Capability The level of capability of the analysts working on a software product.

and whereas of the estimating activity. The second level. the plan includes an notes on the why. what. who. Re-examine estimating objectives as the process proceeds. how much. where. how. when.  Seven Basic Steps in Software Cost Estimation This section provides a seven-step process for software cost estimation. Step 1: Establish Objectives  Key the estimating objectives to the needs for decision making information. and followed up accordingly. reviewed.   Balance the estimating accuracy objectives for the various system components of the cost estimates. The Detailed model apply a three level hierarchical decomposition of the software product whose cost is to be estimated.108 Chapter 6 . is used to apply major overall project relations such as nominal effort and schedule equations. this activity need to be planned. the subsystem level. The top level. The Detailed COCOMO Model The Detailed model differs from the Intermediate model in two aspects:  The Detailed model uses different Effort Multipliers for each cost driver attribute. These phase sensitive Effort Multipliers are used to determine the amount of effort required to complete each phase. but which tend to be the same for all the modules within a subsystem. and modify them where appropriate. the system level. SCED — Schedule Constraint The level of schedule constraint imposed upon the project team developing the software product. and to apply the nominal project effort and schedule breakdowns by phase. Step 3: Pin Down Software Requirements · It is important to have a set of software specifications that are as unambiguous as possible .Software Project Management TOOL — Use of Software Tools The degree to which software tools are used in developing the software product. Step 2: Plan for Required Data and Resources · prepare a project plan at an early stage. the module level. is described by the remainder of the cost drivers which tend to vary from subsystem to subsystem. The lowest level. is described by the number of DSI in the module and by those cost drivers which tend to vary at the lowest level.

Primarily risk and risk management can be assessed by considering the following definitions: . that one can define a clear pass/ fail test for determining whether or not the developed software will satisfy the specification Step 4: Work Out as Much Detail as Feasible  carry out the estimating activities in detail so that the estimates will be very accurate.  It is important to use a combination of techniques.  An iteration of the estimates after finding why they give different estimates may converge to a more realistic estimate.5 RISK MANAGEMENT When considering risk management and the concept of risk in the development of software it may be useful first of all to examine what software management is. the less likely we are to miss the costs of some of the more unobtrusive components of the software. c) the more we think through all the functions the software must perform. the more we get the law of large numbers working for us to reduce the variance of the estimate. Step 7: Follow-up  Once a software project is started. it is essential to gather data on its actual costs and progress and compare these to the estimates 6.BSIT 44 Software Engineering  109 A specification need to be testable to the extent possible. for three main reasons: a) the more detail we explore. Step 6: Compare and Iterate Estimates  The most valuable aspect of using several independent cost-estimation techniques is the opportunity to investigate why they give different estimates. their strengths and weaknesses are complementary. Step 5: Use Several Independent Techniques and Sources  None of the alternative techniques for software cost estimation is better than the others from all aspects. in order to avoid the weakness of any single method and to capitalize on their joint strengths. b) the more pieces of software we estimate. the better we understand the technical aspects of the software to be developed.

110 Chapter 6 .” Risk Management. environment etc. There are two distinct types of risks for each categories said earlier.Software Project Management Risk. Software Risks.” “Incompatibility of the system with the selected hardware and software. threaten the project plan Technical risks.” [IEEE 89] There are different categories of risks that can be considered. “Software risk management is an emerging discipline whose objectives are to identify address and eliminate software risk items before rework. the project manager takes a step towards avoiding it and there by controlling it. it is: Known risks. of the anticipated benefits.” “Technical performance of resulting systems turns out to be significantly below estimate.1 Risk Identification Risk identification is a systematic attempt to specify the threats to the project plan. are obtained from the past project experience Unpredictable risks. product -specific risks they can be identified by those who have a clear understanding of the in and out of the project like technology. as per the Quotations [Boehm 93] “Failure to obtain all or even any.” A definition from Oxford Dictionary.” “Time for implementation that is much greater than expected. injury or other adverse consequences.5. in the first category.” “Costs of implementation vastly exceed planned levels. . loss. By identifying known and predictable risks. “A chance or possibility of danger. they cannot be known in advance and are difficult to find 6. threaten the quality and timeliness of the software to be built Business risks. threaten the viability of the software to be built In the next category. it is:       Project risks. can be uncovered from careful evaluation of the project plan Predictable risks. people. They are generic risks they are a potential threat to every software project.

4.BSIT 44 Software Engineering 111 Both generic and product-specific risks need to be identified systematically. establish a scale that reflects the perceived likelihood of a risk delineate the consequences of the risks estimate the impact of the risk on the project and the product note the overall accuracy of the risk projection so that there will be no misunderstandings. It attempts to rate each risk in two ways – the likelihood or probability that the risk is real and the consequences of the problems associated with the risk. category of risks. Risks Category PS PS PS BU Probability 60% 30% 70% 40% Impact RMMM 2 3 2 3 Size estimate may be significantly low Larger number of users than planned Less reuse than planned End users resist system . is also called as risk estimation. for which a risk item checklist can be used. The sample risk table is given below. if it occurs. The risk item check list is given below:        Product size Business impact Customer characteristics Poor definition Development environment Technology to be built Staff size and experience 6. It has information like list of risks.2 Risk Projection Risk protection. This table provides a simple technique for risk projection. There are four risk estimation activities: 1. Developing a risk table is an important activity of the project planner. 2. probability of its occurrence and its impact. 3.5.

poor working conditions.3 Risk Mitigation. 3 is marginal and 4 is negligible. 6.Software Project Management 50% 40% 80% 30% 2 1 3 2 Where. In order to mitigate the risk. Monitoring and Management In order to assist the project team in developing a strategy for dealing with risks.5. an effective strategy must be considered. The project manager monitors the facts that .) Act to mitigate those causes that are under management control before the project starts Once project starts.g. Some steps in this direction are:       Meeting with staff members to determine the causes for turn over. 2 is critical. risk monitoring activities begins. the second column shows the category of risk encountered such as. and Risk management and contingency planning If a software team adopts a proactive approach to risks. assume turn over will occur and develop techniques to ensure continuity when people leave Organize project teams so that information about each development activity is widely spread Define documentation standards and establish mechanisms to be sure that documents are developed in timely manner Define a backup staff member for every critical technologist As the project proceeds. Monitoring and Management plan that is developed for all risks. BU is business risk etc. The following three issues help in developing a strategy for dealing with risks:    Risk avoidance Risk monitoring. avoidance is the best method. The value of impact implies that 1 is catastrophic. The column RMMM contains a pointer to Risk Mitigation. project management must develop a strategy for reducing the turn over.112 Delivery deadline will be tightened Funding will be lost Lack of training tools Staff inexperienced BU CU DE ST Chapter 6 . PS is project size risk. low pay etc. This is achieved by developing a plan for risk mitigation. (e.

This section will consider some of the most commonly documented problems. DeMarco 97]. Insufficient staffing or appropriate decisions from senior management may mean that the systematic approach to risk assessment is not in place.5. The project manager may be diverted by this activity from managing risk assessment activity.BSIT 44 Software Engineering 113 may provide an indication of whether the risk is becoming more or less likely. In contrast an example of a fatal risk may be that the date set for the release of the software was a hopeless and drastic underestimation. In this example a software project manager may be seen to avoid risks and display a confident can-do attitude. Risk aversion It is very easy to acknowledge the fact that there are large risks present when undertaking software development projects. In addition to monitoring the risk factors.4 The Problems of Putting Risk Management into Practice This part of the report aims to identify the shortcomings that still appear to remain within the discipline of risk management. . The risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. If there are so many good models on risk management then why is there still such a high failure rate of software projects. 6. Design flaws may occur in the project and be missed. Let us discuss a problem of risk aversion by considering the following example based on a recent risk management paper [Boehm. risk management may imply that the failure of the software project is almost a certainty. For example if two more personnel are needed to complete final testing of a software project so it may meet its deadline. It can therefore be tempting for software development managers to completely ignore risk management approaches. A crisis may occur within a project or be precipitated by a customer. Poor Infrastructure The second largest problem when it comes to assessing software risk management is the lack of a good infrastructure in the organization that would allow support to be given to effective risk management. Another problem is that staffing resources from elsewhere may be diverted to deal with a crisis in a project and therefore cause problems when risks are reassessed. the project manager should also monitor the effectiveness of risk mitigation steps. The attitude of can-do project manager for the small risk situation is obviously flawed if ignored but in the case of the large risk would be considered less incompetent. If problems had been identified and risks managed from the start of the project then it is likely that many would have been avoided as they were anticipated. This is considered a small risk and is easily solvable by adding the required staff.

An outline of it is shown below: I Introduction 1. by whom and whether deadline can be met and what action may be required. Factors influencing. It can almost be seen as a feature of a poor infrastructure but is so important is worth mention as an issue itself. and Management Plan. The SEI have developed systematic approaches and so provide a good example as what a systematic approach should entail. Mitigation i. Specific steps to mitigate the risk .Software Project Management Lack systematic risks analysis The lack of a systematic approach to risk management is widely noted as a reason for the reason for problems with it. Overview of major risks Responsibilities a. Approaches used by the SEI (Software Engineering institute) highlighted this as a major problem. General strategy ii. monitoring. probability and impact III Risk mitigation. The probability and impact of risks are recorded using a high medium and low rating against each risk. Breaking down risks in a systematic way and highlighting those that are important is a very difficult and assessing which risks are important. Technical staff II Project risk Table 1. Risk #n a.5. Management b. Scope and purpose of document 2.114 Chapter 6 . It is therefore possible for managers to highlight parts of a risk management plan. 6. 3. management n. look at risks taken. Description of all risks above cut-off 2. monitoring.5 The RMMM Plan A risk management strategy can be included in the software project plan or the risk management steps can be organized into a separate Risk Mitigation.

3. to ensure that goals are being approached and eventually being achieved. tracking and control activity begins. delivery commitments can be modified to accommodate the problem that has been uncovered.BSIT 44 Software Engineering 115 b. Project control is necessary in-order to monitor the progress of activities against plans. 6. a graphical representation of the task flow for a project identification of a time-line schedule Scheduling focuses on the project control activity which are based on project work breakdown structure. Each task noted in the schedule is tracked by the project manager. Once the development schedule has been established.6. Monitoring i. Factors to be monitored ii. So. tasks can be reordered. 6.6 PROJECT SCHEDULING AND TRACKING Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. 5. 4.1 Scheduling Software project scheduling is an activity that involves: 1. Like this. . Special considerations c. the manager can use an automated project scheduling tool to determine the impact of schedule slippage on intermediate project milestones and the overall delivery date. the software development can be controlled. IV V RMMMM Plan iteration Schedule Summary 6. identification of a set of tasks establishing the interdependencies among the tasks identification of resources including people estimation of effort associated with each task creation of a “task network”. It involves quality assurance & control and change management & control. Contingency plan ii. If a task falls behind schedule. 2. resources can be redirected. Monitoring approach Management i.

This process is repeated until. Simple and easy to understand used for small and medium sized projects they show the tasks and their duration clearly they do not show inter task dependencies .1 shows the work break down structure for compiler construction Most of the project control techniques are based on breaking the goal of the project into several intermediate goals. they are :   Gantt charts PERT charts Gantt charts  A Gantt chart is a project control technique that can be used for several purposes like scheduling. drawn against time-line.Software Project Management Compiler project Design Code Integrate & test Write manual Scanner Parser Code generator Figure 6. And each intermediate goal is decomposed further into further goals.        It is a bar chart.116 Work break down structure (WBS) Chapter 6 . Help in scheduling of project activities but not identifying them. budgeting and resource planning. There are two general scheduling techniques followed. each goal is small enough to be well understood. Each bar represents an activity. The length of each bar is proportional to the length of the time planned for the activity.

BSIT 44 Software Engineering 117 PERT Chart  It is Program Evaluation and Review Technique. the white part of the bar (with no slack) indicates the time duration by which each task is estimated to take. The gray part (slack) shows the latest time by which the task must be finishe Jan’94 Apr’94 July’94 Oct’94 Jan’95 A pr’95 Start Design Build scanner Build Parser Build code generation Integration & finish Figure showing Example 1: Gantt chart for a simple compiler project .  Each box represents an activity  Arrows indicate the dependencies of activities on one another  The activity at the head of the arrow cannot start until activity at the tail of the arrow is finished.  It is a network of boxes (or circles) and arrows.  Some boxes can be designated as mile stones  PERT can have starting and ending dates  PERT is suitable for larger projects  Not as simple as Gantt charts Example 1: Gantt chart for a simple compiler project Here.

It provides baselines cost and scheduling information. build code generation.118 Chapter 6 . the design. Scope and purpose of the document B.2 The Project Plan Each step in the software engineering process should produce a work product that can be reviewed and that can serve as a base for further process. Mar 7’ 94 Build Scanner Mar 7’ 94 Jan 1’94 Start Jan 3’ 94 Design Build Parser Nov 14’ 94 Integration & testing Mar 7’ 94 Build code generation Finish Mar 7’ 94 Write manual Mar 13’ 95 Figure showing Example 1: PERT chart for a simple compiler project 6. Project objectives . It is given below: I Introduction A. the project manager must clearly and closely watch the critical path. integration & test path represent a critical path for the project. which can be used through out the software engineering process.6. That is any delay in any activity in this path will cause a delay in the entire project. so.Software Project Management Example 1 using PERT chart Here in the example. The software project plan is produced as an outcome of planning phase.

Team structure B. C. C.BSIT 44 Software Engineering 119 II Project Estimates A. Project work break down structure B. Historical data used for estimates B. duration III Project Risks A. Quality assurance and control B. People Special resources VI Staff Organization A. cost. D. Estimation techniques Estimation of effort. Risk management IV Schedule A. Management reporting VII Tracking and Control A. Risk analysis B. C. Hardware and software B. Task network Time-line-chart Resource chart V Project Resources A. Change management and control VIII Appendices .

——————————is a project control technique that can be used for several purposes like scheduling. estimating project costs.8 SELF CHECK EXERCISE I Fill in the blanks : 1. Estimation makes use of an important approach ——————————. Define the terms: risk mitigation. tracking. process and problem. Its very important to manage them.7 SUMMARY Chapter 6 . 6. risk monitoring Is scheduling same as project tracking ? How do you classify risks ? . 5. It has three P’s which influence on it.Software Project Management Software management is an umbrella activity within software engineering. 7. 10. Why should a software project be planned before development ? What is en estimation model ? Name the different techniques which are based on COCOMO What are cost drivers ? Name the methods that are commonly used for representing scheduling techniques. 3. Name the different kinds of software development team structure. COCOMO stands for ——————————— The equation for the Basic COCOMO model to estimate effort is ——————— PERT stands for ——————————— ———————risks threaten the quality and timeliness of the software to be built II a) Answer the following questions in one or two sentences : 1. Namely. 5. and control. people need to be teamed properly. 2. in order to increase the efficiency of work. 3. 6. So. schedules. People are very important for developing and maintaining software projects. 6. 4. Give the IEEE definition of risk management. 9. The project management activity encompasses activities like risk management. 2.120 6. budgeting and resource planning. people. 4. 8.

define cocomomodel.BSIT 44 Software Engineering 121 II b) Answer the following question in detail 1. Software engineering. 3. 3. 4. 9. 6. 5.9 REFERENCES 1. decomposition Gantt chart COnstructive COst MOdel E = Ab * (KLOC)Bb (person-months) Program Evaluation and Review Technique technical risks 6. 5. 11. 2. 8. Addison-Wesley publications. 2.5 . ed. Pankaj Jalote. 7. 6. Explain different kinds of software development team structure Explain the activities of software project planning Briefly explain a) Estimation model b) Empirical estimation model 4. 2. explain its three different model What is cost diver? explain the four dategories of cost drivers Explain seven basic steps in software cost estimation What is risk management? explain Explain the most commonly documented problems of putting risk management into practice Give the outline of Rmmm plan What are the activities of software projects scheduling? explain Write a note on Gantt charts & part charts Explain the steps for the project plan I Answers for the fill in the blanks 1. 12. An Integrated approach to Software Engineering (second edition). Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. Roger S. 10. 1996. Narosa publishing house Ian Sommerville. 3.

we focus on concepts related to quality. (FTR) applied thought the software process.1 OBJECTIVES At the end of this chapter you should be able to      Define terms like quality. activities that need to be carried out for producing high quality software products. An important goal of software engineering is to produce a high quality software. 7. Software Quality Assurance ( SQA ) is an “umbrella activity” that is applied at each step in the software development process. control of software documentation and changes made to it. a procedure to assure compliance with software development standard and measurement and reporting mechanisms. and the international standards that need to be followed for software engineering.Chapter 7 Software Quality Assurance 7. In this chapter. a multi tired testing strategy. effective software engineering techniques. SQA Encompasses the activities like : a quality management approach. quality control.Software Quality Assurance . quality assurance Discuss the impact of cost on quality State the important quality assurance activities Answer the question “ What is cost impact of software defects ?” Understand the defect amplification model 122 Chapter 7 . And this goal is achieved through what is known as software quality assurance. Formal Technical Reviews.0 INTRODUCTION O ne of the important factors driving any production discipline is quality.

quality of design includes requirements. lines of code etc. two kinds of quality may generally be encountered: quality of design and quality of conformance.2 QUALITY CONCEPTS Quality Quality refers to a measurable characteristic or attribute of an item . specifications. and design of the system. cohesion. so that each work product meets the requirements placed upon it. Quality of conformance is an issue which mainly depends on implementation. in software development. reporting functions of management. That is.such as color. Cost of Quality It includes all costs incurred towards achieving quality. Quality Assurance (QA) It is an activity that consists of auditing. and tests which is carried out during the entire life cycle of a software. it includes the cost of perceiving the quality and its related activities. However. Quality control (QC) It is an activity for controlling the quality of an item. While considering these characteristics. Quality costs may be divided into costs associated with prevention. length etc. appraisal. QC can be carried out automatically or manually or in a combined form. performance specifications . Quality of conformance is the degree to which the design specifications are followed during manufacturing. and the measurable characteristics with reference to a program include cyclomatic complexity. It gives the necessary information to the management regarding the quality of product. and failure. Prevention cost include : quality planning .BSIT 44 Software Engineering    123 Know the importance of Formal Technical Reviews Write the SQA plan Discuss the importance of quality standards 7. It consists of a series of activities like inspections. reviews. Quality of design refers to the characteristics that the designers specify for an item such as the grade of the materials.

well planned software testing etc.124 formal technical reviews test equipment training Chapter 7 .Software Quality Assurance appraisal cost include : in-process and inter process inspection equipment calibration and maintenance testing failure cost include : rework repair help-line support warranty work 7. SQA group also performs other activities like: prepare SQA plan for a projects participate in the development of project’s software process description reviews software engineering activities to verify compliance with the defined software process audits designated software work products to verify compliance with those defined as part of software process ensures the deviations in software work and work products are documented and handled according to a documented procedure . conducting formal technical reviews. Apart from helping the software engineering group.3 SOFTWARE QUALITY ASSURANCE ACTIVITIES The SQA is an important activity usually performed by two groups : software engineer group and software quality assurance group. The software engineering group perform quality assurance by applying technical methods and measures. The software quality assurance group assist the software engineering group in achieving a high quality end product.

errors passed from previous steps are amplified by the current work. 2. Types of reviews 1. Confirm those areas of the product where improvements are not needed. which depicts a measure of review. A box represents a software development step. Point out the needed improvements in the product. It also coordinates the control and management of change and helps to collect and analyze software metrics. 2.also called as Formal Technical Review (FTR) . Formal review . 3.This is an effective means of improving software quality Software defects Defect is a product anomaly. During the step. In some cases. It is a quality problem that is discovered after the software has been released to end users. . Software reviews are needed to 1. Review may fail to find newly generated errors and errors from the previous steps.1. In the figure 7.This is the most effective filter for software engineering processes . 7. resulting in some number of errors that are passed through. detail design and coding steps of software engineering process.4 SOFTWARE REVIEWS Reviews are conducted at various points during software development to find out the errors that can then be removed. errors may be inadvertently generated. So software reviews are a “filter” to software engineering processes. Defect amplification and removal A defect amplification model is used for generation and detection of errors during preliminary design.BSIT 44 Software Engineering 125 - records any non-compliance and reports to senior management. Informal review – Informal reviews could be unscheduled and ad-hoc wherein issues could be discussed and clarifications obtained. the box sub division represent these characteristics and the percent efficiency for detecting errors. These could also be called coffee shop reviews. Make the technical work more manageable.

5 FORMAL TECHNICAL REVIEW This is a software quality assurance activity that is performed by software engineers. To make projects more manageable.126 Development step Defects Errors from previous step Errors passed through Chapter 7 . logic or implementation found in software. 6. round-robin reviews. 2. Objectives 1. . 5. Each FTR is conducted as a review meeting. Serves to promote backup and continuity. design.Software Quality Assurance Detection Amplified errors 1 : x Percent efficiency for error detection Errors passed to next step Figure Newly generated errors 7. 4. 7. FTR includes walkthroughs. implementation. To verify that the software under review meets its requirements. 8. To detect the errors in functions. inspections.1 Defect amplification model 7. 3. To achieve software with consistent quality and on time. To ensure that the software has been represented according to predefined standards. It acts as a training ground for junior engineers to observe different approaches to software analysis.

Other documents Standards. III. design reviews c.2 gives an outline for SQA plans as recommended by the IEEE. Test VIII. Review requirements a. Required software engineering documents 3. The figure 7. Purpose 2. physical audit f. V. software requirements review b. Tasks 3. Responsibilities Documentation 1. management reviews IV. VII. Purpose 2. II. Purpose 2.6 THE SQA PLAN The SQA plan provides a road map and a layout for the software quality assurance activity. Problem reporting and corrective actions IX. X.BSIT 44 Software Engineering 127 7. VI. I. Conventions Reviews and audits 1. software verification and validation reviews d. Tools. functional audit e. Purpose of plan References Management 1. practices and conventions 1. techniques and methodologies Code control . in-process audits g. Organization 2.

The standard contains 20 requirements that must be present for effective quality assurance system. A system called Quality assurance system may be used for this purpose. 3. these processes must address the areas identified in the standard and must be documented and practiced as prescribed. Documenting a process helps an organization to understand. The elements include the organizational structure. processes. Management responsibility Quality system Contract review Design control .Software Quality Assurance XII. Supplier control XIII. quality assurance and quality improvement. and resources needed to implement quality planning. For a quality system to be ISO-complaint. The ISO 9000 describes the elements of a quality assurance system in general.1 The ISO Approach The International standards organization (ISO) quality assurance models treat an enterprise as a network of interconnected processes. and retention XIV. 7. 2. procedures. Training XV. Records collection. Risk management 7.7 QUALITY STANDARDS Certain standards are to be followed for establishing quality in an organization. processes. quality control. This system is defined as the organizational structure. maintenance. responsibilities.7. Media control Chapter 7 . The ISO 9001 standard is the quality assurance standard that applies to software engineering. and resources for implementing quality management. control and improve it.128 XI. The 20 requirements given by ISp 2001 address the following topics : 1. 4. procedures. In order to get into such a system the organization has to get the company’s quality system and operations audited by the third-party auditors. Examples of quality standards include international standards organization (ISO) and the capability maturity model (CMM).

17. 6. The five process maturity levels which are a part of a process model is given below as CMM level : Level 1 : Initial Unpredictable and poorly controlled .7. measuring. and test equipment Inspection and test status Control of nonconforming product Corrective and preventive action Handling. 10. 7. 14. 13. Document and data control Purchasing Control of customer supplied product Product identification and traceability Process control Inspection and testing Control of inspection. 20. SEI uses an assessment questionnaire and a five-point grading scheme that defines important activities required at different levels of process maturity. storage.BSIT 44 Software Engineering 129 5. 7. The Software Engineering Institute (SEI) has developed a comprehensive model called as Capability Maturity Model.2 The Capability Maturity Model In the recent years. 9. 16. This model is used to determine an organization’s current state of process maturity. 12. there has been a significant emphasis on “process maturity”. which is based on a set of software engineering capabilities that should be present as organizations reach different levels of process maturity. 15. 19. packaging. it must set up policies and procedures to address each of the above said requirements and then demonstrate it in the form of practice. prevention and delivery Control of quality records Internal quality audits Training Servicing Statistical techniques In order for a software company to become ISO 9001 registered. 8. 18. 11.

integrity and usability. fairly well understood Process measured and controlled Focus on process improvement The SEI has associated key process areas ( KPA ) with each maturity levels. Each KPA is described by identifying the following characteristics :       Goals Commitments Abilities Activities Methods for monitoring implementation Methods for verifying implementation 7. In order to measure the quality of software important factors proposed by McCall and others are used. and its adaptability to new environments. The factors that affect software can be measured either directly or indirectly. The factor product transition deals with quality factors like portability. reusability and interoperability. . and they are known as McCall’s Quality factors. product operations deals with quality factors such as correctness.8 SOFTWARE QUALITY FACTORS The concept of quality in the context of software needs attention.Software Quality Assurance Can repeat previously mastered tasks Process characterized. efficiency. These aspects of software quality can be visualized to have three dimensions :    Product Operation Product Transition Product Revision The first factor.130 Level 2 : Repeatable Level 3 : Defined Level 4 : Managed Level 5: Optimizing - Chapter 7 . reliability. its ability to undergo change. McCall’s Quality factors It focuses on three important aspects of a software product : its operational characteristics.

and interpret output of a program. Portability The effort required to transfer the program from one hardware and/or software system environment to another. Reusability The extent to which a program can be reused in other applications.2. prepare input. Interoperability The effort required to couple one system to another. operate. These three factors are shown in figure 7. Integrity The extent to which access to software or data by unauthorized persons can be controlled. Usability The effort required to learn. Correctness The extent to which a program satisfies its specification and fulfills the customer’s mission objectives. flexibility and testability. Reliability The extent to which a program can be expected to perform its intended function with required precision. Efficiency The amount of computing resources and code required by program to perform its function. Maintainability The effort required to locate and fix an error in a program. Testability The effort required to test a program to ensure that it performs its intended function. Flexibility The effort required to modify an operational program. .BSIT 44 Software Engineering 131 The factor product revision deals with maintainability.

.9 SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the software process. FTRs. error tolerance.Software Quality Assurance Usually. data commonality. conciseness. The SQA activity includes procedures for effective application of software methods and tools. expandability etc.132 Chapter 7 .. It serves as a filter for the software process. Software review is very important and is an important SQA activity. Software quality factors help to measure the quality of software product. completeness. accuracy. removing errors while they are relatively inexpensive to find and correct. these quality factors are associated with software quality metrics like audibility. testing strategies etc. consistency. execution efficiency. Maintainability Flexibility Testability Product Revision Product transitions Portability Reusability Interoperability Product operations Correctness Reliability Usability Integrity Efficiency Figure 7.2 McCall’s software quality factors 7. And software metrics help to provide a quantitative way to access the quality of internal product attributes.

BSIT 44 Software Engineering 133 7. product transition and product revision —————————— defines the extent to which access to software or data by unauthorized persons can be controlled. ——————— are a “filter” to software engineering processes. 5. round-robin reviews. 4. 6. Quality assurance and quality control. 7. 7. 3.10 SELF CHECK EXERCISE I Fill in the blanks : 1. II a) Answer the following questions in one or two sentences : 1. The quality standard used in software engineering process is ———————— CMM stands for ———————————— McCall’s quality factors focus on ————————————. 8. reporting functions of management. 2. 4. 4. 5. Define the terms: Quality. Explain the quality concepts 2. What are the activities of SQA? explain Explain the types of software reviews What are the objectively of format technical review? explain Give the outline for SAQ plan . What is the importance of SQA plan ? What is the importance of McCall’s quality factors ? Why are quality metrics very important ? II b) Answer the following questions in detail 1. 2. 3. 3. inspections. What is software quality assurance ? Name the different types of software reviews. FTR includes ——————— . What is a defect amplification model ? Name any two commonly used quality standards for software. 5. 6. ———————————is an activity that consists of auditing.

8. 2. 5. Narosa publishing house. 7. An Integrated approach to Software Engineering (second edition). 3. 7.11 REFERENCES 1. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. . Software reviews walkthroughs ISO 9001 Capability Maturity Model Product operations Integrity 7. Quality assurance 2. 4. Explain the 20 requirements for ISP 2001 address Write a note on capability maturity model Explain Mc Call’s quality factors Chapter 7 . Roger S. Pankaj Jalote. 6.Software Quality Assurance I Answers 1.134 6.

In this chapter. So. data and documents that can easily change.0 INTRODUCTION W e know that.1 OBJECTIVES At the end of this chapter. The goal of SCM is to maximize production by minimizing mistakes. ensure that change is properly being implemented and report change to others who may be interested in it. through out software development process. change control and how they influence on software quality. version control.Chapter 8 Software Configuration Management 8. you should be able to :       Define “Software configuration management” Say “what baseline is ?” Appreciate the importance of baselines in software development process Identify the responsibilities of SCM process Identify the importance of versions and the way it is controlled Answer “what is change control ?” BSIT 44 Software Engineering 135 . Software Configuration Management ( SCM ). the software consists of a collection of items such as programs. SCM process. control change. this early changeable nature of software and the fact the changes often take place in the process of software development demands that the changes taking place need to be controlled. a discipline that systematically control the changes that are occurring during the software development process is followed. And it is also seen that during development process the requirements. So. 8. design and code often get changed. SCM is an umbrella that is applied through out the software process. SCM activities are developed to identify change. we will discuss about baselines.

As per IEEE. A baseline is a milestone in the software development process that is marked by the delivery of one or more Software Configuration Items ( SCI ). change can be made quickly and informally. software configuration management concept called Baseline is used.1 Baselines . Before a SCI item becomes a baseline. software passes through different kinds of users. in a software process is quite common. a baseline is defined as : A specification or product that has been formally reviewed and agreed upon. So. and that can be changed only through formal change control procedure. Customers demand for changes in their requirements. A baseline is a SCM concept that helps us to control change without seriously impeding justifiable change. that thereafter serves as the basis for further development. developers may want a change in their technical approach. and formal procedure must be applied to evaluate and verify each change. changes left wildly without control is very difficult to manage. the changes that can be made become specific. This is because.Software Configuration Management 8. Figure 8.2 BASELINES The changes occurring to a software. managers may want to modify project management approach and so on. However. But. once baseline is established. and these Software Configuration Items can be approved through Formal Technical Reviews.136  Discuss the need for configuration audit Chapter 8 . who are subjected to think differently at different times.

BSIT 44 Software Engineering 137 System Engineering System specification Requirements Analysis Software Requirements specification Software Design Design specification Coding Source code Testing Test plans/ procedures/data Release Operational system The progression of activities that lead to a baseline is shown in figure 8.1. .

When a member of software engineering team wants to make a modification to a baseline SCI.2 shows the modification path for a baselined SCI. This extracted SCI can be modified only by following the SCM controls. Figure 8. After SCIs are reviewed and approved. they are placed in a project database. modified SCIs approved SCIs Project database Software engineering tasks SCIs Formal Technical review Stored SCIs Extracted SCM controls SCIs Figure 8.Software Configuration Management Software engineering activities produce one or more SCIs.138 Chapter 8 . it is copied from the project database into engineer’s private workspace.2 Modification paths for baseline SCIs Software Configuration Item SCI is an information that is a part of software engineering process It is the basic unit of modification It is a document that is explicitly under the configuration control .

module design description d. interface design description source code listing test specification a. initial content as-built user manual maintenance documents a. mathematical specifications preliminary user manual design specification a. engineering change orders standards and procedures for software engineering 4. 2. 9. test plan and procedure b. module executable code b. system specification software project plan software requirements specification a. 6. 8. architectural design description c.BSIT 44 Software Engineering 139 The following SCIs are the target for the configuration management technique and form a set of baselines : 1. . prototypes d. graphical analysis model b. 13. 10. 11. schema and file structure b. 7. process specifications c. 12. 5. linked modules database description a. data design description b. 3. software problem reports b. test cases and recorded results operation and installation manuals executable program a. maintenance change orders c.

created by software engineer during analysis. 4.3. Its primary responsibility is to control the collection of basic objects and other aggregate objects. coding or testing.Software Configuration Management SCM is an important element of SQA. 3. source code listing for a module. Basic objects – it is a unit of text. data model and module N are basic objects. a list of resources and a realization. Example : In SRS. However. 2.1 Identification of Objects in Software Configurations The software configuration items must be named and organized using object-oriented approach. Two types of objects can be identified : basic objects and aggregate objects.3 THE SCM PROCESS Chapter 8 . which in turn have objects in them. description. identification of individual SCIs version control change control configuration auditing reporting 8. 5. Figure 8. with design specification as an aggregate object . design specification is an aggregate object which is an aggregation of objects like data design.3 shows configuration objects. design . other responsibilities of SCM include : 1. . Aggregate objects .. Each object or configuration object has certain distinct features like name. This is required to control and manage SCIs. architectural design module design etc.140 8. Example : a section of SRS.

a graph called evolution graph is used.1. objects evolve through out the software process. For this. Since.4 OBJ 1.2 OBJ 1.1 Figure 8.2 OBJ 2.1 OBJ 1.BSIT 44 Software Engineering 141 Design specification Data model Data design description Architectural design Module design Interface design Module N Interface description PDL Figure 8.1 OBJ 1.1.3 OBJ 1.4 Evolution graph .3 Configuration objects Module interconnection language will help in describing interdependencies among configuration objects and enables any version of a system to be constructed automatically. they need to be described about the changes. The diagrammatic representation of en evolution graph is shown in figure 8. OBJ 1.0 OBJ 2.4.0 OBJ 1.

Each version of software is a collection of SCIs and may be composed of different variants. Let us say that component 4 is used only when software is implemented using color displays and component 5 is used only when the software is implemented using monochrome displays.2.0” undergoes revision and becomes “ OBJ 1. 1 2 3 variants 4 Figure 8.1. The configuration management allows the user to specify the alternative configuration of the software system through the selection of appropriate versions.5 components 5 . configuration object “ OBJ 1.1 becomes OBJ etc. let us consider an example: a version of a simple program that is composed of five components. this “OBJ 1.1.1 and OBJ 1. OBJ 1.e. 8. This is shown in figure 8.1”. Evolution graph 2. Version representation There are two version representations : 1.5. complete version of software ).142 Chapter 8 . Attributes can be like a specific version number.1” then undergoes minor change and results in OBJ 1.Software Configuration Management Here. A major update at OBJ 1. Object-pool representation Evolution graph This is shown in figure 8. here each node represents an aggregate object ( i. Each software version has attributes associated with it.2 Version Control It combines procedures and tools to manage different version of configuration objects that were created during software engineering process.2 and similarly it evolves as OBJ 1. attached to each object or a string of Boolean variables.5.

5 In-order to construct variant of a given version. 3. components 1. A version or new version is defined when changes are made to one or more objects . each component is associated with one or more attributes.6 Object-pool representation A component is composed of collection of objects at the same version level. 2. version and variants.pool representation This describes the relationship between components.BSIT 44 Software Engineering 143 There are two variants of version: 1. and this model is shown in figure 8. Object. 2. 2. 3. 4 components 1.6 variants component object version Figure 8. A variant is different collection of objects at the same version level.

He then prepares a report called change report and submits to change control authority ( CCA ) A CCA is a person or group who makes a final decision based on the change report either to deny the change request or grant the change request. - “check-in” and “check-out” processes implement two important elements of change control : 1. overall impact on configuration objects etc. 2. The object to be changed is “checked-out” from project database and it is modified and appropriate SQA activities are applied. Every time a change is approved an engineering change order ( ECO ) is generated. criteria for review and audit. Figure 8. The changed object is then “checked-in” to the project database and appropriate version control mechanisms are used to create next version of software.3 Change Control Chapter 8 .7 shows the process of change control. side effects. the constraints imposed.Software Configuration Management Change control combines the human procedures and automated tools to provide the mechanism for control of change.144 8. access control synchronization control .3. This ECO describes what changes are to be made. and is described here: The user submits the change request for the current version The developer will evaluate the change request of software in order to access the technical merits.

BSIT 44 Software Engineering 145 Need for change is recognized Change request from user Developer evaluates Change report is generated Change control authority decides Request queue for action. ECO generated cha nge request is denied Assign individuals to configuration objects user is informed “ check -out” the SCIs make changes review the changes “check -in” the configuration item have been changed establish a baseline for testing perform quality assurance & testing activities create next version of software distribute new version Figure 8.7 the process of change control .

3. 2. 8.4 Configuration Auditing We can evaluate the changes made during change control using two methods: 1. 8.146 Chapter 8 . FTR – formal technical review Software configuration audit Formal technical review it focuses on the technical correctness of configuration object that has been modified. don’t overwrite one another. Software configuration audit It complements the FTR by assessing a configuration object for characteristics that are generally not considered during FTR. 3. This activity is conducted by quality assurance group The audit asks and answers the following questions : 1. Has the changes specified in the ECO been made ? Have any additional modifications implemented ? Have an FTR been conducted for accessing technical correctness ? Have software engineering standards been followed ? Have all related SCIs been properly updated ? etc. It contains the status information regarding changes that take place in the change control process this report is helpful in improving communication among all people involved in the process and plays an important role in the success of a large software development process . Synchronization control : this ensures that parallel changes made by two different people. 2.5 Status Reporting it is also known as configuration status reporting (CSR) or status accounting. For this purpose “ locks “ are used in the database.3.Software Configuration Management Access control : this governs which software engineer has authority to access and modify a particular configuration object. 4.

The information about the changes taking place is given out in the form of status report. Once a configuration object has been developed and reviewed. maintainers to access the changed information CSR is an SCM task that answers the questions like : 1.4 SUMMARY Software configuration management is an umbrella activity that is applied through out the software process. controls. SCM can be viewed as a software quality assurance activity that is applied through out the software process. may be placed in an on-line database for developers. SCM identifies. 3. . for which controls need to be applied. What happened ? Who did it ? When did it happen ? What else will be affected ? etc. 2. so that it keeps the management and practitioners informed about the important changes A CSR entry is made each time when a SCI is assigned new or updated identification. it becomes a baseline. Changes to a base-lined object results in the creation of new version of that object. The software configuration audit is an SQA activity that helps to maintain quality even when changes are applied to software. audits. Change control is a procedural activity that ensures quality and consistency as changes are made to configuration object. 8. a change is approved by CCA and a configuration audit is conducted The output of CSR. 4. and reports modifications that occurs during the software development process and after the release of software.BSIT 44 Software Engineering 147 - CSR is generated on regular basis.

The most commonly used version representations are evolution graph and ——————— ———————— ECO stands for ———————————— ————————— ensures that parallel changes made by two different people. 3. What is an SCM process ? What are aggregate objects ? Give one example. 7. What is version control ? What is change control ? why is it important ? Name the important functions of SCM process. 6. What is a baseline ? Give two examples of baselines.Software Configuration Management I Fill in the blanks : 1. 6. Software Configuration Items can be approved through ————————. 3. don’t overwrite one another. 5. —————————— will help in describing interdependencies among configuration objects and enables any version of a system to be constructed automatically. 8. 8. 7. SCM is an important element of ————————————— 4. 5. 4. 2. Give the IEEE definition of Software configuration management.148 8. .5 SELF CHECK EXERCISE Chapter 8 . 2. A baseline is a milestone in the software development process that is marked by the delivery of one or more ————————————. ————————— contains the status information regarding changes that take place in the change control process II a) Answer the following questions in one or two sentences : 1.

Give diagram 2. 6. 5.1985 . 3. Formal Technical Reviews Software Quality Assurance Module interconnection language Object-pool representation Engineering Change Order Synchronization control Status reporting 8.BSIT 44 Software Engineering 149 II b) Answer the following questions in detail 1. Pankaj Jalote. 5. 8. 4. Explain the activities of baseline. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. Explain the modification paths for baseline SCIS Explain the responsibilities of scum processes Explain the types of version representations Explain the process of change control Explain the configuration auditing Explain the status reporting concept I Answers 1. 7.. Roger S. 4. Narosa publishing house Richard Fairly. McGraw-Hill Inc. 6.6 REFERENCES 1. 2. An Integrated approach to Software Engineering (second edition). Software Configuration Items 2. 7. 3. Software engineering concepts. 3.

or other entities among the components of a system or program. configuration control — In configuration management. resources. analysis — In system/software engineering. contractual agreements. 150 Glossary . or other criteria code — In software engineering. an independent examination of the configuration status to compare with the physical configuration. approval or disapproval. and implementation of changes to configuration items after formal establishment of their configuration identification. coordination. the process of studying a system by partitioning the system into parts (functions or objects) and determining how the parts relate to each other to understand the whole. configuration auditing – In configuration management. computer instructions and data definitions expressed in a programming language or in a form output by an assembler. the process of expressing a computer program in a programming language. compiler.GLOSSARY SOFTWARE ENGINEERING TERMS allocation — The process of distributing requirements. coding — In software engineering. an element of configuration management consisting of the evaluation. standards. or other translator. architectural design — The process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system audit — An independent examination of a work product or set of work products to assess compliance with specifications.

especially table design in database applications. functional design — The process of defining the working relationships among the components of a system. and documents referenced therein.] functional decomposition — In software engineering. record and report change processing and implementation status. (2) The current approved technical documentation for a configuration item as set forth in specifications. interfaces. specified. components. the partitioning of higher-level system functions into smaller and smaller pieces to render them more manageable and understandable. an element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively. an individual or organization who specifies the requirements for and formally accepts delivery of a new or modified hardware/software product and its documentation. action that produces an incorrect result. or measured value or condition and the true. (1) An element of configuration management consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation. or theoretically correct value or condition. and programmer’s maintenance manual design — The process of defining the architecture. error — The difference between a computed. and verify compliance with specified requirements. and the implementation status of approved changes. data design – Design of a program’s data. and other characteristics of a system or component. documentation — A collection of documents on a given subject. configuration status accounting — In configuration management. associated lists. that provides a quantitative measure of logical complexity of a program. cost estimate — The estimated cost to perform a stipulated task or acquire an item. customer — In system/software system engineering. configuration management (CM) — In system/software engineering. drawings. control changes to those characteristics. Cyclomatic complexity — is a software measure. observed. The customer may be internal or external to the parent organization of the project and does not necessarily imply a financial transaction between customer and developer. . Examples are users’ manual. a discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item. the status of proposed changes to the configuration. a document that is deliverable to a customer. This information includes a listing of the approved configuration identification.BSIT 44 Software Engineering 151 configuration identification — In configuration management. operator’s manual. deliverable document — In software system engineering.

is a multidisciplinary activity that app lies the knowledge. or both. maintenance — The process of modifying a software system or component after delivery to correct faults. incorporated by a software engineer or team of engineers. and prototyping. maintainability. or memory usage. object-oriented design — A software development technique in which a system or component is expressed in terms of objects and connections between those objects. Or To perform operations on data. user environment design. or process possesses a given attribute. and resources that are performed for a given purpose. constraints. control. or adapt to a changed environment. accuracy. inspections — A static analysis technique that relies on visual examination of development products to detect errors. metric — A quantitative measure of the degree to which a system. component. such as speed. syntactic and lexical design. derived from psychology and technology. process management (Software Engineering Process) — The direction. implementation — The process of translating a design into hardware components. The human engineering process encompasses the following steps: activity analysis. . initiation and scope – A non-specific term for work performed early in a software project that includes high-level statements of requirements and rough estimates of project cost and schedule. to specify and design high quality humanmachine interfaces. semantic analysis and design. process definition (Software Engineering Process) Identification of a sequence of steps involving activities. and usability or to specific features of a software product. and tools. methods. performance analysis techniques and tools — Techniques and tools that are used to measure and evaluate the performance of a software system process — A sequence of steps performed for a given purpose. that encompasses process. and coordination or work performed to develop a product or perform a service. . violations of development standards. performance — The degree to which a system or component accomplishes its designated functions within given constraints. the software development process or An executable unit managed by an operating system scheduler. software components. product attributes — Characteristics of a software product. and other problems. improve performance or other attributes. Can refer either to general characteristics such as reliability.152 Glossary human-engineering — In system/software system engineering. process model (Software Engineering Process) – A development strategy. for example.

The primary goal of risk management is to identify and respond to potential problems with sufficient lead-time to avoid a crisis situation. and understand the requirements of the system.Planning) — That aspect of the overall management function that determines and implements the quality policy. and know-how that provides the planning. quality analysis — A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. measures per person-month) that can be used to measure the characteristics of delivered documents and software. standard. project management — A system of procedures. users. an “umbrella” title for the processes used to manage risk. quality management (Software Engineering Management . . Software — Computer programs. specification. technologies. schedule and cost estimates (Software Engineering Management . procedures. staffing. requirement — A condition or capability that must be met or possessed by a system or system component to satisfy a contract. selecting. and managing options (risk analysis) for resolving (risk handling) these risks. requirements engineering — a method of obtaining a precise formal specification from the informal and often vague requirements with a customer. quality attribute — A feature or characteristic that affects an item’s quality. risk management (Software Engineering Management) — In system/software engineering. and lower level attributes may be called quality attributes. managers. or set of work products. or other formally imposed documents requirements elicitation (software requirements) — The process through which the customers (buyers and/or users) and developer (contractor) of a software system discover. In a hierarchy of quality attributes. directing. and controlling necessary to successfully manage an engineering project. project plan — A document that describes the technical and management approach to be followed for a project. practices. Contrast with hardware. or other interested parties for comment or approval. review.BSIT 44 Software Engineering 153 product measure – A metric (e. higher-level attributes may be called quality factors.Planning) — The management activity of determining the probable cost of an activity or product and the time to complete the activity or deliver the product. articulate.g. and possibly associated documentation and data pertaining to the operation of a computer system. organizing.. reviews — A process or meeting during which a work product. It is an organized means of identifying and measuring risk (risk assessment) and developing. customers. is presented to project personnel.

software metric — A quantitative measure of the degree to which a system. software configuration status accounting (software configuration management) – In configuration management. and controlling necessary to successfully manage a software engineering project. software design. technologies. record and report change processing and implementation status. software development methodology — In software engineering: an integrated set of software engineering methods. interfaces. task — A task is a well-defined work assignment for one or more project members.154 Glossary software configuration management — In system/software engineering. implementing. components. software engineering process — The total set of software engineering activities needed to transform a user’s requirements into software software engineering project management (SEPM) — A system of procedures. system integration — In system/software system engineering. tools. modules. and the implementation status of approved changes. component. a discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item. and verify compliance with specified requirements. the status of proposed changes to the configuration. and other methodologies for analyzing. software requirements specification (software requirements) – A document that specifies the requirements for a system or component. procedures. the process of defining the software architecture (structure). This information includes a listing of the approved configuration identification. an element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively. staffing. and know-how that provides the planning. or software requirements. directing.In software engineering. . organizing. control changes to those characteristics. designing. this ensures that the various segments and elements of the total system can interface with each other and with the external environment. techniques. standards. practices. software quality — In software engineering: The totality of features and characteristics of a software product that affects its ability to satisfy given needs (for example. SQA (software quality assurance) — A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. languages. rules. to conform to specifications software requirements analysis — The process of studying user needs to arrive at a definition of system. or process possesses a given attribute. policies. and testing software. and data for a software system to satisfy specified requirements. test approach. hardware.

. version — An initial release or re-release of a computer software configuration item. the testing of a system or component. test design (software testing) — Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests. associated with a complete compilation or recompilation of the computer software configuration item. testing strategies (software testing) — In software engineering. or results of. one of a number of approaches used for testing software. test coverage of code (software testing) — The amount of code actually executed during the test process.BSIT 44 Software Engineering 155 test coverage (software testing) — The degree to which a given test or set of tests addresses all specified requirements for a given system or component. and the final system or component complies with specified requirements. test execution (software testing) — Act of performing one or more test cases. user interface — An interface that enables information to be passed between a human user and hardware or software components of a computer system. test procedure. test log. verification — The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. V&V (verification and validation) — The process of determining whether the requirements for a system or component are complete and correct. the products of each development phase fulfill the requirements or conditions imposed by the previous phase. Types include test case specification. Validation – The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. test plan. test documentation (software testing) — Documentation describing plans for. test report. test incident report.

1 Ian Sommerville. Software engineering concepts. 4. Addison-Wesley publications. 2 Shari Lawrence Peleeger. McGraw-Hill Inc. ed. 1996. Pearson education. Software testing in the real world.4 Edward Kit. 5. 3. MCGraw-Hill publication.1985 Barry W. 6. Boehm. 2001. 7. . Reference Books Roger S. software engineering theory and practice. 2000. ed.. An integrated approach to software engineering. Software Engineering Economics. Software engineering : A practitioner’s approach. Narosa publications. 2 Richard Fairly. 1981. Pressman. ed. 1997.. Software engineering.5 Pankaj Jalote. ed. 1997. Prentice-Hall Inc. 2. ed. Addison-Wesley publications.156 REFERENCE BOOKS 1.

Sign up to vote on this title
UsefulNot useful