Master of Business Administration - MBA Semester III MI0033 – Software Engineering - 4 Credits Assignment - Set- 1 (60 Marks

)
Answer all the questions
Q1. Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss them. Q2. Discuss the Objective & Principles Behind Software Testing. Q3. Discuss the CMM 5 Levels for Software Process. Q4. Discuss the Water Fall model for Software Development. Q5. Explain the Advantages of Prototype Model, & Spiral Model in Contrast to Water Fall model. Q6. Explain the COCOMO Model & Software Estimation Technique.

Q1. Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss them. A. Quality focuses on the software's conformance to explicit and implicit requirements. Reliability focuses on the ability of software to function correctly as a function of time or some other quantity. Safety considers the risks associated with failure of a computer-based system that is controlled by software. In most cases an assessment of quality considers many factors that are qualitative in nature. Assessment of reliability and to some extent safety is more quantitative, relying on statistical models of past events that are coupled with software characteristics in an attempt to predict future operation of a program

There is no doubt that the reliability of a computer program is an important element of its overall quality. If a program repeatedly and frequently fails to perform, it matters little whether other software quality factors are acceptable. Software reliability, unlike many other quality factors, can be measured directed and estimated using historical and developmental data. Software reliability is defined in statistical terms as "the probability of failure-free operation of a computer program in a specified environment for a specified time" [MUS87]. To illustrate, program X is estimated to have a reliability of 0.96 over eight elapsed processing hours. In other words, if program X were to be executed 100 times and require eight hours of elapsed processing time (execution time), it is likely to operate correctly (without failure) 96 times out of 100. Whenever software reliability is discussed, a pivotal question arises: What is meant by the term failure? In the context of any discussion of software quality and reliability, failure is nonconformance to software requirements. Yet, even within this definition, there are gradations. Failures can be only annoying or catastrophic. One failure can be corrected within seconds while another requires weeks or even months to correct. Complicating the issue even further, the correction of one failure may in fact result in the introduction of other errors that ultimately result in other failures.

independent view of the software to allow the business to appreciate and understand the risks of software implementation. As such.[1] Software testing can also provide an objective. Exhaustive testing is not possible. Testing should begin "in small" and progress toward testing "in large". most of the test execution occurs after the requirements have been defined and the coding process has been completed. To be most effective. an independent third party should conduct testing. but are not limited to. Software testing can be stated as the process of validating and verifying that a software program/application/product: Meets the requirements that guided its design and development. The following can be described as testing principals: All tests should be traceable to customer requirements. The Pareto principal applies to testing. depending on the testing method employed. Software testing. Newer development models. such as Agile. Test techniques include. can be implemented at any time in the development process. Different software development models will focus the test effort at different points in the development process. Works as expected.Q2. and Can be implemented with the same characteristics. often employ test driven development and place an increased portion of the testing in the hands of the developer. the methodology of the test is governed by the software development methodology adopted. most of the test effort occurs after the requirements have been defined and the coding process has been completed. before it reaches a formal team of testers. However. Tests should be planned long before testing begins. Discuss the Objective & Principles Behind Software Testing. In a more traditional model. . the process of executing a program or application with the intent of finding software bugs (errors or other defects). Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.

the Software CMM (CMM. The waterfall model is a sequential design process. if not . Initiation. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. government. The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly. According to the Software Engineering Institute (SEI. provide guidance for quality processes. or an entire organization. and delivery — CMMI for Services (CMMI-SVC). Currently supported is CMMI Version 1.[1] CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest. Capability Maturity Model Integration (CMMI) is a process improvement approach whose goal is to help organizations improve their performance. Testing. The word "software" does not appear in definitions of CMMI. management. Patent and Trademark Office by Carnegie Mellon University. Construction. and the acquisition of products and services. Analysis. CMMI currently addresses three areas of interest: Product and service development — CMMI for Development (CMMI-DEV). A.Q3.3. This generalization of improvement concepts makes CMMI extremely abstract. A. Q4. and Product and service acquisition — CMMI for Acquisition (CMMI-ACQ). a division. CMMI in software engineering and organizational development is a process improvement approach that provides organizations with the essential elements for effective process improvement. in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception. set process improvement goals and priorities. Design.S. CMMI was developed by a group of experts from industry. A CMMI model may also be used as a framework for appraising the process maturity of the organization. Discuss the CMM 5 Levels for Software Process. see below). such as the development of hardware products. Service establishment. and the Software Engineering Institute (SEI) at Carnegie Mellon University. the delivery of all kinds of services. Discuss the Water Fall model for Software Development. CMMI helps "integrate traditionally separate organizational functions. CMMI is registered in the U. and provide a point of reference for appraising current processes. Production/Implementation and Maintenance. 2008). It is not as specific to software engineering as its predecessor. often used in software development processes. CMMI can be used to guide process improvement across a project.

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. Q5.[5]In Royce's original waterfall model. there are various modified waterfall models (including Royce's final model) that may include slight or major variations on this process.[4] This. Explain the Advantages of Prototype Model. Advantages of prototyping 1 May provide the proof of concept necessary to attract funding 2 Early visibility of the prototype gives users an idea of what the final system looks like 3 Encourages active participation among users and producer 4 Enables a higher output for user 5 Cost effective (Development costs reduced). the following phases are followed in order: Requirements specification Design Construction (AKA implementation or coding) Integration Testing and debugging (AKA Validation) Installation Maintenance Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice. this hardwareoriented model was simply adapted for software development. A. . & Spiral Model in Contrast to Water Fall model.impossible.[3] though Royce did not use the term "waterfall" in this article. However.[citation needed] The first known presentation describing use of similar phases in software engineering was held by Herbert D. non-working model. Benington at Symposium on advanced programming methods for digital computers on 29 June 1956. The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce presented this model as an example of a flawed. in fact.[1] This presentation was about the development of software for SAGE. but depended on a prototype. Royce. Since no formal software development methodologies existed at the time.

in essentially the same order. This assures that there is no conflict with previous requirements and design. in an effort to combine advantages of top-down and bottom-up concepts. This model of development combines the features of the prototyping and the waterfall model.6 Increases system development speed 7 Assists to identify any problems with the efficacy of earlier design. both technical and managerial. The spiral lifecycle model allows for elements of the product to be added in when they become available or known. controlled aspects of the waterfall model. or incremental refinement through each time around the spiral. and the content reflects the information necessary at that point in the process. It allows for incremental releases of the product. it is a systems development method (SDM) used in information technology (IT). The spiral model combines the idea of iterative development (prototyping) with the systematic. and implementation (the code). nor all at the end (hopefully). Documents are produced when they are required. Identifying major risks. Another positive aspect is that the spiral model forces early . separated by planning. This model uses many of the same phases as the waterfall model. the documents are works in progress. All documents will not be created at the beginning of the process. This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. and determining how to lessen the risk helps keep the software development process under control. system and software design. The idea is to have a continuous stream of products produced and available for user review. expensive and complicated projects. Like the product they define.[3] The spiral model is based on continuous refinement of key products for requirements definition and analysis. the products are extensions of an earlier product. and the building of prototypes and simulations. At each iteration around the cycle. The spiral model is intended for large. This should not be confused with the Helical model of modern systems architecture that uses a dynamic programming approach in order to optimize the system's architecture before design decisions are made by coders that would cause problems. requirements analysis and coding activities 8 Helps to refine the potential risks associated with the delivery of the system being developed 9 Various aspects can be tested and quicker feedback can be got from the user 10 Helps to deliver the product in quality easily 11 User interaction available during development cycle of prototype The spiral model is a software development process combining elements of both design and prototyping-in-stages. risk assessment. Also known as the spiral lifecycle model (or spiral development). The spiral model also explicitly includes risk management within software development.

This article refers to COCOMO 81.000 to 100. integration. It drew on a study of 63 projects at TRW Aerospace where Boehm was Director of Software Research and Technology. Starting at the center. and schedule for software projects. such as user application programs or instrument interface applications. The spiral method also helps manage risk and uncertainty by allowing multiple decision points and by explicitly admitting that all of anything cannot be known before the subsequent activity starts Q6. Boehm. It provides more support for modern software development processes and an updated project database. References to this model typically call it COCOMO 81. just as planning and risk analysis occur in multiple places. For projects with heavy user interfacing. Explain the COCOMO Model & Software Estimation Technique. implementation. some functionality can be delivered to the user faster than the waterfall method. Using this method of development. code reusability and the use of off-the-shelf software components. Final design.[2] COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern software development projects. Plan the next iteration.user involvement in the system development effort. A. alternatives. COCOMO was first published in Boehm's 1981 book Software Engineering Economics[1] as a model for estimating effort. . The model uses a basic regression formula with parameters that are derived from historical project data and current project characteristics. and test occur in iteration 4.000 lines of code. The spiral can be repeated multiple times for multiple builds. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development. Note that the requirements activity takes place in multiple sections and in multiple iterations. In 1995 COCOMO II was developed and finally published in 2000 in the book Software Cost Estimation with COCOMO II. and constraints on the new iteration. Develop and verify the product for this iteration. Evaluate alternatives and identify and resolve risk issues. cost. The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry W. such involvement is helpful. These projects were based on the waterfall model of software development which was the prevalent software development process in 1981. and programming languages ranging from assembly to PL/I. each turn around the spiral goes through several task regions Determine the objectives. The study examined projects ranging in size from 2.

cost. In particular. effort and schedule for software projects. but its accuracy is limited due to its lack of factors to account for difference in project attributes (Cost Drivers). Schedule.COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. has allowed more accurate estimation and more rapid development times. Proxy-based estimating (PROBE) (from the Personal Software Process) Program Evaluation and Review Technique (PERT) SEER-SEM Parametric Estimation of Effort. clearly defined and well understood software development process has. Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally accounts for the influence of individual project phases. shown itself to be the most effective method of gaining useful historical data that can be used for statistical estimation. coupled with the loosening of constraints between parts of a project. in recent years. Function Point Analysis Parametric Estimating PRICE Systems Founders of Commercial Parametric models that estimates the scope. The first level. Risk. Basic COCOMO is good for quick. Methods Popular methods for estimation in software engineering include: Analysis Effort method COCOMO (This model is obsolete and should only be used for demonstration purposes. The use of a repeatable. rough order of magnitude estimates of software costs. The ability to accurately estimate the time and/or cost taken for a project to come in to its successful conclusion is a serious problem for software engineers. early. the act of sampling more frequently. Cost.) COCOMO™ II COSYSMO Evidence-based Scheduling Refinement of typical agile estimating techniques using minimal measurement and total time accounting. Mimimum time and staffing concepts based on Brooks's law SLIM The Planning Game (from Extreme Programming) Weighted Micro Function Points (WMFP) .

Explain i. Tom DeMarco expresses “In the absence of meaningful standards." So software myths prevail but though they do are not clearly visible they have the potential to harm all the parties involved in the software development process mainly the developer team. Software doesn’t Wear Out.Practitioner/Developer Myth before defining the above three myths one by one lets scrutinize why these myths occur on the first place. Q4. There does not exist one best method of software development that ultimately equates to the ubiquitous software myths. The picture below tries to clarify the complexity of the problem of software development requirement analysis mainly between the developer team and the clients . Q2. a new industry like software comes to depend instead on folklore.can be traced to earliest days of computing. ii. Primarily. Q5. Myth is defined as "widely held but false notation" by the oxford dictionary. Q3. Write a note on myths of Software." The given statement points out that the software industry caught pace just some decades back so it has not matured to aformidable level and there are no strict standards in software development. so assign other fields software arena also has some myths to demystify. Write a note on myths of Software. Pressman insists “Software myths. Software is engineered & not manufactured. there are three types of software myths. Q6. all the three are stated below: 1. A.Explain the Different types of Software Measurement Techniques.2 (60 Marks) Answer the Following ( 6 * 10 = 60 Marks ) Q1.MBA Semester III MI0033 – Software Engineering .Set.Write a Note on Spiral Model.Customer Myth3. Explain Version Control & Change Control.4 Credits Assignment .beliefs about software and the process used to build it.Management Myth2.Master of Business Administration . Q1. Discuss the SCM Process. Myths have a number of attributes that have made them insidious.

If you have never used version control before. we will concentrate on choosing and setting up a version control system in a way that will foster cooperative development down the road. These days. . Version Control A version control system (or revision control system) is a combination of technologies and practices for tracking and controlling changes to a project's files. Discuss the SCM Process. The version control system provides a central coordinating force among all of these areas. Explain Version Control & Change Control. SCM concerns itself with answering the question "Somebody did something. configuration items and baselines. and then replaying these facts to whoever asks. code stability and experimental development efforts. incremental changes. and get them to join your project. Answering the question thus becomes a matter of comparing different results and of analyzing their differences. Configuration management practices include revision control and the establishment of baselines. It's so all-encompassing that it must be addressed topically throughout the book. everyone will expect at least your project's source code to be under version control.Identifying configurations. release management. the first thing you should do is go find someone who has. and probably will not take the project seriously if it doesn't use version control with at least minimal competence. software configuration management (SCM) is the task of tracking and controlling changes in the software. It is a communications mechanism where a change is the basic unit of information. In software engineering. documentation. According to another simple definition: Software Configuration Management is how you control the evolution of a software project. Q3. Here. The core of version control is change management: identifying each discrete change made to the project's files. The reason version control is so universal is that it helps with virtually every aspect of running a project: inter-developer communications. Traditional configuration management typically focused on controlled creation of relatively simple products.Q2. Now. A. implementers of SCM face the challenge of dealing with relatively minor increments under their own control. and attribution and authorization of changes by particular developers. annotating each change with metadata like the change's date and author. but with controlled. in particular to source code. in the context of the complex system being developed. bug management. how can one reproduce it?" Often the problem involves not reproducing "it" identically. A. in whatever way they ask. The goals of SCM are generally:[citation needed] Configuration identification . This section does not discuss all aspects of using a version control system. and web pages.

the errors in the software get corrected and the curve flattens. But.Recording and reporting all the necessary information on the status of the development process. As soon as that error gets corrected the curve encounters another spike that means another error in the software. In case of hardware we have a "bathtub" like curve. including requirements. Configuration status accounting . Software doesn't wear out: The hardware can wear out whereas software can't. But.Making sure every defect has traceability back to the source. in the starting time there is relatively high failure rate. Configuration auditing . i. However. which is a curve that lies in between failure-rate and time. Software doesn’t Wear Out.Implementing a controlled change process. Process management . But. The hardware begins to wear out.Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents. After some time the steady state of the software don't remains steady and the failure rate begins to rise. Explain i. ii. Defect tracking . A. the software is not responsible to the failure rate of hardware. Software doesn’t Wear Out.Configuration control . . In this type of curve the failure rate in the initial state is very high. Q4. But. Software is engineered & not manufactured. defects get corrected and failure-rate drops to a steady-state for some time period. This can be explained by the actual curve. If hardware gets failed then it can be replaced but there is no replacement in case of software. architectural specifications and user manuals. the failure-rate again rises due to the effects of rain. temperature extreme and many other environment effects. The failure rate of software can be understood by the "idealized curve". Teamwork . the implication is clear that the software can "deteriorate" it does not "wear out". Build management . dust.Managing the software and hardware that host the system.Facilitate team interactions related to the process.Ensuring adherence to the organization's development process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline. In this curve. Environment management .Managing the process and tools used for builds. after some period of time.