This action might not be possible to undo. Are you sure you want to continue?
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.
1.3 WHAT IS SOFTWARE ENGINEERING ?
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.”
1.4 A GENERIC VIEW OF SOFTWARE ENGINEERING
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
This type of maintenance extends the software beyond its original functional requirements. 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. business rules. This development strategy is often referred to as a process model or software engineering paradigm. what function and performance are desired. 1.5 THE SOFTWARE PROCESS MODELS Software engineering is a discipline that integrates process. The maintenance phase focuses on change that is associated with the software. each . Enhancement – As software is used. A process model for software engineering is chosen based on the nature of the project and application. the software developer attempts to identify what information is to be processed. operating system. how procedures are to be implemented. during the software development. preventive maintenance. what system behavior can be expected.An Introduction to Software Engineering The definition phase focuses on what. how function is to be implemented as a software architecture. methods and tools for the development of computer software. software project planning and requirements analysis. the methods and tools to be used. it is likely that the original environment ( eg. how design will be translated into a programming language. CPU. and the controls and deliverables that are required. Corrective maintenance changes the software to correct defects. That is. how testing will be performed etc. So. This phase includes three main tasks : system or information engineering. That is during definition. external product characteristics etc. Adaptations – As time progresses. for which the software was developed is likely to change. A number of different process models for software engineering have been proposed. the customer will recognize the need for additional functional requirements that will benefit him.). what interfaces are to be established. a software engineer attempts to define how data are to be structured. The development phase focuses on how. Prevention – Computer software deteriorates due to changes. often called software reengineering must be conducted in order to make changes to the computer software more easily. code generation and software testing. what design constraints exist. and what validation criteria are required to define a successful system. This phase includes three main tasks : software design.4 The definition phase The development phase The maintenance phase Chapter 1 . Adaptive maintenance results in modification to the software to accommodate changes to its external environment.
BSIT 44 Software Engineering 5 exhibiting strengths and weaknesses. In the next sub section that follow.1 The waterfall model . let us see some of the important software process models. Test report and Manuals Installation report Installation Operations and maintenance Figure 1. but all having a series of generic phases in common. 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.
On completing the coding phase. the system is installed. a project begins with the feasibility analysis. On successful completion of testing. On successfully demonstrating the feasibility of a project. Which is difficult to give since requirements keep changing according to needs and time. At every phase there is a provision for verification and validation.5. and at what cost.An Introduction to Software Engineering It is the simplest and the widely used process model for software development. 1.2 The Prototype Model The aim of this model is to overcome the limitations of the waterfall model that is. instead of freezing the requirements before the design or coding phase a throw-away prototype is built to help understand the requirements.5. it requires a complete set of user requirements before the commencement of design.1 The Waterfall Model Chapter 1 . In a typical waterfall model. Linear ordering of these activities are shown in the figure 1. This model is . the requirements analysis and project planning begins. testing is done.1. The importance of this model is that it allows for communication between the customer and the software developer and specifies what. After this. the regular operation and maintenance of the system takes place. And the prototype is developed based on the currently known requirements.6 1. The weakness with this model is that. which helps in correction of errors. The design starts after completing the requirements analysis and coding starts after completing the design phase. Here the phases involved in the software development are organized in a linear order. when the product will be delivered. 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.
the cost of the requirements analysis must be must be kept low. since they get an actual feel of the system that they indent to use. This cycle is repeated until the client has no modifications on the system. Based on the client’s feedback. At this stage. the developer incorporates the suggested changes to the system and gives the modified system to the client’s use.2 Requirements analysis Design Design Code Test Code Test Figure 1. The process model of this approach is shown in figure 1. 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. The important characteristics of this model are: For prototyping. 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 . there is a reasonable understanding of the system and its needs. coding and testing. in-order for it to be feasible The development approach followed is “quick and dirty”. After the prototype has been developed.BSIT 44 Software Engineering 7 very attractive for the customers. the clients are permitted to use the prototype system. at which stage the final requirements specification is ready for further processes like designing.2 The Prototyping model The development of the prototype starts when the preliminary version of the requirements specification document has be developed.
Some examples of this model are the incremental model. So .software engineers need a process model that can take care of software products that evolves over time. concurrent development model and the component assembly model. until the complete product is produced. Evolutionary models are iterative.3. The first increment is often a core product.3 The incremental model . so as to meet the better needs of the customer and the delivery of additional features and functionality. evolves over a period of time.An Introduction to Software Engineering 1. This core product is used by the customer. The plan addresses the changes of the core product.3 The Evolutionary Software Process Model Software like any other system. spiral model. where the basic requirements are addressed.3 This model applies linear sequences with reference to time.5.1 The Incremental Model It is also known as the iterative enhancement model. Based on the result of use and/or evaluation. And each linear sequence produces a deliverable “ increment “ of the software. But the problem with this method is that the iterations may never end and the user may never really get the final product. a plan is developed for the next increment. 1.5. This process is repeated following the delivery of each increment. The incremental model is shown in figure 1. It combines elements of the waterfall model with the iterative philosophy of the prototype model. This approach is advantageous for an in-house software development. Such models are termed as evolutionary models. It is an evolutionary model.8 Chapter 1 . 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.
3. Based on the outcome of the development step the next phase is planned. it has some problems associated with it like.5. The last phase is the customer evaluation phase. Each cycle here begins with the identification of objectives for that cycle. The activities in this model can be organized like a spiral. 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 inner cycles represent the early phases of requirement analysis along with the prototyping and the outer spirals represent the classic software lifecycle. each quadrant representing a major activity like planning. bench marking etc. and uses various development strategies that resolve the uncertainties and risks. that has many cycles.4 This model has been divided into four quadrants. there is a risk assessment phase to evaluate the development effort and the associated risk involved for that particular iteration. The second quadrant is associated with risk analysis activity. engineering and customer evaluation. The software process cycle begins with the planning activity represented by the first quadrant of this model (upper-left quadrant). The importance of evaluation is that. . Typically. risk analysis is a major phase in this model and assessment of risks involve a greater technical expertise. It incorporates the elements of both the prototype approach along with the classic software lifecycle. It may include some activities like simulation.BSIT 44 Software Engineering 9 1. risk analysis. The spiral model is shown in figure 1. It involves a review of the preceding development stage. proposed by Barry Boehm.2 The Spiral Model This model is relatively a new model. the alternatives and constraints associated with that objective. It used to evaluate different alternatives that are based on the objectives and constraints listed in the first quadrant. which actually involve the development of the software. The third quadrant is about engineering activity.
A number of process for software engineering have been proposed each with its own strengths and weaknesses. constraints Opera tional prototype Proto Proto 3 2 Plan next phase Figure 1. Software engineering is a discipline that integrates process. methods of engineering it in this unit. alternatives.An Introduction to Software Engineering Determine objectives. resolve risks Proto 1 Requirements plan Concept Simulations.5 SUMMARY Software is a set of instructions or computer programs that when executed provide desired function and performance. and tools for the development of computer software. It is both a process and a product. . methods. identify. 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.4 The spiral model 1.10 Chapter 1 . Evaluate alternatives. And you have learnt some of the important aspects of software. You will be reading more on the generic phases involved in the development of software in the subsequent chapters. models. test alternatives. constraints Risk Analysis Risk Analysis Risk Analysis REVIEW Risk An.
Software is a process and ——————————. software project planning and ————————— —————————————— results in modification to the software to accommodate changes to its external environment. In Water fall model. II (a) Answer the following questions in one or two sentences: 1. 5. What is the advantage of software reusability ? Briefly list out the major application areas of software . 10. 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. 9. List out the important characteristics of software. 8. 3.6 SELF CHECK EXERCISE I Fill in the blanks: 1. 2. 8.BSIT 44 Software Engineering 11 1. Software engineering is a —————————— The definition phase of software engineering includes tasks such as system engineering. 4. 5. 6. The development approach followed in prototype model is ——————————— The ——————————— method is also known as the iterative enhancement model. Give the IEEE definition of software engineering Name the three generic views of software engineering. 3. Software is a set of ————————— that when executed provide desired function and performance. 7. 4. What is Software. the phases involved in the software development are organized in ———————————. 2. 6.
12 Chapter 1 . Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition McGraw-Hill 1997. 7. 1. Pankaj Jalote. Explain the waterfall model with neal diagrams. An Integrated approach to Software Engineering (second edition). 4. 6. 8. 2. 2. 3. Explain the spiral model with neat diagrams. 5. Roger S. 3. Explain the compments of software. Narosa publishing house . instructions or computer programs 2. product discipline requirements analysis adaptive maintenance linear order quick and dirty incremental 1.8 REFERENCES 1.An Introduction to Software Engineering II (b) Answer the following questions in details: 1. I Answers for the in the blanks.
understanding the system is through what is known as requirements capturing and analysis. In this chapter. Thus.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 . the stages of system development and also some of the important process models were discussed. we will see some of the ways of analyzing the problem and explore the characteristics of requirements.0 INTRODUCTION I n the previous chapter. 2. 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 2. We shall also see how to document the requirements for use by the design and test teams.
Chapter 2 - System Analysis and Requirements Specification
2.2 SOFTWARE REQUIREMENTS
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
Prototyping and testing
Documentation and Validation
Figure 2.1 the process of determining requirements
2.2 PROBLEM ANALYSIS
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.
Customer. and textual specs. It is still considered one of the best modeling techniques for eliciting and representing the processing requirements of a system. Accounting Department. It has broad application and usability across most software development projects. In the physical model. Together with these. function. or a Rounded Rectangle (Gane & Sarson notation).g. it is a useful and easy to understand modeling tool. etc. it provides analysts and developers with solid models and specs. Government Agency. process (activity). Symbol: Circle (Yourdon notation). Alone.BSIT 44 Software Engineering 17 Data Flow Diagrams Data Flow Diagrams also called data flow graphs are commonly used during problem analysis. It shows the flow of data through the system it does not represent procedural information. table. External Entity(s) (i. leveled sets of Data Flow Diagrams.. Partitioned Diagrams (single process only — one level). etc. In the . however. in lower levels. e. 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. 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. It is not a user.. The DFD is an excellent communication tool for analysts to model processes and functional requirements. Functionally decomposed.g. Activity.e. Source. this represents a file. for understanding a system. Description Process (i. a data store is an object or entity. workflow modeling tools. Marketing Dept). The different versions are Context Diagrams (Level 0). Supplier. Usually external to the business or system but may be internal (e. etc. The Human Resources System. Any complex system can be broken down into a system with a series of simple data transformations. It views a system as a function that transforms the inputs into desired outputs. It is easily integrated with data modeling. Symbol: rectangular box which may be shaded. a program label is identified in the bottom of the symbol. Sink. Something outside the system. In the physical model. In the logical model. Used effectively. Data Store A repository of information. Symbol: Two parallel lines (Yourdon notation). Terminator) A person or group which interacts with the system. the process and Data Stores.e. or an open ended rectangle (G&S notation) Data Flows The directional movement of data to and from External Entities. it has limited usability.
update. it means a write. . In order for prototyping for requirements analysis to be feasible. Throwaway prototyping In this approach. a partial system is constructed.2 Data Dictionary The data dictionary is a repository of various data flows defined in a DFD. mean read. display. Symbol: Solid line with arrow. the prototype is built with an idea that it will later be converted into the final system. Each data flow is identified with a descriptive name that represents the information (data packet) on the data flow. The components in the structure of a data flow may also be specified in the data dictionary. query. delete. when it flows into a data store. which is used by the client and the developers to have a better understanding of the problem and the needs. Evolutionary prototyping In this approach. as well as the structure of files. Prototyping In this method of problem analysis.System Analysis and Requirements Specification physical model.18 Chapter 2 . its cost must be kept low. select types of transaction. Flows out of Data Stores. 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. It states the structure of each data flow in a DFD. An example of DFD for an employee payment system is shown in figure 2. And the cost of developing and running a prototype can be around 10% of the total development cost of the software. etc. There are two approaches to this methods: throwaway and evolutionary prototyping. 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.
2 DFD for an employee pay system .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.
reliability.4. Requirement specification yields an SRS as the final document. we shall discuss the characteristics of an SRS. This aspect of requirements is a significant problem area for many SRSs. 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.System Analysis and Requirements Specification The following figure 2. For example.3 gives the data dictionary associated with the DFD of an employee payment system.20 Chapter 2 . as well as how it interfaces and interacts with it.4 REQUIREMENTS SPECIFICATION This is an activity that is carried on in parallel with the problem analysis. 2. Next. components associated with it and specification languages. Accurate .1 Characteristics of an SRS The table–1 shown below gives the fundamental characteristics of a quality or good SRS. 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. SRS capability functions and performance levels are compatible.) do not negate those capability functions. 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. although it has to be after the problem analysis.3 Data Dictionary 2. SRS precisely defines the system’s capability in a real-world environment. which is very essential for satisfying the basic goals of the system.
analyze. unambiguously. This is one of the main reasons SRSs are written using natural language. 2. government requirement. etc. A “strong” SRS is one in which the requirements are tightly. accept. Individual requirements of an SRS are hierarchically arranged according to stability.) SRS must contain requirements statements that can be interpreted in one way only. 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. and precisely defined in such a way that leaves no other interpretation or meaning to any individual requirement. perceived ease/difficulty of implementation. A valid SRS is one in which all parties and project participants can understand. While many quality attributes of an SRS are subjective. security. or approve it. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. 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).BSIT 44 Software Engineering 21 Modifiable The logical. 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.4. This is another area that creates significant problems for SRS development because of the use of natural language. or other parameter that helps in the design of that and subsequent documents.2 Designing an SRS Several standards organizations (including the IEEE) have identified nine topics that must be addressed when designing and writing an SRS: . Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present. Each requirement in an SRS must be uniquely identified to a source (use case. industry standard. we do need indicators or measures that provide a sense of how strong or weak the language is in an SRS.
how do these general topics translate into an SRS document? What. 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). 6. 5. 2. specifically. but also from project to project within any one company. 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. and precise because the design specification. It should posses many desired qualities of an SRS. 7. and other project documents are what drive the development of the final product. 8. 2. Unlike formal language that allows developers and designers some latitude. as given below: 1. and then adapt it to meet ones needs.3 Specification Languages Requirements specification necessitates the use of some specification language. The natural language of SRS must be exact.System Analysis and Requirements Specification But. 4. 3. Interfaces Functional Capabilities Performance Levels Data Structures/Elements Safety Reliability Security/Privacy Quality Constraints and Limitations Chapter 2 . 4.4.22 1. 9. 3. The key is to select an existing template or specification to begin with. statement of work. does an SRS document include? How is it structured? And how do you get started? An SRS document typically includes four ingredients. we will see some of the commonly used languages for requirements specification. without ambiguity. Here. . 2.
and try to restrict the use of common phrases in order to improve precision and reduce ambiguity. Some insist on using words like “shall”. written requirements are imprecise and ambiguous. the natural language is used in a structured manner. The use of natural language has some problems associated with it. composition. closure are used in regular expressions. and the bottom part specifies different actions. alternation. 5 C1 C2 C3 Y conditions actions The decision table has two parts. Some basic constructs like atoms. They are helpful in specifying complex decision logic. to define many data streams. table-based notation that can be used to check the qualities like completeness and lack of ambiguity in requirements specification. However. analysts are making an effort to move from natural languages towards formal languages for requirements specification. “should”. Regular Expressions Regular expressions can be used to specify the structure of symbol strings formally. The top part specifies different conditions. using the natural language for smaller systems. So.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. . They can be considered as grammar for specifying the valid sequences in a language and can be processed automatically. If English is used as a natural language. “perhaps”. Written requirements become necessary as the system become more and more complex as against the requirements conveyed verbally. To reduce these problems. Decision Tables It is formal. requirements are broken into sections and paragraphs and paragraph further into subparagraphs.
1 1. System Features 4. External Interface Requirements 3. Introduction 1.6 2.3 2.2 2. This example is an adaptation and extension of the IEEE Standard 830-1998: Table-2 A sample of a basic SRS outline 1.4 User interfaces Hardware interfaces Software interfaces Communication protocols and interfaces 4.2 1.4 Structure of an SRS Chapter 2 .6 2.5 1.4 1.3 1.System Analysis and Requirements Specification The table-2 below shows what a basic SRS outline might look like.24 2.4.2 3.7 Product perspective Product functions User classes and characteristics Operating environment User environment Design/implementation constraints Assumptions and dependencies 3. Purpose Document conventions Intended audience Additional information Contact information/SRS team members References Overall Description 2.5 2.1 2.3 3.1 System feature A .4 2.1 3.
A number of methods exist for requirements validation such as automated cross-referencing. 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.design starts.1.1.2 5.BSIT 44 Software Engineering 25 4.3 5.1 Description and priority 4.. a person from design team etc.2 Action/result 4.1.2 5. the author of the requirements document. reading. . System feature B Other Nonfunctional Requirements 5. are involved in the review process to find errors and discuss the requirements specification of the system.1 5.5 5. review etc.5 VALIDATING REQUIREMENTS It is important that that final requirements be validated before the next phase of software development . prototyping.3 Functional requirements 4. among them the most commonly used method is requirement review.6 Performance requirements Safety requirements Security requirements Software quality attributes Project documentation User documentation 6. Other Requirements Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined 2. In this technique. a team of people consisting of a representative from the client. But.4 5.
this information will help you get started when you are called upon—or step up—to help the development team. . 5. it is essential that the SRS be developed in a systematic and comprehensive way. ———————— 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.26 2. the software is likely to not meet the user’s requirements. In the next chapter we will see how to transform these requirements analyzed into design. If this is done. even if the software conforms with the specification and has few defects. 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. 4. To achieve a high level of IS quality. 6. The software requirements deal with the ————————of the proposed system. 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. 7. 2. template design.System Analysis and Requirements Specification Requirements collection is crucial to the development of successful information systems.7 SELF CHECK EXERCISE I Fill in the blanks 1.6 SUMMARY Chapter 2 . Writing top-quality requirements specifications begins with a complete definition of customer requirements. If it is not done. requirements elicitation and analysis and ————————— Structured analysis mainly depends on data flow diagrams and —————— An external entity is represented using ————————— in a DFD. and precisely defined in such a way that leaves no other interpretation or meaning to any individual requirement. and will lead to user satisfaction. Hopefully. the system meet the user’s needs. There’s so much more we could say about requirements and specifications. and natural language use are in the best position to create and add value to such critical project documentation. 3. A ———————— SRS is one in which the requirements are tightly. unambiguously. 2.
4. What is data dictionary?Explain. 2. 7. Narosa publishing house Ian Sommerville. Give the IEEE definition of software requirements analysis. 6.BSIT 44 Software Engineering 27 II (a) Answer the following questions in one or two Sentences : 1. 3. ed. An Integrated approach to Software Engineering (second edition). 1996. What are the characteristics of SRS? Explain. 5. What is problem analysis? explain the medel to problem analysis. 9. Software Requirements Specification (SRS) Requirements definition and specification Data dictionary Rectangle Strong Checklists 2. II (b) Answer the following questions in details: 2. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. Requirements 2. 8. 6. 4. What is DFD? Explain DFD for an emplayee pay slm. Addison-Wesley publications. 10. 1. 3. 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. Software engineering. 3. What are the goale of SRS? Explain. 5. Briefly explain the requirement process.5 . Roger S. 7.8 REFERENCES 1. Pankaj Jalote.
In this chapter we will see what to do and how to do it.0 INTRODUCTION I n the last chapter. we learned how to work with the customers to determine what they want out of the proposed system. 3.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 .Chapter 3 System Design 3. The outcome of requirements analysis and specification phase was a system requirements specification document.System Design . The next step in development is to translate those desires into a solution: a design that will satisfy the customers’ needs. 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.
The design process for the software has two levels: 1. . the internal design of the modules are decided or how the specifications of the modules can be satisfied are decided. which can be used later to build that system. A design can be object-oriented or function-oriented. the modules that are needed for the system are decided. with each module supporting a functional abstraction. Design is an important phase in the software development life cycle. In object-oriented design. The goal of the design process is to produce a model of the system. the modules in the design represent data abstraction. The design process is a set of iterative steps that enable the designer to describe all aspects of the software to be built. In function-oriented design. 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. system design or top-level design detailed design or logic design System design Using this. The model thus produced is called the design of the system. the specifications of these modules and how these modules need to be connected are also decided. it is necessary to have a means of tracking the requirements.3 DESIGN PRINCIPLES Software design is both a process and a model. resources available and the design concepts. 2. The basic design principles enable the software engineer to proceed with the design process.BSIT 44 Software Engineering 29 3. 3. the design consists of module definitions. Detailed design Using this.2 THE DESIGN PROCESS The software design is an activity which is after the requirements analysis activity. The design should be traceable to the analysis model – since the design needs to satisfy multiple requirements of a problem. it bridges the requirements specification and the final solution for satisfying the requirements. 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. This phase begins when the requirements document for the system to developed is available.
In order to achieve this. structured partitioning. There are a number of fundamental design concepts that has been of interest: Abstraction. format. The design should be structured to accommodate change The design should be structured to degrade gently. software architecture. 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. will have to defined for the design team before design work begins. Internal quality factors are those that lead to high quality design software. ambiguity. the software engineer creates a design that exhibits both internal and external quality factors. events. modularity. coding is not design – design model has a higher level of abstraction than the source code. or operating conditions are encountered Design is not coding. External quality factors are those properties of the software like.. speed. the designer must understand the basic deign concepts. have to be addressed by the designer before dealing with the syntax of the design model. that can be readily observed by the users. information hiding. If the interfaces are well defined for the design components then the design is said to be integrated. software procedure. When the design principles described above are properly applied. . even when aberrant data. The design should be reviewed to minimize conceptual errors – major semantic errors like omissions. style etc. The design should be assessed for quality as it is being created. In order to achieve internal quality factors. inconsistency etc. The design should exhibit uniformity and integration – a design is uniform if it appears that one person developed the entire thing. the design rules. data structure.30 Chapter 3 .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. not after the fact – a number of design concepts and design measures are available and can be used to access quality of the software. Major decisions are at design phase and only small decisions are taken at the implementation phase. reliability. control hierarchy.4 DESIGN CONCEPTS The design concepts provide basic criteria for design quality. refinement. 3. correctness etc.
the data associated with the tasks may have to be refined. providing more and more details at end of each refinement step. more procedural details are given. 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. 3. At the highest level of abstraction. stating the desired effect without stating exact mechanism of control. At the lower levels of abstraction. which implies a long sequence of procedural steps like: walk to the door. co-routines. Data abstraction : A data abstraction is a named collection of data that describes abstract data types. It causes the designer to elaborate on the original statement. Example: ON interrupt DO save STACK_A and call Exception_handler_a. Here the word “open” is an of example of procedural abstraction. at an appropriate level of detail. Control abstraction : It implies a program control mechanism without specifying internal details. move away from the door. turn the knob and pull the door. That is. It deals with problems at some level of generalization without regard to irrelevant low level details. As tasks are refined. 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. that describe the door. And processing procedures and data structures are likely to be refined in parallel. .4. a solution is stated in broad terms using the language of problem environment.1 Abstraction Abstraction is a means of describing a program function. decomposed.BSIT 44 Software Engineering 31 3. door type etc. “open the door”.. objects. operations on objects by suppressing the representation and manipulation details. The word “door” is an example of data abstraction. exception handling. or structured.2 Stepwise Refinement Stepwise refinement is a top-down approach where a program is refined as a hierarchy of increasing levels of detail.4. which has certain attributes like dimensions. Consider an example sentence. weight.
Extra-functional properties This describes about the manner in which the design architecture achieves requirements for system characteristics like performance. Jackson notation. also called as control hierarchy.. indicating how the system configuration may change as a function of external events. It refers to the overall structure of the software and the ways in which that structure provides the conceptual integrity for a system. Notations like Warnier-Orr notation. 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.4 Program Structure The program structure. A set of architectural patterns enable a software engineer to reuse the design level concepts.4. objects). These models use ADL (architectural description language) for describing the system components and the interconnections among them. are used to represent control hierarchy. Functional models can be used to represent the functional hierarchy of a system 3. So.3 Software Architecture Chapter 3 . There are a number of architectural design models that is based on the above said properties. architecture is about structure of software. represents the hierarchy of control with out regard to the sequences of processing and decisions.System Design While refinement is about the level of detail. architectural design should have the ability to reuse architectural building blocks. 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. Process models deals with the design of the technical process that the system must accommodate. the way these components are grouped and interact with one another. Program structure is usually expressed as a simple hierarchy showing super-ordinate and subordinate relationships of modules. security. The tree-like .32 3. adaptability etc Families of related system The design of similar systems usually encounter similar design patterns.4. tree-like diagrams etc. reliability. capacity. The properties associated with an architectural design are: Structural properties This defines the components of the system (such as modules. Dynamic models address the behavioral aspects of program architecture.
BSIT 44 Software Engineering 33 diagram ( as shown in figure 3. Fan-in . width.5 Data Structure Data structure is a representation of the logical relationship among the individual elements of data. Fan-in indicates how many modules directly control a given module. methods of access. It represents the organization. A module that controls another module is said to be super-ordinate to it. Depth refers to the number of levels of control . And a module controlled by another is said to be subordinate to the controller.4.1 control hierarchy 3. Width refers to the overall span of control. which represents hierarchy of modules. Fan-out are usually associated in describing and measuring the program structure.in i r width Figure 3. The terms like depth. The relationship between modules is said to be either super-ordinate or subordinate. degree of associativity. Fan-out is a measure of the number of modules that are directly controlled by another module. and processing alternatives for . M depth a b Fan-out c d f g e h j k m n o p q Fan.1) is the most common structure followed.
data links. the impact of change induced on it will be minimum.System Design problem-related information. Can be included in a program. The logic of partitioning may be based on related functions.4. Classic data structures include scalar. it will be easier to build a module and make changes easily. Modularity does imply interface overhead related to information exchange between modules and execution of modules. 5. Contains instructions. Modularity is a logical partitioning of the software design that allows complex software to be manageable for purposes of implementation and maintenance. Modular composability If a design method enables the existing design components to be assembled in to a new system. Modular understandability If a module can be understood as a single unit without referring to other modules. 3. 3. rather than system-wide changes. makes up the software architecture. there by achieving an effective modular solution. 2. . 4. and hierarchical. or other criteria. Can be separately compiled and stored in a library. it will reduce the complexity of the over all problem. Modular decomposability If a design method provides a systematic way for decomposing a problem into sub problems. Data structure. it will produce a modular solution for the problem. 4. Modules can use other modules. 3. linked-list. implementation considerations. along with program structure.6 Modularity A module is a named entity that: 1. and data structures. n-dimensional.34 Chapter 3 . processing logic. Modular continuity If any small changes to the system requirements result in changes to individual modules. sequential. Modularity derives from the architecture. 2. There are five important criteria for defining an effective modular system that enable us to evaluate a design method: 1. Module segments can be used by invoking a name and some parameters.
Processing defined for each module must include references to all subordinate modules identified by the program structure.5 EFFECTIVE MODULAR DESIGN Among the several fundamental design concepts discussed earlier. a modular design reduces complexity.BSIT 44 Software Engineering 35 5. 3. and data organization. 3. Some of the criteria used to guide modularization Conventional criteria — module is a processing step in execution sequence.4. Problem modeling — modular system structure matches the problem structure (data structures match the problem structure and visible functions manipulate the data structures. Information hiding criterion — modules hide difficult or changeable design decisions.8 Information Hiding Information hiding is an adjunct of modularity. modularity is the most important one. facilitates changes and results in easier implementation of programs.4. Coupling and cohesion — system is structured to maximize the cohesion of module elements and minimize coupling between modules. Data abstraction criterion — modules hide representation details of major data structures behind functions that access and modify the data structure. Modular protection If an aberrant condition occurs with in a module and its effects are constrained within that module. the impact of error induced on it will be minimum. A procedure representation of software is layered. Information hiding simplifies testing and modification by localizing these activities to individual modules.7 Software Procedure Software procedure provides a precise specification of the software processing. It permits modules to be designed and coded without concern for the internal details of other modules. Only the access protocols of a module need to be shared with the implementers of other modules. exact decision points. including sequence of events. . repetitive operations. Levels of abstraction — modules provide hierarchical set of increasingly complex services. 3. Since.
g. several related functions. 4. same invocation of the module. Functional cohesion (all elements relate to performance of a single function).1 Functional Independence The functional independence is a direct outgrowth of concepts like modularity.2 Cohesion Cohesion is a measure of the relative functional strength of a module. I/O module). A cohesive module must perform a single task within a software procedure. e.e. independent modules) is easier to develop and maintain. 3.g. math library) Temporal cohesion (elements are usually bound through logic (2) and are executed at one time. 6. Strength of coupling depends on interface complexity. initialization module). information hiding and abstraction. 1. each process corresponds to a problem entity). i. Cohesion may be represented in various levels ranging from low measure to high measure. Coincidental cohesion (no apparent relationship among module elements). weakest cohesion (1) is least desirable. Strongest cohesion is most desirable (7).e. 3. The functional independence is very important since software with effective modularity (i. type of connections and communication between modules. It is an extension of information hiding concept. e. requiring little interaction with procedures that are performed in other parts of a program. . Independence is measured using two qualitative criteria namely. model structure bears close resemblance to the problem structure or procedure).3 Coupling Coupling is a measure of the relative interdependence among modules. e. objects). Sequential cohesion (output of one element is input to the next. Information cohesion (complex data structure with all its functions/operators.5. 7. In software design. Communication cohesion (all elements are executed at one time and also refer to the same data. concrete realization of data abstraction. 5.System Design or modules form a network of communicating processes.36 Chapter 3 .g.5.5. cohesion and coupling 3. 3. Logical cohesion (some inter-element relationships exist. 2.
C. Data objects and resultant data structures B. 3. Stamp coupling (selective sharing of global data items). System objectives Major software requirements Design constraints. global data 3. Data coupling (parameter lists are used to pass/protect data items). 5. Control coupling (control flag etc. Shown below are the different types of module coupling. Design specification outline I Scope A. External file structure a.BSIT 44 Software Engineering 37 we look for the lowest possible coupling. 1. Simple connectivity among modules results in software that is easier to understand and less prone to error propagation in the system.6 DESIGN DOCUMENTATION The document shown below can be used as a template for a design specification. logical record description c. Content coupling (cross modification of local data by other modules). logical structure b. the weakest (5) is most desirable. 2. access method 2. 4. limitations II Data design A. 3. B. Common coupling (global data cross coupling). file and data cross reference . File and database structures 1. The strongest (1) is least desirable. module controls sequencing of processing in another module).
Review of data and control flow B. 3. Derived program structure Chapter 3 . Interfaces to external systems or devices D. Interfaces to external data 2. D. Processing narratives Interface description Design language description Modules used Internal data structures Comments/restrictions/limitations VI Requirements Cross-reference VII Test provisions 1. Internal interface design rules V Procedural design For each module: A.System Design IV Interface design A. Human-machine interface specification Human-machine interface design rules External interface design 1. C.38 III Architectural design A. B. Test guidelines Integration strategy Special considerations VIII Special notes . C. F. 2. B. E.
emphasizing on the human-machine interface specifications and design rules. major software functions. each module is described with an English language processing narrative. Along with it. internal data structures and a cross reference that connects data objects to specific files. Procedural (detailed) design uses the products of the data and architectural design phases to describe the processing details of the system — module internals. Section VIII and IX is on notes and appendices. Section V is about procedural design. Architectural (preliminary) design defines the components. It defines the fundamentals which software design should adhere to. . and processing alternatives of the system’s data. and a historic perspective on design. Section VII is about the Verification which includes testing guidelines. Here. design’s role as a representational model. of the system and the relationships that exist between them. indicating how the program architecture has been derived from analysis model. integration strategy.BSIT 44 Software Engineering 39 IX Appendices Section I gives the overall scope (overview of system objective. special considerations ( physical constraints. interfaces. high-speed constraints. Design Fundamentals Three distinctive aspects of an information system are addressed during the software design. Section III gives the architectural design. This section covers the nature of software design in more detail. associativity. access methods. the interface description. comments associated with each and every modules is described. memory management ). 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. 3. external data bases. Much of the information is derived from the SRS. Section II gives the data design. major constraints) of the design effort. describing the external file structures. Data design is involved with the organization. Section IV describe the interface design. Section VI contains a requirements cross-reference. internal data structures.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.
relationships. 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.7. However. Following are some of the principles that need to be followed for data design approach: 1. the choice of the data structure depends on the attributes of the data objects. 4. In other words. data flows. 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. 3. 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. Data structures can be designed for reusability. 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. Low-level data design decisions should be deferred until late in the design process – the overall data organization may be defined during requirements analysis. 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. 2. it translates the data objects defined in the analysis model into data structures that reside with in the software. . refined during preliminary design and specified in detail during the later design process. the relationship between these data objects and their use with in the program.40 Chapter 3 . also alternative data organizations should be considered in a similar way that we derive. 3. And a set of data structure templates help to reduce both the specification and design effort for data. The systematic analysis principles applied to function and behavior should also be applied to data – representations of data objects.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. review and specify the functional requirements and preliminary design. 5. 6.
So. (2) flow boundaries are indicated. A data flow diagram is mapped into program structure using one of the following mapping approaches – transform mapping and/or transaction mapping. This method uses information flow (represented as a data flow diagram) characteristics to derive the program structure. (4) control hierarchy is defined by factoring.7. are examples external world information .2 Architectural Design The main objective of architectural design model is to develop a modular structure and represent the control relationships between modules. The transition from information flow to program structure is accomplished as a five step process: (1) the type of information flow is established. 3.. information shown on a computer display etc. Transform flow In the fundamental system model (context level DFD). information must enter and exit software in an “external world” form. (3) the DFD is mapped in to program structure. 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. and reduced procedural complexity. The data entered through a keyboard.BSIT 44 Software Engineering 41 7. (5) the resultant structure is refined using design measures and heuristics. a well designed data can lead to better program structure and modularity.
3. the flow along one of many action paths is initiated. This is shown in figure 3. The transition form external to internal data form occurs at the kernel of the software. When a segment of a DFD shows these characteristics we say transform flow is present. The incoming data moves through the transform center and from this it moves out of the software through the paths called outgoing flow.2 Representation of flow of information The external data that enters the system must be converted in to an internal form for processing. A transaction triggers other data flow along one of many paths as shown in figure 3. The information that enters the system along the paths that transform external data into an internal form is known as incoming flow. When the external information enters the transaction center. . The center of information flow from where many actions paths start is called a transaction center.System Design External data representation Incoming flow Transform flow Outgoing flow Information Internal data representation Time Figure 3. the transaction is evaluated and based on its value.42 Chapter 3 . Transaction flow The information flow in a system is characterized by a single data item called a transaction.2. The transaction flow is characterized by data moving along an incoming path that converts external world information into a transaction. the over all flow of data occurs in a sequential manner.
In general. Review the fundamental system model – context level or 0 level DFD.7. and output along three separately factored module hierarchies.BSIT 44 Software Engineering 43 Transaction T Action paths Transaction center Figure 3. 3.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. processing. 2. The DFD is mapped into a structure that allocates control to input. 1. Determine whether the DFD has transaction or transform flow characteristics – depending on the nature of the DFD. However. . information flow within a system can always be represented as a transform flow. This type of mapping is applied to an information flow that exhibits distinct boundaries between incoming and outgoing data. Let us list out the design steps for performing the transform mapping.3 Transaction flow 3. the type of information flow can be found out. 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. when a transaction characteristic is encountered it can be represented as a transaction flow.2.
44 4.2. The internal and external design are guided by the information obtained from analysis phase. Another substructure controls all potential processing actions based on a transaction. and outgoing is the vice-versa.e. Refine the first iteration architecture using design heuristics for improved software quality 3. Identify the transaction center and flow characteristics along each action path 5. It encompasses internal and external program interfaces and design of the user interfaces.7. non-human producers and consumers of information) (3) the design of the interface between the user and the computer. Review and refine data flow diagrams for the software 3. 3. Transaction Mapping Transaction mapping is applied when a single information item causes flow to branch along one of many paths. Determine whether the DFD has transform or transaction characteristics 4.2. Review fundamental system model 2. Perform the “first level factoring” . (2) the design of interfaces between the software and other external entities ( i. The design steps for transaction mapping include: 1.7. 6. 7. . Perform the “second level factoring” Refine the first iteration program structure using design heuristics for improved software quality 5.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. Factor and refine the transaction structure and the structure of each action path 7. The DFD is mapped into a structure that allocates control to a substructure that acquires and evaluates a transaction.Factoring is the process of decomposing a module into main and subordinate modules. Map the DFD to a program structure amenable to transaction processing 6.3 Interface Design The interface design focuses on three important areas: (1) the design of interfaces between software modules. Chapter 3 .
System response time This is an important issue that need to be addressed. 4. This design must support data validation and error handling algorithms with in a module. External design interface The external design interface evaluates each of the external entity represented in the DFD of the analysis phase. System perception model or user’s model . 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. User model . The data and control requirements of these external entities are determined before going in for this design. 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.the software engineer creates this model. System image model .this depicts an image of the system that is carried by the end users. 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 . Here again. 2. This model depicts the profile of end user of a system. This model incorporates data.this model combines the look and feel of the computer based system with the supporting information available. Design model . User interface design The user interface design process begins with task analysis and modeling.BSIT 44 Software Engineering 45 Internal Design interface The internal design interface.the software engineer establishes this model. knowledgeable. 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. So. Design issues There are four design issues that need to be addressed while designing an interface. There are four Interface design models that provides a human-computer interface (HCI). frequent user. An end user can be a novice. 3. 1. Architectural and procedural description of the software. that a check is made to ensure that data conform to the boundaries set during the requirements analysis phase. which describes the system syntax and semantics. the design must support data validation and error handling algorithms with in a module.
error handling is an important design issue that need to be addressed. since it enables any user to solve a problem without leaving the interface. computer-based system. a typed key or function keys or control sequence such as ^P . User help facilities Help facilities are very essential for any user interactive. Error information handling Error messages or warning messages are produced by interactive system when ever something wrong has occurred. 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.46 Chapter 3 . The system response time depends on two factors : length of the response time and variability. Add-on help facility – this facility is added to the software after system has been built. ^D) Can commands be customized ? etc. In order to have a better quality software. Integrated help facility – is designed to into the software from the beginning. It provides a very quick help for the user. still many users are after the command-oriented interaction. Now-a days. point and pick interfaces. It is an online user’s manual with limited query capabilities. and it is often context sensitive. even though users are after window-oriented. constructive ideas so as to encourage the user to recover from the error the message. Usually. . care must be taken to reduce the likely hood of mistakes. And on-line help is the most thought of. So . So. there are two types of help facilities: integrated help facility and add-on help facility. should carry audio or visual clues the message wordings should never blame the user Command labeling Earlier.e. the deviation from average response time. 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.System Design action is given out by the software. 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.
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
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.
188.8.131.52 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.
184.108.40.206 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
F T Case condition F T Case part
It is also known as N-S charts or Nassi-Shneiderman charts. The graphical representation of structural constructs are shown in figure 3. The fundamental element of this tool is a box.6. .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.
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 .52 Chapter 3 .
It has a list of conditions and actions.BSIT 44 Software Engineering 53 Selection: Case condition Value Value Value Case Part Case part Figure 3. 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.6 3.7. The organization of a decision table is given below: Example: A limited-entry decision table (2N entries. N is the number of conditions) . among them decision table is the popular one. The actions are based on the combinations of conditions.4. 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.
where a string variable is converted in to an integer. structured programming language). Let us consider an example of PDL. A PDL is principally applied during the detailed design phase and it is best used to describe algorithms and specify interfaces between modules.54 Chapter 3 . PDLs impose a language syntax upon their users that makes it possible to use automated tools for validity checking.g. also called pseudocode.4. English) and the overall syntax of another (i.4 Program Design Language Program design languages (PDLs). repetition construct and I/O constructs.7. They express the logic of a program in narrative form (in English).e. Example Function parameter is string containing value to be converted into an integer (single characters are enclosed in single quotation marks. or structured English. A basic PDL syntax should include constructs for subprogram definition. condition construct. and data declaration.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. ‘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 . PDLs were first proposed as a replacement for flowcharts.e. is a pidgin language which uses vocabulary of one language (i. interface description. e.
change sign Return summed value to caller EndFunction .BSIT 44 Software Engineering 55 Initialise variables(return value. 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 .
In object-oriented design. The three important levels of abstraction are procedural abstraction. Why is design an important phase in software development life cycle ? Explain II b) Answer the following questions in detail 2. levels of abstraction. 3. you should keep in mind several important characteristics such as modularity. We have also seen that software design process involves four distinct but interrelated activities. ——————— 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. architectural design. data abstraction and ————————The functional Independence is measured using two qualitative criteria namely. 4. prototyping etc. What are the software design principle suggested by Davil? explain 3. ———————— and repetition. cohesion. What is abstractions? explain the levele of abstraction.9 SELF CHECK EXERCISE I Fill in the blanks : 1. 2. When you build a system. 3.. we will see how to translate the design into implementation. 4. . the modules in the design represent ————— 2.8 SUMMARY Chapter 3 . data design. Explain the model of architectural design.System Design In this chapter. 3. we have looked at what it means to design a system. and you should be able to come out with a design document at the end of a design process. In the next chapter. PDL stands for ——————————— II a) Answer the following questions in one or two Sentences : 1. coupling.56 3. The constructs fundamental to structured programming are sequence. 1. interface design and procedural design. 8.
15. 7. 13. 8. 9. 3. 7. 16. An Integrated approach to Software Engineering (second edition). Addison-Wesley publications. 1996. 2.5 . 4.10 REFERENCES 1. transform mapping condition program design language 3. 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. 11. data abstraction. 6. Narosa publishing house Ian Sommerville. 14. 10. Pankaj Jalote. ed. Software engineering. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997.BSIT 44 Software Engineering 57 5. control abstraction cohesion data coupling transaction mapping. 12. 5.e. 3. 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. 2. Roger S. 6. 8.
we were able to understood the user’s problem. we must focus on implementing the solution as software. several types of jobs are required to be performed by the team. That is. In-order to generate a quality product. there are many ways to implement a design.1 OBJECTIVES In this chapter. we must write the programs that implement the design.2 CODING STANDARDS AND PRACTICES Most of the software is developed by a team of people. it explains some of the software engineering practices that you need to follow when you write the code. this chapter does not teach you how to program rather. 4. Even though.Software Coding .Chapter 4 Software Coding 4. and many languages and tools that are available.Internal and external documentation Understand the use of programming tools 4. we will look at Standards of programming Guidelines for programming Appreciate the importance of documentation with respect to programming Types of documentation . in the form of requirements and the way of addressing them in the form of design to get a high-level solution. Even when writing the code. many people 58 Chapter 4 .0 INTRODUCTION S o far. Now.
test and modify. it is important that the program structure should reflect the design’s control structure. but also why you have written it and how it fits in their work.BSIT 44 Software Engineering 59 are generally involved. control depends on the structure of the code it self. 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. 4. We will see them in more detail here. Thus. so that the code is simple. In procedural designs. such as implicit invocation and object-oriented design. However. No matter what language is used. 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 .3 PROGRAMMING GUIDELINES The primary goal of coding phase is to translate the given design into source code in a given programming language. For these reasons. The design or requirements specification may suggest a programming language for use. easy to understand. control is based on the system states and changes in variables. Standards and procedures can help you to organize your thoughts and avoid mistakes. Good programming is a practice independent of target programming language. Some procedures involve methods of documenting your code so it is clear and easy to follow. one must know the organization’s standards and procedures before beginning to write code. irrespective of the design type. In case of some architecture. it is possible to maintain the correspondence between design components and code components. it is a skill that can only be acquired by practice. And the given design is translated in to code. algorithms and data structures. each program component involves at least three important aspects: control structures. Good programming involves a great deal of creativity. and a great level of cooperation and coordination is required. Control structures Many of the control structures for a program component are given by the architecture and design of a system. Translate designs to code. By structuring code according to standards. it is very important for others to understand not only what you have written.
elseif ( age < 75) Benefit = minimum * 1.60 Chapter 4 . B: if (age < 55) Goto C. so that it helps in better understanding Consider an example. If (age < 75) Goto A.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. A: if (age < 65) Goto B. C: Next statement. Benefit = maximum. Algorithms The program design often specifies a class of algorithms to be used in coding.5 + Bonus . the design may tell the programmer to use binary search technique. For example. Goto C. Even though. here the control skips around among the program’s statements. a programmer has lot of flexibility . The same piece of program can be restructured for better understanding : if (age < 55) Benefit = minimum. Benefit = Benefit * 1. making it difficult to follow: Benefit = minimum.5 + Bonus. elseif (age < 65) Benefit = minimum + Bonus. If (age < 65) Goto B. else Benefit = maximum. Benefit = Benefit * 1.5 . Goto C. If (age < 55) Goto C.
General guidelines There are several strategies that are useful in preserving the design quality of a program. For example. By adopting constructs and data representations without becoming involved immediately in the specifics of each command. data structures can influence the organization and flow of a program. There are two kinds of program documentation : Internal documentation External documentation . The program’s design may specify some of the data structures that can be used in implementing functions. LISP is a language for list processing. Data structures In writing programs. one should format and store data in such a manner that the data management and manipulations are straight forward. 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 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. Therefore. 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. 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. the program sections performing input and output functions are sometimes difficult to test. In general. one can experiment and decide which implementation is most desirable. Because of this dependency.4 DOCUMENTATION Documentation is an important activity in the implementation phase. In some cases. In this way.BSIT 44 Software Engineering 61 in converting the algorithm to code. the data structure must be very carefully considered while deciding the language for implementation. In general. it can even influence the choice of programming language.
algorithms and controls Program comments Comments in a program are textual statements that are meant for program readers and are not executed. helping them to understand how the intentions described in the header are implemented in the code. Although code clarity and structure minimize the need for other comments. The information contains a description of data structures. The header comment block acts as an introduction to the program. It is very important that the comments need to be updated to reflect changes whenever the code is revised. Comments. Comments enlighten the readers as they move through the programs. it is considered as a good style of programming. this information is placed at the beginning of each component in a set of comments called the header comment block. Usually. if any Global variables accessed and/or modified in the module Comments have a place even in clearly structured and well-written code. It is bad practice to choose cryptic . can be invaluable during maintenance. at a level appropriate for a programmer. Since. algorithms and control flow. 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. additional comments are useful whenever helpful information can be added to a component. Providing comments for modules in a program are very useful.62 Chapter 4 . It is desirable that prologue contains the following information : Module functionality Parameters and their purpose Assumptions about the inputs. if properly written and kept consistent with the code. 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.Software Coding Internal documentation Internal documentation is a descriptive material written directly with in the program. And the comments for a module are often called prologue for the module. It contains information directed at some one who will be reading the source code of the program.
else result = 1. that code can easily be read and understood. elseif (slope1 < slope2) result = 3.BSIT 44 Software Engineering 63 names or totally unrelated names. result = 4. the same code can be formatted for clarity by using proper indentation and spacing : if ( xcoord < ycoord) result = -1. . elseif ( xcoord == ycoord ) if (slope1 > slope2) result = 0. 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.0 Makes more sense to the reader than writing the statement C = ( A * B * C) / 100.0 Proper formatting enhances easier understanding When the code is properly formatted. else result = 1. elseif ( xcoord == ycoord) if ( slope1 > slope2) result = 0. Simple_Interest = (Principle * Time * Rate) / 100. elseif ( slope1 > slope2) result = 2. Writing.
External documentation It is a part of overall system documentation. interfaces etc. The nature and number of user documents usually vary across applications and organizations. documentation assumes a very important role. its complexity. boundary conditions etc.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. Based on the following factors. result = 3. a data map is very essential to document data. It explains each algorithm used by the component. when the component is invoked and why it is needed. 4.64 elseif (slope1 > slope2) result = 2. Data description This describes the flow of data at the component level. It is intended to be read by those people who may never look at the actual code. including formulae. Because. The external code documentation contains the following description : Problem description It explains what problem is being addressed by the component. once when the existence of the component is clear. it is in this phase that the skills need to be passed from the development team to the users. And the users have to be extensively trained for it. proper communication in the form of user document becomes very essential. So. So. It explains things more broadly then that of program’s comments. Algorithm description Addresses the choice of the algorithms. it is possible to decide on the type of user documents: The nature of software. elseif (slope1 < slope2) else result = 4. along with flags and passed parameters. Chapter 4 . Usually. it is very difficult for program readers to understand the way in which data is structured and used.5 USER DOCUMENTATION In the implementation phase.
3. 5. 4. Scope Prerequisites for usage Preparatory instructions Cautions and warnings Description of each task giving . 5. reference mode or both Generally. the documentation set could consists of installation 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. user manual. whether it has to be an instructional mode. However. 7. 2. depending on the nature of usage. Any user document would generally consists of the following components: 1. 12. 10. 11. error message manual etc. operations manual. 3. The body of the document gives the main contents of the document. how to use it. 4. procedure manual. conventions followed etc. 9. 6. 2. 8.BSIT 44 Software Engineering 65 User groups. the main idea here is to ensure that the users have complete documentation on how to install. This generally include: 1. use and manage the software. their exposure and training levels of users Volume of information presented Document usage mode. information on other related documents.
code generators and macro-preprocessors. Code creation has four major tools which help the developer in converting the source code into executable code : Linker. . such as organizational standards and guidelines to be followed. code libraries. these relate to the editing of source code browsing tools. It helps in code creation. We were able to see the importance of programming tools.6 PROGRAMMING TOOLS Today. helps to view the source code The source-code beautifiers and templates not only makes a program look consistent but also standardize indentation styles. we have looked at the several guidelines for implementing programs. Debugging tools help in debugging the code. Source-code tools There are two commonly used source-code tools editing tools. we will discuss the way of testing the code and how to make the software a quality software. Let us see some of the popular one. debugging and testing.66 6. It is necessary that certain points need to be considered while writing the programs by the programmer. and also address some of the important issues in implementing the design to produce high quality software.Software Coding Information on associated tasks and limitations 4. incorporation of systemwide error-handling strategy and proper program documentation.7 SUMMARY In this chapter. align variable declarations and format comments. concept of code re-usability. Testing tools help in tracing the code errors. In the subsequent chapters. What user is expected to do What function is to be invoked Possible errors and how to avoid them Expected results Chapter 4 . 4. there are tools available that help to reduce the amount of time spent on the development of programs. Executable code tools Tools that are required for working with executable codes.
BSIT 44 Software Engineering
4.8 SELF CHECK EXERCISE
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
68 4.9 REFERENCES
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
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
In both of these cases. Where software differs is in the manner in which it fails.Software Testing Discuss unit testing. It is commonplace to attempt to test as many of the syntactic features of the code as possible. The problem of applying software testing to reliability estimation is that the input distribution used for selecting test cases may be flawed.70 Give the importance of different testing strategies Chapter 5 . and exercise the input and output domains of the program to uncover errors in program function. By contrast.2 FUNDAMENTALS OF SOFTWARE TESTING Software testing is the process of testing the functionality and correctness of software by running it. not their absence (unless the testing is exhaustive). If any of these parts is faulty. The key to software testing is trying to find the modes of failure — something that requires exhaustively testing the code on all possible inputs. Most physical systems fail in a fixed (and reasonably small) set of ways.but how? That’s where software testing techniques enter the picture. software must be tested to uncover (and correct) as many errors as possible before delivery to the customer. The problem of applying software testing to defect detection is that software can only suggest the presence of flaws. These techniques provide systematic guidance for designing tests that: (1) (2) exercise the internal logic of software components. behavior. Software testing is usually performed for one of two reasons: (1) defect detection. the entire process is compromised. software can fail in many different ways. this is computationally infeasible. The goal is to design a series of test cases that have a high likelihood of finding errors . Software is not unlike other physical processes where inputs are received and outputs are produced. and performance. as an important metrics for testing software 5. the mechanism used to determine whether program output is correct (known as an oracle) is often impossible to develop. integration testing. For most programs. . and (2) reliability estimation. Once source code has been generated. Techniques that try to exercise as much of the code as possible are called white-box software testing techniques. Techniques that do not consider the code’s structure when test cases are selected are called black-box techniques. Obviously the benefit of the entire software testing process is highly dependent on many different pieces. validation testing and system testing and their importance Come out with a test plan Describe reliability. Detecting all of the different failure modes for software is generally infeasible.
2. from module level testing towards entire system 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”. so that testing will be very effective 5. 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.BSIT 44 Software Engineering 71 Testing objectives The following statements serve as the objectives for testing : 1. Test Case Design Any engineered software product can be tested in two ways: . design and coding phase.3 SOFTWARE TESTING TECHNIQUES It is an important element of Software Quality Assurance activity and it is the ultimate review of specification. 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 cannot show the absence of defects it can only show the presence of errors. 3. Exhaustive testing is not possible The tests should be conducted by an independent third party. Testing principles Here are some basic principles that are applicable to software testing.
. Knowing the specified function that the product has been designed to perform. Using this method the software engineer derive the test cases that : 1. . . .1 White . . 3. 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. Knowing the internal working of product. 2. 2. Guarantee that. 2. tests can be conducted to demonstrate that each function is fully operational Examples: Boundary value analysis.Box Method White-box method is also known as glass-box testing. Example : Basis path testing 5. . for i = 1 to 10 boundaries 4. Use of decisions which are based on true and false value or user decisions based on true and false values. Equivalence partitioning method White Box Testing : It is also known as structural testing.72 1.Software Testing Black Box Testing : It is also known as functional testing. White-Box Testing Black-Box Testing Chapter 5 . It is a test case design method or this testing method is used for designing test cases. 4.3. test can be conducted to ensure that all internal operations perform according to specification that all internal components have been adequately used. Execute all the loops at their boundaries and within their internal bound i. 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 .e. 3.9 Internal bound Use internal data structure to assure then validity.
Figure 5. we will consider the procedural design representation and it is represented as a flow chart. Each circle.3 maps the flowchart into a corresponding flow graph. . a flow chart is used to depict program control structure. as shown in Figure 5.1 - Uses flow graphs for representing the control flow or logical flow.BSIT 44 Software Engineering 73 Sequence if while Figure 5. Here. Areas bounded by nodes and edges are called regions. represent flow of control. as shown in figure 5.1 To illustrates the use of flow graph. called edges or links. A sequence of procedure boxes and decision box can map into a single node. called a flow graph node. represents one or more procedural statements. The arrow on the flow graph.2.
it give a number called cyclomatic number.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.Software Testing 1 2 3 6 4 5 7 9 10 8 Figure 5. . that provides a quantitative measure of logical complexity of a program When used in basis path method.74 Chapter 5 .2 Flow Chart Cyclomatic complexity is a software measure. Cyclomatic Number = E .
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 .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. Path 1 : 1.5 Nodes 7 8 9 Region 10 11 Edge Figure 5.3 6 4.
there are 4 regions) V(G) = E . This is performed is later stages of testing.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 . 5. The engineer can derive sets of input conditions that satisfy all the functional requirements of a program. 2. 4. It purposely discards control structures and focuses on information domain. Example: 1.N + 2 where E = flow graph edge. 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. .76 Here. 2. Cyclomatric complexity (CC) can be computed in 3 ways: 1. It finds different class of errors. 3. and N = number of nodes. 3. It focuses on the functional requirements of the software.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 .3. 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. 3. 2. like : 1.2 Block Box Testing Black. 5.box testing is also known as behavioral testing or partition testing. CC = 4 (because. paths 1-2-3 and 4 form the basis set for the flow graph.
Once nodes have been identified. links that represents relationship between objects.BSIT 44 Software Engineering 77 Object #1 Directed link Object #2 Undirected link Object #3 Parallel links Figure 5.Based testing method is used by Transaction flow modeling Data flow modeling Finite state modeling. Test case design for equivalent partitioning is based on the evaluation of equivalence classes for input condition. . Each relationship is studied separately like transitive relation. Equivalence class equivalence class of objects are present if the set of objects have relationships like transitive.4. a software engineer begins by creating a graph . A test case will handle each class of data and produce different classes of errors. the symbolic representation of a graph is shown in figure 5. links. The Input domain of a program is taken and it is divided into classes of data from which test cases can be derived.4 Graph notation In order to accomplish these steps. node weights that describe the properties of node and link weights that describe some characteristics of a link. reflexive relation. Timing modeling etc. link weights should be established. Graph . symmetric relation. Equivalence partitioning It is a block box testing method.a collection of nodes that represents objects. reflexive and symmetric.
may or may not be present Input condition. Input condition range . Input conditions for each data element : Area code : Input condition. etc.values defined between 100 & 999. and Boolean conditions.78 - Chapter 5 .specified values > 200 with no 0 digits.4 digit length Password : Input condition. a set of related values. set .Software Testing represents a set of valid or invalid states for input conditions. Input conditions being: specific numeric value. range .6 character string Command : Input condition. a range of values. value .area code may or may not be present. Suffix : Input condition. value .containing commands as said above. Prefix : Input condition. “deposit “. 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”. Boolean . . Boolean .
just above and just below a & b respectively use maximum and minimum numbers. a strategic approach can be used to provide templates for software testing.BSIT 44 Software Engineering 79 Next equivalence classes are derived using guidelines for input conditions.1 5. A strategic approach to software testing Testing is a set of activities that can be planned in advance and conducted systematically. A range of values (say bounded between a & b) A numeric value Test Case designed is designed with values a & b. So. For this reason a template. boundary testing is followed. Internal data structures Note: guidelines 1 and 2 are applicable to output conditions also. the test cases are selected at the “edges” of the class. It is a complement of equivalence partitioning method. a set of steps into which specific test case design methods can be fitted. 3. 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 . values that are just above and just below maximum and minimum. quality assurance team and the customer. is required.1 Guide lines for BVA: Input Conditions defined 1. Boundary Value Analysis (BVA) It is a testing technique meant for testing the boundaries of the input domain for errors. BVA derives the test cases from the output domain. 2. Here. Table 5. The guide lines for BVA is shown in table 5. It provides a roadmap for the software developer.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. It is a test case design technique. for which text cases are developed and executed.
Software Engineering process may be viewed as a spiral. .1 Unit Testing Concentrates on functional verification of a module Using procedural design description as a guide.4.80 Chapter 5 . but debugging must be accommodated in any testing strategy Verification & validation ( V & V) V & V are Software Quality Assurance activities.a set of activities that ensures that the software that has been built. is traceable to the customer requirements.is a set of activities that ensures that the software correctly implements a specified function. Verification . Validation . with the following types of testing: Unit testing Integration testing Validation test System test 5.Software Testing Testing is conducted by the developer of the software and an independent test group Testing and debugging are different activities. important control paths are tested to find out the errors within the boundary of the module. with the following activities: System engineering. Requirements analysis Design Coding A strategy for software testing may also be viewed as a spiral. It is white-box oriented The functional verification can be done in parallel for multiple modules.
all error handling paths are tested. 5. the maxima and minima.comparison of different data types. Boundary values just above. 4. improper loop termination etc. driver and / or stub software must be developed for each unit test. at. 3. A module in unit test is not a standalone program. The local data structure is examined to ensure that data stored temporarily maintains its integrands during all steps in an algorithm’s execution. reviewed. Unit testing is normally associated with the coding step i. below. Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing. But these two software are overhead. 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. etc. So. Each test case is coupled with a set of expected results. Test cases are so designed to uncover errors due to: erroneous computations . So.e. . mixed mode operations. 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.BSIT 44 Software Engineering 81 Steps involved in unit testing are : 1. incorrect logical operations or precedence. Incorrect comparisons or improper control flow . after the source code has been developed. (i. they are developed but not delivered with the final software product) figure 5.e.Incorrect arithmetic precedence. verified only then the test case design begins. Interface 2.5 shows a unit testing environment.
A stub is a “dummy sub program”. a driver is a software or “main program” that accepts test case data. that replaces the modules that are subordinate to the module to be tested. 5.2 Intergration Testing It is a systematic technique for constructing the program structure while constructing tests to find errors associated with interfacing. Unit testing is advantages when a module to be tested defines only one function. prints verification of entry and returns. A module with high cohesion simplifies unit. The objective is to take modules which are unit tested. and build a program structure that has been dictated by design. passes it to the module to be tested and prints the relevant results. It does minimal data manipulation. and that the number of test cases are reduced which in turn makes error handling easier.4. There are two categories of Integrated testing : .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.5 Unit testing environment In most applications.82 Chapter 5 .
Depth-First Integration: this would integrate all modules on a major control path of the structure. and m5 would be integrated first. All modules are combined in advance. Incremental Integration : The program is constructed and tested in small segments where errors are easier to isolate and correct. the major control path can be arbitrarily selected and it depends an application specific characteristics. Interfaces are more likely to be tested completely and a systematic test approach is applied. Incremental Integration strategies: 1.6. And the entire program is tested as a whole. Then central and right hand control paths are built. Errors are more and difficult to isolate and correct. 3. 2. Top Down Integration: Is an incremental approach to the construction of program structures Modules are integrated by moving down ward through the control hierarchy. Example: Selecting left hand path. 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. Top-down Integration 2. Non-incremental integration: It uses a “Big bang” approach to construct the program.BSIT 44 Software Engineering 83 1. m2. m1 m2 m3 m4 m5 m6 m7 m8 Figure 5. The depth-first integration is shown in figure 5. next either m8 or M6 would be integrated. However. modules m1.6 Depth-first integration . Bottom-up integration Sandwich testing 1. beginning with the main control module (main program).
Regression testing may be conducted to ensure that new errors have not been introduced. Top-down Integration is performed with the following steps: 1. 3. This approach verifies major control or decision points early in the test process. Integrate the software from the bottom of the hierarchy upward – bottom-up testing. Bottom-up Integration : The modules at the lowest levels in the program structure are constructed and tested.7 .workable but leads to significant overhead as stubs become more and more complex. 3. The main control module is used as a test driver. From figure 5. Though this approach sounds relatively simpler. The process continues from step 2 until the entire program structure is built. next control level. 4. A test driver is a main control module. m3 and m4 are integrated first. Stub is a module directly subordinate to main control module. but in practice has several logistical problems. Depending on the Integration approach (either depth-first or breadth-first) subordinate stubs are replaced one at a time with actual modules. and stubs are substituted for all modules directly subordinate to the main control module. On completion of each set of tests.84 Chapter 5 . m5. Here need for stub is eliminated.Software Testing Breadth First Integration : Incorporates all modules directly subordinate at each level. 2.this leads to the difficulty in determining the cause of errors and tends to violate the highly constrained nature of the top down approach.overhead 2. moving across the structure horizontally. Figure 5. m6 and so on. Stubs replace the low level modules at the beginning of top-down testing therefore no significant data can flow upward in the program structure. Tests are conducted as each module is integrated.6 . Advantages : Testing of major control functions early. 2. Delay many tests until stubs are replaced with actual modules . modules m2. another stub is replaced with the real module. The tester is left with 3 choices: 1. 5. Disadvantages: Need for stubs . Develop stubs that perform limited functions that simulate the actual module . The most common of these problems occurs when processing at low levels in the hierarchy is required to adequately test upper levels.
modules are combined to form clusters 1. Similarly. According to figure 5.2 & 3.BSIT 44 Software Engineering 85 Steps required for implementing bottom-up integration strategy : 1. Modules in clusters 1 and 2 are subordinates to ma. 2 are interfaced directly to ma. 3. Now. Then ultimately modules ma & mb are integrated with module mc. 2. Driver D1. Drivers are removed and clusters are combined moving upward in the program structure. driver D3 of cluster 3 is removed and then cluster 3 is integrated to module mb. The cluster is tested. A driver (a control program for testing) is written to co-ordinate test case input and output. Each cluster is tested using a driver (dashed box).7 Bottom-up integration . D2 are removed and the cluster 1. 4.7. mc ma mb D1 D2 Driver D3 Cluster 3 Cluster 1 Cluster 2 Figure 5. Low level modules are combined into clusters (sometimes called builds) that perform a specific software sub function.
Software Testing Advantages: This method is very simple.3 Validation Testing Focuses on requirements Here validation criteria stated in requirements are tested.4. Tests that focus on the software components that have been changed. a combined approach called as sandwich testing is used that takes characteristics of both approaches. This testing may be conducted manually. Regression Testing: Is an activity that helps to ensure that changes that often take place.new data paths are established. selection of an integration strategy depends upon software characteristics and sometimes project schedule. Disadvantages : Program as an entity does not exist until the last module is added. 2) 3) Additional tests that focus on software functions. 5. It uses a top-down strategy for upper levels of the program structure. In general. 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. Sandwich testing : A best compromise between two methods. So. behavioral and performance requirements . This gives a final assurance that the software meets the functional. coupled with a bottom-up strategy for subordinate levels. do not introduce additional errors. 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. that are likely to be affected by the change.86 Chapter 5 . - The regression test suite contains three different classes of test cases: 1) A representative sample of tests that will exercise all software functions. 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 .
Customer records all the problems (real or imagined) that are encountered and reports to the developer at regular intervals. It is a ‘live” application of the software in an environment. are catalogued and detailed to support the maintenance phase of software life cycle. they are not in the controlled environment. Configuration Review: It is also termed as audit It is an input element of the validation process. So. 5. alpha tests are conducted in a controlled environment. After each validation test case has been conducted.. So.. database etc. Validation test criteria is based on test plan and test procedure. Usually the developer keeps track of working of the software. It is actually a series of different tests whose main purpose is to fully exercise the computer based system. records errors etc. A deviation from specifications is uncovered and a deficiency list is created. one of the two possible conditions exists: 1. The software developer is generally not present. The Alpha Test : is conducted at the developer’s site by a customer. Beta Test: is conducted at one or more customer sites by the end user(s) of the software. 2. information. .BSIT 44 Software Engineering 87 - Black box testing is exclusively used.4 System Testing This testing verifies that the system performs well with other system elements like hardware. This is done to ensure that all elements of the software configuration have been properly developed. And a test procedure defines specific test cases that will be used to find errors. 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. Alpha and Beta Testing: Are tests conducted to find out errors at the customer side. A test plan outlines the classes of tests to be conducted.4. The function or performance characteristics conform to specification and are accepted.
a process that results in the removal of errors occur. (i. re-initialization. Stress Testing: It is designed to confront programs with abnormal situations. and restart are each evaluated for correctness. . the meantime to repair is evaluated to determine whether it is within acceptable limits. So.e. Recovery can be automatic or manual.88 Types of system testing: 1) Recovery Testing 2) 3) 4) Security Testing Stress Testing Performance Testing Chapter 5 . 5. data recovery. If recovery requires manual intervention. It is designed to test run -time performance of software within the context of an integrated system. When a test case uncovers an error. for illicit personal gain etc).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. for revenge.5 Debugging It occurs as a consequence of successful testing. This testing executes a system in a manner that demands resources in abnormal quantity. the system designer has to make the penetration cost greater than the value of the information to be obtained. a system failure must be corrected within a specified period of time). then debugging. check pointing mechanisms. the tester plays the role of the individual who desire to penetrate the system. frequency or volume. During this testing. A variation of stress testing is called sensitivity Testing. If automatic.4. Performance Testing : It is mainly used for testing real-time and embedded systems. It is often combined with stress testing. 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.
regression testing is done.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. beginning at the site where symptom has been found. But this testing adds on additional requirements on the testing phase. 2. Backtracking: fairly common. Brute force method : it is the most common and least efficient method. . old test cases are executed with the expectation that the same old results will be produced. We even know that. the source code is traced backward (manually) until the site of course is found. before the software product is developed. can be successfully used in small programs. 5. It is applied when all else fails.BSIT 44 Software Engineering 89 - Debugging process begins with the execution of test cases There are three debugging approaches commonly used : 1. In order to validate that a change has not affected some old functionality of the system. 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. In regression testing. 3. software typically undergoes changes even after if has been delivered.
This plan can be prepared before actual testing begins and can be done in parallel with the coding and design phases. Features to be tested Approach for testing Test deliverables Schedule Personnel allocation. And testing cannot be done all a sudden. . Code is reviewed by a team of people in a formal manner. The testing process focuses on how testing proceed for a particular project. Structural testing (White Box testing) . computational errors and Interface errors. 2. a careful planning is required and the plan has be executed properly. approach to be taken and the schedule of testing.Software Testing Testing is the costliest activity in the software development. is best for testing the entire program or system. Functional Testing (Black .Box Testing). The inputs for forming the test plan are:1. Here faults are found directly. test deliverables and the personnel responsible for different activities of testing. Code Reviews: Cost effective method of detecting errors. Project plan Requirements document System design document A test plan containing the following: Test unit specification. test case generation or test case execution. So. It is good for input errors and data handling errors. 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.6 TEST PLAN It is a general document for the entire project that defines the scope. Does not require test case planning.90 Chapter 5 . 3. 5. it has to be done efficiently.
While forming “test units”. Testing criterion for evaluating the set of test cases should be specified. For each of . These features are the ones specified in requirement or design documents like functional. a test case specification report . Test deliverables: List of test cases that were used Detailed results of testing Test summary report Test log Data about code coverage In general. 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. test summary report and test log should be supplied as deliverables. performance. Personnel allocation: Identifies the persons responsible for performing different activities.BSIT 44 Software Engineering 91 Test unit specification: An important activity of the test plan is to identify the test units. integration testing etc. Approach for testing: Specifies the overall approach to be followed in the current project.e. A test unit is a set of one or more modules together with data. it is input to look for “testability” of a unit. It specifies the levels of testing and the units that need to be tested. 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. The testing process usually begins with a test plan which is the basic document guiding the entire testing of the software. design constraints and attributes. different levels of testing are also specified like unit testing. Along with identification of test units. (i.
reliability models are used. the test cases are executed and various reports are produced for evaluating testing. See fig 5. To assess the reliability of software.8 It is given by the equation: (U) = 0 (1. Simple to understand . first the test case specification are given and renewed. the test summary report and the error report. The reliability of software depends on the faults in the software. The main outputs of the execution phase are: The test log.Software Testing the different units.7 METRICS FOR SOFTWARE TESTING The important metrics used during testing is reliability. MUSA Model (Musa’s basic execution time model) Simplest model proposed for software reliability assessment. Most widely used model This is an execution time model. Most of these reliability models are based on the data obtained during the system and acceptance testing. Failure intensity = number of failures / unit time In basic model. it is assumed that.U/V 0) . Data about time between failures observed during testing are used by these models to estimate the reliability of software. It assumes that the failure intensity decreases with time. 5. Its predictive value has generally been found good This model focuses on failure intensity while modeling reliability. the failure intensity decreases with a constant rate with the number of failures.92 Chapter 5 . then during the test case execution phase.
Failure intensity Total failures Reliability has two parameters. U is the expected number of failures by a given time t. 0 .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. V0 is the total number of failures that would occur in infinite time. . V 0 whose values are used to predict the reliability of the given software.
9 SELF CHECK EXERCISE I Fill in the blanks : 1. ———————— is mainly used for testing real-time and embedded systems. Apart from knowing the test case design approaches. 2. ———————————— is also known as functional testing. Others concepts like. We shall look into quality and its related concepts in the subsequent units. A quality product is what every one wants and appreciates. white-box and black-box testing.8 SUMMARY Chapter 5 . White-box method focuses on the program control structure where as black-box method focuses on finding errors in functional requirements. The main objective for test case design is to derive a set of tests that can find out errors in the software. 5. that provides a quantitative measure of logical complexity of a program. the art of debugging. the test plan specification. design and coding. The important metrics used during testing is —————————— . Equivalence class of objects are present if the set of objects have relationships like ——— —————.94 5. A thoroughly tested software maintains quality. 5. 7. 6. This can be achieved through the help of two test case design approaches namely. 3. ——————————— is a software measure. 4. 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. metrics related to software testing have been discussed in this unit. we also have the different strategies for software testing.Software Testing Software testing is an important phase in the software development life cycle. reflexive and symmetric.
Software testing in the real world. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. Black-Box Testing 2. test plan 6. What is integration testing? explain the categories of integration 10. Write short note on BVA 8. What are the techniques of software testing? explain 3. What is validation testing? explain 11. Explain the testing objectively & testing principal 2.10 REFERENCES 1. reliability 5. 2000.1 . 2. ed. Explain white box testing. Narosa publishing house Edward Kit. What is testing process? explain 14. Addison-Wesley publications. Define system testing. Explain the factors contained in test plan 15. An Integrated approach to Software Engineering (second edition). cyclomatic complexity 3. What is software testing ? II b) Answer the following question in detail 1. Roger S. Explain black box testing 6. Explain the strategic approached to software testing 7.BSIT 44 Software Engineering 95 IIa) Answer the following questions in one or two sentences : 1. What is debugging? explain its approaches 13. non-incremental 5. performance testing 7. What is cycloramic complexity? explain with Flowchart 5. Give explain 4. transitive 4. Explain the material for software testing I Answers for fill in the blanks 1. Pankaj Jalote. explain its types 12. Explain the steps involved unit testing 9. 3.
we shall see the major activities addressed by project management such as cost estimation. Project management includes activities such as project planning. Software Quality Assurance and Software Configuration Management. process and project describe the different types of team structuring say what project planning is discuss planning with respect to resources 96 Chapter 6 . proper management controls are very essential in controlling the developments ensuring quality. how much effort. In the subsequent units. staffing and risk management. 6. So. planning involves estimation . the large workforce has to be properly organized so that they contribute very efficiently and effectively towards the project.Chapter 6 Software Project Management 6. In order for the project to successfully get completed. estimation.an attempt to determine how much money. risk analysis.0 INTRODUCTION S oftware development is an umbrella activity with various phases involving several resources. and how much time it will take to build a specific softwarebased system or product. However. In this chapter.Software Project Management . in the context of set of resources. how many resources.1 OBJECTIVES At the end of this chapter you should be able to know the importance of managing people. we shall discuss on software configuration management. The most important resources being the man power and money. project scheduling. quality assurance. The software development is a lengthy process which may take months or even years for completion. scheduling.
3. what is the necessity of project scheduling and tracking 6. The process must be adapted to the people and the problem. who can be categorized as follows: 1. partitioned into several parts. what is risk . PROJECT AND PROCESS Effective software project management focuses on the three P’s : people. 5. who plan. 2. who interact with the software once it is released for production. organize. End users. Project managers. . an appropriate software engineering paradigm is applied. it is very important to manage them. Senior managers.2 MANAGING PEOPLE. and control the practitioners who do software work. The software process or project is usually populated with several people. and a set of work tasks is chosen to get the job done. how it is managed say.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. and allocated for work by software team. The software team Since a variety of people belonging to different categories are involved in the software development process. People The people are the backbone for software development. A common process framework is selected. who deliver the technical skills that are necessary to engineer a product. Practitioners. problem and process. 4. who specify the requirements for the software to be developed. and coordinated to achieve effective communication. who define the business issues that often have more influence on the project. the structure of the team has a direct impact on the product quality and project productivity. The people must be organized into effective teams. Customers. For an efficient and easier management. motivated to do high-quality work. and coordinated to achieve effective communication. motivate. the people must be organized into effective teams. motivated to do high-quality work. So. The problem must be communicated from the customer to the developer.
he has a backup programmer.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. and programmers the backup programmer helps the chief in making decisions and takes over the role of chief in absence of the chief programmer .98 Chapter 6 . who is responsible for all the major technical decisions of the project.1 Figure 6. He also does most of the design activities and allocates coding part to each and every member of the team under him. program librarian.1 Democratic team structure Controlled centralized it consists of a chief programmer.
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.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.2 Chief programmer Backup programmer Librarian Programmers Figure 6. A proper understanding of the problem helps to prepare quantitative estimates and thus avoids several issues .
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. project planning is very important since. cost over-runs. the problem must be communicated from the customer to the developer and partitioned or decomposed into several parts. since there are a number of process models.e. If the problem to be solved is quite complex to be considered in one piece ( i. . which can be easily managed. poor quality and high maintenance costs for software. Lack of proper planning leads to schedule slippage. in terms of developing cost and effort estimation).3 SOFTWARE PROJECT PLANNING The software management consist of activities like project planning. process decomposition begins. 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 basic goal of software planning is to look into the future. project monitoring and control. Among these activities. a complete plan showing the work tasks required for process framework activities is discussed in project scheduling activity. and project termination.100 Chapter 6 . Process Deciding about a process model is very important for a project manager.Software Project Management related to it. it has to be performed before the development work and all other management phases depends on this very much. then the problem is decomposed into a set of smaller problems. determining the scope of the problem must be established since. Once the preliminary plan is ready. Software project planning includes activities such determining the scope of the software and estimation of resources to accomplish the software development effort. So. 6. The software scope must be unambiguous and understandable at the management and the technical levels. That is. then define a preliminary plan based on the set of common process framework activities. identify the activities that need to be done to complete the project successfully. He must decide the most appropriate model for the project. and plan the schedule and resources. and then allocated for work by software team. Estimation makes use of one or both of the above approaches of decomposition.
a large cost estimation error can make a lot of difference.3. The main resources are the hardware and software tools.1 Software Scope This is the first activity in software project planning. So. People Reusable software components Hardware / Software tools Figure 6. reusable software components and people are shown in figure 6. And one such software function is to prepare the software estimates using one or more techniques such as decomposition and empirical modeling. and reliability.3. Software and People The second task of software planning is estimation of resources required to accomplish the software development effort. the foundation or base of the pyramid which provides the necessary infrastructure to support the development effort. The hardware/software tools make up the development environment. The scope of the project must be very clear and understandable.BSIT 44 Software Engineering 101 6.4 SOFTWARE PROJECT ESTIMATION In early days of computing. leading to cost overrun for the developer. applying an appropriate software cost estimation technique is very essential. But. constraints. The software scope describes function. is to conduct a preliminary meeting or interview.3 Resources 6. And. performance. The middle layer in the pyramid is the reusable software components layer. . 6. today software is the most expensive one in a computer-based system.3. the cost of the software was just a small fraction of the overall cost of a computer-based system. The functions and performance allocated to software during system engineering is assessed to establish the project scope. the people.2 Resources – Hardware. The project planner then examines the statement of the scope and extracts all the important software functions. So. The top most part of the pyramid is the main resource. It constitutes the software building blocks that can reduce the development costs and speed up the delivery. The most commonly used communication technique between the customer and the developer to derive at the scope of the problem. interfaces. any small discrepancy in estimation of software cost had relatively little impact.
As the cost of the project depends on the nature and characteristics of the project. 6. the uncertainties are reduced and more accurate cost estimates can be made. 2. and C are empirically derived constants.4. A. the accuracy of the estimate will depend on the amount of reliable information we have about the final product. The bulk of the cost of software development is due to the human resources needed. When the project is being initiated or during the feasibility study. can be written as E = A + B * (ev)C Where. The LOC and FP data are used in two ways during software project estimation: 1.102 Chapter 6 . Most cost estimates are determined in terms of person-months (PM). Like the problem based techniques. Despite the limitations. There is a great deal of uncertainty about the actual specifications of the system. 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. the process is decomposed into a relatively small number of tasks and the effort required to accomplish each task is estimated. the major functionality of the system. A typical estimation model which is derived on the data collected from the past projects.2 Empirical Estimation Models An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC or FP.Software Project Management Cost in a project is due to the requirements for software.1 Estimation Models The line of code ( LOC ) and function points ( FP ) are the two problem-based techniques. E is the effort in persons-months and ev is the estimation variable ( either in LOC or FP ) . 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. 6. Here. As we specify the system more fully and accurately. and most cost estimation procedures focus on this aspect. at any point. we have only some idea of the data the system will get and produce. the basic measures from which productivity metrics can be computed. hardware and human resources. B.4.
and the Detailed model. It was developed by Barry Boehm. Equation 1 gives a measure of the effort and equation 2 gives the development time. 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. the Intermediate model. E = number of person-month (=152 working hours). Ab . 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. Every project is considered to be developed in one of three modes: Organic Mode: The project is developed in a familiar. Bb = constants. In the COCOMO model. hardware. An embedded mode project will require a great deal of innovation. . inflexible constraints and interface requirements. The product is relatively small. and project attributes. rough order of magnitude estimates of software costs.2. and requires little innovation. Semidetached Mode: The project’s characteristics are intermediate between Organic and Embedded.BSIT 44 Software Engineering 103 6. Basic COCOMO is good for quick. personnel. COCOMO is defined in terms of three different models: the Basic model. 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. Model 1 : The Basic COCOMO model computes software development effort (and cost ) as a function of program size expressed in estimated lines of code. 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. but its accuracy is necessarily limited because of its lack of factors which have a significant influence on software costs. one of the most important factors contributing to a project’s duration and cost is the Development Mode.4. and the product is similar to previously developed products. stable environment. 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. the number of delivered lines of code for the project ( expressed in thousands ).1 The Cocomo Model The COnstructive COst MOdel (COCOMO) is the most widely used software estimation model in the world. Embedded Mode: The project is characterized by tight. E = Ab * (KLOC)Bb (person-months) ——— Equation 1 Where. early.
5 * (Effort) 0.0 * (KDSI)1.5 * (Effort)0.5 0. D = development time in chronological months E = number of person-month (=152 working hours).20 2.05 Effort = 3.4 1.6 * (KDSI)1. D = Cb * (E) Db ———————————————— Equation 2 Where.5 0. Db = constants The values of the coefficients Ab.4 * (KDSI)1.20 TDEV = 2.5 0.35 TDEV = 2.6 1.32 Semidetached: Embedded: .12 2.38 Semidetached 3.05 2.35 Embedded 3.0 1.38 TDEV = 2. Bb. Cb .12 Effort = 3.Software Project Management KLOC = thousands of lines of code or thousands of “delivered source instructions “ (DSI) or KDSI.32 Table 2 : Effort Equations for three development Modes in Basic COCOMO Model Development Mode Organic: Basic Effort equation Basic Schedule Equation Effort = 2.5 * (Effort)0.104 Chapter 6 . and the exponents Cb and Db are given in Table 1 below : Software project Ab Bb Cb Db Organic 2.
which may become significant. DSI values and Cost Drivers can be chosen for individual components. to find the plan that best suits your needs and resources.12 1. and “Use of Software Tools”. The intermediate COCOMO equation takes the form : E = Ai(LOC) Bi * EAF Where. and duration of each of the components — allowing you to experiment with different development strategies. The Effort adjustment Factor is simply the product of the Effort Multipliers corresponding to each of the cost drivers for your project.20 . Ai.0 2. or apply it at the software product component level for more accurate cost estimation in more detailed stages.05 1. cost. The Intermediate model also produces better results than the Basic model because the system can be divided into “components”.8 Bi 1. 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. E is the effort applied in persons-months LOC is the estimated number of delivered lines of code for the project. The Intermediate model produces better results because you supply settings for 15 Cost Drivers that determine the effort and duration of software projects. There are two primary limitations. One can apply Intermediate COCOMO across the entire software product for easily and roughly cost estimation during the early stage. COCOMO can estimate the staffing. The Cost Drivers include factors such as Product Complexity. Table 3 : Software Project Organic Semidetached Embedded Ai 3. It can be very cumbersome to use on a product with many components.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.2 3. Programmer Capability. Bi are the coefficients whose values are given in table 3.
DATA — Data Base Size.5 * (Effort) 0.8 * (KDSI)1. COCOMO model uses 15 cost drivers based on these principles.35 TDEV = 2. and to compress a number of factors which tend to be highly correlated on projects into a single factor.106 Chapter 6 . Independence: this tends to eliminate factors which are strongly correlated with product size. CPLX — Software Product Complexity. Product Attributes RELY — Required Software Reliability. The level of complexity of the product to be developed. computer attributes.12 Effort = EAF * 2.5 * (Effort)0. These cost drivers are grouped into four categories: software product attributes.2 * (KDSI)1. The degree of the total amount of data to be assembled for the data base. 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. personnel attributes. . and project attributes.5 * (Effort) 0.32 There are many candidate factors to consider in developing a better model for estimating the cost of a software project.0 * (KDSI)1.20 Basic Schedule equation TDEV = 2. Effort Equations for Three Development Modes in Intermediate COCOMO Model Development mode Organic: Semidetached: Embedded: Basic Effort equation Effort = EAF * 3.Software Project Management Table 4. The extent to which the software product must perform its intended functions satisfactorily over a period of time.05 Effort = EAF * 3.38 TDEV = 2.
TURN — Computer Turnaround Time The level of computer response time experienced by the project team developing the product. 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.BSIT 44 Software Engineering 107 Computer Attributes TIME — Execution Time Constraint The degree of the execution constraint imposed upon a software product. Personnel Attributes ACAP — Analyst Capability The level of capability of the analysts working on a software product. . STOR — Main Storage Constraint The degree of main storage constraint imposed upon a software product. 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. VIRT — Virtual Machine Volatility The level of the virtual machine underlying the product to be developed. AEXP — Applications Experience The level of applications experience of the project team developing the software product.
reviewed. the system level. The lowest level. and modify them where appropriate. is used to apply major overall project relations such as nominal effort and schedule equations. The top level. Step 2: Plan for Required Data and Resources · prepare a project plan at an early stage. Step 1: Establish Objectives Key the estimating objectives to the needs for decision making information. the module level. but which tend to be the same for all the modules within a subsystem.108 Chapter 6 . 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. is described by the number of DSI in the module and by those cost drivers which tend to vary at the lowest level. is described by the remainder of the cost drivers which tend to vary from subsystem to subsystem. how. and whereas of the estimating activity. Re-examine estimating objectives as the process proceeds. how much. where. and to apply the nominal project effort and schedule breakdowns by phase. These phase sensitive Effort Multipliers are used to determine the amount of effort required to complete each phase. who. when. Seven Basic Steps in Software Cost Estimation This section provides a seven-step process for software cost estimation. SCED — Schedule Constraint The level of schedule constraint imposed upon the project team developing the software product. Balance the estimating accuracy objectives for the various system components of the cost estimates. Step 3: Pin Down Software Requirements · It is important to have a set of software specifications that are as unambiguous as possible . The Detailed model apply a three level hierarchical decomposition of the software product whose cost is to be estimated. and followed up accordingly.Software Project Management TOOL — Use of Software Tools The degree to which software tools are used in developing the software product. this activity need to be planned. the subsystem level. The second level. the plan includes an notes on the why. what.
An iteration of the estimates after finding why they give different estimates may converge to a more realistic estimate. c) the more we think through all the functions the software must perform. b) the more pieces of software we estimate. in order to avoid the weakness of any single method and to capitalize on their joint strengths. 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. their strengths and weaknesses are complementary. it is essential to gather data on its actual costs and progress and compare these to the estimates 6.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. Step 7: Follow-up Once a software project is started. the more we get the law of large numbers working for us to reduce the variance of the estimate. 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. the better we understand the technical aspects of the software to be developed. Primarily risk and risk management can be assessed by considering the following definitions: .BSIT 44 Software Engineering 109 A specification need to be testable to the extent possible. 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. for three main reasons: a) the more detail we explore. It is important to use a combination of techniques.
the project manager takes a step towards avoiding it and there by controlling it. they cannot be known in advance and are difficult to find 6. “Software risk management is an emerging discipline whose objectives are to identify address and eliminate software risk items before rework.” A definition from Oxford Dictionary. it is: Project risks. They are generic risks they are a potential threat to every software project. can be uncovered from careful evaluation of the project plan Predictable risks.” Risk Management.” “Time for implementation that is much greater than expected. “A chance or possibility of danger.” “Technical performance of resulting systems turns out to be significantly below estimate. are obtained from the past project experience Unpredictable risks.110 Chapter 6 . in the first category. loss.” “Costs of implementation vastly exceed planned levels. it is: Known risks.” “Incompatibility of the system with the selected hardware and software. . product -specific risks they can be identified by those who have a clear understanding of the in and out of the project like technology. threaten the quality and timeliness of the software to be built Business risks. There are two distinct types of risks for each categories said earlier.” [IEEE 89] There are different categories of risks that can be considered. threaten the viability of the software to be built In the next category. of the anticipated benefits.Software Project Management Risk. as per the Quotations [Boehm 93] “Failure to obtain all or even any. By identifying known and predictable risks. environment etc. threaten the project plan Technical risks.1 Risk Identification Risk identification is a systematic attempt to specify the threats to the project plan. Software Risks. people.5. injury or other adverse consequences.
category of risks. is also called as risk estimation. Developing a risk table is an important activity of the project planner.2 Risk Projection Risk protection. for which a risk item checklist can be used. if it occurs.5. 3. This table provides a simple technique for risk projection. probability of its occurrence and its impact. 4. 2. 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. The sample risk table is given below. 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. 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 . It has information like list of risks. There are four risk estimation activities: 1.BSIT 44 Software Engineering 111 Both generic and product-specific risks need to be identified systematically. 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.
project management must develop a strategy for reducing the turn over. Some steps in this direction are: Meeting with staff members to determine the causes for turn over. The value of impact implies that 1 is catastrophic. The column RMMM contains a pointer to Risk Mitigation. and Risk management and contingency planning If a software team adopts a proactive approach to risks. avoidance is the best method. 2 is critical. Monitoring and Management In order to assist the project team in developing a strategy for dealing with risks. 3 is marginal and 4 is negligible. In order to mitigate the risk.Software Project Management 50% 40% 80% 30% 2 1 3 2 Where. low pay etc. the second column shows the category of risk encountered such as. The project manager monitors the facts that . poor working conditions. BU is business risk etc. risk monitoring activities begins. an effective strategy must be considered. The following three issues help in developing a strategy for dealing with risks: Risk avoidance Risk monitoring. 6.g.3 Risk Mitigation.5. 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.) Act to mitigate those causes that are under management control before the project starts Once project starts.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. (e. Monitoring and Management plan that is developed for all risks. This is achieved by developing a plan for risk mitigation.
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. risk management may imply that the failure of the software project is almost a certainty.5. the project manager should also monitor the effectiveness of risk mitigation steps. In this example a software project manager may be seen to avoid risks and display a confident can-do attitude. A crisis may occur within a project or be precipitated by a customer. 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. . Let us discuss a problem of risk aversion by considering the following example based on a recent risk management paper [Boehm. This is considered a small risk and is easily solvable by adding the required staff. Risk aversion It is very easy to acknowledge the fact that there are large risks present when undertaking software development projects.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. For example if two more personnel are needed to complete final testing of a software project so it may meet its deadline. In addition to monitoring the risk factors. 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. 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.BSIT 44 Software Engineering 113 may provide an indication of whether the risk is becoming more or less likely. 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. This section will consider some of the most commonly documented problems. It can therefore be tempting for software development managers to completely ignore risk management approaches. 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. DeMarco 97]. Insufficient staffing or appropriate decisions from senior management may mean that the systematic approach to risk assessment is not in place. Design flaws may occur in the project and be missed. The project manager may be diverted by this activity from managing risk assessment activity.
Technical staff II Project risk Table 1.5. Description of all risks above cut-off 2. The SEI have developed systematic approaches and so provide a good example as what a systematic approach should entail. Breaking down risks in a systematic way and highlighting those that are important is a very difficult and assessing which risks are important. It is therefore possible for managers to highlight parts of a risk management plan. Scope and purpose of document 2. Management b. The probability and impact of risks are recorded using a high medium and low rating against each risk. 3.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. General strategy ii.114 Chapter 6 . Risk #n a. It can almost be seen as a feature of a poor infrastructure but is so important is worth mention as an issue itself. Overview of major risks Responsibilities a. probability and impact III Risk mitigation.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. 6. look at risks taken. monitoring. monitoring. management n. Mitigation i. An outline of it is shown below: I Introduction 1. Specific steps to mitigate the risk . and Management Plan. by whom and whether deadline can be met and what action may be required. Factors influencing. Approaches used by the SEI (Software Engineering institute) highlighted this as a major problem.
Monitoring approach Management i. 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.6. Contingency plan ii. Like this. tasks can be reordered. Each task noted in the schedule is tracked by the project manager. 6. to ensure that goals are being approached and eventually being achieved.1 Scheduling Software project scheduling is an activity that involves: 1. the software development can be controlled. Factors to be monitored ii. Project control is necessary in-order to monitor the progress of activities against plans. . 2. If a task falls behind schedule. resources can be redirected. IV V RMMMM Plan iteration Schedule Summary 6. Once the development schedule has been established. 5. Monitoring i. 4. 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. 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. So. delivery commitments can be modified to accommodate the problem that has been uncovered. It involves quality assurance & control and change management & control. 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”.BSIT 44 Software Engineering 115 b. Special considerations c. tracking and control activity begins. 3.
And each intermediate goal is decomposed further into further 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. budgeting and resource planning.116 Work break down structure (WBS) Chapter 6 .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. 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 . Help in scheduling of project activities but not identifying them. The length of each bar is proportional to the length of the time planned for the activity. There are two general scheduling techniques followed. Each bar represents an activity.Software Project Management Compiler project Design Code Integrate & test Write manual Scanner Parser Code generator Figure 6. This process is repeated until. It is a bar chart. each goal is small enough to be well understood.
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. 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 is a network of boxes (or circles) and arrows. 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.
build code generation. That is any delay in any activity in this path will cause a delay in the entire project. It provides baselines cost and scheduling information. integration & test path represent a critical path for the project. so. the project manager must clearly and closely watch the critical path.6.Software Project Management Example 1 using PERT chart Here in the example. Project objectives . It is given below: I Introduction A.118 Chapter 6 . which can be used through out the software engineering process. The software project plan is produced as an outcome of planning phase.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. the design. Scope and purpose of the document B.
Risk analysis B. C. Risk management IV Schedule A. People Special resources VI Staff Organization A. Change management and control VIII Appendices . Project work break down structure B. Hardware and software B. Management reporting VII Tracking and Control A. Historical data used for estimates B. Task network Time-line-chart Resource chart V Project Resources A.BSIT 44 Software Engineering 119 II Project Estimates A. Team structure B. C. C. cost. Estimation techniques Estimation of effort. D. duration III Project Risks A. Quality assurance and control B.
——————————is a project control technique that can be used for several purposes like scheduling. people need to be teamed properly. 4. So. 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. 7. 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. 4. schedules. Name the different kinds of software development team structure. 9. people. Its very important to manage them. Give the IEEE definition of risk management. 2. budgeting and resource planning. estimating project costs. The project management activity encompasses activities like risk management. process and problem.7 SUMMARY Chapter 6 . People are very important for developing and maintaining software projects. 2. 5. 6. tracking.120 6. Namely. 5. 6. Estimation makes use of an important approach ——————————. It has three P’s which influence on it. 10. 6. 8.Software Project Management Software management is an umbrella activity within software engineering. in order to increase the efficiency of work. and control. 3. Define the terms: risk mitigation.8 SELF CHECK EXERCISE I Fill in the blanks : 1. risk monitoring Is scheduling same as project tracking ? How do you classify risks ? .
Roger S. Addison-Wesley publications. 3. 6. 9. 8. 11. Software engineering. Narosa publishing house Ian Sommerville. 1996.9 REFERENCES 1. 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. 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. 6. 3. 5. 5.5 . Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. 7. 2. define cocomomodel.BSIT 44 Software Engineering 121 II b) Answer the following question in detail 1. 2. ed. 10. 3. 2. 4. 12. Pankaj Jalote. An Integrated approach to Software Engineering (second edition). decomposition Gantt chart COnstructive COst MOdel E = Ab * (KLOC)Bb (person-months) Program Evaluation and Review Technique technical risks 6.
Software Quality Assurance .1 OBJECTIVES At the end of this chapter you should be able to Define terms like quality.Chapter 7 Software Quality Assurance 7. effective software engineering techniques. SQA Encompasses the activities like : a quality management approach. a procedure to assure compliance with software development standard and measurement and reporting mechanisms. (FTR) applied thought the software process. and the international standards that need to be followed for software engineering. control of software documentation and changes made to it. Software Quality Assurance ( SQA ) is an “umbrella activity” that is applied at each step in the software development process. activities that need to be carried out for producing high quality software products. Formal Technical Reviews. a multi tired testing strategy.0 INTRODUCTION O ne of the important factors driving any production discipline is quality. In this chapter. And this goal is achieved through what is known as software quality assurance. we focus on concepts related to quality. An important goal of software engineering is to produce a high quality software. 7. quality control. 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 .
lines of code etc. in software development. However. so that each work product meets the requirements placed upon it. Quality of conformance is an issue which mainly depends on implementation. performance specifications . it includes the cost of perceiving the quality and its related activities.such as color. reviews. and design of the system. and tests which is carried out during the entire life cycle of a software. It consists of a series of activities like inspections. cohesion. Quality control (QC) It is an activity for controlling the quality of an item. It gives the necessary information to the management regarding the quality of product. reporting functions of management. Quality of conformance is the degree to which the design specifications are followed during manufacturing. QC can be carried out automatically or manually or in a combined form. length etc. Prevention cost include : quality planning . two kinds of quality may generally be encountered: quality of design and quality of conformance. Cost of Quality It includes all costs incurred towards achieving quality.2 QUALITY CONCEPTS Quality Quality refers to a measurable characteristic or attribute of an item . and failure. and the measurable characteristics with reference to a program include cyclomatic complexity. While considering these characteristics. That is. appraisal. specifications. quality of design includes requirements. Quality Assurance (QA) It is an activity that consists of auditing.BSIT 44 Software Engineering 123 Know the importance of Formal Technical Reviews Write the SQA plan Discuss the importance of quality standards 7. Quality of design refers to the characteristics that the designers specify for an item such as the grade of the materials. Quality costs may be divided into costs associated with prevention.
124 formal technical reviews test equipment training Chapter 7 . The software engineering group perform quality assurance by applying technical methods and measures. 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. The software quality assurance group assist the software engineering group in achieving a high quality end product.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. well planned software testing etc.3 SOFTWARE QUALITY ASSURANCE ACTIVITIES The SQA is an important activity usually performed by two groups : software engineer group and software quality assurance group. Apart from helping the software engineering group.
3.1. Informal review – Informal reviews could be unscheduled and ad-hoc wherein issues could be discussed and clarifications obtained. resulting in some number of errors that are passed through. Point out the needed improvements in the product. So software reviews are a “filter” to software engineering processes. Make the technical work more manageable. . During the step. Types of reviews 1. the box sub division represent these characteristics and the percent efficiency for detecting errors.also called as Formal Technical Review (FTR) .This is the most effective filter for software engineering processes . In some cases. Review may fail to find newly generated errors and errors from the previous steps. errors passed from previous steps are amplified by the current work.BSIT 44 Software Engineering 125 - records any non-compliance and reports to senior management. Software reviews are needed to 1. 2. It is a quality problem that is discovered after the software has been released to end users. It also coordinates the control and management of change and helps to collect and analyze software metrics. 7. A box represents a software development step. 2. errors may be inadvertently generated.This is an effective means of improving software quality Software defects Defect is a product anomaly. which depicts a measure of review. These could also be called coffee shop reviews. Formal review .4 SOFTWARE REVIEWS Reviews are conducted at various points during software development to find out the errors that can then be removed. In the figure 7. detail design and coding steps of software engineering process. Confirm those areas of the product where improvements are not needed. Defect amplification and removal A defect amplification model is used for generation and detection of errors during preliminary design.
To achieve software with consistent quality and on time. To ensure that the software has been represented according to predefined standards. Serves to promote backup and continuity. round-robin reviews. 8.1 Defect amplification model 7. . design. 7. Each FTR is conducted as a review meeting. 6. To make projects more manageable. logic or implementation found in software. To detect the errors in functions.126 Development step Defects Errors from previous step Errors passed through Chapter 7 . 4. FTR includes walkthroughs. 2. inspections. 5.Software Quality Assurance Detection Amplified errors 1 : x Percent efficiency for error detection Errors passed to next step Figure Newly generated errors 7. 3. It acts as a training ground for junior engineers to observe different approaches to software analysis. implementation.5 FORMAL TECHNICAL REVIEW This is a software quality assurance activity that is performed by software engineers. To verify that the software under review meets its requirements. Objectives 1.
physical audit f. Purpose of plan References Management 1. V. X.6 THE SQA PLAN The SQA plan provides a road map and a layout for the software quality assurance activity. Tasks 3. VII. Problem reporting and corrective actions IX. software requirements review b.2 gives an outline for SQA plans as recommended by the IEEE. in-process audits g. Other documents Standards. software verification and validation reviews d. The figure 7. functional audit e. practices and conventions 1. Conventions Reviews and audits 1. design reviews c. Purpose 2. Purpose 2. II. Review requirements a. VI.BSIT 44 Software Engineering 127 7. techniques and methodologies Code control . Responsibilities Documentation 1. Test VIII. I. Purpose 2. Organization 2. management reviews IV. III. Required software engineering documents 3. Tools.
Training XV. and resources for implementing quality management. Supplier control XIII. maintenance. This system is defined as the organizational structure.1 The ISO Approach The International standards organization (ISO) quality assurance models treat an enterprise as a network of interconnected processes. Documenting a process helps an organization to understand. these processes must address the areas identified in the standard and must be documented and practiced as prescribed. Risk management 7. Records collection. procedures. procedures.128 XI. For a quality system to be ISO-complaint. A system called Quality assurance system may be used for this purpose.Software Quality Assurance XII. 7. responsibilities. processes. The elements include the organizational structure.7. processes. Management responsibility Quality system Contract review Design control . Examples of quality standards include international standards organization (ISO) and the capability maturity model (CMM). and resources needed to implement quality planning. The 20 requirements given by ISp 2001 address the following topics : 1. The standard contains 20 requirements that must be present for effective quality assurance system. quality control. and retention XIV.7 QUALITY STANDARDS Certain standards are to be followed for establishing quality in an organization. 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. 2. The ISO 9001 standard is the quality assurance standard that applies to software engineering. Media control Chapter 7 . control and improve it. The ISO 9000 describes the elements of a quality assurance system in general. 3. 4. quality assurance and quality improvement.
7. it must set up policies and procedures to address each of the above said requirements and then demonstrate it in the form of practice. 10. which is based on a set of software engineering capabilities that should be present as organizations reach different levels of process maturity. 18. 16. 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. 20. 19. 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 . measuring. and test equipment Inspection and test status Control of nonconforming product Corrective and preventive action Handling. Document and data control Purchasing Control of customer supplied product Product identification and traceability Process control Inspection and testing Control of inspection. SEI uses an assessment questionnaire and a five-point grading scheme that defines important activities required at different levels of process maturity. The Software Engineering Institute (SEI) has developed a comprehensive model called as Capability Maturity Model. there has been a significant emphasis on “process maturity”.7. 12. 6. storage. 15. packaging. 9. 13.BSIT 44 Software Engineering 129 5. This model is used to determine an organization’s current state of process maturity. 17. 7.2 The Capability Maturity Model In the recent years. 8. 11. 14.
integrity and usability. its ability to undergo change.130 Level 2 : Repeatable Level 3 : Defined Level 4 : Managed Level 5: Optimizing - Chapter 7 . . In order to measure the quality of software important factors proposed by McCall and others are used. efficiency. Each KPA is described by identifying the following characteristics : Goals Commitments Abilities Activities Methods for monitoring implementation Methods for verifying implementation 7. and they are known as McCall’s Quality factors. and its adaptability to new environments.Software Quality Assurance Can repeat previously mastered tasks Process characterized. fairly well understood Process measured and controlled Focus on process improvement The SEI has associated key process areas ( KPA ) with each maturity levels. The factor product transition deals with quality factors like portability.8 SOFTWARE QUALITY FACTORS The concept of quality in the context of software needs attention. product operations deals with quality factors such as correctness. McCall’s Quality factors It focuses on three important aspects of a software product : its operational characteristics. The factors that affect software can be measured either directly or indirectly. reusability and interoperability. reliability. These aspects of software quality can be visualized to have three dimensions : Product Operation Product Transition Product Revision The first factor.
Reliability The extent to which a program can be expected to perform its intended function with required precision. Testability The effort required to test a program to ensure that it performs its intended function. Usability The effort required to learn. prepare input. and interpret output of a program. Flexibility The effort required to modify an operational program. These three factors are shown in figure 7. Integrity The extent to which access to software or data by unauthorized persons can be controlled. Reusability The extent to which a program can be reused in other applications. flexibility and testability. . Correctness The extent to which a program satisfies its specification and fulfills the customer’s mission objectives.2. 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.BSIT 44 Software Engineering 131 The factor product revision deals with maintainability. Portability The effort required to transfer the program from one hardware and/or software system environment to another. Interoperability The effort required to couple one system to another. operate.
conciseness. accuracy.Software Quality Assurance Usually. .. FTRs. Software review is very important and is an important SQA activity. The SQA activity includes procedures for effective application of software methods and tools. data commonality. error tolerance. these quality factors are associated with software quality metrics like audibility. removing errors while they are relatively inexpensive to find and correct. testing strategies etc. consistency.9 SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the software process.2 McCall’s software quality factors 7. Software quality factors help to measure the quality of software product. And software metrics help to provide a quantitative way to access the quality of internal product attributes. completeness. expandability etc. execution efficiency. It serves as a filter for the software process. Maintainability Flexibility Testability Product Revision Product transitions Portability Reusability Interoperability Product operations Correctness Reliability Usability Integrity Efficiency Figure 7.132 Chapter 7 .
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. 4. 4. 2. 8.10 SELF CHECK EXERCISE I Fill in the blanks : 1.BSIT 44 Software Engineering 133 7. reporting functions of management. 7. 5. round-robin reviews. ——————— are a “filter” to software engineering processes. Define the terms: Quality. ———————————is an activity that consists of auditing. What is software quality assurance ? Name the different types of software reviews. Quality assurance and quality control. product transition and product revision —————————— defines the extent to which access to software or data by unauthorized persons can be controlled. FTR includes ——————— . 3. 3. 4. 5. 6. 5. 3. The quality standard used in software engineering process is ———————— CMM stands for ———————————— McCall’s quality factors focus on ————————————. What is a defect amplification model ? Name any two commonly used quality standards for software. 7. 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 . Explain the quality concepts 2. II a) Answer the following questions in one or two sentences : 1. 6. inspections. 2.
An Integrated approach to Software Engineering (second edition). 4. Roger S. 5. 2. 6. Software reviews walkthroughs ISO 9001 Capability Maturity Model Product operations Integrity 7. Narosa publishing house. Explain the 20 requirements for ISP 2001 address Write a note on capability maturity model Explain Mc Call’s quality factors Chapter 7 . Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. 3. 8. Pankaj Jalote.134 6. . 7.11 REFERENCES 1. Quality assurance 2.Software Quality Assurance I Answers 1. 7.
SCM process. version control.Chapter 8 Software Configuration Management 8. In this chapter.1 OBJECTIVES At the end of this chapter. ensure that change is properly being implemented and report change to others who may be interested in it. we will discuss about baselines.0 INTRODUCTION W e know that. The goal of SCM is to maximize production by minimizing mistakes. And it is also seen that during development process the requirements. So. 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. So. 8. through out software development process. design and code often get changed. a discipline that systematically control the changes that are occurring during the software development process is followed. SCM is an umbrella that is applied through out the software process. control change. the software consists of a collection of items such as programs. Software Configuration Management ( SCM ). 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 . SCM activities are developed to identify change. change control and how they influence on software quality. data and documents that can easily change.
and these Software Configuration Items can be approved through Formal Technical Reviews. managers may want to modify project management approach and so on. This is because. However. developers may want a change in their technical approach. who are subjected to think differently at different times.1 Baselines . that thereafter serves as the basis for further development.Software Configuration Management 8. in a software process is quite common.136 Discuss the need for configuration audit Chapter 8 . once baseline is established. So. Figure 8. changes left wildly without control is very difficult to manage.2 BASELINES The changes occurring to a software. But. software passes through different kinds of users. the changes that can be made become specific. Before a SCI item becomes a baseline. As per IEEE. software configuration management concept called Baseline is used. and that can be changed only through formal change control procedure. Customers demand for changes in their requirements. change can be made quickly and informally. a baseline is defined as : A specification or product that has been formally reviewed and agreed upon. A baseline is a SCM concept that helps us to control change without seriously impeding justifiable change. A baseline is a milestone in the software development process that is marked by the delivery of one or more Software Configuration Items ( SCI ). and formal procedure must be applied to evaluate and verify each change.
.1.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.
Figure 8.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 . This extracted SCI can be modified only by following the SCM controls. 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. it is copied from the project database into engineer’s private workspace. they are placed in a project database. When a member of software engineering team wants to make a modification to a baseline SCI.138 Chapter 8 .2 shows the modification path for a baselined SCI. After SCIs are reviewed and approved.
linked modules database description a. 2. engineering change orders standards and procedures for software engineering 4. 3. module design description d. prototypes d. process specifications c. initial content as-built user manual maintenance documents a. interface design description source code listing test specification a. maintenance change orders c.BSIT 44 Software Engineering 139 The following SCIs are the target for the configuration management technique and form a set of baselines : 1. . 5. system specification software project plan software requirements specification a. 9. 8. data design description b. module executable code b. software problem reports b. schema and file structure b. 10. test cases and recorded results operation and installation manuals executable program a. 13. test plan and procedure b. 7. mathematical specifications preliminary user manual design specification a. 12. 11. architectural design description c. graphical analysis model b. 6.
source code listing for a module. data model and module N are basic objects. Example : In SRS. Each object or configuration object has certain distinct features like name. design specification is an aggregate object which is an aggregation of objects like data design. However.. description.is collection of basic objects and other aggregate objects. Figure 8.3 shows configuration objects. coding or testing.Software Configuration Management SCM is an important element of SQA. Its primary responsibility is to control the changes. 4. Aggregate objects . 3.3. a list of resources and a realization. This is required to control and manage SCIs. architectural design module design etc.1 Identification of Objects in Software Configurations The software configuration items must be named and organized using object-oriented approach. . other responsibilities of SCM include : 1. Example : a section of SRS. design .140 8. Basic objects – it is a unit of text. identification of individual SCIs version control change control configuration auditing reporting 8. which in turn have objects in them. 5.3 THE SCM PROCESS Chapter 8 . with design specification as an aggregate object . Two types of objects can be identified : basic objects and aggregate objects. created by software engineer during analysis. 2.
4 OBJ 1.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. The diagrammatic representation of en evolution graph is shown in figure 8.3 OBJ 1.0 OBJ 2.2 OBJ 2. a graph called evolution graph is used.2 OBJ 1.4. they need to be described about the changes.1 Figure 8.1.1. objects evolve through out the software process. Since.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. OBJ 1.1 OBJ 1.4 Evolution graph . For this.0 OBJ 1.1 OBJ 1.
Evolution graph 2.2 and similarly it evolves as OBJ 1.5. Each software version has attributes associated with it. The configuration management allows the user to specify the alternative configuration of the software system through the selection of appropriate versions. attached to each object or a string of Boolean variables. here each node represents an aggregate object ( i.1.1 and OBJ 1.e.2 Version Control It combines procedures and tools to manage different version of configuration objects that were created during software engineering process.1”.Software Configuration Management Here. Each version of software is a collection of SCIs and may be composed of different variants.2.3.1” then undergoes minor change and results in OBJ 1.142 Chapter 8 . Attributes can be like a specific version number. let us consider an example: a version of a simple program that is composed of five components. complete version of software ). 8. Version representation There are two version representations : 1.5 components 5 . Object-pool representation Evolution graph This is shown in figure 8.4 etc. This is shown in figure 8. OBJ 1.1 becomes OBJ 1. this “OBJ 1.5. configuration object “ OBJ 1.1. 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. A major update at OBJ 1. 1 2 3 variants 4 Figure 8.0” undergoes revision and becomes “ OBJ 1.3.
2. version and variants. A variant is different collection of objects at the same version level.6 variants component object version Figure 8. 2. 3. 3. components 1. 4 components 1. 5 In-order to construct variant of a given version.BSIT 44 Software Engineering 143 There are two variants of version: 1. Object. and this model is shown in figure 8. 2. each component is associated with one or more attributes.pool representation This describes the relationship between components.6 Object-pool representation A component is composed of collection of objects at the same version level. A version or new version is defined when changes are made to one or more objects .
144 8. 2. access control synchronization control . The object to be changed is “checked-out” from project database and it is modified and appropriate SQA activities are applied.3 Change Control Chapter 8 . 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. the constraints imposed. 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.7 shows the process of change control.Software Configuration Management Change control combines the human procedures and automated tools to provide the mechanism for control of change. side effects. overall impact on configuration objects etc. Every time a change is approved an engineering change order ( ECO ) is generated. criteria for review and audit. This ECO describes what changes are to be made.3. Figure 8. - “check-in” and “check-out” processes implement two important elements of change control : 1. The changed object is then “checked-in” to the project database and appropriate version control mechanisms are used to create next version of software.
7 the process of change control .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.
Software configuration audit It complements the FTR by assessing a configuration object for characteristics that are generally not considered during FTR.3. 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 .Software Configuration Management Access control : this governs which software engineer has authority to access and modify a particular configuration object. 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. 2.5 Status Reporting it is also known as configuration status reporting (CSR) or status accounting. don’t overwrite one another.3.146 Chapter 8 .4 Configuration Auditing We can evaluate the changes made during change control using two methods: 1. 8. Synchronization control : this ensures that parallel changes made by two different people. 2. 4. 3. FTR – formal technical review Software configuration audit Formal technical review it focuses on the technical correctness of configuration object that has been modified. For this purpose “ locks “ are used in the database. This activity is conducted by quality assurance group The audit asks and answers the following questions : 1. 8.
Once a configuration object has been developed and reviewed. 4. 3.4 SUMMARY Software configuration management is an umbrella activity that is applied through out the software process. 8. 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. SCM identifies. 2. The software configuration audit is an SQA activity that helps to maintain quality even when changes are applied to software. Change control is a procedural activity that ensures quality and consistency as changes are made to configuration object.BSIT 44 Software Engineering 147 - CSR is generated on regular basis. What happened ? Who did it ? When did it happen ? What else will be affected ? etc. may be placed in an on-line database for developers. audits. . controls. SCM can be viewed as a software quality assurance activity that is applied through out the software process. it becomes a baseline. and reports modifications that occurs during the software development process and after the release of software. maintainers to access the changed information CSR is an SCM task that answers the questions like : 1. Changes to a base-lined object results in the creation of new version of that object. The information about the changes taking place is given out in the form of status report. a change is approved by CCA and a configuration audit is conducted The output of CSR. for which controls need to be applied.
6. —————————— will help in describing interdependencies among configuration objects and enables any version of a system to be constructed automatically. 2. The most commonly used version representations are evolution graph and ——————— ———————— ECO stands for ———————————— ————————— ensures that parallel changes made by two different people. A baseline is a milestone in the software development process that is marked by the delivery of one or more ————————————. 6. 3. SCM is an important element of ————————————— 4. 4. Give the IEEE definition of Software configuration management. What is an SCM process ? What are aggregate objects ? Give one example. 8.148 8. What is a baseline ? Give two examples of baselines. don’t overwrite one another. 8.5 SELF CHECK EXERCISE Chapter 8 . 5.Software Configuration Management I Fill in the blanks : 1. What is version control ? What is change control ? why is it important ? Name the important functions of SCM process. 5. . 3. Software Configuration Items can be approved through ————————. 2. ————————— 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. 7. 7.
6. 7. 8. 4.6 REFERENCES 1. 6. 4. Narosa publishing house Richard Fairly.BSIT 44 Software Engineering 149 II b) Answer the following questions in detail 1. Explain the activities of baseline. Pressman : Software Engineering – A Practitioner’s Approach (Fourth Edition) McGraw-Hill 1997. 3. 5.. Roger S. Formal Technical Reviews Software Quality Assurance Module interconnection language Object-pool representation Engineering Change Order Synchronization control Status reporting 8. Pankaj Jalote. Give diagram 2. An Integrated approach to Software Engineering (second edition).1985 . 5. 2. Software engineering concepts. 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. 3. Software Configuration Items 2. 3. McGraw-Hill Inc.
the process of expressing a computer program in a programming language. contractual agreements. compiler. resources. configuration control — In configuration management. approval or disapproval. 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. an element of configuration management consisting of the evaluation.GLOSSARY SOFTWARE ENGINEERING TERMS allocation — The process of distributing requirements. 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. or other entities among the components of a system or program. an independent examination of the configuration status to compare with the physical configuration. standards. analysis — In system/software engineering. configuration auditing – In configuration management. or other criteria code — In software engineering. computer instructions and data definitions expressed in a programming language or in a form output by an assembler. coding — In software engineering. or other translator. 150 Glossary . and implementation of changes to configuration items after formal establishment of their configuration identification.
data design – Design of a program’s data. or theoretically correct value or condition. an individual or organization who specifies the requirements for and formally accepts delivery of a new or modified hardware/software product and its documentation. (2) The current approved technical documentation for a configuration item as set forth in specifications. and documents referenced therein. associated lists. cost estimate — The estimated cost to perform a stipulated task or acquire an item. a document that is deliverable to a customer. Examples are users’ manual. action that produces an incorrect result. interfaces. components. control changes to those characteristics. operator’s manual. functional design — The process of defining the working relationships among the components of a system. and the implementation status of approved changes. Cyclomatic complexity — is a software measure. that provides a quantitative measure of logical complexity of a program. record and report change processing and implementation status. deliverable document — In software system engineering. specified. This information includes a listing of the approved configuration identification. configuration status accounting — In configuration management. error — The difference between a computed. .] functional decomposition — In software engineering. (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.BSIT 44 Software Engineering 151 configuration identification — In configuration management. 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. configuration management (CM) — In system/software engineering. drawings. and other characteristics of a system or component. an element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively. a discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item. especially table design in database applications. or measured value or condition and the true. and programmer’s maintenance manual design — The process of defining the architecture. the status of proposed changes to the configuration. customer — In system/software system engineering. observed. and verify compliance with specified requirements. documentation — A collection of documents on a given subject. the partitioning of higher-level system functions into smaller and smaller pieces to render them more manageable and understandable.
and resources that are performed for a given purpose. or adapt to a changed environment. process definition (Software Engineering Process) Identification of a sequence of steps involving activities. Or To perform operations on data. and prototyping. 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. metric — A quantitative measure of the degree to which a system. Can refer either to general characteristics such as reliability. semantic analysis and design. . . component. to specify and design high quality humanmachine interfaces. and coordination or work performed to develop a product or perform a service. maintenance — The process of modifying a software system or component after delivery to correct faults. the software development process or An executable unit managed by an operating system scheduler. or both. constraints. such as speed. or process possesses a given attribute. 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. for example. and usability or to specific features of a software product. is a multidisciplinary activity that app lies the knowledge. user environment design. methods. violations of development standards. and tools. maintainability. and other problems. improve performance or other attributes. 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. software components. implementation — The process of translating a design into hardware components. performance — The degree to which a system or component accomplishes its designated functions within given constraints.152 Glossary human-engineering — In system/software system engineering. control. process management (Software Engineering Process) — The direction. process model (Software Engineering Process) – A development strategy. that encompasses process. The human engineering process encompasses the following steps: activity analysis. derived from psychology and technology. accuracy. inspections — A static analysis technique that relies on visual examination of development products to detect errors. product attributes — Characteristics of a software product. incorporated by a software engineer or team of engineers. syntactic and lexical design.
and controlling necessary to successfully manage an engineering project. specification. directing. schedule and cost estimates (Software Engineering Management . managers. and managing options (risk analysis) for resolving (risk handling) these risks.BSIT 44 Software Engineering 153 product measure – A metric (e. review. is presented to project personnel. requirement — A condition or capability that must be met or possessed by a system or system component to satisfy a contract. In a hierarchy of quality attributes. higher-level attributes may be called quality factors. The primary goal of risk management is to identify and respond to potential problems with sufficient lead-time to avoid a crisis situation. or other interested parties for comment or approval.g. and know-how that provides the planning. articulate. Contrast with hardware. 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. quality attribute — A feature or characteristic that affects an item’s quality. reviews — A process or meeting during which a work product. Software — Computer programs. practices. requirements engineering — a method of obtaining a precise formal specification from the informal and often vague requirements with a customer. . an “umbrella” title for the processes used to manage risk. or set of work products. risk management (Software Engineering Management) — In system/software engineering. standard. project plan — A document that describes the technical and management approach to be followed for a project. and lower level attributes may be called quality attributes..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. quality management (Software Engineering Management . selecting. project management — A system of procedures.Planning) — That aspect of the overall management function that determines and implements the quality policy. staffing. and possibly associated documentation and data pertaining to the operation of a computer system. customers. users. organizing. procedures. and understand the requirements of the system. 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. technologies. measures per person-month) that can be used to measure the characteristics of delivered documents and software. It is an organized means of identifying and measuring risk (risk assessment) and developing.
and testing software. . and know-how that provides the planning. and controlling necessary to successfully manage a software engineering project. software configuration status accounting (software configuration management) – In configuration management. 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. software design. test approach. designing. the status of proposed changes to the configuration. rules. or process possesses a given attribute.154 Glossary software configuration management — In system/software engineering. a discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item. techniques. task — A task is a well-defined work assignment for one or more project members. implementing. and verify compliance with specified requirements. tools. and data for a software system to satisfy specified requirements. procedures. 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. modules. practices. hardware. technologies. control changes to those characteristics. an element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively. standards. system integration — In system/software system engineering. interfaces. software metric — A quantitative measure of the degree to which a system. or software requirements.In software engineering. 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. to conform to specifications software requirements analysis — The process of studying user needs to arrive at a definition of system. staffing. the process of defining the software architecture (structure). languages. directing. and other methodologies for analyzing. software requirements specification (software requirements) – A document that specifies the requirements for a system or component. This information includes a listing of the approved configuration identification. this ensures that the various segments and elements of the total system can interface with each other and with the external environment. software development methodology — In software engineering: an integrated set of software engineering methods. organizing. policies. component. record and report change processing and implementation status. and the implementation status of approved changes. components.
the products of each development phase fulfill the requirements or conditions imposed by the previous phase. test coverage of code (software testing) — The amount of code actually executed during the test process. V&V (verification and validation) — The process of determining whether the requirements for a system or component are complete and correct. 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. test procedure. Types include test case specification. test plan. test incident report. test execution (software testing) — Act of performing one or more test cases. test documentation (software testing) — Documentation describing plans for. test report. 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 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.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. . one of a number of approaches used for testing software. test log. version — An initial release or re-release of a computer software configuration item. associated with a complete compilation or recompilation of the computer software configuration item. user interface — An interface that enables information to be passed between a human user and hardware or software components of a computer system. testing strategies (software testing) — In software engineering. or results of. the testing of a system or component. and the final system or component complies with specified requirements.
Addison-Wesley publications.. An integrated approach to software engineering. Software engineering : A practitioner’s approach. Pressman. Software engineering.1985 Barry W.5 Pankaj Jalote. 1997. Software testing in the real world. 4. Pearson education. 6. ed. 1997. McGraw-Hill Inc. software engineering theory and practice. 1996. 2000. ed.156 REFERENCE BOOKS 1. 1981. Narosa publications. ed.. 2001. 2.4 Edward Kit. 3. Addison-Wesley publications. Software engineering concepts. 2 Richard Fairly. Reference Books Roger S. ed. .1 Ian Sommerville. 2 Shari Lawrence Peleeger. ed. 5. Boehm. Prentice-Hall Inc. MCGraw-Hill publication. 7. Software Engineering Economics.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.