Unit 1 The Product and The Process: Structure

Software Engineering
Unit 1
Unit 1
The Product and The Process
Structure: 1.1 Introduction Objectives 1.2 The Product The Evolving Role of Software Software Software Characteristics Software Applications Software: A Crisis on the Horizon Software Myths 1.3 The Process The Software Process Software Process Models The Linear Sequential Model The Prototyping Model The Incremental Model The Spiral Model The RAD Model 1.4 Fourth Generation Techniques 1.5 Summary 1.6 Terminal Question(s) (TQs) 1.7 Multiple Choice Question(s) (MCQs) 1.8 Answers to SAQs, TQs, and MCQs
1.1 Introduction
The world today is growing at a very fast pace. Most of the activities related to business and various applications are computerized. Computerization has led to the development of various types of software. Software has become the basis for various decision-making. Software helps in solving day to day problems and also helps in systematic production. It has become an integral part of service industry today. Software has penetrated various other sectors in applications of forecasting, scientific applications, animation, film making, inventory etc. Software has greatly impacted our society and culture. Its significance has no bounds and has led to rapid development of
Sikkim Manipal University Page No.: 1
Unit 1
technologies across the globe. This has also created a competition amongst various companies. The thirst for developing better and better software continues to increase day by day. There is also a need to develop areas of importance like hospitals, crime detection, chemical lab tests, astronomic research etc where quality is of prime importance. Software enables one to have a quality system. The technologies aim at specific applications like Web-Site development, technology domain like object-oriented systems, artificial intelligence, expert systems etc. There is not one software which can do everything. Software is an embodied knowledge and is a social learning process. It is a dialogue in which the knowledge becomes the software. This has resulted in processes, which provides an interaction between users and designers, and between designers and evolving technology. It is repetitive in nature, where the tool itself serves as the medium for communication. It is enriched with more and more rounds of the interaction where plenty of useful knowledge from the people is involved. Objectives In this Unit you will learn about: What is computer software . . . really? Why do we struggle to build high-quality computer-based systems? How can we categorize application domains for computer software? What myths about software still exist? What is a software process? Is there a generic way to assess the quality of a process? What process models can be applied to software development? How do linear and iterative process models differ? What are their strengths and weaknesses? What advanced process models have been proposed for Software Engineering work?
1.2 The Product

1.2.1 Software Evolutionary Role Software has a dual role. First it acts as a product, and secondly it acts as a delivery model. It provides the facility of computing the various needs of computer hardware like network of computers to be made accessible by
Unit 1
local hardware. A software acts as an information transformer. It transforms one or more of production, management, acquisition, modification, displaying, or transmitting information in simple as a single bit. Software is the basis and a driver to deliver the product. It acts as a controller of the ther entire systems of communication of information. Transformation of data is done by software. By transformation data becomes information which is then more useful in various contexts of business and scientific application. It helps in enhancing competitiveness; providing gateway to worldwide information networks, and as a means to acquire information. Along with the growth of the software industry there has been a drastic growth in the development of new hardware components and devices. Self Assessment Question(s) (SAQs) 1. Today software takes on a ______________ role. 2. Software helps in transferring personal information. (T/F) 1.2.2 Software A software refers to instructions which when executed provide desired function and performance and data structures that enable the programs to adequately manipulate information, and documents describing the operation and the use of the software. It refers to a set of instructions also known as program. Self Assessment Question(s) (SAQs) 1. What is software? 1.2.3 Characteristics of a Software Software is a logical element. Software has the following characteristics: 1. Software is not a manufactured component but it is developed or engineered. 2. Software does not undergo wear out which is seen in many manufactured components. 3. Most of softwares today are custom built which means the software are customized to meet the user needs. It is developed keeping in mind the requirements of delivery process and finished product. Self Assessment Question(s) (SAQs) 1. What are the characteristics of software?
Sikkim Manipal University
Page No.: 3
Unit 1
1.2.4 Software Applications The application of software is based on the nature of instructions in a particular area. If the set of instructions are structured well it is appropriate to develop software for such application. Development becomes easy and convenient depending on the degree of structure. Higher the degree better it is to develop the software for such applications. Information content and determinacy play an important role in determining the nature of a software application. Content means the form of incoming and outgoing information. Information determinacy refers to the predictions of the order and timing of information. It is difficult to develop generic categories for software applications. The following software areas indicate potential applications: System software - It is a collection of programs written to serve other programs. e.g., Compilers and Interpreter. Other systems applications like the operating system components, drivers, telecommunication processors process largely indeterminate data. Real-time software: Events that are real world based if possible to be controlled by programs are referred to as programmable events. Such programs control the entire event and act as a monitor or as an analyzer of the real-world events. Such software are known as real time software. It includes data gathering components and formats information from an external environment, an analysis component that transforms information, a responder component that responds to the changes in the external environment, and a monitoring component coordinating all other components. Business software: Business software refers to applications in the areas of business. Such software is mainly useful in decision making and transactions that facilitates business operations or management decision making. In addition to conventional data processing applications, business software applications also encompass interactive computing. Engineering and scientific software: Engineering and scientific software have been developed mainly to deal with "number crunching" algorithms. Applications range from astronomical science to seismology to molecular biology to automated manufacturing. Computer-aided design, system simulation, and other interactive applications have gained prominence.
Unit 1
Personal software: The personal computer software like the word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications, external network, and database access are some of the applications. Web-based software: The Web pages are a software application page that incorporates executable instructions performing one or more tasks. Artificial intelligence software: It uses non-numerical algorithms to solve complex problems. Expert systems, also called knowledge based systems, pattern recognition, artificial neural networks, and game playing are representative of applications within this category. Self Assessment Question(s) (SAQs) 1. What do you mean by Web-based software? 2. Write on personal computer software. 1.2.5 Software Crisis The success rate of software people is high. Last two to three decades never one has seen a serious software crisis. A crisis may indicate either a downfall of a set and well established activity or activities of software. It may signify a change in the software which is considered healthy for the growth of the software and its improvement. The set of problems that are encountered in the development of computer software is not limited to software that malfunctions. Rather, it may be extended to the stages of the development of the software. Also it is based on how we support a growing volume of existing software, and how one can keep pace with a growing demand in the industry. In the other hand we can say that, the selection of the software from total market availability is the software crisis. Self Assessment Question(s) (SAQs) 1. What do you mean by crisis?
1.2.6 Myths about Software

Most of the knowledgeable professionals understand myths as misleading attitudes that have caused serious problems for managers and technical people. It is not possible to easily change the old attitudes and habits. Myth about Management - Managers are often under pressure to maintain budgets, work towards objectives and accomplish task within deadline, keep control schedules from slipping, and improve quality.
Unit 1
Myth: A book that's full of standards and procedures for developing software is available. Is that enough to provide people with everything they need to know? Reality: The question is whether the book of standards was ever used or not? Are managers aware of the availability of such codes? Is it complete? Is it streamlined? Most of the times, the answer to all of these questions is "no." Self Assessment Question(s) (SAQs) 1. What do you mean by myths? 2. What are the different types of myths?
1.3 The Process

1.3.1 The Software Process A lot of focus is on process maturity. Software Engineering Institute (SEI) based on a software engineering capabilities, have developed a model, to address the various levels of maturity levels present in an organization. SEI used a five point grading scheme to assess the maturity level. The five levels are as follows Level 1: Initial level It is to address the initial processes where there is a tendency of one or more processes getting chaotic. Some of the issues are identified and steps are taken to bring in clarity in the initial processes. Level 2: Repeat level Based on the successes of certain processes in the past, processes are reviewed and revised. Some of the processes which are tracked are the process on costing, scheduling and various other related functions. Level 3: Documentation Organizations follow a streamed line of software development activities. These activities are documented procedures developed over years which are used by both the management and development team. Modules developed are integrated into existing organization software processes. Level 4: Managing the processes - It is necessary to measure various product features and processes associated with the software process. Measures are taken to collect data from various processes on various parameter of the software and each one is measured. The quantification of
Unit 1
all such measures is done and used in the performance evaluation of the process and the product. Level 5: Optimization Continual improvement is one of the major objectives of organization today. It is achieved by means of some predefined characteristics which is expected from the processes. The measurement methodology can be different for different processes. A quantitative feedback is obtained for various processes and measured. The measurements are made under constraints under which a process is expected to perform. Hence the measurements have to be optimized measurements. This helps in taking decisions on the improvement of the process on a continual basis. The five levels defined by SEI are on the basis of the evaluation responses from the assessment questionnaire based on CMM. Associated with each process level is the key process area (KPA). It defines various functions associated with each process which reflect the qualitative aspect of the process. KPA is based on the following characteristics Goals goals refer to the overall objectives to be achieved Commitments commitments are the requirements to be adhered to meet the goals. Abilities abilities refer to those aspects necessary to meet the commitments. Activities it signifies task necessary to achieve a particular KPA. Monitoring it refers to the ways and methodologies of monitoring a particular activity or a process. Verification it refers to the ways of verifying the methodologies of the KPA Self Assessment Question(s) (SAQs) 1. What are the different CMM Levels? 1.3.2 Software Process Models A development strategy for each process has to be developed to solve various types of problems associated with a process.
Page No.: 7
Unit 1
Problem solving can become very troublesome if not attempted to solve properly. It may run into repeated process of corrections and trouble shooting. The stages normally encountered are: status quo, problem definition, technical development, and solution integration. These stages are represented in the figure 1.1. Current state is represented by Status quo; identifying specific problem needed to be solved is problem definition; technical development refers to application of technology to solve the problem; and solution integration gives results. This technique may be applied at macro level or at micro level of processes. The stages may also exist in the form of nesting one consisting of the other similar block of stages.
Status Quo
Technical Development
Integrating Solution
Problem Definition
Fig. 1.1: Stages of problem solving in software process model
Self Assessment Question(s) (SAQs) 1. Software process model is used as ________________ level.
Page No.: 8
Unit 1
1.3.3 Linear Sequential Model Linear Sequential Model is also known as the waterfall model. It indicates a systematic and sequential approach to software development. It encompasses the following in a sequential order modeling, analysis, design, coding, testing, and support. Modeling: Modeling is done based on the various characteristics and relevant parameters which affect the performance of the software. The requirements are identified for each system element and the related constraints. The view of the system indicating the interaction of various elements of the system helps in modeling the system. The elements are the hardware, people, and databases. Requirements analysis: The information domain is understood for the software and the related functions and behavior of the various elements. The requirements for software are well documented. The requirements are reviewed for time to time with the customer. Design: The design of software is based on the following steps understanding data structure, the software architecture, the interface representations, and algorithms. The process of design transforms the requirements into a representation of the software which is then assessed for quality. Code generation: The code generation refers to the translation of design into a machine code. Code generation can be done systematically if the design steps are listed in detail. Program Testing: After the development of the program it is subjected to testing. Testing is done on the logics of the program and the functionality. During the process of testing, errors if any are identified and then necessary steps are taken to rectify the error. Support: Customers who are the end users of the software may come across certain points while using the software for their business applications. Such points are communicated to the developer who in turn incorporates the changes in the software. This is recorded as a revision. Software goes through a number of revisions during its lifetime of service.
Page No.: 9
Unit 1
Self Assessment Question(s) (SAQs) 1. What do you mean by linear sequential model? 2. What are the features of sequential model? 1.3.4 The Prototyping Model Detailed input requirements, processing requirements, and output requirements are not identified easily by the customer but states the general objectives. Also there is always a doubt about the efficiency of an algorithm. A prototype model on the requirements stated by the customer is developed which will enable the developer to understand the requirements more clearly and implement those requirements in the system. The customer evaluates the prototype which becomes the basis to refine the requirements. Self Assessment Question(s) (SAQs) 1. The prototyping paradigm begins with ____________ gathering. 2. What are the features of the prototyping model? 1.3.5 The Incremental Model The incremental model has the elements of linear sequential model and the prototype model. While using the incremental model, it is observed that the first increment is a core product. A basic requirement is addressed, but many of the supplementary features are undelivered. Core product is used by customer , who in turn suggests he changes which is reflected as in increment. This is repeated, till such a time that the entire product is completely finished for its intended use. Incremental model focuses on the delivery. This methodology is very useful in situation when there is shortage of staff but a progress is required. An incremental progress is possible then with limited staff. It can be then developed further depending upon the acceptance of the product by the customer and can be very useful in handling technical risks. Self Assessment Question(s) (SAQs) 1. The incremental model combines elements of the __________________ model. 1.3.6 The Spiral Model The spiral model was proposed by Boehm. It combines the repetitive aspect of prototyping and systematic and controlled aspect of linear sequential model. It helps in rapid development of versions of the software through
Unit 1
various incremental forms. Early iterations of the incremental release might be a paper model or prototype. Iterations done later are more in complete versions form. A spiral model is divided into six task regions: Customer Communication it refers to the setting up of a communication channel between the developer and the customer. Planning Resources and other project-related information are organized in a definite manner to achieve the intended results within the timeframe is achieved through planning. Risk Analysis Risks related to technical and management are analysed. Engineering engineering refers to the set of tasks necessary to build one or more application forms. Construction and Release This refers to the tasks required to construct, test, install, and provide user support. Customer Evaluation Various feedback question types are prepared on the different types of processes of the system. The feedbacks are inputs to the data on the software from the customers. The feedbacks are evaluated which in turns determines the level of acceptance of the software by the customer. The system of feedback is a repetitive process aimed at continual improvement of the product and its services. The software team moves around the spiral in a clockwise direction, beginning at the center leading to the development of product specification and subsequent repetitions of the process leads to development of the prototype and hence the product. Each pass through the planning region results in improvements. Cost and schedule are adjusted depending upon the customer needs. The new product will evolve over iterations around the spiral. The spiral model is a realistic approach to develop large-scale systems and software. The spiral model demands attention of the risks involved at various stages of the project and tend to minimize such risks. Self Assessment Question(s) (SAQs) 1. ___________ provides the potential for incremental versions of the software. 2. What are the features of the spiral model? rapid development of
Page No.: 11
Unit 1
1.3.7 The RAD Model Rapid application development (RAD) is similar to incremental software development process model. It focuses on short development cycle. The model is constructed based on the components or rapid development form linear sequential model. RAD approach covers the phases listed below: Business modeling phase in this phase the flow of the information through various business functions is considered. Certain questions to generate the model would be on - What drives the business process? What is generated? Who has generated it? Who is responsible to processes it? Data modeling phase Business data objects are modeled based on the information flow and the functionality of the business module which is needed to be incorporated into the system. Process modeling phase The objects developed in the above phase are transformed into the form necessary to be implemented in the systems as a function of the business. This will enable the smooth flow of the information through the various business processes. Processes are described to add, modify, delete, retrieve objects. Application generation phase - RAD uses fourth generation techniques for creating software. The focus of RAD process is to reuse existing program components. Automated tools may be used to develop the software. Testing and turnover phase The overall testing time is reduced in RAD since it emphasizes on the reusability of the components. In case of new components, testing will have to be done. In case the projects are large and scalable, RAD requires sufficient human resources to form the right team. Developers and customers are needed to the rapid-fire activities necessary to get a system complete. RAD is not appropriate to all types of business applications. RAD becomes troublesome if the if a system cannot be properly modularized. If the technical risks are high then RAD is not appropriate. Self Assessment Question(s) (SAQs) 1. What is the full form of RAD? 2. What is the drawback of the RAD model?
Page No.: 12
Unit 1
1.4 Fourth Generation Techniques

It refers to software tools that enable the software engineer to specify some characteristic of software at a higher level. Based on the developers specifications the tool generates the codes automatically. A software development environment that supports 4GT includes one or more of the following tools: data manipulation tools, nonprocedural languages, interactions, screen generation, code generation; high-level graphics capability; Web-site creation, etc. For applications of smaller size moving from requirements gathering step to implementation a non procedural 4GL may be used. For applications of larger size a design strategy along with the use of 4GL. 4GL is advantages in reducing the development time of the software and has a little disadvantage in it being not too simple to use. Self Assessment Question(s) (SAQs) 1. What do you mean by 4GT?
1.5 Summary
In the evolution of computer based systems, software has become the key element. Over the past few decades, software has evolved from a problem solving tool and information analysis tool to an industry in itself. Software has become a limiting factor. Software consists of programs, data, and documents. These elements comprise a configuration that is created as part of the software engineering process. The aim of software engineering is to build high quality software. Software engineering integrates processes, methods, and tools for the development of software. A number of different process models have been proposed for software engineering. Each has some strength and some weakness.
1.6 Terminal Question(s) (TQs)

1. Software is the differentiating characteristic in many computer-based products and systems. Provide examples of two or three products and at least one system in which software, not hardware, is the differentiating element. 2. Provide five examples of software development projects that would be amenable to prototyping. Name two or three applications that would be more difficult to prototype.
Page No.: 13
Unit 1
3. The RAD model is often tied to CASE tools. Research the literature and provide a summary of a typical CASE tool that supports RAD.
1.7 Multiple Choice Question(s) (MCQs)

1. Which model incurs more cost? (a) Prototyping model (b) RAD (c) Spiral Model (d) None of these 2. Which model is used at the time of risk? (a) Incremental model (b) Spiral model (c) Prototyping model (d) none of these.
1.8 Answers to SAQs, TQs, and MCQs

1.8.1 Answers to Self Assessment Questions (SAQs) 1.2.1 : 1. dual 2. true 1.2.2 Refer to 1.2.2 1.2.3 Refer to1.2.3 1.2.4 1. The Web pages retrieved by a browser are software that incorporates executable instructions (e.g., CGI, HTML, Perl, or Java 2. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications 1.2.5 "the turning point in the course of a disease, when it becomes clear whether the patient will live or die 1.2.6 Refer to 1.2.6 for both question 1 and 2 1.3.1 Refer 1.3.1 1.3.2 Macro 1.3.3 1. The linear sequential model suggests a systematic, sequential approach to software development, that begins at the system level and progresses through analysis, design, coding, testing, and support. 2. Refer to 1.3.3 1.3.4 1. Requirements 2. Refer to1.3.4 1.3.5 Linear sequential
Unit 1
1.3.6 1. 2. 1.3.7 1. 2. 1.4
Spiral model Refer to1.3.6 Rapid application development Refer to 1.3.7 The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common: each enables the software engineer to specify some characteristic of software at a high level.
1.8.2 Answers to Terminal Questions (TQs) 1. Refer to section 1.2.2 2. Refer to section 1.3.4 3. Refer to section 1.3.7 1.8.3 1. a 2. b Answers to Multiple Choice Questions (MCQs)
Page No.: 15
Unit 2
Unit 2
Project Management Concepts, Process and Project Metrics
Structure 2.1 Introduction Objectives 2.2 The Management Spectrum People Coordination and Communication Issues The Product 2.3 Software Process and Project Metrics Measures, Metrics, and Indicators Metrics in the Process and Project Domains Software Measurement Metrics for Software Quality Measuring Quality Defect Removal Efficiency 2.4 Process Decomposition 2.5 Summary 2.5 Terminal Question(s) (TQs) 2.7 Multiple Choice Question(s) (MCQs) 2.8 Answers to SAQs, TQs, and MCQs
2.1 Introduction
Project management/Software Project Management is an area of management in which the people, processes and control are monitored and controlled according to the plan. This is an ongoing process throughout the evolution of software from a preliminary concept to an operational implementation. A software engineer is responsible in managing day-to-day activities of planning, monitoring, and controlling. Project managers plan, monitor, and control the work of software engineering team members. Managers at senior level look after the interface between the business and the software professionals. The entire process of software development becomes complex as and when conditions changes and forces a revision in the software. The process involves contribution from number of people working for a long time on the development. In a software
Unit 2
project the management is essentially the management of people, product, project and process. People have to work in a coordinated manner and make their contributions effective towards the development of the software. Another important aspect in the successful development of software is the communication. Communication is a process used for imparting information from a source sender to a destination receiver with the use of some medium of communication. Communication helps in establishing the requirements of the customer clearly and also define the scope of the project software. The development should be appropriate to the people and the product. Effort required for the completion of the project and the time required to complete the project has to be properly estimated through the use of suitable estimation models. The planning must encompass definitions of products, quality checkpoints, and mechanisms to monitor and control activities defined in the plan of the project. Objectives In this unit we will study: How must the people, process, and problem be managed during a software project? What are software metrics and how can they be used to manage a software project and the software process? How does a software team generate reliable estimates of effort, cost, and project duration? What techniques can be used to formally assess the risks that can have an impact on project success? How does a software project manager select the set of software engineering work tasks? How is a project schedule created? How is quality defined so that it can be controlled? What is software quality assurance? Why are formal technical reviews so important? How is change managed during the development of computer software and after delivery to the customer?
Page No.: 17
Unit 2
2.2 The Management Spectrum

The four Ps: people, product, process, and project are the main points to focus on during the management of a software project. Software project manager has to pay attention to the risks involved in the processes of the project. Else the manager runs the risk of inducting competent technical methods and tools into the project process. This will decide the fate of the success of the software project. (1) The People: For people, recruitment, selection, performance, training, compensation etc play a key role in the maturity model. It is also important to note that organizations that achieve high levels of maturity in people management models have been effectively implementing software engineering. (2) The Product: The product objectives and scope are defined by customers and the software managers/engineers. This follows the steps of initial software engineering process establishment and development. This enable the manager to do an effective software requirements analysis. Product relevant objectives have to be stated. The product scope defines the functions and the primary data. It indicates the relationship and behavior. Alternative solutions are developed. The managers work on the alternatives and select the best alternative under the limitations of deadlines, personnel availability, budgetary restrictions, technical interfaces, etc. (3) The Process: Based upon the complexity of the processes involved in a project development, the entire development process can be broken down into number of small processes which can all be set with a framework of overall software development. Different tasks and products, along with quality assurance points enable the framework of activities to be adapted to the characteristics of the software project. (4) The Project: the only way to manage complex software projects is to go about it in a planned and a controlled manner. The success rate of the project depends a lot on the planning and the contribution by people working on the project. In order to avoid project failure, a software project manager, and the software engineers who build the product must avoid warning signs, understand the critical success factors, and
Page No.: 18
Unit 2
develop a commonsense approach for planning, monitoring and controlling the project. Self Assessment Question(s) (SAQs) 1. What is the different management spectrum? 2.2.1 People There are a number of people working on a software project. They are known as players. A player participates in the software processes and perform effective software engineering. (1) The Player The software process has players categorized as follows : 1. Project manager plans, motivate, organizes, and controls the practitioners who work on various processes of the software. 2. Senior manager defines the business issues that has a significant influence on the project and its related processes. 3. Practitioners deliver the technical skills necessary for the product or application. 4. Customers specify the software requirements. 5. End-users are the ones who interact with the system. The software project team has to be very effective and for being effective they have to work in a coordinated manner. The teamwork should be such that one gives the best for obtaining good results from the software project. Team Leader Software project management is an area where lots of people are involved in various processes of the project. The one who manages these people in the team and works toward the success of the software project is the team leader. Motivation: It refers to the act of encouraging the people working on the software project development. Ideas or innovation: the organization should encourage people to create and feel creative. They must work within bounds established for a particular software product or application. A software project manager should concentrate on understanding the problem, managing the ideas, letting everyone on the team understand the importance of quality in the service
Unit 2
and product. The aspects of ideation and innovation may be phased in the following manner : Problem solving: Based upon the problems faced in the past and the solutions derived to solve such problems it becomes easy to the software engineer to device methods to avoid such problems in future. A scheme of handling such situations by means of some techniques and tools and then develop the software reflects effective problem solving. Managerial identity: A project manager must establish good authority on the project development processes. The manager must take into confidence the abilities of the project members and maintain a stable and competitive environment in order to effectively develop the project. In all these activities the project manager establishes the identity of his or her being a successful leader. Achievement: Managers have to take initiatives to encourage the team members to optimize the productivity of a project team. Influence and team building: A project manager must understand the attitude of the people and understand their signals in terms of satisfaction or dissatisfaction. Even if the situation is tough the manager must keep calm and handle the situation. Self Assessment Question(s) (SAQs) 1. What do you mean by people? 2. What is the different category of player? 2.2.2 Issues regarding Coordination and Communication Software projects are disturbed because of various reasons. One of the reasons is the scale of the project. Scale refers to the size of the project, the magnitude of the effort, complexities involved in the project and the size of the team working on the project or a part of the project. Another reason is the Uncertainty because of the changes in the project characteristics. Interoperability ie. Communication between the old modules of the software and the new modules could be another reason. To deal with these factors the team members can work in a coordinated manner. As per Kraul and Streeter, project coordination techniques are categorized in the following manner:
Unit 2
Formal, impersonal approaches include software engineering documents and deliverables (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data. Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections. Informal, interpersonal procedures include group meetings for information dissemination and problem solving and collocation of requirements and development staff. Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members. To assess the efficacy of these techniques for project coordination, Kraul and Streeter studied 65 software projects involving hundreds of technical staff; this expresses the value and use of the coordination techniques just noted. Referring to the figure, the perceived value (rated on a seven point scale) of various coordination and communication techniques is plotted against their frequency of use on a project. Techniques that fall above the regression line were judged to be relatively valuable, given the amount that they were used. Techniques that fell below the line were perceived to have less value. It is interesting to note that interpersonal networking was rated the technique with highest coordination and communication value. It is also important to note that early software quality assurance mechanisms (requirements and design reviews) were perceived to have more value than later evaluations of source code (code inspections). Self Assessment Question(s) (SAQs) 1. What are the different project coordination techniques? 2.2.3 The Product A software project manager has to work on quantitative estimates and suitable plan to deliver the intended product. Analysis pertaining to the
Unit 2
requirements of the software has to be done to get proper estimates on the product and its performance. Time is the major constraint. A minimum scope of the product has to be established. (1) Software Scope Determination of software scope is the first step. By answering the
following questions it becomes easy to determine the scope:

Context: Understand the software product under the framework of the various constraints in the system and the requirements of the system in which the product is expected to work. Information objectives: It refers to object visible to the customers. What are the outputs from the software and what are the inputs to the software? Function and performance: Understand the functions of the software. Understand the transformation job of each function of the software. The functions should be clearly stated so that the management and technical people can understand it easily. (2) Decomposition of the Problem It is also known as partitioning. It is the core software requirement analysis step. Decomposition is done with respect to the functionality of the software and the process. It means a complex problem is partitioned into smaller problems. Smaller problems are easy to manage. Self Assessment Question(s) (SAQs) 1. What are the software scopes? 2. Problem decomposition are sometimes called _________________ or ________________.
2.3 Software Process and Project Metrics

Software metrics refers to various methodologies of measurements for software. For continual improvement in the software, it is necessary to have a measurement done for the software with respect to its functionality and utility. Measurements are used in a software project for various estimations, quality controls, assessment of productivity, and various controls.
Page No.: 22
Unit 2
2.3.1 Measures, Metrics, and Indicators The necessity of measuring a software product process is to evaluate, to predict, or to improve. For the measurements it is necessary to understand the processes, products, resources, and environment in which the software works, and establish a reference to track the progress. Status should be brought out to review the progress. This will help identify the deviations and thereby control the project. These measurements helps in predictions and predictions in turn will help in setting up various plans. Self Assessment Question(s) (SAQs) 1. What do you mean by metrics? 2. What do you mean by an indicator? 2.3.2 Metrics in the Process and Project Domains There is always a dilemma as to which metrics is appropriate and which is not in software engineering. The question is whether it could have been better than what it is now? Obtaining a suitable measurement indicator is always a challenge before the software engineer and the software manager. An indicator is a metric or a combination of metrics on the software process. An indicator enables the project manager or software engineer to improve the process through adjustments. 1) Process Metrics and Improvement of Software Process: The best way to develop and improvised metric process is to concentrate on specific process attributes, and provide indicators leading to adoption of a methodology for improvement. Measure the efficiency of every process based on the outcomes. Outcomes may be assessed based on the error rate, defect rate, human effort, time required and conformance to schedule. 2) Software Metrics Software process metrics are meant for analyzing strategic issues and are used for the work flow in the project and related technical activities. To estimate time and effort for current activities, details of metrics and outcomes are collected from past identical projects. It helps in understanding the variances in the ongoing project if any. The project manager monitors and controls the progress of the project based on the indicators on each attribute of the process. One process output
Unit 2
performance affects the input of another process. It is a chain reaction. Hence every process becomes significant in terms of quality delivery. Self Assessment Question(s) (SAQs) 1. What do you mean by software metrics? 2.3.3 Software Measurement Software measurements are of two types (a) direct measurements include cost and effort pertaining to the software leading to measurement of number of lines of codes, speed, size of memory, error rate and (b) Indirect measurements includes functionality, quality, reliability, efficiency, complexity and maintainability of the product. 1) Size oriented metrics: Normalizing quality and productivity measures can be done by considering the size of the software. To indicate the size of the software a simple record of the size or a table of information on the size may be maintained by the organization for the last few years. The effort and cost recorded in the table represents all activities. 2) Function oriented metrics: It refers to the functionality delivered by the software application. Functionality cannot be measured directly. Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the function point. Function points are derived using an empirical relationship. 3) Extended Function Point Metrics: The function point measure was inadequate for many engineering applications but was suitable in most of the cases for business applications. Self Assessment Question(s) (SAQs) 1. What are the different types of software measurement techniques? 2.3.4 Metrics for Software Quality: The software engineers have to work towards achieving a good quality system and good product. For this purpose they have to resort to good techniques along with suitable software process. They along with the managers of the project have to evaluate quality at every stage of the
Unit 2
project. The main objective in doing so should be to measure and control errors and defects. Effectiveness has to be measured. 2.3.5 Measuring Quality As per Gilb the following are the definitions and measures of quality: Correctness: A program must operate correctly or it provides little value to its users. Correctness is the degree to which the software performs its required function. The most common measure for correctness is defects per KLOC. Maintainability: Software maintenance accounts for more effort than any other software engineering activity. Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements. A simple time-oriented metric is mean-time-to-change (MTTC), the time it takes to analyze the change request, design an appropriate modification, implement the change, test it, and distribute the change to all users. Hitachi has used a cost-oriented metric for maintainability called spoilage the cost to correct defects encountered after the software has been released to its end-users. When the ratio of spoilage to overall project cost (for many projects) is plotted as a function of time, a manager can determine whether the overall maintainability of software produced by a software development organization is improving. Actions can then be taken in response to the insight gained from this information. Integrity: Software integrity has become increasingly important in the age of hackers and firewalls. This attribute measures a system's ability to withstand attacks (both accidental and intentional) to its security. Attacks can be made on all three components of software: programs, data, and documents. To measure integrity, two additional attributes must be defined: threat and security. Threat is the probability (which can be estimated or derived from empirical evidence) that an attack of a specific type will occur within a given time. Security is the probability (which can be estimated or derived from empirical evidence) that the attack of a specific type will be repelled. Usability: The catch phrase "user-friendliness" has become ubiquitous in discussions of software products. If a program is not user-friendly, it is often
Unit 2
doomed to failure, even if the functions that it performs are valuable. Usability is an attempt to quantify user-friendliness and can be measured in terms of four characteristics: (1) the physical and or intellectual skill required to learn the system, (2) the time required to become moderately efficient in the use of the system, (3) the net increase in productivity (over the approach that the system replaces) measured when the system is used by someone who is Moderately efficient, and (4) a subjective assessment (sometimes obtained through a questionnaire) of users attitudes toward the system. Self Assessment Question(s) (SAQs) 1. What are the different quality measurement techniques? 2.3.6 Defect removal efficiency (DRE) DRE is a measure of the filtering ability of quality assurance and control activities. When considered for a project as a whole, DRE is defined in the following manner: DRE = NE/(NE + ND) Where NE is the number of errors identified before the delivery of software and ND is the number of defects found after delivery. Value of DRE is 1 under ideal situations. This happens when there are no errors. Self Assessment Question(s) (SAQs) 1. What do you mean by defect removal?
2.4 Process Decomposition

While dealing with any software project, one must look into the flexibility options available to deal with the project. If a project is similar to an earlier executed project, then a simple linear sequential approach may be adopted to deal with the project. If the constraints are severely imposed on the project specially the time constraint, then RAD (Rapid Application Development) model is more appropriate. Incremental strategy would be the best if the deadlines are very tight. Once the process model is chosen, CPF (common process framework) involving customer communication, planning, risk analysis, etc may be applied. Process decomposition involves decomposing a task into number of small tasks to accomplish the task, one by one by means of various events leading to the main task. The sub task
Page No.: 26
Unit 2
list varies from project to project depending upon the complexities of the project.
2.5 Summary
Software project management is an umbrella activity within software engineering. It begins before any technical activity is initiated and continues throughout the definition, development, and support of computer software. Four Ps have a substantial influence on software project management people, product, process, and project. People must be organized into effective teams, motivated to do high-quality software work, and coordinated to achieve effective communication. The product requirements must be communicated from customer to developer, partitioned (decomposed) into their constituent parts, and positioned for work by the software team. The process must be adapted to the people and the problem. A common process framework is selected, an appropriate software engineering paradigm is applied, and a set of work tasks is chosen to get the job done. Finally, the project must be organized in a manner that enables the software team to succeed. The pivotal element in all software projects is people. Software engineers can be organized in a number of different team structures that range from traditional control hierarchies to open paradigm teams. A variety of coordination and communication techniques can be applied to support the work of the team. In general, formal reviews and informal person-to-person communication have the most value for practitioners. The project management activity encompasses measurement and metrics, estimation, risk analysis, schedules, tracking, and control. Each of these topics is considered in the chapters that follow.

1. The Software Engineering Institutes people management capability maturity model (PM-CMM) takes an organized look at key practice areas that cultivate good software people. Your instructor will assign you one KPA for analysis and summary. 2. You have been appointed as project manager for a major software products company. Your job is to manage the development of the next generation version of its widely used word-processing software. Because competition is
Unit 2
intense, tight deadlines have been established and announced. What team structure would you choose and why? What software process model(s) would you choose and why? 3. Describe the difference between process and project metrics in your own words. 4. What is an indirect measure and why are such measures common in software metrics work?

1. Different Management Spectrum (a) People (b) Project (c) All the above (d) none of these 2. What are the different software practices and projects? (a) Measure (b) Metrics (c) All the above (d) none of these
2.7 Answers to SAQs, TQs and MCQs

2.7.1 Answers to Self Assessment Question(s) (SAQs) 2.2 People, project, product, process 2.2.1 1. Refer to 2.2.1 2. Software team, team leader, end user, customer etc. 2.2.2 Formal impersonal approaches, interpersonal procedures, Informal interpersonal procedures, Electronic communication etc 2.2.3 1. Context, inform objective, function and performance 2. Partitioning, problem elaboration 2.3.1 1. Refer to 2.3.1 2. Refer to 2.3.1 2.3.2 Software process metrics are used for strategic purposes. Software project measures are tactical. 2.3.3 Specific oriented, Function Oriented, Extend function 2.3.5 Correctness, Maintainability, Integration, Usability 2.3.6 A quality metric that provides benefit at both the project and process level is defect removal efficiency (DRE).
Page No.: 28
Unit 2
2.7.2
Answers to Terminal Question(s) (TQs) refers 2.3.1 refers 2.2.1 refer 2.3.2 Answers to Multiple Choice Question(s) (MCQs) 1. c 2. c
2.7.3
Page No.: 29
Unit 3
Unit 3
Software Project Planning, Scheduling, Tracking and Risk Management
Structure: 3.1 Introduction Objectives 3.2 Observation and Estimation Project Planning Objectives Software Scope Resources Software Project Estimation Decomposition Techniques Empirical Estimation Models The Make/Buy Decision 3.3 Risk Analysis and Management Reactive versus Proactive Risk Strategies Software Risks Risk Identification Risk Projection Risk Refinement Risk Mitigation, Monitoring, and Management 3.4 Project Scheduling and Tracking The Relationship between People and Effort Defining a Task Set for the Software Project Selecting Software Engineering Tasks Defining a Task Network Earned Value Analysis Error Tracking The Project Plan 3.5 Summary 3.6 Terminal Question(s) (TQs) 3.7 Multiple Choice Question(s) (MCQs) 3.8 Answers to SAQs, TQs, and MCQs
Page No.: 30
Unit 3
3.1 Introduction
Software project management begins with project planning. The work to be done and the planning of the resource have to be done keeping in mind the various objectives of the project work and the constraints on the resources that are going to be utilized. Another important factor is the time factor which needs to be estimated well in advance to control the progress of the project. The entire planning has to be done vey systematically and scientifically. Project of identical nature to the current project which has been executed in the past should be studied and understood to bring in necessary control in the ongoing project. Past experience on the project will always add value to the execution of the current project. Any past experience will help in developing the software easily. Objectives In this unit you will learn: The software planning process The risk management planning The software tracking and scheduling
3.2 Observation and Estimation

There will be risks associated with every project. The nature and magnitude of the risk depends upon the various forces that affect the project modules and the project as a whole. Hence there is a need to estimate the resources and prepare appropriate schedule for a software engineering effort. This requires a lot of experience and also the support of historical data will strengthen the process. Estimations are subjected to some risks and such risks leads to uncertainty. Uncertainties increase the project complexity thereby affecting the project plan. A number of methods are available today to measure complexities in the system. Most of the methods are applicable at the design level of the software. At the planning stage it is not convenient to apply such methods. Another factor that affects the accuracy of the estimates is the Project size. One should not forget the Murphy's law which states that What can go wrong will go wrong and if there are more things that can fail, more things will obviously fail.
Page No.: 31
Unit 3
Self Assessment Question(s) (SAQs) 1. ___________ increase the project complexity thereby affecting the project plan. 2. _________ is another important factor that can affect the accuracy and of estimates. 3.2.1 Project Planning Objectives There are a number of project planning objectives. Though there are a number of objectives in a software project the most important one is the objective which is focused on planning. It emphasizes on the framework enabling the manager to make estimates of resources, cost, and schedule. These estimates serve as checkpoints for monitoring the entire project during the course of its progress from start to finish. Also check point must reflect on the extreme values of the outcome of each stage so that the entire development process remains under control within the extreme values. These checkpoints on extreme values serve as boundaries which can help the manager to validate the outcomes of each stage. Self Assessment Question(s) (SAQs) 1. What is the objective of any project planning? 3.2.2 Software Scope Determination of software scope is the first activity in software planning. To determine the scope one has to understand the functionality and performance of the module in the software. The scope statement should be bounded. Software scope must include data, controls, functions, performance, constraints, interfaces, and reliability. Based on the software metrics of the completed projects, estimates and schedules can be prepared with greater accuracy leading to reduction in risks. Risk is measured by the degree of uncertainty in the quantitative estimates pertaining to resources, costs and schedule. The software planner must achieve completeness of function, performance, and interface definitions. A preliminary discussion between the software engineer/manager with the customer can be structured enough to narrow the focus on to the determination of the software scope else it may take number of meetings to actually determine and define a proper scope. After this phase a feasibility study will have to be conducted on the initial system design and requirements.
Unit 3
Self Assessment Question(s) (SAQs) 1. The first activity in software project planning is the determination of _______. 2. Based on the _________ of the completed projects, estimates and schedules can be prepared with greater accuracy leading to reduction in risks. 3.2.3 Resources The second activity in software planning is the estimation of the resources. Resources for software projects are the hardware and software tools. They provide the infrastructure to support the development of the software. Reusable software components are found at higher levels of the development process governed by people. It is possible to determine the number of people required for a software project only after an estimate of development effort has been made. Unit of development effort is generally expressed as person-months. It may become useful to identify the software components from the past projects that may be reused. Reusability leads to optimization of the software resources. Self Assessment Questions 1. What are the different resources? 3.2.4 Software Project Estimation In estimating the software cost and effort the software engineer will have to consider variables like human, technical, environmental and political. These variables are found to affect the ultimate cost of software and effort. If the estimates are based on projects completed in the past which are identical to current one then the chances of errors creeping in reduces. One may even use a decomposition technique to estimate the project. A number of empirical estimation models may also be used with a fare degree of accuracy. Self Assessment Questions 1. Software ____ and _____ are affected by variables like human, technical, environmental and political. 3.2.5 Decomposition Techniques While dealing with software project estimation for large size software, it is convenient to estimate after decomposing the entire project process into
Unit 3
number of smaller process and then estimate. The entire software project problem can also be broken down into number of smaller problems and then each smaller problem could be solved easily. Software project estimation is a form of problem solving. 3.2.1.1 Software Sizing The prediction of accuracy of software project estimate is based on size of the product to be built, ability to translate size into human effort, time and money and the environment that supports the effort of software engineering. 3.2.1.2 Problem-Based Estimation Lines of code (LOC) and function points (FP) are used as estimation variables to "size elements of the software. LOC and FP are used in conjunction with estimation variables to develop cost and effort predictors for various projections. As mentioned earlier the software scope is considered and various functions are listed out. For each of the functions LOC and FP are estimated. Example of estimation Process Based: Estimation is done by considering the various activities and tasks involved in a project. A list of functions involved in operating the various elements of the software and the corresponding standard requirements are stated and points are assigned to each function. There may be a list of parameters for each function for the purpose of estimation. The points are converted into percentages and expressed as effort. The data may be collected through a customer process by way of feedback on the functions. 3.2.1.3 Software Equation: Based on the productivity data collected for over thousands of contemporary software projects and estimation model may be considered in the form of a software equation as given below: EPM = ( L x Sk(1/3) /PP)3 x(1/d4) Where EPM effort in person months L number of code line Sk factor of special skills PP parameter of productivity d duration
Page No.: 34
Unit 3
3.2.1.4 A decision tree A decision tree is helpful in analyzing a software problem which has multiple decision stages. Each stage is represented by a node (rectangle). The multiple options available at this node are represented as branches of this node in the form of straight lines. Each branch of the tree represents alternatives and it may further lead to some probable events/outcomes. Each such event is associated with a probability value and some cost ( utile) / gain (+ utile). A utile is a monetary value. Nodes which represent probable outcomes are known as chance nodes and are represented by circles. A connection of such nodes and branches constitute a decision tree. Problems associated with risks can be well represented by a decision tree.
P-1
Str-1
A
P-2
Str-3
1
Str-2
Str-4
3.2.1.5 Automated Estimation Tools Automated estimated tools are useful to estimate cost and effort and to perform what-if analysis for variables in projects such as staffing and delivery rate. They exhibit characteristics like sizing of the deliverable, proper selection of activities, estimation of staffing levels and software effort/cost and schedules. Self Assessment Questions 1. What are the different decomposition techniques? 3.2.6 Empirical Estimation Models An estimation model used for estimation of software is used to predict effort as a function of LOC or FP. Number of sample projects considered to derive such models are small. Hence the reliability on such small sample data based empirical relations is less.. For this reason, no estimation model is
Unit 3
appropriate for all classes of software and in all development environments. Therefore, one must judiciously use the results obtained from such models. (i) The Structure of Estimation Models A regression analysis is used to derive the model based on data collected from past software projects. Most of the forms follow the pattern Y = a + bX, where a and b are the regression constants In addition to the above relationship, majority of estimation models have some form of project adjustment component. Among the many LOC-oriented estimation models proposed in the literature are E = 5.2 x (KL) 0.91 Walston-Felix model E = 5.5 + 0.73 x (KL)1.16 Bailey-Basili model E = 3.2 x (KL)1.05 Boehm simple model E = 5.288 x (KL)1.047 Doty model for KL > 9 FP-oriented models have also been proposed. These include E = 13.39 + 0.0545 FP Albrecht and Gaffney model E = 60.62 x 7.728 x 10-8 FP3 Kemerer model E = 585.7 + 15.12 FP Matson, Barnett, and Mellichamp model Estimation models needs to be calibrated before actually it is used. (ii) The COCOMO Model Barry Boehm in his book on Software Engineering Economics has introduced a number of software estimation models known as COCOMO, for COnstructive COst Model which has evolved into COCOMO II. COCOMO II addresses the following: Application composition model: This model is useful in the intitial stages of software engineering when prototyping of user interfaces, interactions of software and system are considered, assessment of performance is done and the evaluation of maturity of technology. Early design stage model: Once the requirements have been listed out and stabilized this model becomes useful. Post-architecture-stage model: construction of the software. Useful during the process of
Self Assessment Questions 1. What are the different Empirical Estimation Models?
Page No.: 36
Unit 3
3.2.7 The Make/Buy Decision It is observed that buying a software application is more cost effective than getting the entire software developed. This is one of the challenges before every software engineer/ manager. In addition to this a number of options as listed below makes it difficult to the software engineering managers. 1) software purchased off-the-shelf, 2) full-experience or partial-experience software components may be subjected to changes 3) software may be custom built The acquisition of software is governed by the criticality of the software to be purchased and the end cost. For expensive software products, the following guidelines may be considered: 1. Develop specifications for function and performance. 2. Define measurable characteristics. 3. Estimate the internal cost Various make/buy decision techniques are : Constructing Decision Trees. Outsourcing. Automated Estimation Tools. Self Assessment Questions 1. What are the different make/buy decision techniques?
3.3 Risk Analysis and Management

3.3.1 Reactive versus Proactive Risk Strategies A majority of software teams work on a structured framework of risk strategy. The framework consists of only the likely risks which are anticipated during the process of development of software. Whenever there is a problem outside the framework then the software team adopts measures on a case to case basis to solve the problem which is referred to as fire fighting. When fire fighting doesnt help then crisis management takes over, and the project gets into real stiff situation. Self Assessment Questions 1. What do you mean by fire fighting mode?
Page No.: 37
Unit 3
3.3.2 Software Risks Software risks are analyzed and managed by careful consideration of all the forces that act on the software processes. It is derived from thorough study of the people, the product, the process, and the project. Contingency plans have to be prepared to manage risks in software development processes which should be realistic. Risk may or may not be there in a project or project process. But if it does exist then it may result in severe losses to the project. Project risks always poses a threat to the project plan. If project risks become real, it is likely that project schedule hampers and results in increased project costs. Project complexity, size, and the uncertainties of the project are factors contributing to project risks. Self Assessment Questions 1. What are the different Software risks? 3.3.3 Risk Identification A project manager is always on the lookout for risks which might hamper the progress of the project work. The main two types of risks are generic risks and product specific risks. Generic risks are always a threat to every software project. Product-specific risks are specific to the product characteristics and can be identified only by those who have a clear understanding of the technology, the people, and the environment. To identify product-specific risks, the project plan and the software statement of scope are examined. A checklist of risk items are prepared to systematically identify the risks in a project which can be used in the following categories: Product size risks associated with the overall size of the software to be built or modified. They pertain to Business impact risks associated with market constraints Customer characteristics risks associated with the characteristics identified and listed by the customer Process definition risks associated with the degree to which the software process has been defined Development environment risks associated with the availability and quality of the tools Technology to be built risks associated with the complexity of the system
Page No.: 38
Unit 3
Staff size and experience risks associated with the overall technical and project experience of the software engineers.
3.3.4 Assessing risks, components, drivers, safety risks and hazards: Risks can be assessed overall by taking risk data through surveys. A number of questions as part of questionnaire can be framed as a tool to collect data, which can then be used to analysis and assess risks in software projects. The project may be at risk depending upon the number of negative responses obtained during the survey. Manager has to identify the risk drivers that affect the risk components in a project. One must identify the software performance costs and the relevant controls. Safety risks and hazards can occur during installation of software or even after its installation. These are associated with the software failure. These are the quality assurance activities which can affect performance of the software and hence the overall software. If it is possible to identify the risks at an early stage of the development, then automated functions can be incorporated to eliminate if encountered in future. 3.3.5 TSS value, Timeline and Tracking A TSS Task set selector is a selector used to select a set of tasks, which would be appropriate to a project. The task set will be different for different projects. It is a collection of software work tasks, deliverables which are to be completed to compete the project. For an effective development of the software one must a well defined task set. Different degrees of rigor may be considered in selecting a set of task for a project. Some of them are structured, casual, strict and reaction. The task set becomes the basis for the preparation of task network. It is also known as activity network. The monitoring the such a network of tasks is done with the help of a time line chart which indicates the start time of an activity, its duration and its finish time followed by the next activity and so on till the last activity is reached and completed. The project map which reflects the entire project schedule is the basis for tracking the project and its performance. Tracking can be done through project meetings and reviews, measuring the progress of each activity, evaluating the performance, comparing performances, and understanding the gaps for future course of action to be decided.
Page No.: 39
Unit 3
Self Assessment Questions 1. _________________ is a systematic attempt to specify threats to the project plan. 3.3.6 Risk Projection Risk projection rates each risk in two ways the likelihood that the risk is real and the consequences of the problems associated with the risk, should it occur. Risk projection is also known as risk estimation. The risk projection activities are: 1) establish a scale to indicate the likelihood of a risk, 2) list out the consequences of the risk, 3) estimate the impact of the risk and 4) determine the overall accuracy of the risk projection Self Assessment Questions 1. Risk projection is also called _____________ 3.3.7 Risk Refinement After the commencement of the project, during the initial stages the statements on risks appear to be vague and general. Only after some progress of the project does it become possible to clearly state the risks. it may be possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and manage. One way to do this is to represent the risk in condition-transition-consequence (CTC) format [GLU]. The condition can be refined in the following manner: Subcondition 1: Certain reusable components were developed by a third party with no knowledge of internal design standards. Subcondition 2: The design standard for component interfaces has not been solidified and may not conform to certain existing reusable components. Subcondition 3: Certain reusable components have been implemented in a language that is not supported on the target environment. The consequences associated with these refined sub conditions remains the same, but the refinement helps to isolate the underlying risks and might lead to easier analysis and response.
Unit 3
Self Assessment Questions 1. What are the different conditions for risk refinement? 3.3.8 Risk Mitigation, Monitoring and Management The risk analysis activities help the software team to develop strategy to deal with risks. An effective strategy is generally based on the following issues of risk: avoidance monitoring contingency planning Risk management Avoidance is the best strategy if the team adopts a proactive approach. The following steps may be followed : Meet current staff to determine causes for turnover. Mitigate causes of risks as quickly as possible Assume turnover will occur Organize project teams so that information is communicated well among each member Define documentation standards and their requirements Establish mechanisms to ensure proper upkeep of the documents Conduct peer reviews of all work Self Assessment Question(s) (SAQs) 1. What is the main goal of risk analysis?
3.4 Project Scheduling and Tracking

In the process of development and delivery of the software it is found that most of the time the delivery of the finished product is delayed. There are many reasons that could be attributed to the delayed delivery of the product. Some of the reasons which leads to the delay of the project are listed below: Very often the requirements are not clearly stated by the customer and this leads to further changes in the developments which on the whole causes a delay in the project completion. Setting up of deadlines which are unrealistic based on the inputs from agencies outside the software development group.
Page No.: 41
Unit 3
Improper or underestimated amount of the effort and the number of the resources required to do the job. Inaccurate tools to monitor and track the project progress Certain risks that were not considered during the planning process leading to development of bottlenecks in the project. Also there could be one or more problems related to the technicalities in the project Improper communication systems within and outside the development area of the software.
3.4.1 People and Effort - Relationship It is a well known fact that for small projects less number of people are required and for large projects more people are required. The team working on the project understands the requirements of the projects, analyze the constraints and the conditions under which the product has to be developed. They have to have a strong design and analytical mind to execute the project as per the plan. As the requirements increases or as the complexity in the project increases there might be a need to add more people into the team to share the work. Sometimes it is successful and sometimes not. Since more people would either gel well in the system team or add confusion in the team. It is necessary to carefully assess the need to add more people in the team by means of proper estimation of the effort and load involved. Empirical relationships may also be used to estimate the project completion in terms of the code lines to be delivered in the product completion. Similarly the effort distribution in the project can be streamed. It is believed that the effort distribution in a project generally follows a 40-2040 rule. This means about 40% of effort is towards front end and design aspect. 20% of effort goes towards coding and the remaining 40% is towards back end tasks. Self Assessment Question(s) (SAQs) 1. Explain the relationships between people and effort. 3.4.2 Defining a Task Set for the Software Project It is not always possible to define a unique set of task which would be appropriate for all types of projects. It is dependent on the size of the project, complexities involved in the project, constraints of the projects and the skill set and capabilities of the team members working on the project.
Unit 3
The task set is defined based on the category of the project which is dealt with by the development team. The categories of project work that are normally encountered are: 1. Projects dealing with development of new concepts in business. 2. Projects dealing with development of new applications in business as indicated in the requirements list stated by the customer. 3. Projects dealing with the enhancement of existing facilities in the product. 4. Project dealing with maintenance aspects of the business modules or applications. 5. Project dealing with total new structure or restructuring an old system into a new system or application leading to reengineering. Self Assessment Question(s) (SAQs) 1. It is not always possible to define a ________ set of task which would be appropriate for all types of projects. 3.4.3 Selecting Software Engineering Tasks 1. A task has to be properly distributed according to the needs of the project deadlines and set targets. Each project may result in product flow into another type. After completion of one project it leads to another phased project to work on the enhancements. To develop a project schedule, a task set must be distributed on the project time line. Sometimes the projects may lead into what is known as Concept Development instead of enhancements. The trigger for concept development is the necessity of a new technology in a particular area. determines the overall scope of the project. Concept Scoping determines the overall scope of the project. Following tasks are performed leading to Concept development projects: 1. Determine the scope of the project 2. Concept planning which establishes the organizations ability to work as defined in the project scope. 3. Technology risk assessment is done to evaluate the risk associated with the technology. 4. A proof or evidence of the concept to justify the feasibility of the technology in the project.
Page No.: 43
Unit 3
5. Implement the concept in such a manner that the customer would understand it and review it and based on this react. Self Assessment Question(s) (SAQs) 2. In order to develop a project schedule, a task set must be _______on the project time line. 3. ____________determines the overall scope of the project. 3.4.4 Defining a Task Network Tasks and Subtasks are related to each other in the sequence of project network. When there are more people working on the project there is a chance of people working parallel on different tasks. Under this situation, a good control system has to be established to monitor the parallel tasks. Task network is also known as Activity network. Activity network can be represented graphically. Sometimes it is used as a methodology through which sequence of tasks and dependencies are input. 3.4.5 Earned Value Analysis Earned value analysis is a quantitative technique to assess the progress in the project activities. The assessment is somewhat difficult as it involves qualitative analysis of various factors affective the progress of the project. There is an element of subjectivity which is difficult to measure. Hence earned value analysis is considered very important in assessments of activities in a project. As per Humphrey, the earned value system provides a common value scale for every project task, regardless of the type of work being performed. The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total. Earned value is a measure of progress expressed as percentage of completed project. As per Fleming and Koppleman earned value analysis provides accurate and reliable readings of performance from as early as 15 percent into the project. Earned value can be determined as follows: [Source : Software Engineering- By Roger S Pressman] 1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. The work (in person-hours or person-days) of each software engineering task is planned. Hence,
Unit 3
BCWSi is the effort planned for work task i. To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule. 2. The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence, BAC = (BCWSk) for all tasks k 3. Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule. Self Assessment Question(s) (SAQs) 1. What do you mean by earned value analysis? 2. ____________________enables us to assess the percent of completeness of a project using quantitative analysis rather than rely on a gut feeling. 3.4.6 Error Tracking A team that works on a project to deliver the product or the services might end up committing an error. The errors introduced could be at different levels associated with different processes. If a record of such errors over number of projects is maintained, it can become a useful source of information to take decisions on similar errors in future. The manager may even develop a process to manage such errors based on an appropriate decision model to tackle the errors. Suitable metrics and measure may be used to handle errors of similar nature if errors recurs. This process can become one of the useful sources of information to report the status of the project progress. Self Assessment Question(s) (SAQs) 1. _______________can be used as one means for assessing the status of a current project. 3.4.7 The Project Plan A Project plan refers to a blue print of the project plan and its execution. A plan has to indicate clearly the scope of the project , resources required, risks associated and the corresponding risk management techniques, management review plan, cost aspects and the methods and measure to
Unit 3
ensure quality in the project. The project plan is represented in different forms dependent on the type of user of the document of plan. The project plan on the whole acts as a source of information to planner and executers. The executers benefit from the project plan in the sense that they will have the idea of how to monitor and control the progress of the project and to ensure that the project throughout is kept on track. Self Assessment Question(s) (SAQs) 1. What do you mean by project plan?
3.5 Summary
The software project planner estimates (i) time the project will take for completion, effort required and the manpower needed. The project planner must also know how to analyze future requirement of the project in terms of manpower and other related resources. The scope of the project enables the project manager to develop suitable estimates. The estimates involves understanding (1) the number of Lines of codes (2) values within the information domain, (3) manpower size or (4) the number of person-months required. Empirical techniques and automated tools may be used to predict project quantities. The time spent identifying, analyzing, and managing risk results in stabilizing the project progress, guiding the project smoothly towards its completion, along with tools and techniques to track and control a project.

1. Develop a list of software characteristics (e.g., concurrent operation, graphical output) that affect the complexity of a project. Prioritize the list. 2. Performance is an important consideration during planning. Discuss how performance can be interpreted differently depending upon the software application area. 3. Provide five examples from other fields that illustrate the problems associated with a reactive risk strategy.

1. What are the different ways of creating project schedule? (a)Time Line Chart (b) Gantt Chart (c) all the above (d) none of these 2. Which of the following are the project scheduling methods? (a) PERT (b) CPM (c) All the above (d) none of these
Unit 3

3.8.1 Answers to Self Assessment Question(s) (SAQs) 3.2.1 1. Uncertainty 2. Project size. 3.2.2 The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. 3.2.3 1. Software scope 2. Software metrics 3.2.4 Refer to section 3.2.4 3.2.5 Cost and effort 3.2.6 Software sizing, problem based estimation 3.2.7 The Structure of Estimation Models, COCOMO model 3.2.8 Creating a Decision Tree, Outsourcing, Automated Estimation Tools 3.3.1 Refer to section 3.3.1 3.3.2 Uncertainty, loss 3.3.3 Risk identification 3.3.4 Risk estimation 3.3.5 Refer to section 3.3.5 3.3.6 To assist the project team in developing a strategy for dealing with risk. 3.4.1 Refer to 3.4.1 3.4.2 Unique 3.4.3 Distributed, Concept scoping 3.4.4 Refer to section 3.4.4, Earned Value Analysis 3.4.5 Error tracking 3.4.6 Refer to section 3.4.6 3.8.2 Answers to Terminal Question(s) (TQs) 1. Refer to section 3.2.5 2. Refer to section 3.2.7 3. Refer to section 3.3.4 3.8.3 Answers to Multiple Choice Question(s) (MCQs) 1. c 2. c
Page No.: 47
Unit 4
Unit 4
Software Quality Assurance
Structure 4.1 Introduction 4.2 Software Quality Assurance Quality Concepts The Quality Movement Software Reviews Formal Technical Reviews Software Reliability Background Issues Software Quality Assurance Activities SQA plan 4.2 Summary 4.3 Terminal Question(s) (TQs) 4.5 Multiple Choice Question(s) (MCQs) 4.6 Answers to SAQs, TQs, and MCQs
4.1 Introduction
The main objective of software engineering is to produce high quality software. But the question is What is meant by software quality ? According to Philip Crosby - The problem of quality management is not what people don't know about it. The problem is what they think they do know . . . Most of the software engineers believe that the quality of software begins only after the software has been developed and implemented. In many cases the software engineers start anticipating the quality issues that are likely to be of importance and work towards development in that direction. Irrespective of nature of approach it is the Software quality assurance (SQA) that is applied throughout the software development process. Objectives In this chapter you will learn: What is software quality assurance? How does it work? What is work product? How is it important?
Unit 4
4.2 Software Quality Assurance

4.2.1 Quality Concepts It is a well known fact that all engineered and manufactured parts exhibit some or the other variation. The variations may not be clearly visible always. The variations are sometimes microscopic which can be identified by means of some equipment necessary to measure the geometrical attributes, electrical characteristics etc. Quality Designers specify the characteristics of the quality of a product. The grade of materials used in the product development and product characteristics, permissible tolerances, and performance specifications contribute to the quality of design. For higher-grade of materials the tolerances are very small. When the tolerance is set to a very low level the expected design characteristics would be of high quality. When greater levels of performance are specified, there is an increase in the design quality of a product and the manufacturing processes and the product specification are set according to the specified quality norms. Quality of conformance is expressed as the degree to which the design specifications are followed during the process of manufacturing. If the degree of conformance is high then the level of quality of conformance is also deemed as high. Quality of conformance is mainly focused on the implementation of the software. Quality Control Quality is the buzz word of every organization today. But how does one work towards achieving quality in the organization and within the organization at various process levels. There are a number of ways of achieving quality. One can consider the fundamental step of quality where the variations are measured with respect to the expected values in any process or characteristics of the product. The first step towards quality is to see that the variations are minimized. Controlling quality can be done by means of measuring various characteristics of the product and understanding the behavior of the product towards changes in the product characteristics. It involves a series of inspections, reviews, and tests on the software processes. A feedback mechanism in the process list will help in
Unit 4
constantly reviewing the performance and enhancement in the performance. A combination of the measurement and the feedback allows the software developer to refine the software process and tend to approach perfection. It is possible to automate these steps in the quality control process of the software system. One of the concepts of quality control is that every process can be measured. The measurement will tell as to whether there has been any improvement in the process or not. Quality Assurance Quality assurance is a process of auditing various areas and identifying the non conformances in such areas. A non conformance is reported if a deviation is observed in the actual performance when compared with the planned performance against certain expectation. The expectations are listed out based on the requirement of certain standards norms. The nonconformances are reported area wise or process wise. The report based on the audit provides the management with the information that is necessary for them to take suitable actions. Cost of Quality There are many activities involved in a software project leading to the completion of the intended service or the product. Every such activity is associated with some cost. And associated with every process is the quality which again comes with certain cost. The total cost of quality means the sum total of all the costs involved in setting up a quality process or a quality activity and additional resources procured towards maintaining and running the quality process. The main categories under which the quality costs may be listed are the ones dealing with processes towards prevention, processes towards appraisal, and processes towards maintenance. The main components contributing towards the cost are the cost component of quality planning, cost component of formal technical reviews and the cost component pertaining to the test equipment. Self Assessment Questions 1. _____________ is a process of auditing various areas and identifying the non conformances in such areas. 2. ______________involves the series of inspections, reviews, and tests used throughout the software process to ensure each work product meets the requirements placed upon it
Unit 4
3. The _________________includes all costs incurred in the pursuit of quality or in performing quality-related activities. 4.2.2 The Quality Movement The quality movement started in the 1940s with a major contribution on quality aspects from W. Edwards Deming. One of the major benefit of quality has been the saving in the overall cost of production. A system of continuous improvement helps in achieving good quality. Kaizen, refers to a system of continuous process improvement. The purpose of kaizen is to develop a process that is visible, repeatable, and measurable. After Kaizen it is atarimae hinshitsu, which refers to examination of intangibles that affect the process and works to optimize their impact. Both kaizen and atarimae hinshitsu focuses on processes. The next stage is kansei which leads to improvement in the product itself and, potentially, to the process that created it. The final stage is miryokuteki hinshitsu which broadens the management concern beyond the immediate product. Self Assessment Questions 1. The first step of quality movement is known as___________. 4.2.3 Software Reviews [Source: Software Engineering Roger S Pressman] Software reviews are a "filter" for the software engineering process. That is, reviews are applied at various points during software development and serve to uncover errors and defects that can then be removed. Software reviews "purify" the software engineering activities that we have called analysis, design, and coding. Freedman and Weinberg discuss the need for reviews this way: Technical work needs reviewing for the same reason that pencils need erasers: To err is human. The second reason we need technical reviews is that although people are good at catching some of their own errors, large classes of errors escape the originator more easily than they escape anyone else. The review process is, therefore, the answer to the prayer of Robert Burns: O wad some power the giftie give us to see ourselves as other see us
Page No.: 51
Unit 4
A review any review is a way of using the diversity of a group of people to: 1. Point out needed improvements in the product of a single person or team; 2. Confirm those parts of a product in which improvement is either not desired or not needed; 3. Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageable. Cost Impact of Software Defects The primary objective of formal technical reviews is to find errors during the process so that they do not become defects after release of the software. The obvious benefit of formal technical reviews is the early discovery of errors, so that they do not propagate to the next step in the software process. A number of industry studies (by TRW, Nippon Electric, Mitre Corp., among others) indicate that design activities introduce between 50 and 65 percent of all errors (and ultimately, all defects) during the software process. However, formal review techniques have been shown to be up to 75 percent effective in uncovering design flaws. By detecting and removing a large percentage of these errors, the review process substantially reduces the cost of subsequent steps in the development and support phases. Defect Amplification and Removal A defect amplification model can be used to illustrate the generation and detection of errors during the preliminary design, detail design, and coding steps of the software engineering process. A box represents a software development step. During the step, errors may be inadvertently generated. Review may fail to uncover newly generated errors, and errors from previous steps, resulting in some number of errors that are passed through. In some cases, errors passed through from previous steps are amplified (amplification factor, x) by current work. The box subdivisions represent each of these characteristics and the percent of efficiency for detecting errors, a function of the thoroughness of the review.
Page No.: 52
Unit 4
Self Assessment Questions 1. What is the use of using review? 4.2.4 Formal Technical Reviews Software engineers participate in all the reviews of the technicalities of the software. A technical review is a software quality assurance activity. The main objectives of the Formal Technical Reviews are : a) to bring out the nature and type of errors related to function, logic or even with respect to the implementation of the software; b) to check that the software development is as per the expectations expressed in the plan; c) to ensure conformance to standards stated with respect to the software under considerations ; d) to manage the project more conveniently and easily. FTR also acts as a forum to provide orientation to members in the team to work on the developments, provide facts leading to new ideas and generation of approaches that could be adopted in the development of the software. The Review Meeting The review meeting is also referred to as executive committee review meeting or the management review. The frequency of the meeting is decided by the review leaders of various functions in the organization. The meeting is structured by the representative of the organization and the review team by means of well defined agenda. The meeting is attended by all the members and leaders of the various functions. There is an in-charge to record the proceedings of the meeting. The in-charge is known as the recorder. The FTR commences with an introduction of the members, welcoming of new members to the meeting, and introduction of the agenda. The meeting then begins agenda wise. The agenda is read out by the representative and discussions on the agenda begin. A report on the agenda is presented by the representative or by the function heads. If any problems are encountered in a particular area, it is discussed at length by the members of the meeting. Suitable corrective actions and preventive actions are decided for implementation. Such action plans are recorded by the recorder. After the completion of the review meeting the members of the
Page No.: 53
Unit 4
review committee would have understood and accepted the action plan resulting in the following : 1) product is accepted without any modification, 2) product is to be rejected because of major errors, 3) product modifications accepted with a clear understanding of the deadlines and the in-charge who would be responsible for the change. i) Review Reporting and Record Keeping The meeting discussions are recorded and the minutes of the meeting are circulated to all the members of the review committee. The minutes are sometimes referred to as the key notes for various reports generated based on the agenda. The contents of the reports are important as it will enable one to understand the areas of strengths and weaknesses in the organization. Review Guidelines Various guidelines are framed with respect to the review agenda and communicated to all the concerned in the organization. The following are some of the minimum guidelines for formal technical reviews: 1. While reviewing the product, errors should be pointed out gently in order not to hurt anybody. The meeting discussion should be taken up positively and should be constructive in suggestion. Once the review session has commenced the members should follow the agenda. The discussion should be related to the agenda. At no point of time during the review should the focus be lost from the agenda. Any clarifications on the agenda should be sought preferably in advance so as to ensure a smooth conduct of the review. The review convener or the head should throughout keep track of the time and the agenda and make arrangements to support the discussions by means of arranging necessary documents, equipments, demonstrations, statistics, reports etc. 2. Recording points for further adjournment : Whenever there is any discussion leading to some kind of debate or arguments or dissent, the convener of the FTR can pitch in and moderate the discussion as the case may be. But if the convener feels that certain points may not be possible to be discussed during the ongoing session then the convener may list out such points as agenda to be discussed in the next meeting
Unit 4
or even adjourn the discussion of FTR to another mutually agreeable date and time as per the convenience of the FTR members. 3. Areas of Problems : Areas which have reported problems during the past performance may be highlighted by the convener so that the such areas can become major areas of discussion. This would enable the members of other similar areas to check upon their activities and control recurring of such problem in their areas. 5. Limiting the members : It is a good practice to keep the FTR members limited to the heads of the functions in the organization. Much before the FTR members of various functions can organize meeting at their functional level and come out with concreted points for the main discussion in the FTR by the Function head. This would create a great impact on the overall outcome of the FTR. The discussion in FTR if limited to only the key persons or the heads it becomes easy to focus on the key points pertaining to the agenda, as otherwise opinions and ideas expressed by many members would lead to confusion and chaos in the FTR. Also the focus on the agenda would get diluted. Self Assessment Question(s) (SAQs) 1. What are the different steps for reviewing guidelines? 4.2.5 Software Reliability The need for quality is there in the minds of everybody associated with the software project. One of the key issues pertaining to the quality aspect is the reliability of the software product. There are number of methods to ensure reliability of the product which depends upon the characteristics of the product and its features and the expectations from the product and its services. One of the task before the software engineer or the software manager is to establish the relevant reliability measures well in advance before the implementation so that the quality is assured. A series of audits may be conducted to keep a tab on the deviations if they tend to occur. Statistically the software reliability may be defined as the probability of an operation of a computer program which is free from error or has not failed during the operation time, tested under a specified environment and for specified time. Failure refers to nonconformance to the requirements of the software stated. One of the simple measures of reliability is the express it as the meantime between failure (MBF) which is the sum of mean time of
Unit 4
occurrence of failure (MTF) and mean time towards repair (MTR). It is necessary to identify and assess the hazards in software projects that affect the software performance. If it is possible to identify the hazards in the early stages of the software project then a module to counteract such hazards could be developed or built in to the software which will then be able to rectify errors leading to hazards. Suitable models could be used to achieve this safety. Background Issues The quality assurance processes are very vital in establishing quality features in the product. Various standard mechanisms are developed in the companies to focus on the quality of the product. These mechanisms have to undergo improvements time to time in order to maintain the competition in the market. The product has to be viewed from the user point of view. A satisfaction note on the various features of the product is necessary to be reviewed to bring a change in the product to enhance it and to make it a quality product. 4.2.6 Software Quality Assurance Activities The quality assurance has a number of activities. A number of people are involved in these activities from software engineers to software managers to quality controllers. The activities ranges from selecting a suitable method to maintain the quality of the product, monitor the processes control the processes, testing and validating various process and to ensure that the performances of such processes are within certain prescribed quality norms. The objective of the team members working on the SQA activities is to achieve high degree of satisfaction on the quality front from the customers. 4.2.7 SQA plan A plan pertaining to the software project is prepared and reviewed by various experts before actually it is implemented. Everybody involved in the project are bound to be governed by the plan. The plan indicates (a) various types of assessments to be done (b) periodic reviews to be done (c) conformance to standards (d) relevant documents and (e) proper feedback mechanism which will enable to collect sufficient data which is used for analysis.
Page No.: 56
Unit 4
4.3 Summary
Quality is the buzz word of every organization today. But how does one work towards achieving quality in the organization and within the organization at various process levels. A feedback mechanism in the process list will help in constantly reviewing the performance and enhancement in the performance. Quality assurance is a process of auditing various areas and identifying the non conformances in such areas. There are many activities involved in a software project leading to the completion of the intended service or the product. A technical review is a software quality assurance activity. FTR also acts as a forum to provide orientation to members in the team to work on the developments, provide facts leading to new ideas and generation of approaches that could be adopted in the development of the software. The need for quality is there in the minds of everybody associated with the software project. One of the key issues pertaining to the quality aspect is the reliability of the software product. Failure refers to nonconformance to the requirements of the software stated. The quality assurance processes are very vital in establishing quality features in the product. A plan pertaining to the software project is prepared and reviewed by various experts before actually it is implemented. Data about the software engineering process should be collected, evaluated, and disseminated to smoothly conduct a SQA. Statistical SQA is helpful in improving the quality of the product and the software process. Software reliability models along with suitable metrics, are considered which leads to the identification of the appropriate data and data collection methodologies making the process simpler and easier.
4.4 Terminal Questions (TQs)

1. Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss them. 2. Can a program be correct and still not be reliable? Explain. 3. Can a program be correct and still not exhibit good quality? Explain.
4.5 Multiple Choice Questions (MCQs)

1. What is the full form of MTBF (a) meantime- between-failure (b) Max time between failure (c) all the above (d) none of these.
Unit 4

4.6.1 Answers to Self Assessment Question(s) (SAQs) 4.2.1 Quality assurance, Quality control, cost of quality 4.2.2 Kaizen 4.2.3 Refer to section 4.2.3 4.2.4 Refer to section 4.2.4 4.6.2 Answers to Terminal Question(s) (TQs) 1. refer to section 4.2.2 2. refer to section 4.2.4 3. refer to section 4.2.6 4.6.3 Answers to Multiple Choice Question(s) (MCQs) 1. a
Page No.: 58
Unit 5
Unit 5
Software Configuration Management
Structure: 5.1 Introduction 5.2 Software Configuration Management Software Configuration Management The SCM Process Identification of Objects in Software Configuration Version Control Change Control Configuration Audit SCM Standards 5.3 Summary 5.4 Terminal Question(s) (TQs) 5.5 Multiple Choice Question(s) (MCQs) 5.6 Answers to SAQs, TQs, and MCQs
5.1 Introduction
It is not possible to avoid changes in software that has been developed based on the specifications laid down by the customer. Changes may come from customer or from a third party who is using the software module for some or the other application. Changes can lead to lot of confusion amongst various users if not perceived and analyzed properly. Changes have to be understood and should be documented for all future references. It is a good practice to keep a log of all such reviews and discussion leading to the changes in the software. Configuration management is the management of all such activities that require proper coordination of members and the changes required in the software. It is an activity of the software development. Its main objective is to minimize confusions in bringing about a change in the software and thereby the software development activity. This will lead to maximization of the productivity of the software. Software configuration management (SCM) is applied throughout the software process and it is applied as and when the change is required because changes can occur during any stage. The main reason to develop SCM activities are (1) to identify the changes, (2) to control the changes,
Page No.: 59
Unit 5
(3) ensure proper implementation of changes and (4) reporting the changes to the concerned. Objectives In this chapter you will learn : What is software configuration? What are the steps in software configuration? Why is it important?
5.2 Software Configuration Management

5.2.1 Software Configuration Management It is well known that the output of most of the software process is the information. This information is divided into three broad categories programs, documents and data. The list of items that consists of all the information produced by one or more processes of the software are together known as software configuration. As more and more processes are executed more and more items are generated and the information list grows along with the number of software configuration items (SCI).The software project plan and the software requirements specifications are laid forth each time the software configuration items builds up. This leads to creation of hierarchy of information. The systems engineering law states that in the systems life cycle, the system will undergo a change if not there will be a tendency to change. This tendency will persist throughout the life cycle of the software project development activity. Baseline A baseline is a concept of the software configuration management that is useful in controlling the changes in the software process based on certain guidelines. Software Configuration Items Configuration objects are formed out of clusters of software configuration items. The objects are listed in the project database under a title. The object has all applicable attributes and is connected by means of arrows indicating relationships amongst objects in the system. An arrow indicates compositional relation. A compositional relation means a data model and a specific component are held together as a part of the object design
Page No.: 60
Unit 5
specification. Interrelationships are indicated by means of doubled headed straight arrows. Self Assessment Question(s) (SAQs) 1. What do you mean by Baselines? 5.2.2 The SCM Process A software project has to go through a set of processes. Each process has to be well defined according to the output it is expected to generate. The outputs are dependent on the inputs fed to the process. These processes have to be developed keeping the quality aspect in mind. The processes are expected to deliver quality output. The assurance on the quality front has to be made at every process level in the overall development of the product and the related services. One of the important elements of the software quality assurance is the software configuration management. It is mainly concerned with the control of the changes that are required in the processes and maintaining different versions of the changes. These changes are audited periodically to have a proper control on the changes and qualitative control on the changes. Proper documentation is necessary for the audits to be successful. A set of questions can become a part of periodic audit process within each function of the software process like the ones listed below : What are the documented procedures to bring about a change in the process and the product ? How are the changes identified ? What are the reasons for the change ? Who has approved the change ? What are the deadlines and who is responsible to bring about the change? How are the change s controlled ? Upon bringing about the change is it communicated to others associated with the project ? The key five SCM task that could be brought out based on the above questions are identification of change, change control, change version control, auditing, and reporting.
Page No.: 61
Unit 5
Self Assessment Question(s) (SAQs) 1. Software configuration management is an important element of _________. 5.2.3 Identification of Objects The software configuration items have to be managed and controlled. The management of the items and their control is possible only if they are named and identified depending upon the category to which they belong to. Object oriented approach may be adopted for this task. There are two categories generally basic objects and aggregate objects. A unit of text is the basic object. It is created by a software engineer during the stages of analysis, design, coding and testing. Whereas aggregate objects are collection of basic objects. Sometimes aggregate objects may also contain other aggregate object. Self Assessment Question(s) (SAQs) 1. What are the different types of objects? 5.2.4 Version Control A number of configuration objects are created during the software process. The changes resulting because of the process specification changes and the tools are held together and combined into a single version control number. Clemm describes version control in the context of SCM as Configuration management allows a user to specify alternative configurations of the software system through the selection of appropriate versions. This is supported by associating attributes with version number and allowing a configuration to be specified by describing the set of desired attributes. Self Assessment Question(s) (SAQs) 1. ______________combines procedures and tools to manage different versions of configuration objects that are created during the software process. 5.2.5 Change Control The change control in software engineering context as per James Bach is: Change control is vital. But the forces that make it necessary also make it annoying. We worry about change because a tiny perturbation in the code can create a big failure in the product. But it can also fix a big failure or
Unit 5
enable wonderful new capabilities. We worry about change because a single rogue developer could sink the project; yet brilliant ideas originate in the minds of those rogues, and a burdensome change control process could effectively discourage them from doing creative work. Self Assessment Question(s) (SAQs) 1. What do you mean by change control? 5.2.6 Configuration Audit A software developer can maintain records pertaining to identification label, change version control, and change control in order to avoid confusion because changes if any in future. But the question is how can one ensure that the change has been implemented properly or not? The answer is (1) formal technical reviews and (2) the software configuration audit. To determine the consistency with all SCIs, the reviewers have to assess the omissions and the side effects of omission. It is a good practice to conduct FTR for every change but however the size of the FTR committee may be restricted depending upon its significance to other functions related to the software project. Self Assessment Question(s) (SAQs) 1. What do you mean by Configuration Audit? 5.2.7 SCM Standards Over the past two decades a number of software configuration management standards have been proposed. Many early SCM standards, such as MILSTD-483, DODSTD- 480A and MIL-STD-1521A, focused on software developed for military applications. However, more recent ANSI/IEEE standards, such as ANSI/IEEE Stds. No. 828-1983, No. 1042-1987, and Std. No. 1028-1988 [IEE94], are applicable for nonmilitary software and are recommended for both large and small software engineering organizations. [Source : Software engineering by Roger S Pressman]
5.3
Summary
Configuration management is the management of all such activities that require proper coordination of members and the changes required in the software. It is an activity of the software development. Its main objective is to minimize confusions in bringing about a change in the software and thereby the software development activity. As more and more processes are
Unit 5
executed more and more items are generated and the information list grows along with the number of software configuration items (SCI). The software project plan and the software requirements specifications are laid forth each time the software configuration items builds up. Configuration objects are formed out of clusters of software configuration items. The objects are listed in the project database under a title. A software project has to go through a set of processes. Each process has to be well defined according to the output it is expected to generate. The outputs are dependent on the inputs fed to the process. The software configuration items have to be managed and controlled. The management of the items and their control is possible only if they are named and identified depending upon the category to which they belong to. A software developer can maintain records pertaining to identification label, change version control, and change control in order to avoid confusion because changes if any in future.

1. Why is the First Law of System Engineering true? How does it affect our perception of software engineering paradigms? 2. Discuss the reasons for baselines, in your own words. 3. Assume that you're the manager of a small project. What baselines would you define for the project, and how would you control them?

1. Which of the following are the types of objects? (a) Basic Objects (b) Aggregate objects (c) All the above (d) None of these 2. Software Configuration belongs to which of the following activities? (a) Umbrella activity (b) Economic Activity (c) All the above (d) None of these.

5.6.1 Answers to Self Assessment Question(s) (SAQs) 5.2.1 A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change 5.2.2 Software quality assurance
Unit 5
5.2.3 5.2.4 5.2.5 5.2.6
Basic objects and aggregate objects Version control Refer to 5.2.5 Refer to section 5.2.6
5.6.2 Answers to Terminal Question(s) (TQs) 1. Refer to section 5.2.3 2. Refer to section 5.2.1 3. Refer to section 5.2.4 5.6.3 Answers to Multiple Choice Question(s) (MCQs) 1. c 2. a
Page No.: 65
Unit 6
Unit 6
Structure 6.1 Introduction Objectives 6.2 System Engineering Computer Based Systems The System Engineering Hierarchy Requirements Engineering 6.3 Summary 6.4 Terminal Question(s) (TQs) 6.5 Multiple Choice Question(s) (MCQs) 6.6 Answers to SAQs, TQs, and MCQs
System Engineering
6.1 Introduction
One of the main reasons for the software engineering to get initiated is the process called system engineering. Systems engineering deals with software and also other related elements of the software pertaining to a business. It deals with analysis, design and organization of the various elements into the business system. The system ultimately has to give the end result in the form of a product or a service. This process of systems engineering is known as business process engineering. If a product with certain characteristics is to be built the process is called product engineering. The two processes business process and the product process are responsible for the development of computer based systems. Objectives In this chapter you will study: What is System Engineering? What is the importance of System Engineering? What are the steps of System Engineering?
6.2 System Engineering

6.2.1 Computer Based Systems There are so many types of systems namely political systems, educational systems, avionics systems, manufacturing systems, banking systems, subway systems, control systems, traffic systems, quality systems, etc. A
Unit 6
system refers to a systematic style of doing things. The system works according to the predefined rules and procedure. People working with the systems have to follow the guidelines of the systems and strictly follow the procedures in order to smoothly run the system. Only then it is possible to get good results from the system. Any such system which takes the support of the electronic computer is a computer based system. According to Webster's definition, a computer-based system is A set or arrangement of elements that are organized to accomplish some predefined goal by processing information. Self Assessment Question(s) (SAQs) 1. What do you mean by system? 6.2.2 The System Engineering Hierarchy Systems engineering can be seen in any software development domain irrespective of its application. It basically works on the top down approach or the bottom up approach. These approaches are useful to navigate various elements of the system. The system engineering process begins with a word view. To ensure proper business or technology context the entire business domain is tested and inspected. The product domain also is inspected. The purpose of the word view is to fully focus on a specific domain of the business enterprise. Within each domain of the business, the need for the systems engineering elements is analyzed. The elements that are focused during the analysis are World view, Domain view, Element view, Detailed view, Domain of interest, System element, the system engineering, hierarchy, and design. A detailed description of the entire analysis is provided. The broad context of the entire analysis is provided at the top of the document hierarchy and technical details of various technical activities are provided at the bottom. System Modeling System engineering is also a modeling process. The systems engineer creates the model based on the requirements and the forces acting in the domain in which the application is to be developed. The various steps in the modeling that the systems engineer follows are: 1. Process Definition: In this step the system engineer identifies the needs and specifications pertaining to the applications and clearly defines each
Page No.: 67
Unit 6
process one by one with appropriate linkages and relationships between each process. 2. Process Behavior: The systems engineer represents the process behavior and the related assumptions for each process. 3. Process Input The systems engineer defines the exogenous and endogenous input to the model. 4. Process Linkages: the process linkages have to be well established so that the engineer can understand the relationships better. System Simulation Whenever there is a need to develop an application to cater to the real world problems, a model has to be prepared. The model has to be developed based on the parameters identified to solve the problem and then to sensitize the model towards any changes in the external forces that affect the model. A model is an abstraction of the reality. There are different computers that interact with the real world in different manner. Real world events are monitored by automated systems and the programs that control the activities through hardware and related software. The hardware and the software together constitutes the computer based systems. Based on the inputs and the information provided to the systems, the computer based systems controls the machines and the processes. Lack of knowledge and experience of the software engineer leads to inefficient performance of the systems in which they work and also the outputs that are delivered by these systems. It has been difficult to predict the performance, efficiency, and behavior of such systems. Self Assessment Question(s) (SAQs) 1. What do you mean by system stimulation? 2. What do you mean by system modeling? 6.2.3 Requirements Engineering As discussed in the earlier paragraphs the computer based system is the outcome of an engineering process and the specification pertaining to the business domain application. But the main question is whether the specifications have been stated clearly or not, or is it adequately stated, so that the system engineer will not have to go through any major amendments in future. The amendments if any may be restricted to a small proportion. There is no unique solution to this question. The best thing is to work on a
Unit 6
solid requirements engineering process. Requirements engineering will provide necessary mechanism to understand what the customer wants and what the customer needs are. The best way to tackle this is to have a solid requirements engineering process. The process has to validate the specification stated and manage other requirements as they are transformed into a active operational system. The requirements engineering process can be stated in five steps as follows: Requirements description Analysis of requirements Specification of requirements Modeling of the system Validation of the system Management the various requirements Self Assessment Question(s) (SAQs) 1. What are the various steps of requirements engineering?
6.3 Summary
Systems engineering deals with software and also other related elements of the software pertaining to a business. It deals with analysis, design and organization of the various elements into the business system. Any such system which takes the support of the electronic computer is a computer based system. According to Webster's definition, a computer-based system is A set or arrangement of elements that are organized to accomplish some predefined goal by processing information. The system engineering process begins with the with a word view. To ensure proper business or technology context the entire business domain is tested and inspected. The product domain also is inspected. The purpose of the word view is to fully focus on a specific domain of the business enterprise. The systems engineer creates the model based on the requirements and the forces acting in the domain in which the application is to be developed. Whenever there is a need to develop an application to cater to the real world problems, a model has to be prepared. The model has to be developed based on the parameters identified to solve the problem and then to sensitize the model towards any changes in the external forces that affect the model. A model is an abstraction of the reality.
Unit 6

1. Find as many single-word synonyms for the word system as you can. Good luck! 2. Build a hierarchical "system of systems" for a system, product, or service with which you are familiar. Your hierarchy should extend down to simple system elements (hardware, software, etc.) along at least one branch of the "tree." 3. Select any large system or product with which you are familiar. Define the set of domains that describe the world view of the system or product. Describe the set of elements that make up one or two domains. For one element, identify the technical components that must be engineered.

1. Which of the following are the steps in system engineering? (a) Requirements elicitation (b) Requirements analysis and negotiation (c) All the above (d) none of these

6.6.1 Answers to Self Assessment Question(s) (SAQs) 6.2.1 A set or arrangement of things so related as to form a unity or organic whole. 6.2.2 1. Refer to section 6.2.2 2. Refer to section 6.2.2 6.2.3 Requirements elicitation, Requirements analysis and negotiation, Requirements specification, System modeling, Requirements validation, Requirements management 6.6.2 Answers to Terminal Question(s) (TQs) 1. Refer to section 6.2.1 2. Refer to section 6.2.2 3. Refer to section 6.2.3 6.6.3 Answers to Multiple Choice Question(s) (MCQs) 1. c
Page No.: 70
Unit 7
Unit 7
Analysis Concepts and Principles
Structure: 7.1 Introduction Objectives 7.2 Analysis Concepts and Principles Requirements Analysis Requirements Elicitation for Software Analysis Principles Software Prototyping 7.3 Summary 7.4 Terminal Question(s) (TQs) 7.5 Multiple Choice Question(s) (MCQs) 7.6 Answers to SAQs, TQs, and MCQs
7.1 Introduction
A step towards building a good and a stable software platform for the user requires the software team of engineers and managers to concentrate on the processes of discovery, refinement, modeling, and specification. The system engineer has to establish the system requirements and role allocated to software in detail. The software engineer has to then create various models to indicate the need of specific data, information and controls. The needs are translated into suitable formats represented by the models. For the purpose of detailed analysis models are created and alternative solutions are analyzed. Donald Reifer describes the software requirement engineering process in the following way: Requirements engineering is the systematic use of proven principles, techniques, languages, and tools for the cost effective analysis, documentation, and on-going evolution of user needs, and the specification of the external behavior of a system to satisfy those user needs. Notice that like all engineering disciplines, requirements engineering is not conducted in a sporadic, random or otherwise haphazard fashion, but instead is the systematic use of proven approaches. The effectiveness of the operations of the software depends upon the degree of involvement of the software engineer and customer. The
Unit 7
involvement refers to how much the software engineer and customer take an active role in software requirements engineering. Software requirements engineering is a set of activities known as analysis. The role of the software engineer as a software developer is to act as an interrogator, consultant, problem solver, and negotiator. Objectives In this unit you will study: What is concept analysis and principle? What is the work product? What is the work product of concept analysis and principle?
7.2 Analysis Concepts and Principles

7.2.1 Requirements Analysis A software is developed based on the requirements stated by the customer. The requirements stated are sometime not very clear. The interpretation of the requirements in the initial outlay may change as the interaction between the developer and the customer goes on and on with respect to the software. It is very difficult to perfectly predict the customers expectation from the software hence there is always a gap between the software system level requirements engineering and the software design. A process is therefore necessary to bridge the gap. Requirements analysis is a software engineering process which helps in bridging the gap between system level requirements engineering and software design. It results in the specification of softwares operational characteristics with respect to function, data, and behavior. It also acts as an indicator that indicates software's interface with other system elements and the various constraints within which the software developed must work. As a step in requirements analysis, the software engineer refines the software allocation, and build models of the data, functional, and behavioral domains. Requirements analysis provides the software designer with a representation of the following : i) information, ii) function, and iii) behavior
Page No.: 72
Unit 7
The three representations can be translated to data, architectural, interface, and component-level designs. Requirements specification is stated. It provides the developer and the customer with the means to assess quality of the software. The five areas of software requirements analysis are: 1) problem recognition, 2) evaluation and synthesis, 3) modeling, 4) specification, and 5) review. The commencement of the software requirements analysis and the development activity is marked by the studies and reports on the System Specification and the Software Project Plan. For the software development team it is important to understand the software in the context of a system. They should be able to review the software scope that was used to generate planning estimates. Communication of the analysis details to the customer is very important. This will lay the foundation to the development of a good software system for the customers. Self Assessment Question(s) (SAQs) 1. ____________is a software engineering task that bridges the gap between system level requirements engineering and software design. 7.2.2 Requirements Elicitation for Software The requirements have to be analyzed and modeled. The details are gathered through an elicitation process. The problem a customer has may be possible to be solved by a computer-based solution technique. For the communication of the details between the developer and the customer one has to make it clear by taking necessary steps to ensure that the communication is proper. Once the communication begins there will be lots of points which may be not very clear or is misunderstood. A proper communication process may be established and the following stages in the process may be followed : Initiating the Process This basically involves asking a few general questions pertaining to the software process, and on the personnel involved in the process. It can act as an ice-breaker which is very necessary for a successful completion of a project.
Page No.: 73
Unit 7
Facilitated Application Specification Techniques It helps in grouping of customers and enable people to work together to understand the problem identified, discuss various techniques to solve the problem, and the related methodologies. Quality Function Deployment- it is one of the main steps which enables the team to understand the customer requirements and translate them into technical forms. Use-Cases- Based on the above points it is possible to link the requirements stated by the customer to situations and scenarios already faced and bring out the performances to the notice of the customer to enable him to understand the process in a better way. At this stage the customer will be in a position to bring about changes to the stated requirements.
Self Assessment Question(s) (SAQs) 1. What are the different steps in requirement elicitation for software? 7.2.3 Analysis Principles A large number of analysis models have been developed over the last few decades of research in the software development area. Analysis problems and their causes have been identified and developed by the researchers. Each of the model is unique in its own way to deal with the software problem. However, the analysis methods are all related by various operational principles which are as follows: 1. The information domain of a problem should be well represented and understood. 2. Definition of the functions that the software is to perform. 3. Representation of the behavior of the software. 4. The models used to predict information, function, and behavior must be partitioned. The analysis process migrates from essential information towards implementation details. By applying these principles, the analyst will be able to systematically approach a problem. A systematic approach consists of four steps information domain, modeling, partitioning, essential and implementation views. Examination of the information domain leads to clear understanding of the model and its application clearly. The use of appropriate models characteristics the function and behavior which is then communicated to the
Unit 7
customer. Partitioning can be applied to reduce complexity. Implementation views of the software are necessary to accommodate the logical constraints that are imposed by the processing requirements as explained below: 1) The Information Domain Software applications are a set of processes. Software applications are collectively called data processing. Software is built to process data, to transform data from one form to another. It accepts inputs in one form and processes it or manipulates it to generated information of another form which is then the output of that process. This is applicable to batch software for a payroll system or real-time embedded software to control fuel flow to an automobile engine. A software also processes events. An event represents some system control and is a boolean data. 2) Modeling Functional models are created in order to understand the actual entity of software clearly. A model should be able to take different forms depending upon the area of application. The model must be capable of representing the information that software transforms, the functions that enable the transformation to occur, and the behavior of the system as the transformation is taking place. 3) Partitioning Problems are sometimes very large and complex. Such problems are difficult to understand in the first attempt. To manage such situation partitions may be made. Problems are broken down in to small parts that can be easily understood and interfaces could be established between such small parts. For this reason, we tend to partition (divide) such problems into parts that can be easily understood and establish interfaces between the parts. This will lead to overall achievement of the function. Partitioning decomposes a problem into its constituent parts. A hierarchical representation of function and the partition according to the hierarchy will lead to the following i) increased visibility of the function vertically in the hierarchy, ii) decomposing the problem horizontally in the hierarchy, and iii) increased clarity of the relationships between various functions
Page No.: 75
Unit 7
4) Essential and Implementation Views The functional aspect of the software and the information to be processed forms the essential view of software requirements. Options can be open in the early stages of the development. The focus of the development can then be on one or more options which tend to appear more feasible than the rest. Implementation details to a large extent are then clear in the minds of the development team. The implementation view of the software requirements exhibits the real world attributes of processing functions and the information structures. The analyst has to recognize the constraints imposed by predefined system elements. They have to consider the implementation view of function and information when such a view is appropriate. Self Assessment Question(s) (SAQs) 1. A/an _______of software requirement presents the functions to be accomplished and information to be processed without regard to implementation details. 7.2.4 Software Prototyping Analysis should be conducted independent of the software engineering approach. The form of analysis will vary according to the area of analysis.. In some cases, operational analysis principles are applied and a model is derived. In such situations requirements elicitation is conducted. Various analysis principles are applied, and a model of the software to be built, called a prototype, is developed. the construction of a prototype at the beginning of analysis is desired. The model is the only means through which requirements can be effectively derived. The model evolves into production software. Selecting the Prototyping Approach Prototyping Methods and Tools Self Assessment Question(s) (SAQs) 1. What do you mean by software prototyping? 7.2.1 Elements of analysis model An analysis model consists of data dictionary at the center of three main segmented diagrams (i) ERD-entity relationship diagram, (ii) DFD - data flow diagram and (iii) STD - state transition diagram. The construction of the
Unit 7
three diagrams is based on the inputs from data objects designed on customer requirements, their controls specified and the necessary processes. 7.2.2 ERD, Functional and Behavioral modeling and the Control Specification ERD indicates relationships between data objects. The attributes of each such object is described by object description. The DFD provides indication of transformation of data from one stage to another and the functions responsible for such transformation. This is essentially based on the functional modeling and its specifications. Based on the functionality the relationship and the behavioral aspect of the objects entities are described and detailed. Description of each function of the DFD is indicated in PSPECprocess specification. The STD indicates the behavior of the systems to external changing forces. The description of each is listed out in the Data dictionary. Necessary controls are then described in order to control the flow of data at various functional modules and the way it needs to be formatted for further processing. Additionally, information on the control features of the system can be stated in specification known as CSPEC- control specification. Self Assessment Question(s) (SAQs) 1. The ________ indicates the behavior of the systems to external changing forces. 2. The _________ provides indication of transformation of data from one stage to another and the functions responsible for such transformation.
7.3 Summary
The system engineer has to establish the system requirements and role allocated to software in detail. The software engineer has to then create various models to indicate the need of specific data, information and controls. The effectiveness of the operations of the software depends upon the degree of involvement of the software engineer and customer. The involvement refers to how much the software engineer and customer take an active role in software requirements engineering. A software is developed based on the requirements stated by the customer. Requirements analysis provides the software designer with a representation
Unit 7
of the information, function, and behavior. The commencement of the software requirements analysis and the development activity is marked by the studies and reports on the System Specification and the Software Project Plan. The requirements have to be analyzed and modeled. The details are gathered through an elicitation process. The problem a customer has may be possible to be solved by a computer-based solution technique. A proper communication process may be established and the following stages : Initiating the Process, Facilitated Application Specification Techniques, Quality Function Deployment, Use-Cases. A systematic approach to requirement analysis consists of four steps information domain, modeling, partitioning, essential and implementation views. Various analysis principles are applied, and a model of the software to be built, called a prototype, is developed. the construction of a prototype at the beginning of analysis is desired.

1. Software requirements analysis is unquestionably the most communication intensive step in the software process. Why does the communication path frequently break down? 2. There are frequently severe political repercussions when software requirements analysis (and/or system analysis) begins. For example, workers may feel that job security is threatened by a new automated system. What causes such problems? Can the analysis task be conducted so that politics is minimized? 3. Discuss your perceptions of the ideal training and background for a systems analyst?

1. Software Analysis is divided into the following areas. (a) one (b) three (c) five (d) 6
Page No.: 78
Unit 7

7.6.1 Answers to Self Assessment Questions 7.2.1 Requirements analysis 7.2.2 Initiating the Process, Facilitated Application Specification Techniques, Quality Function Deployment, Use-Cases 7.2.3 Essential view 7.2.4 Refer to section 7.2.4 7.2.5 i) STD, ii) DFD 7.6.2 Answers to Terminal Question(s) (TQs) 1. Refer to section 7.2.2 2. Refer to section 7.2.4 3. Refer to section 7.2.3 7.6.3 Answers to Multiple Choice Question(s) (MCQs) 1. c
Page No.: 79
Unit 8
Unit 8
Design Concepts and Principles
Structure: 8.1 Introduction Objectives 8.2 Design Concepts and Principles Software Design and Software Engineering The Design Process Design Principles Design Concepts Effective Modular Design Design Heuristics for Effective Modularity 8.3 User Interface Design The Golden Rules User Interface Design 8.4 Component-Level Design Structured Programming 8.5 Summary 8.6 Terminal Question(s) (TQs) 8.7 Multiple Choice Question(s) (MCQs) 8.8 Answers to SAQs, TQs, and MCQs
8.1 Introduction
The goal of the designer is to produce a model of an entity that will later be developed. The process by which the design model is developed is described by Belady There are two major phases to any design process: diversification and convergence. Diversification is the acquisition of a repertoire of alternatives, the raw material of design: components, component solutions, and knowledge, all contained in catalogs, textbooks, and the mind. During convergence, the designer chooses and combines appropriate elements from this repertoire to meet the design objectives, as stated in the requirements document and as agreed to by the customer. The second phase is the gradual elimination of all but one particular configuration of components, and thus the creation of the final product.
Page No.: 80
Unit 8
Objectives In this chapter you will study: What is Design concept and principles? What is the work product? What is the work product of Design Concept and principles?
8.2 Design Concepts and Principles

8.2.1 Software Design and Software Engineering Its evolution and hierarchy Software design is present at the technical kernel of software engineering. Software design is applied regardless of the software process model that is used. After the software requirements are stated and analyzed, software design is the first of three technical activities design, code generation, and test. These three technical activities are required to build and verify the software. Each activity transforms the information into a form which is a validated computer software. Each of the elements of the analysis model provides information necessary to create the four design models required for a complete design specification. Software requirements which are stated usually comes with a stream of data, functional, and behavioral models, which is the basis for design task. The design task produces a data design, an architectural design, an interface design, and a component design. The information domain model is transformed by the data design into a suitable data structure .this data structures is necessary to create the software. Entity relationship diagram represents the relationships between entity and the data objects. The data content in the data dictionary provide the basis for the data design activity. This may happened in conjunction with the design of software architecture. As each component of the software is designed, more and more detailed data design occurs. The interface design describes how the software communicates within itself. It also describe how the software communicate with systems that interoperate with it, and with the people who are the end users. An interface signifies the flow of information and a specific type of behavior. The component-level design is responsible for the transformation of the structural elements of the software architecture into a procedural description of software components. The basis for a component design in the software is the information that is obtained from the PSPEC, CSPEC, and STD.
Unit 8
During the process of the software design, decision have to be taken at various stages which is mainly responsible for the overall success of the software and the convenience with which the software could be maintained. Self Assessment Question(s) (SAQs) 1. The ___________transforms the information domain model created during analysis into the data structures that will be required to implement the software. 2. The _________________ transforms structural elements of the software architecture into a procedural description of software components. 8.2.2 The Design Process Software design is type of a repetitive process also referred to as an iterative process. Through this iterative process the requirements are translated into a blueprint for constructing the software. Initially, the blueprint represents a holistic view of software. This means that the design is represented at a high level of abstraction. The highest level of abstraction can be directly traced to the specific system objective, and more detailed data, functional, and behavioral requirements. As more and more iterations takes place the software undergoes refinement in its design leading to design representations at much lower levels of abstraction. It can still be traced to the requirements, but the connection is more elusive. i) Design and Software Quality- It is necessary that the quality of the design process is maintained and monitored throughout the design process. The entire design process is broken down into modules, distinct data structures to present the data and interfaces and independent functional modules. This will enable easy control of the software quality. ii) The Evolution of Software Design- It is a continuous process. Various technological developments in the design has lead to the evolution of various improved methodologies in the software design and its architecture. It is necessary to apply basic principles and concepts to the pertinent data and interfaces at component level. Self Assessment Question(s) (SAQs) 1. What is the design process?
Page No.: 82
Unit 8
8.2.3 Design Principles Software designing involves both modeling and designing processes. Hence software design is both a process and a model. All the aspects of the software design are possible to be represented in the form of a sequence of steps. The sequenced steps enable the designer to describe and understand all the aspects for the software module in the design. To develop a good software it is necessary to have experienced developers in the software team who are capable of anticipating likely problems under specific conditions. They will be well conversant with the critical success factors which are necessary to develop competent software. The design model that is created for software provides number of views. The software developer will be able to navigate the entire software process based on the basic principles of the software design. Davis suggests a set of principles for software design, which have been adapted and extended in the following list: The design process should not suffer from tunnel vision. A good designer should consider alternative approaches, judging each based on the requirements of the problem, and the resources available to do the job. The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model. The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have very likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas, and integrating those patterns that already exist. The design should minimize the intellectual distance [DAV95] between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain. The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work
Unit 8
begins. A design is integrated if care is taken in defining interfaces between design components. Self Assessment Question(s) (SAQs) 1. What are the different Design principles? 8.2.4 Design Concepts A number of design concepts have evolved over the past few decades. Each concept is strong in its foundation that enables the designer to work conveniently on various models both simple and complex. Each of the concept provides the software engineer with knowledge to answer the following questions: What is the criteria that will help in partitioning a software? How is it possible to separate the function or data structure from a conceptual representation of the software? What are the criterions that define the quality of the software design? Abstraction and Refinement Abstraction refers to the process of formulating general concepts by abstracting common properties of instances. Data abstraction refers to a collection of data that describes a data object taken from a real world problem. The process of program refinement proposed by Wirth is analogous to the process of refinement and partitioning that is used during requirements analysis. The differentiation of the data abstraction is created at the level of implementation. At different levels of the software design process, refinement is done. It is actually a process of elaboration. At the beginning the statement of function is made. The statement is defined at a high level of abstraction. The statement describes the function and the information conceptually. It is also very important to hide certain design details in a software program specially the functions. It is necessary to hide the design details because some of the functional aspects in the program would undergo a change during the course of its development based on changes indicated by the customer. This would also enable the security of the other parts of the software as each change would be local to the function in which the change is expected to be incorporated. It provides no information about the internal workings of the function or the internal structure of the information. Refinement requires the designer to work on the elaborate details of the function statement. It provides more and more detail
Unit 8
as each successive refinement occurs. Refinement is very effective if the following points are considered and are taken into the process of decomposing and understanding the function problem of the software. 1. Modularity 2. Software Architecture 3. Control Hierarchy 4. Structural Partitioning 5. Data Structure 6. Software Procedure 7. Information Hiding Self Assessment Question(s) (SAQs) 1. A ________is a named collection of data that describes a data object. 2. What do you mean by refinement? 8.2.5 Effective Modular Design Cohesion and Coupling Most of the concepts revolve around the idea of modularity, as mentioned in earlier sections. Modularity is one of the most accepted idea in most of the practical areas. The benefit of modularity is derived in the form of simplicity in solving complex problems, easy approach to maintain the systems, and permits parallel development and implementation of various other modules in the system. The modularity induces functionality in the modules. Each module of the system is independent of the other and the functional independence can be either of coupling type or cohesion type. Coupling refers to the degree of interaction between two or more modules in a system. Cohesion is the term used to describe how well the contents of a module in the system are bonded together. It is good to have a high degree of cohesion and low degree of coupling. Cohesion and coupling support the reuse of a code and easy maintenance. The design aspects of the modularity focus on maximizing cohesion and minimizing coupling. A cohesive module is generally meant to perform a single task in a system with little interactions with other modules in the system. Cohesion can be of any of the three types : coincidental, logical, communication type. Coupling can be of the following types : i) data coupling used for passing parameters and interaction with data
Page No.: 85
Unit 8
ii) control coupling control data iii) common coupling iv) content coupling another module.
used for the purposed of sharing
related
for the purposed of sharing common data for linking one module to another content in
Self Assessment Question(s) (SAQs) 1. What are the different parts of effective modular design? 8.2.6 Design Heuristics for Effective Modularity It is possible to achieve effective modularity by careful study of the entire systems and meticulously planning the modules. Also the design could be made effective by thoroughly understanding the relationships between different modules in the system and their interdependencies. The program structure for modularity can be adjusted according to the following heuristics: Meyer defines five criteria to evaluate a design method or the steps in terms of its ability to define an effective modular system: i) Modular decomposability: it refers to a mechanism where a problem is decomposed in to sub problems, as this will help reduce the complexity in the problems and make the entire big complex problem in to smaller simpler problems. ii) Modular composability: it refers to a design methodology that enables existing components of the design modules to be assembled in to new ones. iii) Modular understandability: it refers to the understanding ability of the developer of the modules as a single standalone modules as this enables the developer to build the module further and makes it easier to change the module. iv) Modular continuity: it refers to the flexibility offered to bring in changes in the modules without bringing in major changes in the entire system modules. v) Modular protection: it refers to the security of the modular content from getting modified accidentally. Modules may be exploded to improve module independence once the program structure has been developed. In the final structure an exploded module becomes two or more modules. An imploded module is the result of
Unit 8
combining the processes of the modules. The scope of a module is defined based on the effect of the decision changes on all other modules. If one of the module makes a decision that affects another module it refers to violation of this heuristic. The main cause of software errors is the module interface complexity. Interfaces should be designed to pass information. Interfaces should be consistent. Unrelated data passed via an argument list is an indication of low cohesion. The module in question should be reevaluated. A module is said to be predictable when it is treated as a black box. This means the same external data will be produced irrespective of internal processing details. Modules that have internal "memory" can be unpredictable. Software is easier to understand and therefore easier to maintain. Self Assessment Question(s) (SAQs) 1. What are the Design Heuristics for Effective Modularity? 8.2.1 Design Model Implementation and Documentation: A design model for the development of software should be stable. The various design issues are considered based on the requirements specification and each one of the issue is review at full length and then a evaluation is made. The evaluation of the design aspects is based on the experience of the team members and the ability to lay down criteria for such evaluation. Criteria for each of the module in the software and its modularity is listed module by module, considering the modules interface and the various object interface to the module and the corresponding actions that are expected by the objects on other such modules or objects. It can be made stable by adopting a suitable model of stability like a pyramid model. The design model should not get toppled even with the slightest of the changes in the system or factors external to the system. The designing aspects with respect to the specifications have to be documented, indicating all relevant procedures, algorithms, data structures, data tables etc. Appropriate instruction manuals may be prepared to indicate the usage of the application. 8.2.2 Architecture and its importance Architecture refers to the structure of the system. It consists of various components and their
Unit 8
relationships in the system. The components can be considered as software program module. It enables one to easily communicate various aspects of the module under development and the one which is already developed. It also helps to build successive modules based on the development of the modules already done by means of proper architectural documents. 8.2.3 Data concepts Objects pertaining to data are designed from the ERDs. Data structure has been the main component of the design in the past. But today the challenges are different which has led to the emergence of concepts like data mining and data warehouse apart from the conventional databases. The purpose of data mining is to provide a means to search through the databases to abstract business information suitable to a business environment. In a data warehouse, large amount of databases are stored holding the business information on a day to day basis. Some of the key aspects of data warehouse are its orientation to the subject of interest, consistent naming conventions, and non-changing nature of the data in the database. 8.2.4 Style, Mapping and Flow software that is developed may exhibit certain style which is unique to its purpose and application. The style describes categorically the components and the connectors of the components. It also describes the limitations and the semantics pertaining to the overall characteristics of the software. The different styles that exist in different software architectures have to make to adhere to a uniform standard style. This can be achieved by means of mapping. For an effective mapping to be implemented one has to have an effective information flow from module to another. The data that has to move from one module of a particular style to another module of a different style will have to flow through a transforming module which transforms it to the form needed. The flow in and the flow out to and from the transforming module is controlled in a sequential manner. Each of the tasks has to follow a defined design step. 8.2.5 Interface Object and Actions-In any design objects which interface have to be defines and the actions on them have to be clearly stated. Objects are then classified depending upon their type. The objects may be of target type, source type or application type. Actions on the stored data could be sorting, merging etc., followed by screen layout.
Page No.: 88
Unit 8
8.2.6 Design Issues, Implementation, Evaluation and Notation The commonly considered design issues are systems response time, help to the user, handling of error information and labeling of command. Response time refers to the time from the point user enter the response till the time system responds to the user. A design model is implemented as a prototype. The prototype is checked by users and they are then modified. A number of interface design and tools of prototyping are used to create windows, menus, command, messages etc. For implementing the tools provide support to manage various devices, validation of inputs, error handling etc. The user then evaluates the interfaces keeping in mind its usage. User then provides a feedback on the interface either to modify, or to change, or in the form of few suggestions to change the outlook etc. The user comments are then reviewed by the designer and takes action to implement the changes. In the design, various notations are used to graphically represent a task or an instruction. Sequence is represented by means of two connected boxes. If then else is represented by means of rhombus, repetition can be indicated by means of closed sequential connected boxes and rhombus. Another notation is to use the graphical box design, developed by Nassi and Shneiderman and extended by Chapin also know as N-S charts or Chapin charts. Another notation is to use a decision table to indicate multiple conditions and multiple actions based on conditions. The table consists of four parts list of conditions, list of actions, condition combinations and action on conditions. Another form is a PDLprogram design language also known as pseudo-code. It uses the simple language for indicating the steps with some parts written in the syntax of the language of programming. A PDL should include subroutine definitions, description of all interfaces, data definition, structures etc.
8.3 User Interface Design

8.3.1 The Golden Rules Theo Mandel states three golden rules: 1. Place the user in control. 2. Reduce the users memory load. 3. Make the interface consistent. These golden rules form the basis for a set of user interface design principles that guide this important software design activity.
Unit 8
Self Assessment Question(s) (SAQs) 1. What are the different golden rules? 8.3.2 User Interface Design Different Models of system function are created to design a user interface. The human and computer oriented tasks are then delineated; design issues pertaining to the interfaces are considered; prototyping tools are used and ultimately implement the design model. The results are then evaluated for the purpose of quality. Self Assessment Question(s) (SAQs) 1. What is the first step of user interface design?
8.4 Component-Level Design

8.4.1 Structured Programming and PDL Various concepts towards component level designs were developed in the early 1960s and during late 1960s, Dijkstra and others proposed constrained logical constructs from which any type of logical program could be developed. These constructs mainly focused on functional domain. The constructs are used as descriptions for writing down the detailed design method and the related documentation needed. The methods for designing and documentation as acceptable in any standards is written down to explain the details of the software under consideration. It may also contain certain pseudo-codes indicating the closeness of the programming language to the documented procedure which is known as PDL or the program design language. Example : Drawing a line: Select a tool to draw the line. Indicate the start point on the screen. Start point could be selected based on the coordinate of the pixels on the screen where a line is to be drawn. Use command LINE. Select point using a mouse or enter co-ordinate in the text command box available in the tool box. Select another point to which the line is required to be connected to. Call the two points From Point and To Point.
Page No.: 90
Unit 8
The constructs are mainly sequence, condition, and repetition. Sequence refers to algorithmic approach presenting the processing steps in sume order. Condition provides the facility for selected processing. Repetition allows for looping. These three constructs are the core fundamentals of structured programming. Structured constructs limits the procedural design of software to a small number of predictable operations. The use of a limited number of logical constructs leads to understanding of the processes. Various notations : Graphical Design Notation Tabular Design Notation Program Design Language Self Assessment Question(s) (SAQs) 1. What are the different structured programming languages?
8.5 Summary
Software design is present at the technical kernel of software engineering. Software design is applied regardless of the software process model that is used. After the software requirements are stated and analyzed, software design is the first of three technical activities design, code generation, and test. The information domain model is transformed by the data design into a suitable data structure .this data structures is necessary to create the software. Entity relationship diagram represents the relationships between entity and the data objects. The component-level design is responsible for the transformation of the structural elements of the software architecture into a procedural description of software components. Software design is type of a repetitive process also referred to as an iterative process. Through this iterative process the requirements are translated into a blueprint for constructing the software. It is necessary that the quality of the design process is maintained and monitored throughout the design process. Software designing involves both modeling and designing processes. Hence software design is both a process and a model. All the aspects of the software design are possible to be represented in the form of a sequence of steps. Abstraction refers to the
Unit 8
process of formulating general concepts by abstracting common properties of instances. Data abstraction refers to a collection of data that describes a data object taken from a real world problem. Component-level design depicts the software at a level of abstraction that is very close to the code. At the component level, the software engineer must represent data structures, interfaces, and algorithms in sufficient detail to guide in the generation of programming language source code. Intent of structured programming is to assist the designer in defining algorithms that are less complex and therefore easier to read, test, and maintain. The benefit of modularity is derived in the form of simplicity in solving complex problems, easy approach to maintain the systems, and permits parallel development and implementation of various other modules in the system. Modules may be exploded to improve module independence once the program structure has been developed.

1. Develop two additional design principles that place the user in control. 2. All modern programming languages implement the structured programming constructs. Provide examples from three programming languages.

1. Which of the following is the structured programming language a) Graphical Design Notation b) PDL c) All the above d) None of these

8.8.1 Answers to Self Assessment Question(s) (SAQs) 8.2.1 1. Data design, 2. Component-level design 8.2.2 Design and software Quality, The Evolution of software Design 8.2.3 Refer to section 8.2.3 8.2.4 Data abstraction , refer section 8.2.4 8.2.5 Functional dependency, Cohesion, Coupling 8.2.6 Refer to section 8.2.6
Unit 8
8.3.1 8.3.2 8.4.1
Refer to section 8.3.1 The creation of different models of system function Graphical Design Notation, Tabular Design Notation, Program Design Language
8.8.2 Answers to Terminal Question(s) (TQs) Refer to section 8.3.2 Refer to section 8.4.1 8.8.3 Answers to Multiple Choice Question(s) (MCQs) 1. b
Page No.: 93
Unit 9
Unit 9
Software Testing Techniques and Technical Metrics
Structure: 9.1 Introduction Objectives 9.2 Software Testing Techniques Software Testing Fundamentals White-Box Testing Basis Path Testing Controlling Structure Testing Black-Box Testing Testing for Specialized Environments, Architectures, and Applications 9.3 Introduction to Technical Metrics 9.4 Technical Metrics for Software Software Quality A Framework for Technical Software Metrics Metrics for the Analysis Model Metrics for the Design Model Metrics for Source Code 9.5 Summary 9.6 Terminal Question(s) (TQs) 9.7 Multiple Choice Question(s) (MCQs) 9.8 Answers to SAQs, TQs, and MCQs
9.1 Introduction
Software testing and its implications with respect to software quality should be well understood. The development of software systems involves a series of production activities. Every process is prone to errors. The software development should be subject to quality assurance process. Software testing represents the ultimate review of specification, design, and code generation. The visibility of software system and the costs associated with a software failure are the main forces for software testing.
Page No.: 94
Unit 9
Objectives In this chapter we will study: o What is testing? o What are the different testing techniques? o Where and how to use this testing techniques?
9.2 Software Testing Techniques

9.2.1 Software Testing Fundamentals and Comparison During the process of software development the software development team goes through the stages of the development based on the principles of the developmental models and the requirements stated. The engineer attempts to build software from an abstract concept to what is known as tangible product. To check upon the development testing is done. Testing is one step in the software process that could be viewed psychologically as a destructive process rather than constructive process though there is no such damage done to the system as may be perceived in the general sense. i) Testing Objectives Glen Myers states a number of rules that can serve well as testing objectives: 1. Testing is a process of executing a program with the intent of finding an error. 2. A good test case is one that has a high probability of finding an as return discovered error. 3. A successful test is one that uncovers an as-yet-undiscovered error. ii) Testing Principles Davis suggests a set of testing principles that have been adapted in this book: All tests should be traceable to customer requirements: As we have seen, the objective of software testing is to uncover errors. It follows that the most severe defects (from the customers point of view) are those that cause the program to fail to meet its requirements. Tests should be planned long before testing begins: Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been
Page No.: 95
Unit 9
solidified. Therefore, all tests can be planned and designed before any code has been generated. The Pareto principle applies to software testing: Stated simply, the Pareto principle implies that 80 percent of all errors uncovered during testing will most likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and to thoroughly test them. Testing should begin in the small and progress toward testing in the large: The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system. Exhaustive testing is not possible: The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised. To be most effective, testing should be conducted by an independent third party- By most effective, we mean testing that has the highest probability of finding errors (the primary objective of testing). For reasons that have been introduced earlier in this unit, the software engineer who created the system is not the best person to conduct all tests for the software.
iii) Testability James Bach describes testability in the following manner. Software testability is simply how easily [a computer program] can be tested. Since testing is so profoundly difficult, it pays to know what can be done to streamline it. Sometimes programmers are willing to do things that will help the testing process and a checklist of possible design points, features, etc., can be useful in negotiating with them. There are certainly metrics that could be used to measure testability in most of its aspects. Sometimes, testability is used to mean how adequately a particular set of tests will cover the product. It's also used by the military to mean how easily a tool can be checked and repaired in the field. Those two meanings are not the same as software testability.
Unit 9
Self Assessment Question(s) (SAQs) 1. What are the different testing objectives? 2. What are the different testing principles? 9.2.2 Test Case Design The tests for software have to be designed depending upon the nature of the system and the working of the processes. Designing of the test model can be as challenging as the initial design of the product itself. Testing can be done in two ways: 1) Knowing the specified function that a product has been designed to perform. 2) Knowing the internal workings of a product. Self Assessment Question(s) (SAQs) 1. _______testing of software is predicated on close examination of procedural details. 2. A ________test examines some fundamental aspect of a system with little regard for the internal logical structure of the software. 9.2.3 White-Box Testing White-box testing is also known as glass-box testing. It uses the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can derive a number of test cases. The test case checking for (1) all independent module paths have been exercised at least once, (2) check all logical decisions for being true or false, (3) execute all loops within their operational bounds, and (4) exercise validity of internal data structures. Self Assessment Question(s) (SAQs) 1. White box testing is also known as ______________ 2. What is white box testing? 9.2.4 Basis Path Testing Basis path testing is the same as white-box testing. The technique first proposed by Tom McCabe. It enables the test case designer to derive a logical complexity measure of a procedural design. It uses this measure as a guide to define the basis set of execution paths. Test cases execute every statement in the program at least one time during testing.
Page No.: 97
Unit 9
i) Flow Graph Notation The flow graph depicts the logical flow of the control. Each structured construct has a corresponding flow graph symbol. ii) Cyclomatic Complexity Cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program. In basis path testing, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program and provides with an upper bound for the number of tests. An independent path is any path through the program. Independent path introduces at least one new set of processing statements. iii) Deriving Test Cases The basis path testing method is generally applied to a procedural design or to source code. The following steps can be applied to derive the basis set: 1. Draw flow graph: Flow graph is created using the symbols and construction rules which are based on the design foundation. 2. Determination of cyclomatic complexity : The cyclomatic complexity, V(G) can be determined without developing a flow graph by counting all conditional statements in the PDL (Program design language). iv) Graph based testing Graph Matrices A graph matrix is a data structure and is considered as a software tool that assists in basis path testing. A graph matrix is a square matrix. The size of the square matrix is equal to the number of nodes on the flow graph. Each row and column pertains to a node. The entries in the matrix correspond to the connections between nodes and the associated link weight. In its simplest form, the link weight is 1 (a connection exists) or 0 (a connection does not exist). Link weights can be used to indicate : The probability of execution of the link. The processing time to traverse the link. The memory required during link traversal. The resources required to traverse the link.
Page No.: 98
Unit 9
Self Assessment Question(s) (SAQs) 1. A ________is a square matrix whose size (i.e., number of rows and columns) is equal to the number of nodes on the flow graph. 2. An ____________is any path through the program that introduces at least one new set of processing statements or a new condition. 9.2.5 Controlling Structure Testing Although basis path testing is simple and highly effective, there arises a number of other variations on control structure that broaden the testing coverage and improve quality of white-box testing. i) Condition Testing Condition testing refers to a test case design method that exercises the logical conditions contained in a program module. ii) Data Flow Testing The data flow testing method selects test paths for testing based on the locations of definitions and uses of variables in the program. iii) Loop Testing Loop testing is a white-box testing technique focusing mainly on the validity of loop constructs. Four different classes of loops that could be tested are: simple loops, concatenated loops, nested loops, and unstructured loops. Self Assessment Question(s) (SAQs) 1. ___________is a test case design method that exercises the logical conditions contained in a program module. 2. The ____________method selects test paths of a program according to the locations of definitions and uses of variables in the program. 9.2.6 Black-Box Testing Black-box testing is also known as behavioral testing. It focuses on the functional requirements of the software. Black-box testing helps to derive sets of input conditions to handle and test all functional requirements for a program. Black-box testing is complementary to white-box techniques to uncover different class of errors. Black-box testing finds errors in the following categories: 1) Incorrect functions, 2) Errors in the Interface 3) Data structure errors
Unit 9
4) Performance errors 5) Errors due to initialization and termination. Graph-Based Testing Methods This is the starting point of software testing. A graph is created for important objects along with t heir relationships with each other. A series of tests are conducted on the objects and the errors are identified. This is then rectified. Equivalence Partitioning this divides the input of program into classes of data from which tests are devised. It helps in uncovering the errors. Boundary Value Analysis this is used to identify errors which occurs on the periphery of the classes and not at the centre of the object. Comparison Testing Real time comparison is done with respect to items to be tested through new version software. The same old data is put through the new software to check whether it produces identical results or not? Orthogonal Array Testing- It is applicable to testing of software where the input set is very small. It is useful to find errors which are connected with the faulty logics of the software. Self Assessment Question(s) (SAQs) 1. Black box testing is also known as ________________ 2. What are the different black boxes tests? 9.2.7 Testing for Specialized Environments, Architectures, and Applications The white-box and black-box testing methods discussed are applicable across all environments, architectures, and applications. Testing guidelines for specialized environments, architectures, and applications that are commonly encountered by software engineers are : Testing GUIs Complexities of GUI increases depending upon its utility and usage. To address the issues related to specific data and objects, finite state graphs may be used. Testing is done with automated tools. Testing of Client/Server Architectures This environment is distributed hence on different machines the performance issues are different. These issues are more complicated to deal with than on standalone machines. It requires more time and is a costly process.
Page No.: 100
Unit 9
Similar is the case in testing under the following categories: i) Testing Documentation and Help Facilities ii) Testing for Real-Time Systems Challenges of Technical Metrics: It is always a challenge to the researches to develop a model of testing, one which will be comprehensive covering all the aspects of testing software. In the process various complexities have been dealt with for measurements. These measurements on the program attributes like modularity, independence etc can be used as indicators of quality. Attributes of Effectives software metrics: The various attributes which may be considered in testing software effectively are i) Simplicity in understanding the metric ii) Satisfaction about the various attributes should be experienced iii) Metric should be yielding results iv) The metric should have uniform and consistent used of dimensions v) Metrics should be program independent vi) Metric should be capable of providing quality information for further developments. Interface Design Metrics: There is shortage of metrics which could be used for providing insight into the quality and usability of the interface. Different methodologies have been used in such measurements. The methods have been based on the appropriateness of the application and the interface. Metrics for Testing and Maintenance: Most of the metrics are developed on the process of testing and not on the technicalities of the tests. The tests rely mainly on the design characteristics and the analysis characteristics of the software. Metrics which are function based are also found to be effective. These metrics enable to measure the effort of testing, time required to test and errors of testing if found. Almost every metrics can be used to measure the maintenance aspects of a software. IEEE has suggested SMI-Software maturity index that indicates the stability of the product software. Based on the mean time required to
Page No.: 101
Unit 9
produce software, empirical models can be considered for maintenance models. Self Assessment Question(s) (SAQs) What do you mean by testing GUI?
9.3 Introduction to Technical Metrics

Measurement is the key element of any engineering process. Measurements are used to understand the attributes of the models. Measurements are used to assess the quality of the engineered products. Fenton states that measurement is the process by which numbers or symbols are assigned to the attributes of entities in the real world in such a way as to define them according to clearly defined rules.
9.4 Technical Metrics for Software

9.4.1 Software Quality The following three points are emphasized while defining a software quality: 1. The foundation from which the quality is measured the software requirements. Lack of quality is nothing but the lack of conformance to requirements. 2. Specified standards guide the manner in which software is engineered. 3. If software conforms to its explicit requirements but if it fails to meet implicit requirements, software quality is doubtful. Software quality is a complex mix of factors that will vary across different applications and the customers who request them. i) McCalls Quality Factors The software quality factors can be categorized in two groups: 1) Directly measurable factors 2) Indirectly measurable factors. McCall, Richards, and Walters propose a useful categorization of factors that affect software quality. These software quality factors focus on three important aspects of a software product: operational characteristics, ability to undergo change, and adaptability to new environments. McCall and his colleagues provide the following descriptions:
Page No.: 102
Unit 9
Correctness: The extent to which a program satisfies its specification and fulfills the customer's mission objectives. Reliability: The extent to which a program can be expected to perform its intended function with required precision. [It should be noted that other, more complete definitions of reliability have been proposed. Efficiency: The amount of computing resources and code required by a program to perform its function. Integrity: Extent to which access to software or data by unauthorized persons can be controlled. Usability: Effort required to learn, operate, prepare input, and interpret output of a program. Maintainability: Effort required to locate and fix an error in a program. [This is a very limited definition.] Flexibility: Effort required to modify an operational program. Testability: Effort required to test a program to ensure that it performs its intended function. Portability: Effort required to transfer the program from one hardware and/or software system environment to another. Reusability: Extent to which a program [or parts of a program] can be reused in other applications related to the packaging and scope of the functions that the program performs. Interoperability: Effort required to couple one system to another. ii) FURPS Hewlett-Packard developed a set of software quality factors that has been given the acronym FURPS Quality Factors functionality, usability, reliability, performance, and supportability. The FURPS quality factors define the following attributes for each of the five major factors: Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system. Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation.
Unit 9
Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program. Performance is measured by processing speed, response time, resource consumption, throughput, and efficiency.
iii) ISO 9126 Quality Factors The ISO 9126 standard was developed in to identify quality attributes for computer software. There are six key quality attributes which are as follows: Functionality: The degree to which the software satisfies the requirements against the attributes: suitability, accuracy, interoperability, compliance, and security. Reliability: Based on sub-attributes: maturity, fault tolerance, recoverability, it is the time of availability of the software. Usability: The degree to which the software is easy to use indicated by the understandability, learn ability, operability of the software. Efficiency: The degree to which the software makes optimal use of system resources as indicated by time and resource behavior. Maintainability: It refers to the ease with which repair may be made to the software indicated by sub-attributes : analyzability, changeability, stability, testability. Portability: The ease with which the software can be transposed from one environment to another indicated by adaptability, install ability, conformance, and replace ability. iv) The Transition to a Quantitative View According to Cavano and McCall there is no such thing as absolute knowledge, one should not expect to measure software quality exactly, for every measurement is partially imperfect. The metrics represent indirect measures. The complicating factor refers to the precise relationship between the variable that is measured and the quality of the software. Self Assessment Question(s) (SAQs) 1. __________ is the degree to which the software makes optimal use of system resources as indicated by the following sub-attributes: time behavior, resource behavior.
Unit 9
2. ____________is the amount of time that the software is available for use as indicated by the following sub-attributes: maturity, fault tolerance, recoverability. 9.4.2 A Framework for Technical Software Metrics A framework for the technical software metrics is established based on the principles of technical metrics for software. The framework may be well understood under the following points: 1) The Challenge of Technical Metrics Over the past three decades, many researchers have attempted to develop a single metric that provides a comprehensive measure of software complexity. Complexity takes a somewhat different view of what is expected from quality metrics. Consider a metric for evaluating an attractive motorcycle. Some emphasize body design, others might consider mechanical characteristics, or performance, or fuel economy, or the ability to recycle when the motorcycle is scrapped. It is very difficult to obtain a single value for attractiveness. A similar problem is seen with the computer software. 2) Measurement Principles Technical metrics assist in the evaluation of the analysis and design models. It provides an indication of the complexity of procedural designs and source code, and facilitates the design of more effective testing, it is important to understand basic measurement principles. Roche suggests a measurement process that can be characterized by five activities: Formulation. The derivation of software measures and metrics that is appropriate for the representation of the software that is being considered. Collection. The mechanism used to accumulate data required to derive the formulated metrics. Analysis. The computation of metrics and the application of mathematical tools. Interpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation. Feedback. Recommendations derived from the interpretation of technical metrics transmitted to the software team.
Page No.: 105
Unit 9
Self Assessment Question(s) (SAQs) 1. __________is the computation of metrics and the application of mathematical tools. 2. _____________is the mechanism used to accumulate data required to derive the formulated metrics. 9.4.3 Metrics for the Analysis Model Analysis model is the starting point of all technical work in software engineering. At this stage, requirements are derived and a foundation for design is established. Therefore, technical metrics that provide insight into the quality aspect of the analysis model are desirable. It is possible to adapt metrics for use in this context. There is a possibility of the two size and design complexity being correlated directly. i) Function-Based Metrics The function point metric is used for predicting the size of a system. The function can manage the interactions between users, accept user password, to activate or deactivate systems, and allows inquiries on various security sensors. The function displays messages and sends control signals to various components of the security system. The data flow diagram is evaluated to determine the key measures of the function point metric on the following point : number of user inputs, outputs, inquiries, files and external interfaces. ii) Metrics for Specification Quality Davis and his colleagues propose a list of characteristics useful to assess the quality of the analysis model and the corresponding requirements specification: specificity (lack of ambiguity), completeness, correctness, understandability, verifiability, internal and external consistency, achievability, concision, traceability, modifiability, precision, and reusability. These characteristics are qualitative in nature; Davis et al. suggest that each can be represented using one or more metrics. Self Assessment Question(s) (SAQs) 1. ___________is the number of user observable states in the state transition. 2. _____________is the number of state transitions in the state transition.
Unit 9
9.4.4 Metrics for the Design Model The design of complex software systems does not have any measurement to start with. The design metrics for software are available, but most of the software engineers are unaware of the metrics. Design metrics for computer software are not perfect. There is always a scope for debating on this issue. Design without measurement is an unacceptable alternative. Some of the common design metrics to be considered are: 1) Architectural Design Metrics Architectural design metrics focus on architectural characteristics of the software and the effectiveness of modules. These metrics do not require any knowledge of the inner workings of a particular software component. 2) Component-Level Design Metrics Component level design metrics focus on internal characteristics like module cohesion, coupling, and complexity. These measures can help a software engineer to judge the quality of design. Suitable metrics may be applied once a procedural design has been developed. Self Assessment Question(s) (SAQs) 1. __________assigns quantitative laws to the development of computer software, using a set of primitive measures that may be derived after code is generated or estimated once design is complete.
9.5 Summary
The primary objective for test case design is to derive a set of tests that have the highest likelihood for uncovering errors in the software. The development of software systems involves a series of production activities. Every process is prone to errors. The software development should be subject to quality assurance process. During the process of software development the software development team goes through the stages of the development based on the principles of the developmental models and the requirements stated. Davis suggests that All tests should be traceable to customer requirements, Tests should be planned long before testing begins, The Pareto principle applies to software testing, Testing should begin in the small and progress toward testing in the large, Exhaustive testing is not possible.
Page No.: 107
Unit 9
To be most effective, testing should be conducted by an independent third party. The tests for software have to be designed depending upon the nature of the system and the working of the processes. Designing of the test model can be as challenging as the initial design of the product itself. White-box testing is also known as glass-box testing. It uses the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can derive a number of test cases. Basis path testing is the same as white-box testing. The technique first proposed by Tom McCabe. The flow graph depicts the logical flow of the control. Each structured construct has a corresponding flow graph symbol. Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. In basis path testing, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program and provides with an upper bound for the number of tests. The basis path testing method is generally applied to a procedural design or to source code. Black-box testing is also known as behavioral testing. It focuses on the functional requirements of the software. Black-box testing helps to derive sets of input conditions to handle and test all functional requirements for a program. Measurement is the key element of any engineering process. Measurements are used to understand the attributes of the models. Measurements are used to assess the quality of the engineered products. Software quality may be defined as conformance to explicitly state functional and performance requirements. It may also be conformance to explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. A framework for the technical software metrics is established based on the principles of technical metrics for software. Analysis model is the starting point of all technical work in software engineering. At this stage, requirements are derived and a foundation for design is established. The function point metric is used for predicting the size of a system. The function can manage the interactions between users, accept user password, to activate or deactivate systems, and allows inquiries on various security sensors.
Page No.: 108
Unit 9

1. What do you mean by Basic Path Testing? 2. What are the differences between black box and white box testing? 3. Write a detailed note on Technical Metrics for Software.

1. Which of the following is a Basic path Testing? (a) Flow graph (b) Graph metrics (c) all the above (d) none of these. 2. Which of the following are ISO 9126 Quality Factors? (a) Reliability (b) Usability (c) both a & b (d) none of these

9.8.1 Answers to Self Assessment Question(s) (SAQs) 9.2.1 Refer to section 9.2.1 9.2.2 1. White-box, 2. black-box 9.2.3 1. Glass box Testing, 2. Refer to section 9.2.3 9.2.4 1. Graph matrix, 2. Independent path 9.2.5 1. Condition testing, 2. Data flow testing 9.2.6 1. Behavioral testing, 2. Refer to section 9.2.7 Refer text 9.2.7 9.4.1 1. Efficiency 2. Reliability 9.4.2 1. Analysis 2. Collection 9.4.3 1. State 2. Transition 9.4.4 1. Software Science 9.8.2 Answers to Terminal Question(s) (TQs) Refer to section 9.2.4 Refer to section 9.2.3 Refer to section 9.4 9.8.3 Answers to Multiple Choice Question(s) (MCQs) 1. c 2. c
Page No.: 109
Unit 10
Unit 10
Object-Oriented Concepts and Principles
Structure: 10.1 Introduction Objectives 10.2 Object-Oriented Concepts and Principles Object Oriented Concept Identifying the Elements of an Object Model Management of Object-Oriented Software Projects 10.3 Object-Oriented Analysis Object Oriented Analysis Domain Analysis Generic Components of the OO Analysis Model The OOA Process The Object-Behavior Model Identification of Events with Use Cases Representation of State 10.4 Summary 10.5 Terminal Question(s) (TQs) 10.6 Multiple Choice Question(s) (MCQs) 10.7 Answers to SAQs, TQs, and MCQs
10.1 Introduction
A real world feature can be represented as an object. The details of the real world feature are abstracted into objects. Objects can be categorized, described, organized, combined, manipulated, and created. An abstraction enables us to model the world. An object-oriented development was proposed first during the 1960s. One can derive a number of benefits from the object technologies. Both the management and technical level people have benefited from object techniques in dealing with real world business problems. Object-oriented techniques provide a number of strategies in software based on practical methodologies. Most of the object techniques have been implemented and tested. The techniques are proven. The strategies are
Page No.: 110
Unit 10
designed to deal with complex natural and man-made system. The strategies are very fundamental. Objectives In this Chapter you will learn: What is Object Oriented Concept? What is Object Oriented Analysis? What are Object Oriented Techniques?
10.2 Object-Oriented Concepts and Principles

10.2.1 Object Oriented Concept Object oriented approach can be understood well if the knowledge of the real world entity is clear. A simple approach has to be considered to analyze any object. Consider an example of a car. A car is an automobile. Car belongs to the category of automobiles. Therefore we can say that car is an instance of automobile. Car is treated as an object and automobile is treated as a class. Every class of objects will have certain attributes and functions. In case of the automobile, an automobile has engine, fuel system, ignition system, exhaust system, wheels, seat for driver etc. These attributes can be seen in any object belonging to the class of automobiles. Ex. A car, a bus, a truck etc. The objects are said to inherit all the properties of the class to which it belongs to. i) Classes and Objects Object oriented approach and concepts used in object oriented technology lead to effective modularity. A class encapsulates the data and procedural abstractions required to describe the content and behavior of a real world entity. The data abstractions are also referred to as attributes. The attributes are controlled and manipulated by abstraction procedures known as operations or methods. These methods are also referred to as services. There is only way to access and operate the attribute of any object and that is through one of the operations. A class encapsulated both data and the processing function on the data. It is known as encapsulation. Classes can of two main types : super-class and subclass. A super-class refers to a collection of classes, and a subclass is referred to as a specialized instance of a class.
Page No.: 111
Unit 10
ii) Attributes Real world entities have features such as shape, weight, color, and type of material. These are abstracted as attributes of the object representing the real world problem. A person is considered to have attributes like date of birth, parents, name, and eye color. A domain is simply a set of specific values. For example, assume that a class named automobile has an attribute say - color. The domain for color could be {white, black, silver, gray, blue, red, yellow, green}. Under some situations, the domain can be a set of classes. The domain values can be supported with a default value for an attribute. iii) Messages Messages are the means by which objects communicate with each other. The message triggers some behavior to occur in the object that receives the message. The behavior is seen when an operation is executed. iv) Encapsulation, Inheritance, and Polymorphism Encapsulation refers to the data and the methods on the data which are held together in a class by means of specifications stated for the class. Inheritance refers to the condition of acquiring all the properties by an object from the class to which it belongs to and also from the class which is superior to its parent class. Polymorphism refers to the behavior of the object and its ability to behave in more than one form depending upon the method specification. This provides a number of benefits: The internal implementation details of data and procedures are hidden from the outside world. Data structures and the operations that manipulate them are merged in a single class. This enables it to be reused. An object that sends a message is controlled based on the specification of the internal data structure. Self Assessment Question(s) (SAQs) 1. ________ are the means by which objects interact. 2. What is a class?
Page No.: 112
Unit 10
10.2.2 Identifying the Elements of an Object Model The main elements of an object model are the classes and objects, attributes, operations, and messages. To identify the various elements from a given problem or a case one should concentrate to determine the following: Identifying the nouns in the case problem Specifying Attributes Defining Operations Finalizing the Object Definition Identifying the actions verbs in the problem Self Assessment Question(s) (SAQs) 1. What are the elements of an object model? 10.2.3 Management of Object-Oriented Software Projects Modern software project management can be divided as : 1. Establish a common process framework . 2. Use framework to develop effort and time estimates. 3. Establish deliverables and milestones to enable measurement of progress. 4. Define checkpoints for risk management, quality assurance, and control. 5. Manage the changes. 6. Tracking, monitoring, and controlling the progress. The technical manager who is faced with an object-oriented project applies these six activities. i) The Common Process Framework (CPF) It defines an organizations approach to software engineering. It identifies the paradigm that is applied to build and maintain software. It establishes the degree of rigor necessary to approach different kinds of projects. The CPF can meet the individual needs of a project team. ii) Project Metrics and Estimation Conventional software project estimation techniques require the estimates of lines-of code (LOC). It may also require function points (FP) for estimation. FP estimates is effective because the information domain counts that are required are readily obtainable from the problem statement. FP analysis provides value for estimating Object Oriented projects. The FP measure does not provide enough granularities for the schedule and effort.
Unit 10
According to Lorenz and Kidd, the following points on project metrics may be followed: Number of scenario scripts. A scenario script is a detailed sequence of steps that describe the interaction between the user and the application. Each script is organized into triplets of the form {initiator, action, participant} where initiator is the object that requests some service (that initiates a message); action is the result of the request; and participant is the server object that satisfies the request. The number of scenario scripts is directly correlated to the size of the application and to the number of test cases that must be developed to exercise the system once it is constructed. Number of key classes. Key classes are the highly independent components that are defined early in OOA. Because key classes are central to the problem domain, the number of such classes is an indication of the amount of effort required to develop the software and also an indication of the potential amount of reuse to be applied during system development. Number of support classes. Support classes are required to implement the system but are not immediately related to the problem domain. Examples might be GUI classes, database access and manipulation classes, and computation classes. In addition, support classes can be developed for each of the key classes. Support classes are defined iteratively throughout the recursive/ parallel process. The number of support classes is an indication of the amount of effort required to develop the software and also an indication of the potential amount of reuse to be applied during system development. Average number of support classes per key class. In general, key classes are known early in the project. Support classes are defined throughout. If the average number of support classes per key class were known for a given problem domain, estimating would be much simplified. Lorenz and Kidd suggest that applications with a GUI have between two and three times the number of support classes as key classes. Non-GUI applications have between one and two times the number of support classes as key classes. Number of subsystems: A subsystem is an aggregation of classes that supports a function that is visible to the end-user of a system. Once
Unit 10
subsystems are identified, it is easier to lay out a reasonable schedule in which work on subsystems is partitioned among project staff. iii) An OO Estimating and Scheduling Approach Software project estimation remains more of an art than a science. However, this in no way precludes the use of a systematic approach. To develop reasonable estimates it is essential to develop multiple data points. That is, estimates should be derived using a number of different techniques. Effort and duration estimates used for conventional software development are applicable to the OO world, but the historical database for OO projects is relatively small for many organizations. Therefore, it is worthwhile to supplement conventional software cost estimation with an approach that has been designed explicitly for OO software. Lorenz and Kidd suggest the following approach: 1. Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. 2. Using OOA, develop scenario scripts (use-cases) and determine a count. Recognize that the number of scenario scripts may change as the project progresses. 3. Using OOA, determine the number of key classes. 4. Categorize the type of interface for the application and develop a multiplier for support classes. iv) Tracking Progress for an OO Project Although the recursive/parallel process model is the best framework for an OO project, task parallelism makes project tracking difficult. The project manager can have difficulty establishing meaningful milestones for an OO project because a number of different things are happening at once. In general, the following major milestones can be considered completed when the criteria noted have been met. Self Assessment Question(s) (SAQs) 1. What are the different activities of modern software management?
10.3 Object-Oriented Analysis

10.3.1 Object Oriented Analysis The main objective of object-oriented analysis is to develop a model that describes computer software. The model should work to satisfy a set of
Unit 10
customer-defined requirements. The model used for the purpose of analysis depicts information, function, and behavior within the context. i) Conventional vs. OO Approaches Fichman and Kemerer address the question head-on: a unified modeling language (or some other method). What is the work product? An objectoriented analysis model is created. The OO analysis model is composed of graphical or language-based representations. These representations define class attributes, relationships, and behaviors, as well as interclass communication and a depiction of class behavior over time. At each stage, the elements of the object-oriented analysis model are reviewed. The review is done with respect to clarity, correctness, completeness, and consistency with customer requirements. Fichman and Kemerer suggest modeling dimensions that may be used to compare various conventional and object-oriented analysis methods: 1. Identification/classification of entities 2. General-to-specific and whole-to-part entity relationships 3. Other entity relationships 4. Description of attributes of entities 5. Large-scale model partitioning 6. States and transitions between states 7. Detailed specification for functions 8. Top-down decomposition 9. End-to-end processing sequences 10. Identification of exclusive services 11. Entity communication ii) The OOA Landscape The OOA approach lead to development of number of concepts in object technologies during the late 1980s and into the 1990s. Each of these introduced a process for the analysis of a product. A number of process diagrams were developed during the analysis stage. The diagrams drawn were based on the standards accepted universally and hence the notations used enabled the software engineer to create the analysis model in a consistent manner. Among the most widely used were: The Booch method. The Booch method encompasses both a micro development process and a macro development process. The micro level
Unit 10
defines a set of analysis tasks that are reapplied for each step in the macro process. Hence, an evolutionary approach is maintained. Boochs OOA micro development process identifies classes and objects and the semantics of classes and objects and defines relationships among classes and objects and conducts a series of refinements to elaborate the analysis model. The Rumbaugh method. Rumbaugh and his colleagues developed the object modeling technique (OMT) for analysis, system design, and objectlevel design. The analysis activity creates three models: the object model (a representation of objects, classes, hierarchies, and relationships), the dynamic model (a representation of object and system behavior), and the functional model (a high-level DFD-like representation of information flow through the system). The Jacobson method. Also called OOSE (object-oriented software engineering), the Jacobson method is a simplified version of the proprietary objectory method, also developed by Jacobson. This method is differentiated from others by heavy emphasis on the use-case. A description or scenario that depicts how the user interacts with the product or system. The Coad and Yourdon method. The Coad and Yourdon method is often viewed as one of the easiest OOA methods to learn. Modeling notation is relatively simple and guidelines for developing the analysis model are straightforward. A brief outline of Coad and Yourdons OOA process follows: Identify objects using what to look for criteria. Define a generalization/specification structure. Define a whole/part structure. Identify subjects (representations of subsystem components). Define attributes. Define services. The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner do not make a clear distinction between analysis and design tasks. Rather a continuous process that begins with the assessment of a customer specification and ends with design is proposed. A brief outline of Wirfs-Brock et al.'s analysisrelated tasks follows: Evaluate the customer specification. Extract candidate classes from the specification via grammatical parsing.
Unit 10
Group classes in an attempt to identify super-classes. Define responsibilities for each class. Assign responsibilities to each class. Identify relationships between classes. Define collaboration between classes based on responsibilities. Build hierarchical representations of classes. Construct a collaboration graph for the system.
iii) A Unified Approach to OOA Over the last few decades, Grady Booch, James Rumbaugh, and Ivar Jacobson have collaborated to combine the best features of their individual object-oriented analysis methods. Analysis methods along with design methods were combined into a unified method of modeling language. The resulting language was called the Unified Modeling Language (UML). UML allows a software engineer to express an analysis model. The analysis model is expressed based on the standards notation of UML, governed by a set of syntactic, semantic, and pragmatic rules. Eriksson and Penker explain these rules in the following way: The syntax tells us how the symbols should look and how the symbols are combined. The syntax is compared to words in natural language; it is important to know how to spell them correctly and how to put different words together to form a sentence. The semantic rules tell us what each symbol means and how it should be interpreted by itself and in the context of other symbols; they are compared to the meanings of words in a natural language. The pragmatic rules define the intentions of the symbols through which the purpose of the model is achieved and becomes understandable for others. This corresponds in natural language to the rules for constructing sentences that are clear and understandable. In UML, a system is represented using five different views that describe the system from distinctly different perspectives. Each view is defined by a set of diagrams. The following views are present in UML: User model view- This view represents the product as a system. The view is from the users perspective. The use-case is the modeling approach of choice. This important analysis representation mainly describes a scenario for usage from the perspective of the end-user.
Page No.: 118
Unit 10
Structural model view- Data and functionality are viewed. The view is internal and is view from within the system. Static structure is modeled based on the data and functionality. Behavioral model view- This part of the analysis model represents the dynamic aspects of a system. The dynamic aspect refers to the behavioral aspects of the system. It depicts the interactions or collaborations between various structural elements. Implementation model view- The structural and behavioral aspects of the system are developed and assembled depending upon the requirements and built according to the end user needs. Environment model view- The structural and behavioral aspects of the environment are represented. UML analysis modeling focuses on the user model and structural model views. One of the task of UML design modeling is to address the behavioral model, implementation model, and environmental model views. Self Assessment Question(s) (SAQs) 1. Name any two views used in UML. 10.3.2 Domain Analysis At the business or enterprise level, the techniques associated with OOA can be coupled with a business process engineering approach. At the business area level, an object model that describes the workings of a particular business area an be defined. At an application level, the object model focuses on specific customer requirements as those requirements affect an application to be built. Self Assessment Question(s) (SAQs) 1. What various levels of domain analysis? 10.3.3 Generic Components of the OO Analysis Model Rumbaugh et al. states that Analysis is concerned with devising a precise, concise, understandable, and correct model of the real world. . . . The purpose of object-oriented analysis is to model the real world so that it can be understood. To do this, you must examine requirements, analyze their implications, and restate them rigorously. You must abstract real-world features first, and defer small details until later.
Unit 10
To develop a precise, concise, understandable, and correct model of the real world, a software engineer must select a notation that implements a set of generic components of an OO analysis model. Monarchi and Puhr define a set of generic representational components that appear in all OO analysis models.6 Static components are structural in nature and indicate characteristics that hold throughout the operational life of an application. These characteristics distinguish one object from other objects. Dynamic components focus on control and are sensitive to timing and event processing. They define how one object interacts with other objects over time. The following components are identified Static view of semantic classes: A taxonomy of typical classes was identified. Requirements are assessed and classes are extracted (and represented) as part of the analysis model. These classes persist throughout the life of the application and are derived based on the semantics of the customer requirements. Static view of attributes. Every class must be explicitly described. The attributes associated with the class provide a description of the class, as well as a first indication of the operations that are relevant to the class. Static view of relationships. Objects are connected to one another in a variety of ways. The analysis model must represent these relationships so that operations (that affect these connections) can be identified and the design of a messaging approach can be accomplished. Static view of behaviors. The relationships just noted define a set of behaviors that accommodate the usage scenario (use-cases) of the system. These behaviors are implemented by defining a sequence of operations that achieve them. Dynamic view of communication. Objects must communicate with one another and do so based on a series of events that cause transition from one state of a system to another. Dynamic view of control and time. The nature and timing of events that cause transitions among states must be described. Self Assessment Question(s) (SAQs) 1. What are the various generic component of object oriented analysis?
Unit 10
10.3.4 The OOA Process The OOA process begins with an understanding of the manner in which the system will be used. The modeling of the software begins only after the scenario of usage has been well understood and defined. The following points may be followed to gather customer data to model the system: i) Use-Cases This refers to the model of the system from the end-users point of view. It is created during elicitation of user requirements. The following objectives have to be borne in mind with respect to use-cases: Define the functional and operational requirements of the system Provide a clear and unambiguous description of the interaction between the end-user and the system. Provide a basis to validate the testing ii) Class-Responsibility-Collaborator Modeling After having developed the usage scenarios, dentify candidate classes and indicate their responsibilities and collaborations. Class-responsibilitycollaborator (CRC) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler describes CRC modeling in the following way: A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right. Classes Identify classes and objects based on the following guidelines: Identify from the cases and problem under consideration, the variety of forms an object may assume, external entities, things, occurrences, or events, roles, organizational units, places etc. Perform a grammatical parse on the processing aspects of the system. List of all the identified nouns become potential objects. The following are the characteristics of selection : 1. Retained information- During analysis the potential object will be useful only if it is necessary to remember the information 2. Needed services- The operations have to identified wrt the potential object.
Unit 10
3. Multiple attributes- The focus should be on "major" information pertaining to the object, this may result in multiple attribution of the object. 4. Common attributes- A set of attributes defined may appear to be common when compared with other object in the system. 5. Common operations- There can be a common set of operations on the object which are identified as potential object 6. Essential requirements- External entities be defined as objects in the requirements model. iii) Defining Structures and Hierarchies Once classes and objects have been listed out with the help of CRC model, the analyst then focuses on the structure of the class model. The analyst then determines the hierarchies with respect to each object and classes. Class diagrams are created with the help of UML. iv) Defining Subjects and Subsystems Group of all classes are referred to as subsystems or packages. A subsystem can be treated as a black box when it is viewed from outside. A subsystem implements one or more contracts. A contract is a specific list of requests made on the subsystem. Subsystems can be represented with the by creating a subsystem index card. The subsystem index card indicates the name, contracts, and classes of the subsystems that support the contract. Packages can be referenced by a single icon. Package references can be created for multiple objects structure. Self Assessment Question(s) (SAQs) 1. ________models the system from the end-users point of view. 2. Generalization/specialization class structures can be created for ___________ classes. 10.3.5 The Object Relationship and Behavior Model The CRC and the object-relationship model represent static elements the Object analysis model. To incorporate dynamic behavior into the model, consider the behaviour of the system as function of specific events and time. The object-behavior model is sensitive to external events. To model the functionality the following steps may be considered: 1. Evaluate all use-cases 2. Identify events
Unit 10
3. Create an event trace 4. Build a state transition diagram 5. Review the object-behavior model 10.3.5.1 Identification of Events with Use Cases The methodology of going through the various sequences of activities and understanding the process helps in easy identification of the events. Any such case will be looked into to capture information. The performer actor is to be identified in the case scenario. Conditions and limitations if any are identified and listed. After identifying the events in the scenario, they are to be allocated to objects. 10.3.5.2 Representation of State There are two different aspects of the state to be considered. The first is the state of the object and the second is the state of the system in which the object functions. The state of object can be active or passive. The object is said to be in active state if it is undergoing a transformation through a process. Event is responsible to bring about a change in the object whereas the passive state indicates the status of all the attributes of the object. Self Assessment Question(s) (SAQs) 1. What are the steps followed in object-behavior model?
10.4 Summary
An abstraction enables us to model the world. An object-oriented development was proposed first during the 1960s. One can derive a number of benefits from the object technologies. Object oriented approach can be understood well if the knowledge of the real world entity is clear. A class encapsulates the data and procedural abstractions required to describe the content and behavior of a real world entity. The data abstractions are also referred to as attributes. The attributes are controlled and manipulated by abstraction procedures known as operations or methods. A super-class refers to a collection of classes, and a subclass is referred to as a specialized instance of a class. Real world entities have features such as shape, weight, color, and type of material. These are abstracted as attributes of the object representing the
Unit 10
real world problem. Messages are the means by which objects communicate with each other. Encapsulation refers to the data and the methods on the data which are held together in a class by means of specifications stated for the class. The main elements of an object model are the classes and objects, attributes, operations, and messages. Software project estimation remains more of an art than a science. To develop reasonable estimates it is essential to develop multiple data points. That is, estimates should be derived using a number of different techniques. The main objective of object-oriented analysis is to develop a model that describes computer software. The model should work to satisfy a set of customer-defined requirements. The model used for the purpose of analysis depicts information, function, and behavior within the context. The use-case is the modeling approach of choice. This important analysis representation mainly describes a scenario for usage from the perspective of the end-user.

1. Develop a classroom presentation on one static or dynamic modeling diagram used in UML. Present the diagram in the context of a simple example, but provide enough detail to demonstrate most important aspects of the diagrammatic form. 2. In your own words describe the difference between static and dynamic views of an OO system. 3. Using your own words and a few examples, define the terms class, encapsulation, inheritance, and polymorphism.

1. Which of the following are the features of object oriented approach? (a) Polymorphism (b) inheritance (c) all the above (d) none of these 2. Which of the following are the elements of object model? (a) classes and objects (b) attributes (c) all the above (d) none of these
Page No.: 124
Unit 10

10.7.1 10.2.1 10.2.2 10.2.3 10.3.1 10.3.2 10.3.3 Answers to Self Assessment Question(s) (SAQs) 1. Message 2. Refer section 10.2.1 Classes and objects, attributes, operations, and messages Refer to section 10.2.3 Implementation model view, environment model view Refer to section 10.3.2 Static view of semantic classes , Static view of attributes ,Static view of relationships, Static view of behaviors, Dynamic view of control and time, Dynamic view of communication 10.3.4 1. Use-cases 2. Identified 10.3.5 Refer to section 10.3.5 10.7.2 Answers to Terminal Question(s) (TQs) 1. Refer to section 10.3.2 2. Refer to section 10.3.4 3. Refer to section 10.2.3 10.7.3 Answers to Multiple Choice Question(s) (MCQs) 1. c 2. c
Page No.: 125

Unit 1 The Product and The Process: Structure

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 1 The Product and The Process: Structure

Uploaded by

Copyright:

Available Formats

Software Engineering

The Product and The Process

1.2 The Product

Sikkim Manipal University

1.2.6 Myths about Software

1.3 The Process

Sikkim Manipal University

Fig. 1.1: Stages of problem solving in software process model

Sikkim Manipal University

Sikkim Manipal University

Sikkim Manipal University

Sikkim Manipal University

1.4 Fourth Generation Techniques

1.6 Terminal Question(s) (TQs)

Sikkim Manipal University

1.7 Multiple Choice Question(s) (MCQs)

1.8 Answers to SAQs, TQs, and MCQs

1.3.6 1. 2. 1.3.7 1. 2. 1.4

Sikkim Manipal University

Project Management Concepts, Process and Project Metrics

Sikkim Manipal University

2.2 The Management Spectrum

Sikkim Manipal University

following questions it becomes easy to determine the scope:

2.3 Software Process and Project Metrics

Sikkim Manipal University

2.4 Process Decomposition

Sikkim Manipal University

2.5 Terminal Question(s) (TQs)

2.6 Multiple Choice Question(s) (MCQs)

2.7 Answers to SAQs, TQs and MCQs

Sikkim Manipal University

Sikkim Manipal University

Software Project Planning, Scheduling, Tracking and Risk Management

Sikkim Manipal University

3.2 Observation and Estimation

Sikkim Manipal University

Sikkim Manipal University

Sikkim Manipal University

3.3 Risk Analysis and Management

Sikkim Manipal University

Sikkim Manipal University

Sikkim Manipal University

3.4 Project Scheduling and Tracking

Sikkim Manipal University

Sikkim Manipal University

3.6 Terminal Question(s) (TQs)

3.7 Multiple Choice Question(s) (MCQs)

3.8 Answers to SAQs, TQs and MCQs

Sikkim Manipal University

Software Quality Assurance

4.2 Software Quality Assurance

Sikkim Manipal University

Sikkim Manipal University

Sikkim Manipal University

Sikkim Manipal University

4.4 Terminal Questions (TQs)

4.5 Multiple Choice Questions (MCQs)

4.6 Answers to SAQs, TQs and MCQs

Sikkim Manipal University

Software Configuration Management

Sikkim Manipal University