Unit 1-Chapter 1 Introduction 1.0 Structure of the Unit 1, Outcomes of the unit Introduction to Software Software Crisis Introduction to Software engineering Software Processes and Characteristics . Process Models . Self-Assessment Questions and Activities Ww why 6 7. 8. Multiple Choice Questions (MCQs) 9. Keys to MCQs 10. Summary 1.1 Outcomes of the Unit 1. Discuss the software, software engineering (SE Define software products. :xplain the attributes of good software Discuss the importance of SE and its applications. Analyze software process models, and crisis, wh 1.2 Introduction Software refers to the computer programs and related documentation developed for a specific client or a general market, The software consists of computer programs, data structures, and documentation, Examples of software are Online Reservation System, Windows Operating System, VLC Movie Player, Firefox, Google Chrome, etc. A program is a set of instructions written in a programming language used to execute a specific task or function. Software is a collection of several programs and other procedures and documentation, Software and Program: A program consists of a set of instructions that are coded in a programming language like c, C++, PHP, Java, etc. The software consists of bundles of programs and data files. Programs in specific software use these data files to perform dedicated types of tasks. The program has limited functionality and fewer features. The software has lots of functionality and features such as GUI, inpuvoutput data, process, etc. A program may not be software but software can be a program. The software takes relatively more time to build/make when compared to a program. The program development approach may be un-procedural, unorganized, and unplanned. The software development approach is systematic, organized, and very well-planned. The size of a program may range from kilobytes (KB) to megabytes (MB). Thesize of software may range from megabytes (MB) to gigabytes (GB) or more. The program may have patchy documentation mostly technical. The software has comprehensive documentation including user manuals. The major types of software are: 1. System Software: Operating System, Text Editors, Compilers 2. Programming Software: Tools for writing computer programs, such as Java, Python, C, C++, ete. 3. Application Software; Sofware for a particular task such as accounting, data proc games, etc, The other types of software are given a 1. Scientific / Engineering Software 2. Embedded Software Application Software Web application 5. Artificial intelligence software Software is in our daily life. Software systems lack physical constraints. The software can be extremely complex to create, difficult to understand, and expensive to change, Sofware development is still a complex and challenging task. The modern world is unimaginable without software. The sofiware has ng, -y Ss presence across various industries. Among numerous sectors, the software is usefull in manufacturing, utilities, distribution, finance, education, and entertainment. Some of the software applications are: 1. Global positioning system (GPS) 2. WhatsApp, Instagram, websites, Student Portals 3. Traffic lights, fire alarms. 4. Home and Office Autom: 5. Security Systems, online examination, reservation systems 1.2.1 Software Products When software is developed for a specific requirement, it is known as a software product. There are two types of software products. 1, Generic products: Software sold in the open market is generic. E.g., packages for Preparing drawings, typesetting, accounting, hospital management-related tools, etc. Customized products; Software developed for a specific customer is custom-made or bespoke software, E.g,, airline traffic control, the control system in customer, Software Products are produced using SE, 1.2.2 Attributes of Good Software Maintainability: We should be able to do changes in the software based on business needs. 2. Dependability: Software should be reliable and should not cause damage or financial loss during failure. 3. Security: Unauthorized or unknown persons should not be allowed to use the software as they can create harm to the system. 5Software should be quick, consume less memory, and should not waste computer resources. $. Acceptability: All types of users must be able to use the software. It should be easy to understand, use and install on different systems 1.3 Software Crisis Software products are difficult to alter, debug, and enhance; use resources non-optimally; often fail to meet the user requirements; are far from being reliable; frequently crash, and are often {clivered late, Many factors such as larger problem sizes, lack of adequate training in software engineering, increasing skill shortage, and low productivity improvements have created a software crisis. Ineffective development of the product and inefficient resource usage, lead to more cost and ime. This situation was termed a software crisis. Software applications are getting larger, and more complex. and the demands change, Systems nust be built and delivered more quickly. In many places ad-hoc approach to software Jevelopment is widespread. Therefore, software tends to be unreliable, and expensive to maintain and use. An engineering approach to developing and managing software is required. This entails xducation and training in software engineering methods, A satisfactory solution to the present software crisis can come from a spread of SE practices among the engineers with advancements © the software engineering discipline itself. Good software can be developed with the use of systematic software engineering. 1.4 Introduction to SE The term ‘software engineering’ was first proposed in 1968 at a NATO conference held to discuss what was then called the software crisis. It became clear that individual approaches to program development did not scale up to large and complex software systems. The software was unreliable, 20st more than expected, and was delivered late. Software engineering techniques such as structured programming, information hiding, and object-oriented development. Tools and standard rotations were developed and are now extensively used. Definition of SE: A detailed study of engincering to the design, development, and maintenance of software is known as SE. SE is a branch of engineering related to: © Collecting customers’ requirements © Preparing the design © Writing programs or code © Testing © Maintenance 1.5 Software Processes and Characteristics 4 software process is defined as a collection of related activities for producing quality software. The development of software is done using standard programming languages such as C, Java,Python, etc. A modem approach is the use of readymade tools or developed software components. Reusing the existing software reduces a lot of time and effort. A software process consists of four activities as given below. w | Software Specification 2.Software Design and Implementation 3.Software Validation 4,Software olution Software Specification: The different functions in the software and the conditions under which it is developed are defined in his step. In this phase, the requirement engineering tion document that fulfills the detailed process is used to develop a requirement specifi system specification. There are two levels high-level statement is for end-users and clients. The detailed design is for stakeholders such as system managers, developers, ete. Software Design and Implementation: The requirement is converted into a design and implemented using programming language to meet the requirement specification. The structure of the software to be implemented is given by the software design. The system components, interfaces, database, and architecture designs are produced in this stage. The design can be top-down, bottom-up, structured, etc. Object-oriented design and procedure- oriented designs are prepared using standard tools and techniques. Software implememtation is done using programming languages such as C, Python, Java, C++, and other supporting packages. The programming style is dependent on the individual programmer. Software Validation: The software is verified whether it is fulfilling the requirements of the client. Here the programs are tested using test data. Whether the developed system is alidated in this step. Unit testing, system testing, and acceptance testing are some examples of software validation steps, Software Evolution; The software must get refined to meet the needs of the customers, The software meeting the customer's requirements or not is idered flexible. The software is part of a complex system that requires continuous modification, Software evolution refers to software maintenance or accommodating changes in the software over time. There is no common software process for all the applications. The software process is complex and creative based on the decisions taken by the people, The people involved in the software process are clients, developers, managers, administrators, etc. The major classification of the software process is plan-based and agile. In the plan-based software process, requirements are fixed, and plans are concrete and not changed. In the agile software process. the software process steps are flexible and are changed as per changes in the requirements. The architecture or framework of the software process can be represented using various models as given below. The activities in the software process are described using an abstract mode! known as the softwaredevelopment life cycle (SDLC) or process model. The SDLC model includes all the stages in software development from requirement specification to the maintenance of the software. 1.6 Software Process Models The software process models represent the generic or partial information of a software arocess. It does not depict any specific activity but shows the framework. The process nodels discussed in this section are: 1. The Waterfall Model 2. The Incremental Development Approach 3, Prototyping Models 4. Boehm’s Spiral Model 1.6.1 The Waterfall Model The waterfall model is developed in 1970 for representing a simple system engineering process by a scientist Royce. In this model, there is cascading of one phase from another like a waterfall. Another common name used for this model is the software life cycle. The phases of the waterfall model are described as follows: 1. The requirement definition phase: Used to collect information about what a client wants. 2. The design phase: Used to prepare the architecture or a blueprint of the software to be developed 3. The implementation and unit testing: These phases are used to convert the design into computer programs. Unit testing refers to testing small computer program components, 4. The integration and testing phase: These phases are used to combine all the components developed and test the complete software system 5. Operating and maintenance phase: The last phase is where the software system is used and tested in the customer's workspace. The maintenance phase is used to accommodate new requirements. The waterfall model is depicted in Figure 1.1.Figure 1.1 The Waterfall Model ‘The Important characteristics of the waterfall model are: * Asoftware development process consists of several phases in sequence. * Aphase can be started only after the completion of the previous phase. * This development model is sequential: the phases do not overlap each other. * Work can be divided, according to phases, among different classes of experts. * Advantages: Simple and easy to understand. All phases are processed one at atime and well documented. It is well suited for smaller software systems. The progress can be tracked more accurately. It reduces development and maintenance costs. * Disadvantages: The waterfall model is rigid. This is not a good model for complex or long-ongoing software systems. If requirements change midway, it is difficult to accommodate those in this model. There is no working software Produced till the very end of the life cycle as integration is generally done towards the end of the software life cycle. |,.6.2 Incremental Development Model The incremental development model is used to produce an initial software, deliver it to the user, understand the user's feedback, and then arrive at the final product version, Incremental software development is based on agile software development. The software is developed in Parts, if there is any mistake, it is possible to go back and correct it easily as compared to the waterfall model. The phases of the incremental software development model are given as follows: 1. Specification: Collect the requirements from the client and prepare system specifications. nw Development: Prepare a design or model of the software and complete programming, Validation: Test the developed software to ensure that the client's requirements are fulfilled.Final Version Figure 1.2 Incremental Development Software Model ‘The versions shown in the above figure are referred to as increments, At the initial stage, urgent work is included in the system. Then the dditional functions are added based on the response given by the customer. The important features of incremental development are given as follows, 3 Software product is developed in increments or steps. First a few functions are developed to get a working model of the software, Later more functions are added, The requirements are collected using a fixed method like the Waterfall Model. But coding, integration, and testing are done incrementally. Incremental software development uses a mix of both planned and agile software processes. Advantag Users’ changes can be incorporated, The most important functionality is developed first with better quality, Time taken is less. Testing functions, error detection, and correction are easier. Drawbacks: Preparing multiple versions of the software product can be very costly, Upgrading software many times can lead to time delay and frequency changes can corrupt the structure. Involving clients i necessary for an incremental development model, Such kinds of customer-developer contract re not very usual. 63 Software Prototyping Model In this model, a working prototype of the software is given to the user for comments and feedback. It helps the user to give all their requirements in a more detailed fashion. A prototype means a s jarting version of a software system. This initial version illustrates different concepts, design layouts, etc. Based on the prototype, problems or loopholes and related remedies can be found. A prototype is an initial version of a software system that is used to demonstrate the concepts and design of the software. A prototyping model clarifies and validates thequirements. The design ideas and interface between the different parts of the software design in be explored using prototypes. The prototyping model is developed into two types. a) Evolutionary Prototyping: In this model, a prototype is developed and used by the clients. Based on the feedback, i refined by including the additions, This model is modified in several iterations. It begins with the requirements that are best understood. The different steps in the evolutionary model are shown in Figure 1.3. sing initial requirements Figure 1.3 Evolutionary Prototyping Model The important features of the evolutionary prototyping model as given below. w The evolutionary computing model is useful when the now known beforehand. Some examples include artificial intelligence, machine learning, and user interface systems, tem specifications are Evolutionary prototyping builds a system as a set of increments and is delivered to customers. Rapid software development with reusable components, computer-aided software engineering (CASE) tools, and 4GL are based on evolutionary prototyping. The interfaces are built using GUI. The advantage of the evolutionary prototyping model is it gives a quick delivery of software products. It also involves clients using the system from its initial development to the final The drawback of the evolutionary model is it requires specialist skills to accommodate the changes. The maintenance is expensive due to continuous changes. The system structure may get corupt due to continuous maintenance. There are management and contractual problems in evolutionary prototyping models. b) Throw-away Prototyping: System requirements are derived in this model. The software process of this type starts with requirements that are poorly understood. The prototype iswot 1.6.4 developed as a trial version and given for experimentation and then it is discarded, Thus, it is not considered a final product, The stages of throw-away prototyping are depicted in Figure 1.4, Here the initial version of the software is developed only temporarily to get detailed requirements from the user. This is then thrown away and a revised version of the software is developed using the Waterfall Model or some other model. Figure 1.4 Throw-away Prototyping Model The important features of the throe-away prototyping model as given below. The software product delivery is fast as the throw-away prototype is developed using rapid software development tools. It clarifies requirements. It includes reusable, COTS components and involves customers in the development of the software product. Boehm’s Spiral model The spiral model is developed by scientist Barry Boehm in 1986. The spiral model is also known as the Meta Model as it is made of characteristics of different models such as waterfall. incremental and evolutionary models. The spiral model produces the software quickly and it is flexible in accommodating changes in requirements and design. It has good documentation control, and it satisfies customers with risk management features. The spiral model includes four quadrants with different activities of software development as shown in Figure 1.5.Quadrant 2: Anatys! Wentity Aternatives & Fiske Figure 1.5 Boehm’s Spiral Model Aspiral model is an iterative approach and there is a spiral for each phase of software development. the specific activity of sofiware engineering such as requirement In each spiral or cye' specification, design, coding, ete, takes place. This activity can be like any other model such as waterfall, prototyping, or incremental. The spiral model is risk-driven, and it identifies and asses: es risk in activities, It combines customer satisfaction, approval, and documentation control. Each loop in the spiral model includes four sectors as given below. 1) Objectives: Define the objectives, constraints, management plan, ete for the software product. Identify the project risks and alternative strategies if required. This step is the starting point of the spiral model. The objectives are concerned with the functionality and performance of the software product 2) Assessing and reducing risks: Assess the risks and perform a detailed analysis and steps to reduce risks. For example, if risks are inappropriate, then develop a prototype for the system to understand the needs. The initial model can be further used to incorporate the remaining features. In this step, risks are resolved using activities related to information collection. 3) Development and Validation: In this step, a model is selected after the risk evaluation. ‘Throw-away prototyping can be used if there are risks in user interaction. A formal system model is helpful if there are safety risks. Risks may be related o finance, new programming language, compiler, etc. 4) Planning: In this step, based on the risk evaluation, a decision is taken on whether to continue with the project. If the project is to be continued, then plans for the next phases are drawn, Steps in project management related to preparing schedules, cost estimation, and manpower are planned in this step.The important characteristics of the spiral model are as follows, ) The spiral model is used for large and complex projects in software engineering. The phases in the spiral model are planning, analyzing risks, engineering that includes coding and software deploying, and software evaluation by customers. The spiral model is useful if there are frequent changes in requirements, unclear and complex. Cost estimation is easy and software deployment is faster in the spiral model. There are several advantages to the Spiral model, but it works for large projects and requires a risk assessment. Thus, it is not suitable for small projects. 3 4 2s 6) Documentation in the spiral model is more as there are many intermediate steps. 7) The risk assessment in the spiral model may not meet the schedule or budget of the project. 1.7 Self-Assessment Questions and Activities 1) Define software engineering and explain its need. 2) What are the types of software? 3) Explain software produc 4) Describe the term software cri $) List a few applications of soft 6) Identify the nee 7) What is a software development life cycle? 8) Explain the phases of the waterfall model. 9) How the waterfall model is different from other models? 10) Discuss the drawbacks of the waterfall model. 11) Describe the incremental development model. re, ry characteristics of the software. 12) What are the types of prototyping models? Discuss with suitable examples. 13) Explain the different sectors in the spiral model, 14) Discuss the strengths and weaknesses of the spiral model. 15) What are the limitations of the waterfall model? How the spiral model addresses these issues’? 1.8 Multiple Choice Questions (MCQs) 1)A Linux Operating system is an example of ___ A. System Software B. Application Software C. Scientific Software D. Web Software 2) Ifa newcomer college student is assigned software development, which SDLC is suitable? A. Waterfall ModelB. Throw-away Prototyping C. Evolutionary Prototyping D. Spiral Model 3) Which of the following a model can be used for risk analysis? A, Spiral Model B. Prototyping Model C. Waterfall Model D. None of the above 4) Waterfall model is not suitable for__ A. Accommodating changes B. Large complex project C. Small projects D, Testing projects 5) Which of the following is not a phase in the software development model? A. Requirement gathering B. Feasibility study C. Requirement validation D. Prototyping 6) The most fundamental model for software process is A. Waterfall Model B. Evolutionary Prototyping C. Throw-away Prototyping D. Incremental Development 1,9 Keys to MCQs 1) System Software (A) 2) Throw-away Prototyping (B) 3) Spiral Model (A) 4) Accommodating Changes (A) 5) Prototyping (D) 6) Waterfall Model (A) 1.10 Summary of the Unit Sofware refers to the computer programs and related documentation developed for a specific client or a general market. When software is developed for a specific requirement, it is known as a software product. A detailed study of engineering to the design, development, and maintenance of software is known as Software Engineering. The software process is represented using abstract models known as the SDL or process model. The fundamental SDLC model is the waterfall model, used when the requirements are well known. The SDLC models are incremental development, prototyping, spiral model, etc.Unit 1-Chapter 2 Reliability and Quality 2.0 Structure of the Unit 1. Outcomes of the unit 2. Software Quality and Reliability: Introduction 3. Importance of Software Retiabil 4. Failure and Faults 5. Reliability Models 6. Total quality management T. Software Quality Models 8. 180-9000 9, SEILCMM Model 10, Compatison of ISO and CMM 11, Self-Assessment Questions aid Activities 12. Multiple Choice Questions (MCQs} 13. Keys to MCQs 14, Summary 2.1 Outcomes of the Unit Discuss the retiability issues in software. Identify the reliability metrics in quantifying the reliability of the software products. Understand the reliability of growth moxteting, Discuss the quality factors im the software, 5. Understand and comparison of [SO ancl SEI CMM Models 2.2 Intreduetion The quality of the software is determined by its reliability, Reliability is a failure-free software ‘operation in a specific environment, Software reliability iy diffieult as it is complex. For example. the aircraft of this generation will have billions of lines of code. Software failure is due to errors. incorrect usage of software, incompetent developers, or inadequate testing. The reliability may be hardware or software, 2.2.1 Software Reliability: Software reliability isthe probability of the software working correetly over a given time. Software reliability depicts the trustworthiness or dependability of the system, Software with many defects is known as unreliable, Reliability is difficult to measure, as it changes when the errors are removed, it relies on the observation and location of the error, Reliability also depends on bw that product is used. Ifthe input to the system is selected such that it always gives eorryet output, then the reliability is high, whereasif the input always invokes crrorsin the software, then the relia Pwois low. The reliability can be improved by reducing the number of defects, Meastining software reliability is difficult due to several reasons: ‘© More errors, and paor reliability. © The reliability depends on how well the software product is observed and tested using suitable input © Based on fixing bug. the reliability keeps changing. 2.2.2 Software Failure ‘The reliability is based on software failure. Software failures are classified into five different types as follows. L Transient: This failure is only due to certain inpat values given to the system 2. Permanent: Software failures for all input values while invokingea function of the system are called permanent failures, 3. Recoverable: When a system can recover with or without any manual help from the failure, then it is called recoverable failure. 4. Unreceverable: A software failure where the system needs to be restarted. 5. Cosmetic: System failure due to cosmetics leads to minor irritable software failures, © g.. ‘not being able to click on an option for selecting a menu 2.3 Hardware and Software Relial ity Hardware reliability is different from software reliability as most of the time, the components wear and tear ever time, and there is hardware failure, The software fault will remain till the error is tracked and either the design oF program is changed, After the hardware repair, the reliability is maintained, whereas, in the ease of software reliability, it may increase or decrease. Thus, the hardware reliability study is related to stability, and software reliability aims at reliability growth. The difference between hardware and software reliability is shown in Figure 2.1 ate Hate Figure 2.1: Hardware Product‘As shown in the graph, the hardware and software reliability depend on how much hardware components are deteriorated over usage or after many days the software is outdated. The software product growth is shown in Figure 2.2 Testing Ountanest sei Lite Faure Rate Figure 2.2: Software Product ‘Table 2.1: Differences between Hardware and Software Reliability I ee The components wear and tear overtime, | Software failure is due ta bugs and there is a hardware failure (After a hardware repair, reliability is maintained ‘Afier fixing bug, reliability may increase or decrease. Hence while fixing a bug, care should be taken not to introduce other bugs. mture | Software faults may be design or logical faults | which are hard to detect and correct | ‘Hardware faults are physical in 2.4 Reliability growth modeling Software with fewer defects i reliable. Ensuring 3 reliable software product is usually a goal of any organization. to determine the quality of software at any given point in time during the software development process, softwate reliability metrics ate used. ‘The reliability growth model is used as a mathematical approach to determine how software reliability can be improved as bugs are found and later repaired. To predict when a particular level of reliability can be achieved, reliability growth models are used. The models can be used to decide when to stop testing the software for finding bugs once a reliability level has heen reached. A software reliability model defines the behavior of software failure to time, ‘Various software models have been used to understand the features of why and how the software fails, and also to measure software teliability. Software reliability is difficult to measure as there is no individual model that can be used in all situations. It depends on the software being developed. The software usually fails due to improper/faulty functionality and not due to wear out. Many models have evolved aver the years, but due tothe rise in demand{or software reliability models, based on their nature these software reliability models are categorized as « Prediction Models + Estimation Models Prediction Models Historical data from real software projects are used. Previous data is used for analysis. They are used hefore the development or test phases to predict reliability at some time in the furure. Estimation Models ‘Uses curcent failure data from testing to forecast failure rate, Usually used after collecting some data and hence are used later in the life cycle development, 2.5 Software Quality Software quality is determined, unlike a traditional product such as the working of a fan or any machine. Software is not considered a quality product if it only satisfics the functional If the software is working as per requirement specification but it takes a long time and memory, then it is not quality software, Software that is defect free, delivered within the allocated budget and time, meets the client's requirements. and can be casily maintained is known as quality software, The software quality reflects both functional as well as structural quality. Asper the modern view of quality, several fuctors determine software quality, © Portability: When a software product can be made to work on different operating system environments, different systems, etc. hen itis known as portable software ‘* Usability: When both expert senior and movies of new persons can use the software without any difficulty, then itis said to have usability quality attributes. © Reusability: This factor determines the reusability of the software, where different ‘components can be reused several times to develop new software. © Correctness: This factor determines whether the software is correctly implemented aceonting to the requirement speci fications. ‘© Maintainability: This factor determines whether the software product can be easily corrected and whether new functions can be added without much overhead. 2.6 Software Quality Management System. A quality management system is also referred to as a quality system. It is a fundamental methodology used by organizations 1o give assurance that the products have desirable quality, A quality management system must contain the following. + Managerial Structure and © Quality System Activities livid | Responsibilities1, Managerial Structure and Individual Responsibilities: Quality iss responsibility of the whole organization with many departments. There is quality department in every organization, Quality management is used to establish a framework for the organization's standards. The standanis are applied to software-related documentation such as system requirements, design, and code, At the project level, every process is checked whether it isa quality process producing products that are of the expected quality standard. 2. Quality System Activities ‘The quality system activities are related to auditing the projects, reviewing the quality. developing guidelines, and methods, ete, for otyanizations, generating reports for the top management, etc, The quality goals are defined in the quality plan to define what processes are to be used. The most used terms are quality assurance or quality control in the manufacturing industry. Quality management is evolving over the past several years. In the earlier days before World War Il. the quality was checked only to chiménate the defects. Since then, the quality system has undergone different stages of evolution us shown in figure 2 Initially, the quality system was only to determine the defcts but in recent days, the reasons for the cause of defects are also considered for correction, Thus, quality control is not just rjecting the produets but also correcting them. Quarry | Inepection Quatity Asgurance Paradigm Process, f i 4-----4 Product — Assurance Figure 2.3: Evolution of Quality Management 2.7 ISO 9000 certification 1SO stands for International Standatds Organization, ts an international standard development organization, It 1s composed of representatives from the national standards organizations of ‘member countries, 1SO published its 9000 series of standards in 1987. It provides guidelines for maintaining quality [SO certification and serves as 4 reference for contracts between independent patties, The operations and responsibilities, and report aspects are addeessed by the ISO for producing high-quality development. The ISO 9000 standand gives guidelines for Producing the product and itis not concerned with the product itself.‘Types of ISO 9000; 1. ISO 9001: This standard applies to most software organizations. The design, development. production, and servicing of the products use this standard 2. 180-9002: This standard applies to those organizations which are not involved in the design of the product but are concerned with the production. The industries such as a car of sicel manufacturing companies buy their design from extemal parties and only focus oa manufacturing, Therefore, this standard does not apply to soware products, 3. 180-9003: This standant is applied only to organizations that are involved only in the installation and testing of the products, Need for ISO Certification: With the use of ESO certification, the customer gets confidence in the product, ISO 9000 uses fa well-structured and documented process in place, and this assures that the developed software is of high quality. The development process is much more efficient and cost-effective with the ISO 9000. Lf there are any Weak poits, then they are pointed out by the ISO 9000 and the remediesare given. Thus, the use af ISO 9000 sets the basic framework for an efficiem, process and results in total quality management (TQM), However, [SO 9000 sets the steps for the software production process but does not guarantee the high quality of the process. It is nota full-proofagency, and it may downplay the domain experts. It requires a heavy emphasis ‘oa documentation and takes a Lot of time and effort. 2.8 Software Engineering Institute Capability Maturity Model (SEI CMM) Software Engineering Institute (SE!) is a research and development center promoted by the U.S. Department of Defence (DOD) that has developed the Capability Matunty Model (CMM). CMM is 4 procedure that is used to develop and measure the maturity of an organizatioi’s software process. The quality of the software can be improved using the SEL CMM. With the help of the SEI CMM model, there can be business benefits. SELCMM has two methods that can be used for capability evaluation and software process assessment Capabainry Schware Process| ‘Evaluabon Assessment Figure 2.4: Methods of SEICMM Capability Evaluation: With the help of capability evaluation, we can understand how to assess an onganization’s software process capability.Software Process Assessment: To improve the process capability. the software process assessment is used by am organization. It is purely used for internal purposes. There are five maturity levels of software development industries using SEE CMM. + Initial + Repeatable’ Managed + Defined + Quantitatively Managed + Optimizing TEE! | recmeawe weorecictable. oty contotnd and tea Figure 2.5: Levels of CMM the processes are unplanned and disorganized. Success depends upon individual efforts as very few processes are defined. Prediction of product quality and time of completion is difficult as the environment is unstable for software development. © Repeatable: Project management policies are established. Based on earlier project experience new projectsare managed. The focus is on software requirement gathering. project planning. configuration management, and quality assurance. Processes are established to track the cost, schedule, and functionality of the software. * Defined: Standard guidelines for the processes. of software development and Mainicnancs are introduced and documented, Training programs are conducted for improving the skills of the development team to ensure understanding and increase wark efficiency. + Quantitutively Managed: The organization set quantitative quality goals. Software metrics like product metrics and process metrics are given importance ta develop a quality product. © Optimizing: Thistevel focuses on continuous process improvement using quantitative feedback in the organization To prevent defects from recurring, mow tools and techniques are usedThere are several key areas provided by SEICMM for the organizations. The key process areas (KPA are given in Table 2.2. The quality is improved gradually from onc level to the Next over several stages. Each stage is carefully designed so that one stage enhances the already existing capability. Table 2.2: KPA sand CMM Levels | cnt Level Focus Key Process Areas Initial ‘Competent people No KPA Soltwire project planning and cantigutaiion | management Process definition, training programs, and peer reviews Repeatable Project Management Defined | Defining of processes ‘Product and process Managed Software metrics and quality management quality SS naan ane | Defect prevention, process change Optimizing MaPFOvement °F) eranagement, and technology change continuous process management. 2.9 Comparison between ISO and SEI CMM Table 2.3: ISO and SEI CMM comparison 1SO 9000 includes a set of international standards on quality management, and it is awarded by the international standards body, It helps companies to get efficient software industry and therefore addresses many issues which are specific to the software industry alone. documentation for quality The ISO 9000 8 focused on the customer | SEICMM is only on the improvement of and supplier relationship intermediate processes to achieve a high- quality produc - 10 9000 is accepted by most countries | SET CMM isused in the USA and less in other countries. 2.10 Self-Assessment Questions QI. Explain software reliability in brief. Q2. Compare software and hardware retiabilityQ3. What are the different software failures? Explain with a suitable example QS. Explain the different refiability metrics used to measure the reliability of software QS. Deine reliability and explain the reliability metries in brief Q6. Write a note on reliability growth modeling. Q7. What is software quality? Explain the factors to determine the software quality Q8. Explain the software quality management system in brief. Q9. Explain differem versions of SO 9000, 10. What is the need for ISO 9000? Explain in brief. QUL. Identify and explain the different levels of the SE! Capability Maturity Model QI2. Explain Software Engineering Institute Capability Maturity Model (SEL CMM). Q13. Explain the key process arcas ofa software organization provided by the SEI Capability Maturity Model Q14_ Differentiate between ISO 9000 certification and S 2.11 Self-Assessment Activities lain how the reliability of the software product can be enhanced. Discuss in brief Hain how the quality of software can be improved with a suttable example. AJ. Explain the steed for [SO centification and make a list of software companies with ISO 1 MM. certification. 2.12 Multiple-Choice Questions Qu isthe probability of the software working correctly overa given period. ware reliability A. Software Quality B. Software Maintenance CC. None of the above Q2, Which of the Following does not belong to software failure classification? A. Transient B. Recoverable C. Unrevoverable D. Completeness Q3. Which of the following does not belong to reliability issues? A. The quality of the software isdetermined by its reliability: BL The reliability may be hardware or soflware C. Software is always reliableD. Software failure is due to errors Q4. With the usage of sofia: A. alwys increases ts reliability 'B. may increase or decrease ©. always decreases D. isconstant throughout its use Q5. Factors that determine software qual A. Portability B. Usbitity ©. Reusbility D. All ofthe above Q6, The _of the software can be improved using the SEI CMM. A. Fixing bugs B. Maintenance Quality 1D. None of the above Q7.1SO stands for A. Indian Standard Organization ‘B. International Standards Organization C. International Software Organization D. None of the above Q& __was developed specifically for the software industry and therefore addresses many issues whieh are specific to the software industry alone. A. MTTF B. 150 © SEICMM D. MTBR2.13 Keys to Multiple-Choice Questions ‘Q1-Software [A] Q2.Completeness [D] (Q3.Software is always reliable [C] G4. may increase or decrease [B] QS. All of the above [D] 96. Quality [C] ‘Q7. Intemational Standards Organization. [1B] 8. SEI CMM [C] 2.14 Summary of the Unit Software reliability is the probability of the software working correctly over & given period. The reliability is based on software failure. The reliability may be hardware or software, The reliability growth model is used ay a mathematical approach to determine how software reliability can be improved as bugs are found and later repaired. The software quality reflects both functional as well as structural quality. Several factors determining sofiware quality are portability, usability, reusability, correctness, and maintainability. ISO 9000 includes a set of international standards on quality management. and it is awarded by the international standards body. It helps companies to get efficient documentation for quality. The quality of the software can be improved using the SEL CMM.Unit 2-Chapter 3 Software Project Management: 3.0 Structure of the Unit Outcomes of the unit Software Project Management life cycle 3, Software Project Planning, 4. Project Size Estimation 5. Cost and Effort Estimation Model: COCOMO Model 6. Risk Estimation and Management 7. Project Monitoring, and Control 8. Project Scheduling: Basic Concepts and Principles 9, Task Network, 10, Gantt Chart and PERT 11, Project Staffing 12, Self-Assessment Questions and Activit 13. Multiple Choice Questions (MCQs) 14. Keys to MCQs 15, Summary 3.1 Outcomes of the Unit Discuss software project management. ‘Discuss the estimation of various parameters such as cost, Efforts, and schedule duration. ‘Evaluate software in terms of size. cost, and schedule using project management principles. Analyze the constructive cost models (COCOMO) and, resource allocation models. Develop effort and risk estimation models. Analyze project monitoring and control ovens 3.2 Software Project Management (SPM) life cycle SPM is an important part of software cagineering from the stage of a conceptual model to the developed software stage, Any project in software engineering is under the constraints of budget and schedule planned. The siceess of the project varies based on the application and users, but in general, the goals of the SPM are- Maintuin the agreed timing of the software delivery. ‘Keep the project activities under the alloted budget. ‘Fulfill the client’s specifications Make sure that the development teams functioning well in a happy atmosphere.4.2.1 Management Spectrum: The SPM is effective with a focus on the four Ps. known as the management spectrum, as givei below = People: Software engineening involves tremendous human work. The people include clients, the project manager, and his team. Clientsare involved in giving clear expectations The project manager coordinates all the people and activities. A successful software product is developed with a well-structured software project plan. Software engineering involves tremendous human work. Senior managers define the business éssues that often have a significant influence on the project, Project (technical) managers must plan, motivate, organize. and control the praciitioners who do software work. Practitioners deliver the technical skills that are necessary 10 engineer a product ar application. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome, End users interact with the software once itis released for production use: ‘© Product: A detailed plan is needed to examine the product and the problem it is antended to salve at the very beginning of the project. There are two important things in the product: Scope and problem decomposition. The scope of the product must be established and bounded. The scope is defined by 1. Context: The size, business, aid other contexts ire determined 2. Information objectives: The output and input datw are determined as information objectives © Process: The software process is a framework that establishes different activities. The process framework establishes # skeleton for project planning. It is adapted by allocaung a tsk set that is appropriate to the project, The process model is decided using the class of cchents, product characteristics, and the project environment. ‘+ Project: The project must be organized in a manner that enables the software team to succeed. The five common-sense ajyprouches for the project are: 1. Start on the right foot 2. Maintain momentum, 3. Track progress 4. Make smart decisions, $8. Conduct post-mortem analysis, Project management in software engineering is different from other engineering practices. In civil or mechanical engincering, the progress of the project underdevelopment is visible and the Project manager can see it. Whereas in software engincering the product is intangible. A review ‘of the progress with team members is only possible in software development. The software processes are dynamic, unlike electrical or civil engincering project tasks. When the software to be developed is part ofa large engineering project, it becomes impossible to determine whether there will be any software development problems. SPM is managed by the project manager, For any project, whether itis small or big, the project manager is employed for its completioa, Theproject manager is responsible for, Project planning. Reporting, Risk management, People management, and Proposal wniting 3.3 Project Planning The SPM life cycle includes project planning as a major activity. This activity is followed by project monitoring and project control. Activities in project planning are shown in Figure 3.1. Figure 3.4: Activ In project planning. the project manager is responsible for planning the project and estimating and developing the project schedule. The different task allocation to team members is dane by the project manager. The manager will manitor the project development progress within the given schedule and budget. Project plunning is completed befure the software development activity begins. Project planning includes the following important activities. stimation of project size, cost duration, and efforts: The size of the project determines the ‘complexity of the project im terms of the complexity of efforts and time required for software development, The cast of the project refers to how much finanee is necessary 10 develop a project. The duration refers to the time required to complete project development ‘The effons refer to the manpower and other resources required for project completion, Preparing a schedule of manpower and resources such as web, database, hardware, etc ‘Organisation and appointment of staff, In this activity, analysis is done to find out if the ‘existing stafT is sufficient for the project or if new hiring is required. 4. Configuration management and quality assurance planning. The different activities can be conducted in the order shown an Figure 3.1, The size of the project is determined first. The effort estimation is connected to project staffing. The size 1s connected to the time of duration required for completion and scheduling. Each activity is equally important in peojeet planning in Project Planning 3.4 Project Size EstimationWhen developing any software project, itis always necessary to estimate the cost, schedule, and time required to complete the project. The cost, schedule, and time of the project can be determined using the size of the project. This is the reason the size of the project must be determined very accurately. There are some important metrics commonly used in project size estimation: © Lines of Code (LOC) © Function Point (FP) Project Estimation Techniques A.A Lines of code (LOC) This is the simplest metric used where the project size is calculated by counting the number ‘of source instructions in the program. The comments and the header file sinternents, are excluded from the count, LOC includes the lines in « program containing the declaration of all variables, and executable and non-executable statements, For estimation of the project size at the imal stages of development, the project size can be divided into modules and submodules, and so on, To estimate the accurate LOC. the expertence in the past and the skill of the software developer are considered. Programming skills can be divided into 3 types as shown in Table 3.1 Table 3.1 Division of Programming Skills Skill Level Developed Code | Efficient | Optimistic (Sopt) Average | Most Likely (Sm) Poor Pessimistic (Spess) The LOC cam be calculated using the formula: Sopt + 45m + Spess) s- ee) Example: Consider a software system, at the initial stage it is estimated that there are 5200 Sopt, 7000 Sm, and 9000 Spess. Find the expected LOC of the software. tion: ‘ (ct + 45m + Spess ) eae (5200 + 4* 7000 + 9000)/6 = 7033 LOC 3.4.2 Function point (FP) Funetion point was proposed in 1983 and it overcomes many pitfalls of the LOC metre Unlike the LOC method, FP can be used to estimate LOC night from the stage of problemspecification, Function point (FP) is used to measure the size of software based on the fianetional view. The main concept of the FP method is that size of the software depends on the number of functions or features included in the project. The more the number of functions ‘or tasks in the project, the higher the size of the project. Other parameters to estimate the size are the number of files and interfaces to the project, and inputioutput date values. FP calculation considers the number of inputs, outputs, queries, internal files. and external files FP determines the approximate development cost at the early stage. The functionality of the system is from the user's point of view, Table 3.3: Notutions used in Function Poiats | Important Notations FP = Function Point FPC = Function Point Count UFP = Unacijusted function point VAF = Value adjusted factor TDI = Total degree of influence DI = Degree of Influence EI = — Number of external Inputs EG = Number of external outputs EQ = Number of external inquiries r Number of Internal Files EIF = Number of external and internal interfaces Weighting Pactor Table: Table 3.3: Weighting Factor Table used im Function Pots ‘Weighting Factor Table (generally average calculation is used) Function Unit | LOW | AVG) HIGH (Number ofextemalinpus(—ED ——s—=<“i*~‘“‘“‘<«<~S!*S!SCS | Number of external outputs (EO) — | 4i)s), 7 4 | Number of external inquiries (EQ) as Tay (Number of intemal Files (IF) 10 | Number of external and internal interfaces (IF) |S 7 Degree of Influence (D1) : Table Degree of Influence (D1) No influence 0‘Steps for Function Point (FP) ealcuiati Example for finding the FP co [ Incidental T i | Moderate T 2 | average TF] | Significant T 4 1 | Essential 5 Table 3.6; Formulas and Steps used in the Function Points (FP) calculation Compute the Unadjusted Function Points (UFP), Find the Total Degree of Influence (TDD. Compute Value Adjustment Factor (VAF). Find the Function Point Count (FPC). ‘This means: 1, UFP = (EI*AWF) + (EO*AWF) + (EQ*AWF) +(ILF*AWF) +(EIF*AWF) (AWE: Average Weighing Factor) 2. TDI = 14°DT 3. VAF = 065+ (0.01 * TDD) 4.FP-UFP* VAF 1. Consider software project with the following functional units. » 2 3 4 3 6 7 Number of user inputs = 20 Number of user outputs = 40 Number of inguines = 4 Number of files = 5 Number of external interfaces Degree of influence is given as Weight Factors are given as = 3132543331254 erage for which the values are 4, Caleulate the function point estimation of the project. Solution = From the data given, Table 8.7 is prepared for calculating UFP. Table 3,7; UFP Caleulation ‘UFP Calculation| Measurement Factor ‘Count | Weight Factor | Total Average Number of external Inputs (E1) a 4 7) | Number of external ourputs (£0) oo 5 300 Number of external inquiries (2Q) a a 16 ‘Number of Internal Files (LF) 7s I 10 i 50 Number of external and internal interfaces z Y 7 ry (Er) | Total UFP - . [ 360 1. UFP = (EI*AWF) + (EO*AWF) + (EQ*AWF) +([LF*AWF) +{EIF* AWE) (20 #4) + (40* 5) +14 4y=0S* 10+ 0° 7) = 80+ 200+16+50+ 14 UFP = 360 2. Calculation of DI = Average of given comples factor = average 0f 3,1,1.3.2.84,3.3,3,1.2,5.4 as given in the problem = (Brit +342: = 4014 DI = 2.857 3. Calculate TDL = 14 * DL ‘TDI = 39.99% 4. Calculate VAF = 0.68440.01 TDI) AedSr bedstead = 0.65 + (0.01 * 39.998) 0399 1,05 AF S. Calculate FP = UFP* VAF =360* 1.05 (The value of UFP is taken as the average value from Table 3.7) FP=378 Advantages and drawbacks of FP Metrics Unlike LOC, FP can be used at the initial software development stage. It does not depend on the programming language. U sing FP, the productivity of the software can be determined using just the problem definition. With the FP method, the analysis of the same problem using different languages can be done and the best one can be determined. Kean be used where there are many interfaces such as GUI.Some of the drawbacks af the FP metric is it depends on subjective evaluations with a lot of judgment. This model is Hot suitable for real-time system software development. In many applications, itis necessary to convert FPto LOC for measiring software metrics. 3.5 Effort and Cost Estimation The most fundamental parameters such as the size of the project, efforts, duration, and cost are determined in the project estimation technique known as Constructive Cost Management Model (COCOMO) COCOMO Model The COCOMO model is proposed by Barry Boehm in 1981 after considering a study of 63 projects. The diffcrem parameters such as size, ef and quality are estimated in this model. Acconding to Bochm, software projects can be divided as follows. 1) Organic: In this type of project is well understoex! with a small development team having good experience in a similar project. These projects are simple, and the project size is in the range (of 2KLOC -S0 KLOC) 2) Semidetached: [n this type of project, the development team isa mixture of experienced and inexperienced team members. These projects are used for creating utility programs in the range of (S0KLOC 300 KLOC) bedded: In this type of project, the software to be developed is strongly connected to the nplex hardware. A development team needs to know embedded system-based software of this type. These are complex jyrojects with restricted regulations and a size “300 KLOC. cost ti The COCOMO model is divided into three types. 1) Basic COCOMO Model 2) Intermediate COCOMO model 3) Complete COCOMO model 1) Basic COCOMO Model The basic COCOMO model gives an approximate estimate of the project parameters, The basic COCOMO estimation model is given by the following expressions: Effort = ay x (KLOC)"2 PM Tdev = b, x (Effort)"’2 Months * KLOC: Kilo Lines of Code as an estimated size of the project al, a2, bl b2: Constant values for each category of the software products, + ‘Tdev: estimated time to develop the software, expressed in months PMs: Tota! effort required to develop the software product, expressed in person-months ‘The constant values are given in the following tableSS Organic 24 10s 25 038 Semi Detached 3.0 1.12 25 035 Embedded 36 1.20 25 0.32 1) Estimation of development effort: The formulas for estimating the effort for the three classes of software products, based on the code size are shown below Organic : Effort = 2.4(KLOc)"> PM Semi-detached : Effort = 3,0(KLOC)'"? PM Embedded —: Effort =3,6(KLOC)'" PM 2) Estimation of development time: Organic : Tdev = 2.8(Effort)"** Months Semi-detached : Tdev = 2.5(Effort)’* Months Embedded =: Tdev = 2.5(Effort)"*? Months Example; Assume that the size ofan organic type of software prexluct has been estimated to be 32,0400 lines of source code. Assume that the average salary of software engineers is Rs. 15.000 - per month. Determine the effort required to develop the software product and the nomanal development time. Solution: From the basic COCOMO estimation formula for organie software: Effort = 2.4 x (3291.05 = 91 PM Nominal development time The cost required ta develop 1 x (9190.38 = 14 months product = 14 x 13,000 = Rs. 210,000/- 2) Intermediate COCOMO model The basic COCOMO model determines efforts using LOC whieh is only a function of the size ‘number of lines of code and some. But in practice. only LOC cannot be used te determine any system’s efforts and schedule. Other factors such as experience, capability, and reliability must be considered should be used in estimating efforts, These factors are known as multiptiers or cast drivers. There are 1$ such drivers used in cost estimation The cost drivers are classified based o the attributes of the following items 1. Product: The complexity and reliability of the product are considered in this attabute 2. Computer: The con figuration of the computer stich as execution speed. memory storage. ele, 8 considered in this attribute.3. Perso he experience of the soflware developer, knowledge, and analytical ability is considered in this attribute, 4. Development Environment: The fucilities available for software development are considered in this attribute. One of the important features that are required in this attribute is CASE tools used for the readymade availability of the software components, 3) Complete COCOMO madel In the basic and intermedinte COCOMO: model, the software product is considered a homogeneous entity, Most of the large systems consist of many smaller sub-systems. These subsystems may be organic type, some may be semidctached ar embedded. The camplexity and inbility oF these subsystems may be difforent. The complete COCOMO model considers these characteristics and estimates the efforts and development ti the individual subsystems, The cost of each subsystem is done separately. Each subsystem may have widely different charneteristics. For example, some subsystems may be considered as organic type. some semidetched, and same are embeded. The complexity and reliability requirements of cach subsystem may be different. The complete COCOMO model considers these differences in characteristics of the subsystems and estimates the effort and development time as the sum of the estimates for the individual subsystems. The cost of each subsystem is Himated separately. The margin of'error ia the final estimate is less in this model, The cost driver's impact on each step of the software engineering process is considered ‘The COCOMO is applied in each phase to estimate effort and then the efforts are added. The ‘Six phases of detailed COCOMO are: 1. Planning and requirements System design Detailed design Module code and test Integration and test Cost Constructive model as the sum of the estimates for Pewee Example of Complete COCOMO Model Consider a distributed Management lnformation System (MIS) product for an organization. The organization is spread across the country with offices in several places. Each offi ‘components such as 4 database, graphical user interfuce communication is of the type of embedded software. Th and GUI is of the type organic software type. The o sum of the thres subcomponents 3.6 Risk Estimation and Management Risk indicates the problem that may cause some damage or loss or predict that the project nity not be successful. Riskis a threat that is not yet happened. Risk is that input or event or situation that affects of bacotnes an obstacle to the project completion. Risk Management is associated with a software project and solving the problem before they damage the project, Risk management helps ¢ cant have sub- (GUD, and communication part, Here the database part is semi-detached software Il cost of the system is estimated as thein analyzing the impacts of risks so that the quality af the software is improved. It is like an investment or an insurance policy, The different risks in SPM are: © Project Risks: Project risks refer to scheduling problems, resources, person allotment, and some client-related difficulties. The software product cannot be seen ar touched like any mechanical, electrical, or other engincering-based product, For example, in house construction, the different stages of construction such as bricks level, slab or carpentry work, ete. can be monitored very easily. But in software, this is not the ease, he slippage in scheduling is a major project risk # Technical Risks: The problems in main design, programming, imterficing, testing, and maintenance problems can lead to technical risks. The technical risks exist bevause the development team has less knowledge about the domain, or the software used. If the sofiware requirement specifications are confusing, incomplete, or frequently changing then there isa technical risk. In a few cases, there is a technical risk due to outdated sofware © Business Risks: This type of risk is related to the budget available for the product. The software product may be very good, but it may inclade business risks due to its unaffordable price. ©) Other Risks: The ther risks include people risks whieh indicate the risk with the people associated with the product development. Some people may quit the ongoing project, and this creates a disturbance. If the organizational environment is ot feasible for the employee, then there is threat of organizational risk. Tool risk is like technology risk that is derived from the supporting software and other tools. Risk Management Process: The risk Management process is shown in Figure 3.2 Listot Possible Risks Figure 3.2; Risk Management Process 1. Risk Identification: This is the starting stage of the risk management process. This stage includes brainstorming where a team of members gathers and identify the type of risks Generally, this process is led by the project manager. The manageable list of risks is summarized at the end of this stage,Risk Assessment/Analysis: In the risk assessment, the rank of the risks is idlemtified which describes the potential for damage 1o the software, The rank of the risk is calculated as follows, Let r be the possibility ofa risk coming true and the consequences or effect of the problems associated with these risks is indicated by the term s, then the priority of each rik is calculdted as: . With the priority of the risks, the most damaging risk is handled first. Risk Planning: In the Risk Planning process, for each identified risk, different strategies are developed, Each fisk should be handled separately. Risk planning includes the following steps; Avoidance Strniegics, Risk Reduction’Minimization strategies, and Contingeney plans, Risk Monitoring: In this process, the assumptions, and the business risk description is verified, Any change in the identified risk is monitored in this step. The risks can beavoided ‘or transferred of reduced. For selecting the spesific strategy for handling risk, the project manager estimates the cost using risk leverage. The risk leverage ts nothing, but the cost, and it iscaleulated as: RL=(R_B-R_AVC Where R_L is the risk leverage, R_Bis the risk exposure before reduction, R_Ais the risk exposure afer reduction and C is the cost of risk reduction 3.7 Project Monitoring In this step. a project management plan is prepared which serves as a guideline for executing @ project. A project is executed successfully if it is monitored carefully. There isa need for tracking to check the performance of a project. For tracking the success of a project, measurements are used. The data must be collected and analyzed so that the step-by-step project execution can be checked. The LOC, FP, and other metrics are used in project measurements. The main goal of project managers for monitorang 4 project so that they can determine whether any action needs to be taken t-ensure that the project goals are met. As project goals are expressed as effort schedule. and quality. There are three levels of monitoring for a project as given below Activity-level monitoring: This level ensures that each activity in the detailed schedule is done properly and within time, This type of monitoring ix done on daily basis im team mectings conducted by the project manager. Tools like Microsoft Project can be used to track the project status. Siatus reports: These reports are prepared weekly to inke stock of what has happened and what needs to be done. Status reports summarize the activities completed since the last status report. The purpose ofa status report is to check any delayed activities o issues in the project.+ The milestone analysis: In this step, milestone analysis is dome every few weeks. The project plan is prepared for effort and the schedule is often itichuiled in the milestone analysis. 3.8 Project Scheduling: Basic Concepts and Principles Project scheduling involves preparing various graphical represedtations showing project activities, their durations, and staffing. The process of organizing a praject imo a set of tasks and deciding ‘when and how the tasks are executed is called Project Scheduling. The different tasks involved in project scheduling are: Project scheduling activiticn ane given as shown in Figure 3 Figure 3.3 Project Scheduling Process *The calendar time, the effort, and the people working on the task should be identified ‘The resources such as server, disk space. specialized hardware, simulator, ete. must be determined “The travel budget for the project must be determined. Divide the project into tasks and estimate the time and resources required to complete cach task, Optimize the use of the workforce so that the tasks eam be perfarmed in a parallel fashion. “Minimize task dependencies to avoid delays caused by one task waiting for another to complete “These activities depend on project managers" intuition and experience. 3.8.1 Principles of Project Scheduling Project scheduling is based on the following principles, 1, Companmentalization; Define distinct tasks. 2. Interdependency: Indicates the relationship among tasks 3. Effort validation: Check whether resources are available. 4. Defined responsibilities: Assign duties to people. 5. Defined outcomes: There should be output for exch task, 6, Defined milestones: Review for quality,Doring project scheduling. resource allocation is done using a Gantt chart, Afier resource allocation, a program evaluation and review technique (PERT) chart is prepared for project Monitoring and control activity. 3.9Task Network Task networks are also known as activity networks. The flow between the tasks is represemied in a grphical manner using task networks. The tasks depend on cach other and are performed sequentially. These dependencies or connection between the tasks is shown using Task networks In some situations, the tasks are conducted simultaneously, These parallel tasks must be known to the project manager. There are automated touts for managing task networks. These task networks re 4 graphic representation of the task flow for a project. It is sometimes used as the mechanism thraugh which task sequence and dependencies are input to an automated project scheduling tool (Consider activities Al, A2.A3, A4.A5 and A6 activities. There are two sets [AI, A2, A3] and (94. AS, AG] exceuted simultaneously. The final stage is the target stage. [> {= }{+ Figure 3.4 Task Network project scheduling are: The commonly used time management tool: *Gantechart *Programme evaluation and review technique (PERT) 3.10 Gantt Chart and PERT 1. Gantt Chart shows the task mame and start and finish date For each task 2. Iemay change with time but are a useful starting point, 3. A Gantt chart is a type of horizomal bar chart, and itis used in project management, 4.1t provides a graphical visualization of a schedule that helps to plan, coondinate, and track specific tasks (or elements) in a project. S.With the help of the Gantt chart, multiple tasks can be grouped into single page. A Gainnt Chart for completing a final year project for a student is given in Figure 3.5igure 3,8 Gantt Chart for Project Completion, PERT Chart: 1. PERT stands for Program Evaluation and Review Technique) 2. PERT chart isu project management tool used to schedule, organize. and coordinate tasks within 4 project 3. ILis.a useful too! to identify the tasks invalved in completing a project 4, I helps find the minimurn time needed tw complete the total project. Figure 3.6 PERT Chart for Software Development Lift: Cycle In Figure 3.6, some activities are sequential, and a few are in a parallel fashion, The source is 1 and the destination is 6. In the Figure, the rectangles with numbers ave milestones or events. The direction of the arrow indicates that the events must occur sequentially. The dotted lines indicate that there is no need for resources, and these are dummy activities. 3.11Project Staffing ‘The different project teams are organized in scheduling using the project staffing technique. The right persons arc identified for handling the project and assigning responsibilities. The skill setand talents of the people are identified. Every project is unique and requires distinet knowledge andskill, The proper selection of software engineers affects the overall proxtuctivity of the entire sofware team. The advantages of project staffing are: 1. Eff 2 Good reensitment and placement 3. Training and development 4. Developing a human source in the company 4.12 Self-Assessment Questions and Activities QLExplain the management spectrum. Q2.Deseribe the key features of: COCOMO for cost esti mation Q3.Discuss the LOC metrics (Q4. What is a function point? Explain its imponance. (Q5.Explain the different parameters in function paint analysis. Q6.Explain the types of risks in SPM. Q7.A suitable diagram describes project planning in SPM. Q8.Explain the risk management process with « suitable diagram. (Q9.What are the principles of project scheduling? 10, Explain Project scheduling activities with a suitable diagram. QL1. Draw a GANTT chant for completing house construction Q12. Prepare a PERT chart for completing a project related to ATM activities. ordination 4. 3Multiple Choice Questions (MCQs) Q1.LOC and FP calculation ts used for: a) Manpower b) Duranon cc) Cost d) Software Size Q1.The correemess is measured using: a) Cost per LOC 1b) Documents for LOC <) Defects per LOC d) Time for LOC (Q3-The software size metric is used for a} Number of modules 1b) Number of functions e} Number of inputs id) Number of lines of codeQ4 Project size and complexity are part of the a} Process Metrics 1b) Product Metrics ©) Software Rel xd) None of the above Q5.Software project management goal does not refer to: a) Software delivery im the allotted time 'b) Keeping-a good environment in the team e) Avoiding customer clients 4) Managing costs within the budget ‘QS. Risk managemieit addresses the following issues a) Riskavoidince b) Risk management ¢) Risk identification 4) All the above (Q7. Software risk involves a) Firefighting b) Crisis Management ©) Budget ) uncertainty and toss ‘QS. Risk in developing a product with no budget and use is___ a) Product risk ‘by Project risk ©) Business risk 4) Know risk 'Q9. Risks encouniered during software development are 4) Product risks: bi) Project risks ©) Business risks d) All the above ‘Q10. Genetic risk requires more attention than product risks. a) Tre by False 3.14 Keys to MCQs (QL-Software size (D) Q2. Defects per LOC (C) ‘Q3. Number of lines of cade (D) ‘Q4.Product Metrics (B) Q5. Avoiding customer clients (C)Q6.All the above (D) ‘Q7.Uncertainty and toss (D) ‘QW. Business Risk (C) (Q9.All the above (D) Q10 False (B) 3.15 Summary of the Unit SPM includes. activities such as project planning, monitoring. and contro, The different Parameters in project management are cost, effort, and schedule'duration, The LOC and function point metrics are used to determine the project+management activities, Halstead”s ssoflware science is used to determine these metrics. The software quality is determined by applying function point measures, cyclomatic complexity, and control flow graphs. The ‘COCOMO isa well-known model used in the estimation of eost in SPM. 3.16 Keywords: * Loc +P + COCOMO Model © Halstead Software Mewics © Project planning and monitoring © Project Scheduling + Gantt and PERT Chast