You are on page 1of 22

MBA - Semester-III

MI0033 – Software Engineering

Roll No.- 521134301

Master of Business Administration-MBA Semester – III

Assignment Set- 1 *********************************************************** Q1. Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss them. Answer: One of the challenges of software quality is that "everyone feels they understand it. In addition to more software specific definitions given below, there are several applicable definitions of quality which are used in business. Software quality may be defined as conformance to explicitly stated functional and performance requirements, explicitly documented development standards and implicit characteristics that are expected of all professionally developed software. The three key points in this definition:
1. Software requirements are the foundations from which quality is measured.

Lack of conformance to requirement is lack of quality.
2. Specified standards define a set of development criteria that guide the

management in software engineering. If criteria are not followed lack of quality will usually result.
3. A set of implicit requirements often goes unmentioned, for example ease of

use, maintainability etc. If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspected. A definition in Steve McConnell's Code Complete divides software into two pieces: internal and external quality characteristics. External quality characteristics are those parts of a product that face its users, where internal quality characteristics are those that do not.[4] Another definition by Dr. Tom De Marco says "a product's quality is a function of how much it changes the world for the better. This can be interpreted as meaning that user satisfaction is more important than anything in determining software quality.

MI0033: Software Engineering (Set-1)

Spring Drive - 2012

MBA - Semester-III
Another definition, coined by Gerald Weinberg in

Roll No.- 521134301
Quality Software

Management: Systems Thinking, is "Quality is value to some person." This definition stresses that quality is inherently subjective - different people will experience the quality of the same software very differently. One strength of this definition is the questions it invites software teams to consider, such as "Who are the people we want to value our software?" and "What will be valuable to them?" Software product quality

• • • • • • • • • •

Product quality conformance to requirements or program specification; related to Reliability Scalability Correctness Completeness Absence of bugs Fault-tolerance Extensibility Maintainability Documentation The Consortium for IT Software Quality (CISQ) was launched in 2009 to

standardize the measurement of software product quality. The Consortium's goal is to bring together industry executives from Global 2000 IT organizations, system integrators, outsourcers, and package vendors to jointly address the challenge of standardizing the measurement of IT software quality and to promote a marketbased ecosystem to support its deployment. It is essential to supplement traditional testing – functional, non-functional, and run-time – with measures of application structural quality. Structural quality is the quality of the application’s architecture and the degree to which its implementation accords with software engineering best practices. Industry data demonstrate that poor application structural quality results in cost and schedule overruns and creates waste in the form of rework (up to 45% of development time in some organizations). Moreover, poor structural quality is strongly correlated with high-impact business disruptions due to corrupted data, application outages, security breaches, and performance problems. As in any other field of engineering,

MI0033: Software Engineering (Set-1)

Spring Drive - 2012

MBA . Source code quality A computer has no concept of "well-written" source code. which often stress readability and usually language-specific conventions are aimed at reducing the cost of source code maintenance. by MI0033: Software Engineering (Set-1) Spring Drive . It is defined as "the probability of failure-free operation of a computer program in a specified environment for a specified time".2012 . CPU Number of compilation or lint warnings Robust input validation and error handling. established by software fault injection Methods to improve the quality: • • • Refactoring Code Inspection or software review Documenting the code Software reliability Software reliability is an important facet of software quality. whereas much of software quality is subjective criteria.[7] This distinction is especially important in the discipline of Software Quality Assurance. Goal of reliability The need for a means to objectively determine software reliability comes from the desire to apply the techniques of contemporary engineering fields to the development of software. One of reliability's distinguishing characteristics is that it is objective. However. measurable.Semester-III Roll No. Many source code programming style guides. and can be estimated. testing.. fixing. from a human point of view source code can be written in a way that has an effect on the effort needed to comprehend its behavior. That desire is a result of the common observation. Some of the issues that affect code quality include: • • • • • • Readability Ease of maintenance.521134301 an application with good structural software quality costs less to maintain and is easier to understand and change in response to pressing business needs. debugging. modification and portability Low complexity Low resource consumption: memory. These measured criteria are typically called software metrics.

with consequences for the data which is processed.Semester-III Roll No. general-purpose knowledge. the argument goes. software is fundamentally incapable of most of the mental capabilities of humans which separate them from mere mechanisms: qualities such as adaptability. or even better. As software becomes more and more crucial to the operation of the systems on which we depend. and common sense. exactly how the software is intended to operate. reliable. it should present a means for at least considering objectively whether the software is. Secondly. especially at the high level of reliability that is often expected from software in comparison to humans. which is that software in some sense takes on a role which would otherwise be filled by a human being. In other words. the software should behave in the way it is intended. it is also more and more frequently observed that software has penetrated deeply into almost every aspect of modern life through the technology we use. even singular purpose. The more critical the application of the software to economic and production processes. If the possibility can be allowed that said purpose can be well or even completely defined. This is a problem on two levels. most software programs could safely be considered to have a particular. It is only expected that this infiltration will continue. which is the difficulty of determining. the machinery on which the software runs. it only follows that the software should offer a concomitant level of dependability. that computer software does not work the way it ought to. Firstly. Challenge of reliability The circular logic of the preceding sentence is not accidental—it is meant to illustrate a fundamental problem in the issue of measuring software reliability.. in advance. The problem seems to stem from a common conceptual error in the consideration of software. or to lifesustaining systems. up to and including outright failure.521134301 both lay-persons and specialists. and by extension the people and materials which those machines might negatively affect.MBA . a sense of conceptual and functional context. In other words. the more important is the need to assess the software's reliability. in fact. software is seen to exhibit undesirable behavior. most modern software performs work which a human could never perform. Regardless of the criticality of any single software application. Nevertheless. along with an accompanying dependency on the software by the systems which maintain our society.2012 . by comparing the MI0033: Software Engineering (Set-1) Spring Drive . in the way it should.

Reliability in program development Requirements A program cannot be expected to work as desired if the developers of the program do not. Communicating this knowledge is made more difficult by the fact that.MBA . both for actual programs and theoretical descriptions of programs.521134301 expected outcome to the actual outcome of running the software in a given environment. to achieve it. However. in sufficient detail. Whether a program's desired behaviour can be successfully specified in advance is a moot point if the behaviour cannot be specified at all. if not actually impossible. MI0033: Software Engineering (Set-1) Spring Drive . In situ with the formalization effort is an attempt to help inform non-specialists. and runtime evaluation. various attempts are in the works to attempt to rein in the vastness of the space of software's environmental and input variables. These stages principally include: requirements. as hinted above.Semester-III Roll No. in fact. who commission software projects without sufficient knowledge of what computer software is in fact capable. or if they cannot at least determine its desired behaviour in parallel with development. What level of detail is considered sufficient is hotly debated. in the case of real software. testing. but may be impractical. with given data. know the program's desired behaviour in advance.. The idea of perfect detail is attractive. design. or more accurately. without which it is probably impossible to determine the program's reliability with any certainty. and this is the focus of attempts to formalize the process of creating requirements for new software projects. Such attempts to improve software reliability can be applied at different stages of a program's development. programming. The study of theoretical software reliability is predominantly concerned with the concept of correctness.2012 . failed attempts. a mathematical field of computer science which is an outgrowth of language and automata theory. it is still not known whether it is possible to exhaustively determine either the expected outcome or the actual outcome of the entire set of possible environment and input data to a given program. particularly non-programmers. Unfortunately. This is because the desired behaviour tends to change as the possible range of the behaviour is determined through actual attempts. even programmers cannot always know in advance what is actually possible for software in advance of trying.

It applies additional constraints to the development process by narrowing the scope of the smaller software components. thereby removing language-specific biases and limitations which would otherwise creep into the design. Programming The history of computer programming language development can often be best understood in the light of attempts to master the complexity of computer programs. and thus the use of better MI0033: Software Engineering (Set-1) Spring Drive . (Another way of looking at the evolution of programming languages is simply as a way of getting the computer to do more and more of the work. As such. Software design usually involves the use of more abstract and general means of specifying the parts of the software and what they do. which can be shared by different teams of developers working on disparate parts. perhaps unwittingly on the part of programmer-designers. at least at a high level. to specify how the program should do it. or overall program concept and structure. Finally. and perhaps most controversially. It provides a program template. from problems of actual coding. The usefulness of design is also questioned by some. but those who look to formalize the process of ensuring reliability often offer good software design processes as the most significant means to accomplish it.. which otherwise becomes more difficult to understand in proportion (perhaps exponentially) to the size of the programs. The purposes of high-level design are as follows.2012 . but this may be a different way of saying the same thing).Semester-III Design Roll No. design is meant. such that they can know in advance how each of their contributions will interface with those of the other teams. it can be seen as a way to break a large program down into many smaller programs. which solve problems of actual data processing. it specifies the program independently of the implementation language or languages. It separates what are considered to be problems of architecture. such that those smaller pieces together do the work of the whole program.521134301 While requirements are meant to specify what a program should do.MBA . Lack of understanding of a program's overall structure and functionality is a sure way to fail to detect errors in the program. and thereby—it is hoped —removing variables which could increase the likelihood of programming errors. including the specification of interfaces.

521134301 languages should.. culminating in the abstract data type. change control and reporting are collectively known as Software configuration management. The totality of the compiling and assembly process is generically called "building" the software. such as the application server. For this reason.2012 . In addition.. class. Software builds are typically done in work area unrelated to the runtime area. which.Semester-III understanding. component and more have allowed the arrangement of a program's parts to be specified using abstractions such as layers. And. Software Build and Deployment Many programming languages such as C and Java require the program "source code" to be translated in to a form that can be executed by a computer. The deployment procedure may also involve technical parameters. and even the state of the data before and after it is accessed. For example. a Java application server may have options for parent-first or parent-last class loading. so that from any point of view the program's code can be imagined to be orderly and comprehensible. The software build is critical to software quality because if any of the generated files are incorrect the software build is likely to fail. A number of software tools have arisen to help meet MI0033: Software Engineering (Set-1) Spring Drive . Roll No. library. Using the incorrect parameter can cause the application to fail to execute on the application server. bind. then testing can lead to false results. file. if the incorrect version of a program is inadvertently used. which provide structure at different granularities. These data types can be specified to a very fine degree. conversely. This translation is done by a program called a compiler. link or package files together in order to create a usable runtime configuration of the software application. reduce the number of errors by enabling a better Improvements in languages tend to provide incrementally what software design has attempted to do in one fell swoop: consider the software at ever greater levels of abstraction. template. improvements in languages have enabled more exact control over the shape and use of data elements.MBA . hierarchies and modules. The technical activities supporting software quality including build. if set incorrectly. Additional operations may be involved to associate. sub-routine. a deployment step is needed to physically transfer the software build products to the runtime area. can also prevent software testing from beginning. Such inventions as statement. deployment. including how and when they are accessed.

they are characteristics that one seeks to maximize in one’s software to optimize its quality.. Testing includes. Software quality factors A software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract. ask instead the degree to which it does (or does not). but is not limited to: • • • • • • Unit Testing Functional Testing Regression Testing Performance Testing Failover Testing Usability Testing A number of agile methodologies use testing early in the development cycle to ensure quality in their products. For example. that is. Runtime Runtime reliability determinations are similar to tests.521134301 the challenges of configuration management including file control tools and build Software testing. but nevertheless is a desirable requirement which enhances the quality of the software program. Testing Main article: Software Testing Roll No. So rather than asking whether a software product “has” factor x. they are not “either you have it or you don’t” traits. can increase overall software quality of conformance by testing that the product conforms to its requirements. Note that none of these factors are binary. Some software quality factors are listed here: Understandability MI0033: Software Engineering (Set-1) Spring Drive . where tests are written before the code they will test.MBA . when done correctly. is used in Extreme Programming to ensure quality. but go beyond simple confirmation of behavior to the evaluation of qualities such as performance and interoperability with other code or particular hardware configurations. the test-driven development practice. Rather.2012 .Semester-III control tools.

should not be complex. This is obviously subjective in that the user context must be taken into account: for instance.. Completeness Presence of all constituent parts. with each part fully developed. Conciseness Minimization of excessive or redundant information or processing. and should have spare capacity for memory. all of the design and user documentation must be clearly written so that it is easily understandable. a complex design leads to poor testability. and terminology within itself. and it is generally considered good practice to keep lines of code to a minimum. Maintainability Propensity to facilitate updates to satisfy new requirements. Such a characteristic must be built-in during the design phase if the product is to be easily testable. It also applies to documents. This is important where memory capacity is limited. the software package must provide reference to that library and all required parameters must be passed. It can be improved by replacing repeated functionality by one subroutine or function which achieves that functionality. Thus the software product that is maintainable should be well-documented.MBA . This means that if the code calls a subroutine from an external library. if the software product is to be used by software engineers it is not required to be understandable to the layman. symbology. Portability can mean both between different hardware—such as running on a PC as well as a Smartphone—and between different operating systems—such as running on both Mac OS X and GNU/Linux. Testability Disposition to support acceptance criteria and evaluation of performance.521134301 Clarity of purpose: This goes further than just a statement of purpose. Portability Ability to be run well and easily on multiple computer configurations. appearance. Usability MI0033: Software Engineering (Set-1) Spring Drive .2012 .Semester-III Roll No. Consistency Uniformity in notation. All required input data must also be available. storage and processor utilization and other resources.

The component of the software that has most impact on this is the user interface (UI).521134301 Convenience and practicality of use.MBA . Efficiency Fulfillment of purpose without waste of resources. This implies a time factor in that a reliable product is expected to perform correctly over a period of time.. Software that contains few faults is considered by some to have higher quality than software that contains many faults. Reliability Ability to be expected to perform its intended functions satisfactorily. Several leaders in the field of software testing have written about the difficulty of measuring what we truly want to measure well. such as memory. space and processor utilization. network bandwidth.Semester-III Roll No.2012 . a GUI). that are decried as harmful by others. It also encompasses environmental considerations in that the product is required to perform correctly in whatever conditions it finds itself (sometimes termed robustness). blogging software vs. security also implies resilience in the face of malicious. and so prefer qualitative measures. Others believe that contexts where quantitative measures are useful are quite rare. which for best usability is usually graphical (i. Measurement of software quality factors There are varied perspectives within the field on measurement.e. Besides the presence of appropriate security mechanisms such as authentication. navigational software)? Does this take into account the size and complexity of the software? MI0033: Software Engineering (Set-1) Spring Drive . time. Some believe that quantitative measures of software quality are essential. Security Ability to protect data against unauthorized access and to withstand malicious or inadvertent interference with its operations. access control and encryption. Questions that can help determine the usefulness of this metric in a particular context include: a) What constitutes “many faults?” Does this differ depending upon the purpose of the software (e..g. intelligent and adaptive attackers. This is affected by such things as the human-computer interface. etc. There are a great many measures that are valued by some professionals—or in some contexts.[8][9] One example of a popular metric is the number of faults encountered in the software.

does that mean that the product is now higher quality than it was before? Or that this is a smaller/less ambitious change than before? Or that fewer tester-hours have gone into the project than before? Or that this project was tested by less skilled testers than before? Or that the team has discovered that fewer faults reported is in their interest? This last question points to an especially difficult one to manage..521134301 b) Does this account for the importance of the bugs (and the importance to the stakeholders of the people those bugs bug)? Does one try to weight this metric by the severity of the fault. rate of failure occurrence.2012 . That may mean that email begins to circumvent the bug tracking system. Software quality factors cannot be measured because of their vague definitions. which can be used to quantify them as non-functional requirements. All software quality metrics are in some sense measures of human behavior. Q. or the incidence of users it affects? If so. For example. The difficulty is measuring what we mean to measure.3. which can indeed be measured. reliability is a software quality factor. or metrics. from which a measurement of the characteristic can be obtained. Some type of scoring formula could be developed based on the answers to these questions. how do I know what that means? For example.Semester-III Roll No. there is a strong tendency for the team to start reporting fewer defects.[8] If a team discovers that they will benefit from a drop in the number of reported bugs. or that testers learn not to report minor annoyances. However. how does one know that 100 faults discovered is better than 1000? c) If the count of faults being discovered is shrinking. Some such attributes are mean time to failure. and availability of the system. A scheme that could be used for evaluating software quality factors is given below. there are a set of questions which are relevant to that characteristic. how? And if not.MBA . there are related attributes to reliability. but cannot be evaluated in its own right. or that four or five bugs get lumped into one bug report. Discuss the CMM 5 Levels for Software Process. without creating incentives for software programmers and testers to consciously or unconsciously “game” the measurements. an attribute of portability is the number of target-dependent statements in a program. Similarly. It is necessary to find measurements. MI0033: Software Engineering (Set-1) Spring Drive . since humans create software. For every characteristic.

The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software engineering capabilities that should be present as organizations reach different levels of process maturity. This level includes all characteristics defined for level 4. schedule. and success depends on individual effort. there has been a significant emphasis on “process maturity”. The results of the questionnaire are MI0033: Software Engineering (Set-1) Spring Drive . Level 2: Repeatable – Basic project management processes are established to track cost. and integrated into an organized-wide software process. The Software Process: Roll No. Both the software process and products are quantitatively understood and controlled using detailed measures. standardized. All projects use a documented and approved version of the organizations process for developing and supporting software.MBA . Level 5: Optimizing – Continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies. The grading scheme determines compliance with a capability maturity model (CMM) [PAU93] that defines key activities required at different levels of process maturity.521134301 In recent years.Semester-III Answer. To determine an organization’s current state of process maturity. and establishes five process maturity levels that are defined in the following manner: Level 1: Initial – The Software process is characterized as ad hoc and occasionally even chaotic. Level 4: Managed – Detailed measures of the software process and product quality are collected. Few processes are defined. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. The five levels defined by the SEI were derived as a consequence of evaluating responses to the SEI assessment questionnaire that is based on the CMM. the SEI uses an assessment that results in a five point grading scheme. and functionality.. Level 3: Defined – The software process for both management and engineering activities is documented. The SEI approach provides a measure of the global effectiveness of a company’s software engineering practices. This level includes all characteristic defined for level 2. This level includes all characteristics defined for level 3.2012 .

Commitments – requirements (imposed on the organization) that must be met to achieve the goals. the linear sequential model encompasses the following activities : System / information engineering and modeling – because software is always part of a larger system (or business). Methods for monitoring implementation – the manner in which the activities are monitored as they are put into place. The Linear Sequential Model: Sometimes called the classic life cycle or the waterfall model.2012 . Modeled after a conventional engineering cycle. The KPAs describe those software engineering functions (e.. The linear sequential model for software engineering.Semester-III process maturity.4. design. Answer.MBA . or provide proof of intent to comply with the goals. the linear sequential model suggests a systematic. Q. requirements management) that must be present to satisfy good practice at a particular level. sequential approach to software development that begins at the system level and progresses through analysis. Discuss the Water Fall Model for Software Development. - Methods for verifying implementation – the manner in which proper practice for the KPA can be verified. This system view is essential when software must interact with other MI0033: Software Engineering (Set-1) Spring Drive .g. Roll No. - Activities – the specific tasks required to achieve the KPA function.521134301 distilled to a single numerical grade that provides an indication of an organization’s The SEI has associated key process areas (KPAs) with each of the maturity levels. coding testing. software project planning. Each KPA is described by identifying the following characteristics: - Goals – the overall objectives that the KPA must achieve. - Abilities – those things must be in place (organizationally and technically) to enable the organization to meet the commitments. work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. and support..

because the software must be adapted to accommodate changes in its external environment (e. The testing process focuses on the logical internals of the software. interface representations. a change required because of a new operating system or peripheral device). The code generation step performs this task.The requirements gathering process is intensified and focused specifically on software. Design – Software design is actually a multistep process that focuses on four distinct attributes of a program : data structure. the design is documented and becomes part of the software configuration.MBA . and databases. Information engineering encompasses requirements gathering at the strategic business level and at the business area level.g. Like requirements.. and interface. code generation can be accomplished mechanistically. Software support / maintenance reapplies each of the preceding phases to an existing program rather than a new one. Code generation – The design must be translated into a machine-readable form. software architecture. or because the customer requires functional or performance enhancements.521134301 elements such as hardware.2012 . conducting tests to uncover errors and ensure that defined input will produce actual results that agree with the required results. program testing begins. Thedesign process translates requirements into a representation of the software that can be assessed for quality before coding begins. as well as required function. behavior. Test – Once the code has been generated. that is. System engineering and analysis encompass requirements gathering at the system level. Requirements for both the system and the software are documented and reviewed with the customer. Change will occur because errors have been encountered. Support – Software will undoubtedly undergo change after it is delivered to the customer (a possible exception is embedded software). the software engineer (“analyst”) must understand the information domain for the software. ensuring that all statements have been tested. with a small amount of top level design and analysis. To understand the nature of the program(s) to be built. and on the functional externals. and procedural (algorithmic) detail. If design is performed in a detailed manner. Software requirements analysis . performance. people. The linear sequential model is the oldest and the most widely used paradigm MI0033: Software Engineering (Set-1) Spring Drive .Semester-III Roll No.

if undetected until the working program is reviewed. criticism of the paradigm has caused even active supporters to questions its efficacy [HAN95].. The customer must have patience. Although the linear model can accommodate iteration. coding. The classic life cycle remains a widely used procedural model for software engineering. the classic life cycle paradigm has a definite and important place in software engineering work. The linear sequential model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. Each of these problems is real.521134301 for software engineering. It provides a template into which methods for analysis. changes can cause confusion as the project team proceeds. and support can be placed. 2. it is significantly better than a haphazard approach to software development. However. found that the linear nature of the classic life cycle leads to “blocking states” in which some project team members must wait for other members of the team to complete dependent tasks. However. testing. 3.2012 . can be disastrous. In an interesting analysis of actual projects Bradac [BRA94]. Among the problems that are sometimes encountered when the linear sequential model is applied are: 1. it does so indirectly. While it does have weaknesses. A working version of the program(s) will not be available until late in the project time-span. It is often difficult for the customer to state all requirements explicitly. MI0033: Software Engineering (Set-1) Spring Drive . As a result.MBA . the time spent waiting can exceed the time spent on productive work ! The blocking state tends to be more prevalent at the beginning and end of a linear sequential process. In fact. Real projects rarely follow the sequential flow that the model proposes. design. A major blunder.Semester-III Roll No.

Everyone has to work on the same thing and at the same time. it can be changed. Analysis.MBA . In every prototype created. Answer: Prototype Model Advantages Creating software using the prototype model also has its benefits. more effort is placed in creating the actual software. One of the key advantages a prototype modeled software has is the time frame of development.Semester-III Roll No. Construction. The work on prototype models could also be spread to others since there are practically no stages of work in this model.521134301 Q. 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. Initiation. Instead of concentrating on documentation. This way. Explain the Advantages of Prototype Model. users could give their honest opinion about the software. often used in software development processes.. Another advantage of having a prototype modeled software is that the software is created using lots of user feedbacks. Design. MI0033: Software Engineering (Set-1) Spring Drive . Production/Implementation and Maintenance. Testing. reducing man hours in creating a software.5. Slowly the program is created with the customer in mind.2012 . If something is unfavorable. The waterfall model is a sequential design process. the actual software could be released in advance. in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception. & Spiral Model in Contrast to Water Fall model.

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

Costar allows you to define a software structure to meet your needs. "the project will enjoy good management") Every definition (e. and you'll use Costar to give you early estimates about the proper schedule and staffing levels. you can use Costar to produce more and more refined estimates. including: • • The underlying cost estimation equations Every assumption made in the model (e. As you refine your knowledge of the problem.521134301 The COCOMO cost estimation model is used by thousands of software project managers. Typically.MBA . Unlike other cost estimation models. and because it doesn't rely upon • • proprietary estimation algorithms.g. and is based on a study of hundreds of software projects..2012 . secretaries aren't) Because COCOMO is well defined.000 lines of code. 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.you can use Costar to define the components MI0033: Software Engineering (Set-1) Spring Drive . project managers are included. and yet powerful enough to plan and control large projects. Your initial estimate might be made on the basis of a system containing 3. Your next estimate will continue the process -. so all of the details are published.g. and to produce more accurate estimates Costar is a faithful implementation of the COCOMO model that is easy to use on small projects. COCOMO is an open model.Semester-III Roll No. the precise definition of the Product Design phase of a project) The costs included in an estimate are explicitly stated (e. and as you design more of the system. 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). you'll start with only a rough description of the software system that you'll be developing.g.

that it's possible to misuse it -. Costar permits you to continue this process until you arrive at One word of warning: It is so easy to use Costar to make software cost estimates.every Costar user should spend the time to learn the underlying COCOMO assumptions and definitions from Software Engineering Economics and Software Cost Estimation with COCOMO II. The major difference between DSI and SLOC is that a single Source Line of Code may be several physical lines. Roll No. are derived from this quantity. You set each Scale Driver to MI0033: Software Engineering (Set-1) Spring Drive .Semester-III the level of detail that suits your needs. which are very similar to SLOC. 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 to develop a project. Source Lines of Code The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code (SLOC). including the estimates for Requirements and Maintenance. For example. The Scale Drivers In the COCOMO II model. SLOC is defined such that: • Only Source lines that are DELIVERED as part of the product are included -test drivers and other support software is excluded SOURCE lines are created by the project staff -.2012 . Most of the other COCOMO results. an "if-then-else" statement would be counted as one SLOC. some of the most important factors contributing to a project's duration and cost are the Scale Drivers..MBA .521134301 of each subsystem. but might be counted as several DSI.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.

KSLOC)): Effort = 2. these Scale Drivers determine the exponent used in the Precedentedness Development Flexibility Architecture / Risk Resolution Team Cohesion Process Maturity Note that the Scale Drivers have replaced the Development Mode of COCOMO 81.26.MBA . That rating corresponds to an effort multiplier of 1. The 5 Scale Drivers are: • • • • • Roll No.Semester-III Effort Equation. Mode did. Precedentedness and Development Flexibility actually describe much the same influences that the original Development COCOMO II has 17 cost drivers � you assess your project. and team to set each cost driver.2012 . COCOMO II Effort Equation The COCOMO II model makes its estimates of required effort (measured in PersonMonths � PM) based primarily on your estimate of the software project's size (as measured in thousands of SLOC..521134301 describe your project. For example.94 * EAF * (KSLOC)E Where EAF Is the Effort Adjustment Factor derived from the Cost Drivers. development environment. COCOMO II defines each of the cost drivers. meaning that your project will require 26% more effort than a typical software project. MI0033: Software Engineering (Set-1) Spring Drive . if your project will develop software that controls an airplane's flight. and the Effort Multiplier associated with each rating. The cost drivers are multiplicative factors that determine the effort required to complete your software project. Cost Drivers The first two Scale Drivers. Check the Costar help for details about the definitions and how to set the cost drivers. you would set the Required Software Reliability (RELY) cost driver to Very High.

000 source lines of code.3179 that is calculated from the scale drivers.34 * 1. a project with all Nominal Cost Drivers and Scale Drivers would have an EAF of 1.0) * (8)1.34).3179 = 12.Semester-III E Is an exponent derived from the five Scale Drivers. if your project is rated Very High for Complexity (effort multiplier of 1.94 * (1. For example. the EAF is the product of 1. and an average staffing of between 3 and 4 people: Duration = 3.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.67 * (42. and all of the other cost drivers are rated to be Nominal (effort multiplier of 1. and substituting the exponent of 0.09 = 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.3 Person-Months) / (12.00 and exponent.09. yields an estimate of just over a year.46) * (8)1. The duration of a project is based on the effort predicted by the effort equation: Duration = 3.0997 = 28.9 Person-Months of effort is required to complete it: Effort = 2.2012 . Roll No. E. COCOMO II estimates that 28. Effort Adjustment Factor = EAF = 1.0997 = 42.0997.3)0.1 Months) = 3. and Low for Language & Tools Experience (effort multiplier of 1.3 Person-Months COCOMO II Schedule Equation The COCOMO II schedule equation predicts the number of months required to complete your software project.46 Effort = 2.09).521134301 As an example.34 and 1.5 people MI0033: Software Engineering (Set-1) Spring Drive .94 * (1.1 months Average staffing = (42.. Assuming that the project is projected to consist of 8. of 1.MBA .00).

2012 .1 Months Effort Adjustment Factor = EAF = 1.1 Months) = 6. and requires a special explanation.09) * (8)1. MI0033: Software Engineering (Set-1) Spring Drive . COCOMO produces these estimates: Duration = 75% * 12.1 Months = 9.MBA .. 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.4 Person-Months Average staffing = (60. A SCED rating of Very Low corresponds to an Effort Multiplier of 1.0997 = 60.43 (in the COCOMO II.Semester-III The SCED Cost Driver Roll No.09 Effort = 2.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.4 Person-Months) / (9.09 * 1.34 * 1. Continuing the example used earlier. but assuming that SCED has a rating of Very Low.94 * (2.2000 model) and means that you intend to finish your project in 75% of the optimum schedule (as determined by a previous COCOMO estimate).43 = 2.521134301 The COCOMO cost driver for Required Development Schedule (SCED) is unique. Remember that the SCED cost driver means "accelerated from the nominal schedule".