You are on page 1of 16

Master of Business Administration Semester-IIi

ASSIGNMENT

MI0033 – Software Engineering Set- I

SUBMITTED BY:
NAME ROLL NO COURSE CENTRE CODE CENTRE CITY : : : : : VIJAY KUMAR SHARMA 520933061 mba 3293 NEW DELHI

Note: Note: Each question carries 10 Marks. Answer all the questions.

permissible tolerances. Repeatable. There are a number of ways of achieving quality.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. When the tolerance is set to a very low level the expected design characteristics would be of high quality. which refers to examination of intangibles that affect the process and works to optimize their impact. The quality movement started in the 1940s with a major contribution on quality aspects from W. 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. The variations may not be clearly visible always. Answer. Quality of conformance is mainly focused on the implementation of the software. A system of continuous improvement helps in achieving good quality. Quality and reliability are related concepts but are fundamentally different in a number of ways. The first step towards quality is to see that the variations are minimized. potentially. and measurable. Quality Concepts: It is a well-known fact that all engineered and manufactured parts exhibit some or the other variation. The next stage is kansei which leads to improvement in the product itself and. Discuss them. The variations are sometimes microscopic which can be identified by means of some equipment necessary to measure the geometrical attributes. and performance specifications contribute to the quality of design. When greater levels of performance are specified. Quality Control: Quality is the buzz word of every organization today. 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. If the degree of conformance is high then the level of quality of conformance is also deemed as high. One of the major benefits of quality has been the saving in the overall cost of production. Quality: Designers specify the characteristics of the quality of a product. Edwards Deming. After Kaizen it is atarimae hinshitsu. electrical characteristics etc. The purpose of kaizen is to develop a process that is visible. Kaizen refers to a system of continuous process improvement. to the process that created it. The final stage is miryokuteki hinshitsu which broadens the management concern beyond the immediate product. Controlling quality can be done by means of measuring various characteristics of Page 2 of 16 Vijay Kumar Sharma . But how does one work towards achieving quality in the organization and within the organization at various process levels. The grade of materials used in the product development and product characteristics. Quality of conformance is expressed as the degree to which the design specifications are followed during the process of manufacturing. Both kaizen and atarimae hinshitsu focuses on processes.I Q1. For higher-grade of materials the tolerances are very small.

And associated with every process is the quality which again comes with certain cost. A non conformance is reported if a deviation is observed in the actual performance when compared with the planned performance against certain expectation. cost component of formal technical reviews and the cost component pertaining to the test equipment. The report based on the audit provides the management with the information that is necessary for them to take suitable actions. One of the concepts of quality control is that every process can be measured. 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. and processes towards maintenance. processes towards appraisal.I the product and understanding the behavior of the product towards changes in the product characteristics. 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. reviews.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. The expectations are listed out based on the requirement of certain standards norms. A feedback mechanism in the process list will help in constantly reviewing the performance and enhancement in the performance. The measurement will tell as to whether there has been any improvement in the process or not. One of the key issues pertaining to the quality aspect is the reliability of the software product. Every such activity is associated with some cost. 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. The nonconformances are reported area wise or process wise. The main components contributing towards the cost are the cost component of quality planning. Quality Assurance: Quality assurance is a process of auditing various areas and identifying the non conformances in such areas. and tests on the software processes. A series of audits may be conducted to keep a tab on the deviations if they tend to occur. It is possible to automate these steps in the quality control process of the software system. A combination of the measurement and the feedback allows the software developer to refine the software process and tend to approach perfection. Cost of Quality: There are many activities involved in a software project leading to the completion of the intended service or the product. 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. Failure refers to nonconformance to the Page 3 of 16 Vijay Kumar Sharma . tested under a specified environment and for specified time. It involves a series of inspections. The main categories under which the quality costs may be listed are the ones dealing with processes towards prevention. Software Reliability: The need for quality is there in the minds of everybody associated with the software project.

Therefore. These mechanisms have to undergo improvements time to time in order to maintain the competition in the market. Discuss the Objective & Principles Behind Software Testing. Detailed definition of test cases can begin as soon as the design model has been solidified. Tests should be planned long before testing begins: Test planning can begin as soon as the requirements model is complete. Testing Principles Davis suggests a set of testing principles that have been adapted: All tests should be traceable to customer requirements: As we have seen. 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 occurrence of failure (MTF) and mean time towards repair (MTR). A good test case is one that has a high probability of finding an as return discovered error. Various standard mechanisms are developed in the companies to focus on the quality of the product. It is necessary to identify and assess the hazards in software projects that affect the software performance. Suitable models could be used to achieve this safety. is to isolate these suspect components and to thoroughly test them. The Pareto principle applies to software testing: Stated simply. Answer: Testing Objectives Glen Myers states a number of rules that can serve well as testing objectives: 1. 3. of course. Page 4 of 16 Vijay Kumar Sharma . Q2. the objective of software testing is to uncover errors.I requirements of the software stated. The product has to be viewed from the user point of view. 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. Background Issues: The quality assurance processes are very vital in establishing quality features in the product. 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. A successful test is one that uncovers an as-yet-undiscovered error.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. 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. Testing is a process of executing a program with the intent of finding an error. It follows that the most severe defects (from the customer’s point of view) are those that cause the program to fail to meet its requirements. all tests can be planned and designed before any code has been generated. The problem. 2.

software maintenance. For this reason.By most effective. Although the CMM comes from the area of software development. Page 5 of 16 Vijay Kumar Sharma . For reasons that have been introduced earlier in this unit. Answer: The Capability Maturity Model (CMM) is a theoretical process capability maturity model. it can be (and has been and still is being) applied as a generally applicable model to assist in understanding the process capability maturity of organisations in areas as diverse as. we mean testing that has the highest probability of finding errors (the primary objective of testing). risk management. it is impossible to execute every combination of paths during testing. information technology (IT). to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised. the software engineer who created the system is not the best person to conduct all tests for the software. The CMM was originally developed as a tool for objectively assessing the ability of government contractors' processes to perform a contracted software project. however.I Testing should begin “in the small” and progress toward testing “in the large”: The first tests planned and executed generally focus on individual components. It is possible. For this reason. The 5Level structure of the CMM can be illustrated by the diagram below. Exhaustive testing is not possible: The number of path permutations for even a moderately sized program is exceptionally large. As testing progresses. system engineering. for example: software engineering. To be most effective. it has been used extensively for avionics software and government projects around the world. and personnel management. testing should be conducted by an independent third party. project management. Discuss the CMM 5 Levels for Software Process.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. system acquisition. focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system. Q3.

 Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs. basing it on the earlier work of Phil Crosby . The goals signify the scope.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set.where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement. and hence was also known as "Humphrey's CMM". Page 6 of 16 Vijay Kumar Sharma .the stages that organizations’ processes will need to pass through as they progress up the CMM continuum. and intent of each key process area.the old CMM being renamed to Software Engineering CMM (SE-CMM). boundaries. including. Variants of maturity models derived from the CMM emerged over the years. for example. and for each KPA there are five definitions identified: Goals Commitment Ability Measurement Verification • o o o o o The KPAs are not necessarily unique to CMM. Humphrey had started development the model at the SEI (US Dept. Accreditations based on the SE-CMM expired on 31 December 2007.  Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way.) The CMM involves the following aspects: • Maturity Levels: A 5-Level process maturity continuum .as they do . The SEI was at Carnegie Mellon University in Pittsburgh. (Note that maturity models generally started to become part of international standards as part of ISO 15504. Measurement and Analysis. Key Process Areas: Within each of these maturity levels are Key Process Areas (KPAs) which characterise that level.I The CMM was first described in the book managing the Software Process (1989) by Watts Humphrey. Systems Security Engineering CMM (SSE-CMM) and the People Capability Maturity Model. There are five types of common features: Commitment to Perform.the latter had earlier published the Quality Management Maturity Grid in his book Quality is Free (1979).the Capability Maturity Model Integration (CMMA) . of Defence Software Engineering Institute) in 1986. Activities Performed. and Verifying Implementation.  Common Features: Common features include practices that implement and institutionalize a key process area. Ability to Perform. The CMM has been superseded by a variant . representing . The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level.

schedule. is established and improved over time. according to the SEI: "Predictability.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. Projects establish their defined processes by the organization’s set of standard processes according to tailoring guidelines. Organizations are characterized by a tendency to over commit. however. at major milestones and at the completion of major tasks). and procedures. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. While not rigorous. There is still a significant risk of exceeding cost and time estimate. and control of an organization’s software processes are believed to improve as the organization moves up these five levels. they frequently exceed the budget and schedule of their projects. and. Level 2 . The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed. These standard processes are used to establish consistency across the organization. process descriptions.Initial Processes are usually ad hoc and the organization usually does not provide a stable environment. chaotic environment. Software project success depends on having quality people. Basic project management processes are established to track cost. At level 2. Project status and the delivery of services are visible to management at defined points (for example. The processes may not repeat for all the projects in the organization. and functionality.Defined The organization’s set of standard processes.I Levels of the CMM: There are five levels defined along the continuum of the CMM. effectiveness. A critical distinction between level 2 and level 3 is the scope of standards. abandon processes in the time of crisis.Repeatable Software development successes are repeatable. projects are performed and managed according to their documented plans. the standards. maturity level 1 organizations often produce products and services that work. and not be able to repeat their past successes again. In spite of this ad hoc." Level 1 . Process discipline helps ensure that existing practices are retained during times of stress. and Page 7 of 16 Vijay Kumar Sharma . the empirical evidence to date supports this belief. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. which is the basis for level 3. When these practices are in place. Level 3 . process descriptions. The organization may use some basic project management to track cost and schedule.

Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities. management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. 3. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives.Optimizing Focusing on continually improving process performance through both incremental and innovative technological improvements. processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning. and deployed. shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives. Optimizing processes that are nimble. At this level organization set a quantitative quality goal for both software process and software maintenance. At maturity level 3. on a particular project). In particular. Quantitative process-improvement objectives for the organization are established. process descriptions. management can effectively control the software development effort. Though processes may produce predictable results. processes are only qualitatively predictable. Sub processes are selected that significantly contribute to overall process performance.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. Page 8 of 16 Vijay Kumar Sharma . At maturity level 4. Level 4 . Level 5 . At level 3. and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit. processes are concerned with addressing common causes of process variation and changing the process (that is. continually revised to reflect changing business objectives. A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. the standards. adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization.Managed Using precise measurements. evaluated. These selected sub processes are controlled using statistical and other quantitative techniques. Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified. At maturity level 5.I procedures may be quite different in each specific instance of the process (for example. A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. Discuss the Water Fall model for Software Development. At maturity level 4. and is quantitatively predictable. and used as criteria in managing process improvement. the performance of processes is controlled using statistical and other quantitative techniques. the results may be insufficient to achieve the established objectives.

The outputs of the earlier phases are often called intermediate products or design document. when the activities of a phase are completed. which states that the phases are organized in a linear order. And coding begins after the design is done. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system. Since changes performed in the output of one phase affect the later phases that might Page 9 of 16 Vijay Kumar Sharma . A project begins with feasibility analysis. project plan. After this the regular operation and maintenance of the system takes place. Once the programming is completed. changing requirements cannot be avoided and must be faced. The consequence of the need of certification is that each phase must have some defined output that can be evaluated and certified. to clearly identify the end of a phase and beginning of the others. detailed design. However. Another implication of the linear ordering of phases is that after each phase is completed and its outputs are certified. This is usually done by some verification and validation. the output of a software project is to justify the final program along with the use of documentation with the requirements document. the system is installed. coding and unit testing. the activities performed in a software development project are requirements analysis. the output is the code. these outputs become the inputs to the next phase and should not be changed or modified. The Waterfall Software Life Cycle Model With the waterfall model. On successful completion of testing. project planning. system integration and testing. test plan and test results.I Answer: Water fall model: The simplest software development life cycle model is the waterfall model. Therefore. the requirements analysis and project planning begins. The design starts after the requirements analysis is done.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. First. Some certification mechanism has to be employed at the end of each phase. For the coding phase. there should be an output product of that phase and the goal of a phase is to produce this product. On the successful demonstration of the feasibility analysis. the code is integrated and testing is done. From this point of view. design document. Linear ordering of activities has some important consequences. The following figure demonstrates the steps involved in waterfall life cycle model. system design.

The configuration management ensures that any changes to a baseline are made after careful review. Initiation. These changes have to make in a controlled manner after evaluating the effect of each change on the project. often used in software development processes. One of the key advantages prototype modeled software has is the time frame of development. Explain the Advantages of Prototype Model. The work will even be faster and efficient if developers will collaborate more regarding the status of a specific function and develop the necessary adjustments in time for the integration. Everyone has to work on the same thing and at the same time. Production/Implementation and Maintenance. Slowly the program is created with the customer in mind. Analysis. Q5. Design. more effort is placed in creating the actual software. The certified output of a phase that is released for the best phase is called baseline. Construction. This brings us to the need for configuration control or configuration management. Another advantage of having prototype modeled software is that the software is created using lots of user feedbacks. The work on prototype models could also be spread to others since there are practically no stages of work in this model. The waterfall model is a sequential design process. & Spiral Model in Contrast to Water Fall model. all phases listed in the waterfall model must be performed anyway. For a successful project resulting in a successful product. Instead of concentrating on documentation. Testing. it can be changed. If something is unfavorable. users could give their honest opinion about the software.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. Answer: Prototype Model Advantages Creating software using the prototype model also has its benefits. in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception. This way. the actual software could be released in advance. Any different ordering of the phases will result in a less successful software product.I have been performed. There are two basic assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall model. Page 10 of 16 Vijay Kumar Sharma . In every prototype created. reducing man hours in creating software. keeping in mind the interests of all parties that are affected by it.

like a waterfall.[4] Q. if not impossible. but depended on a though Royce did not use the term "waterfall" in this article. non-working model (Royce 1970). The first formal description of the waterfall model is often cited as a 1970 article by Winston W.[1] This presentation was about the development of software for SAGE.6.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly. Progress flows from the top to the bottom. The first known presentation describing use of similar phases in software engineering was held by Herbert D. In 1983 the paper was republished prototype. Royce. this hardware-oriented model was simply adapted for software development. is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice. Explain the COCOMO Model & Software Estimation Technique. Royce presented this model as an example of a flawed.I The unmodified "waterfall model". Benington at Symposium on advanced programming methods for digital computers on 29 June 1956. Since no formal software development methodologies existed at the time. This. in fact. [3] [2] with a foreword by Benington pointing out that the process was not in fact performed in strict top-down. Answer: Page 11 of 16 Vijay Kumar Sharma .

As you refine your knowledge of the problem. project managers are included. Costar permits you to continue this process until you arrive at the level of detail that suits your needs. you can use Costar to produce more and more refined estimates. Typically. so all of the details are published. and because it doesn't rely upon proprietary estimation algorithms. Your next estimate will continue the process -. and is based on a study of hundreds of software projects. that it's possible to misuse it -. Your initial estimate might be made on the basis of a system containing 3.g.000 lines of code.g.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set.I The COCOMO cost estimation model is used by thousands of software project managers. and yet powerful enough to plan and control large projects. "the project will enjoy good management") Every definition (e. and as you design more of the system.every Costar user should spend the time to learn the underlying Page 12 of 16 Vijay Kumar Sharma . Costar offers these advantages to its users: • • COCOMO estimates are more objective and repeatable than estimates made by methods relying on proprietary models COCOMO can be calibrated to reflect your software development environment. Your second estimate might be more refined so that you now understand that your system will consist of two subsystems (and you'll have a more accurate idea about how many lines of code will be in each of the subsystems). One word of warning: It is so easy to use Costar to make software cost estimates. Unlike other cost estimation models. you'll start with only a rough description of the software system that you'll be developing. Costar allows you to define a software structure to meet your needs. the precise definition of the Product Design phase of a project) The costs included in an estimate are explicitly stated (e.you can use Costar to define the components of each subsystem. and to produce more accurate estimates Costar is a faithful implementation of the COCOMO model that is easy to use on small projects. including: • • • • The underlying cost estimation equations Every assumption made in the model (e. COCOMO is an open model.g. secretaries aren't) Because COCOMO is well defined. and you'll use Costar to give you early estimates about the proper schedule and staffing levels.

Source Lines of Code The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code (SLOC). Most of the other COCOMO results. some of the most important factors contributing to a project's duration and cost are the Scale Drivers. but might be counted as several DSI.test drivers and other support software is excluded SOURCE lines are created by the project staff -.I COCOMO assumptions and definitions from Software Engineering Economics and Software Cost Estimation with COCOMO II. The 5 Scale Drivers are: • • Precedentedness Development Flexibility Page 13 of 16 Vijay Kumar Sharma . including the estimates for Requirements and Maintenance. SLOC is defined such that: • • • • • Only Source lines that are DELIVERED as part of the product are included -. You set each Scale Driver to describe your project. For example. which are very similar to SLOC. these Scale Drivers determine the exponent used in the Effort Equation.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. an "if-thenelse" statement would be counted as one SLOC. The Scale Drivers In the COCOMO II model. The major difference between DSI and SLOC is that a single Source Line of Code may be several physical lines. are derived from this quantity. Introduction to the COCOMO Model The most fundamental calculation in the COCOMO model is the use of the Effort Equation to estimate the number of Person-Months required developing a project.code created by applications generators is excluded One SLOC is one logical line of code Declarations are counted as SLOC Comments are not counted as SLOC The original COCOMO 81 model was defined in terms of Delivered Source Instructions.

you would set the Required Software Reliability (RELY) cost driver to Very High. The cost drivers are multiplicative factors that determine the effort required to complete your software project. COCOMO II defines each of the cost drivers. E Is an exponent derived from the five Scale Drivers. if your project will develop software that controls an airplane's flight. of 1.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. KSLOC)): Effort = 2. E. The first two Scale Drivers. and the Effort Multiplier associated with each rating.94 * EAF * (KSLOC)E Where EAF Is the Effort Adjustment Factor derived from the Cost Drivers. meaning that your project will require 26% more effort than a typical software project. and team to set each cost driver. development environment. That rating corresponds to an effort multiplier of 1. COCOMO II estimates that 28.I • • • Architecture / Risk Resolution Team Cohesion Process Maturity Note that the Scale Drivers have replaced the Development Mode of COCOMO 81.0997.26. Precedentedness and Development Flexibility actually describe much the same influences that the original Development Mode did. Cost Drivers COCOMO II has 17 cost drivers � you assess your project.00 and exponent. Check the Costar help for details about the definitions and how to set the cost drivers.9 Person-Months of effort is required to complete it: Page 14 of 16 Vijay Kumar Sharma . Assuming that the project is projected to consist of 8. For example. As an example. a project with all Nominal Cost Drivers and Scale Drivers would have an EAF of 1.000 source lines of code. COCOMO II Effort Equation The COCOMO II model makes its estimates of required effort (measured in Person-Months � PM) based primarily on your estimate of the software project's size (as measured in thousands of SLOC.

3 Person-Months COCOMO II Schedule Equation The COCOMO II schedule equation predicts the number of months required to complete your software project.3)0.34).34 and 1. and substituting the exponent of 0.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set. and all of the other cost drivers are rated to be Nominal (effort multiplier of 1.9 Person-Months Effort Adjustment Factor The Effort Adjustment Factor in the effort equation is simply the product of the effort multipliers corresponding to each of the cost drivers for your project.09).0997 = 42.34 * 1. and Low for Language & Tools Experience (effort multiplier of 1.94 * (1.3179 that is calculated from the scale drivers. if your project is rated Very High for Complexity (effort multiplier of 1.94 * (1.1 months Average staffing = (42.3179 = 12.1 Months) = 3. and an average staffing of between 3 and 4 people: Duration = 3.5 people Page 15 of 16 Vijay Kumar Sharma .09 = 1.46 Effort = 2.09.3 Person-Months) / (12.0) * (8)1.46) * (8)1.67 * (Effort)SE Where Effort is the effort from the COCOMO II effort equation SE Is the schedule equation exponent derived from the five Scale Drivers Continuing the example. yields an estimate of just over a year. For example.00). The duration of a project is based on the effort predicted by the effort equation: Duration = 3.67 * (42. the EAF is the product of 1.0997 = 28. Effort Adjustment Factor = EAF = 1.I Effort = 2.

4 Person-Months) / (9. Continuing the example used earlier.34 * 1.1 Months = 9.2000 model) and means that you intend to finish your project in 75% of the optimum schedule (as determined by a previous COCOMO estimate).End ------------------------- Page 16 of 16 Vijay Kumar Sharma . A SCED rating of Very Low corresponds to an Effort Multiplier of 1. The SCED cost driver is used to account for the observation that a project developed on an accelerated schedule will require more effort than a project developed on its optimum schedule.Master of Business Administration – Semester-III MI0033 – Software Engineering Assignment Set.1 Months Effort Adjustment Factor = EAF = 1. but assuming that SCED has a rating of Very Low. COCOMO produces these estimates: Duration = 75% * 12.09 * 1.94 * (2.09 Effort = 2.43 = 2. Remember that the SCED cost driver means "accelerated from the nominal schedule".4 Person-Months Average staffing = (60.09) * (8)1.7 people Notice that the calculation of duration isn't based directly on the effort (number of Person-Months) � instead it's based on the schedule that would have been required for the project assuming it had been developed on the nominal schedule.43 (in the COCOMO II.0997 = 60.1 Months) = 6. ------------------.I The SCED Cost Driver The COCOMO cost driver for Required Development Schedule (SCED) is unique. and requires a special explanation.