MB 0033- Software Engineering

Ensure that you answer all questions according to the marks allocated (not more than 400 words for a 10-mark question and not more than 200 words for a five-mark question). The total page limit shall not exceed 8 pages of A-4 size. Q 1 . Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss them. Answer -Quality focuses on the software's conformance to explicit and implicit
requireme nts. Reliability focuses on the ability of software to function correctly as a fu nction 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 ele ment of its over all quality. If a program repeatedly and frequently fails to per form, it matters little whether other software quality factors are acceptable. Sof tware reliability, unlike many other quality factors, can be measured directed an d estimated using historical and developmental data. Software reliability is defined in statistical terms as "the probability of failure-free operation of a comp uter 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 pro cessing 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 reliabilty is discussed, a pivotal questionarises: What is meant by the term failure? I n the context of any discussion of software quality and reliability, failure is n on conformance 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 failure s.

Q2. Discuss the Objective & Principles Behind Software Testing. Answer-Objective and Principle behind software Testing can be defined as follows : (i) Testing Objectives In an excellent book on software testing, Glen Myers states a number of rules th at can serve well as testing objectives: 1. Testing is a process of executing a program with the intent of finding an err or. 2. A good test case is one that has a high probability of finding an as return d iscovered error. 3. A successful test is one that uncovers an as-yet-undiscovered error. These ob jectives imply a dramatic change in viewpoint. They move counter to the commonly held view that a successful test is one in which no errors are found. Our objec tive is to design tests that systematically uncover different classes of errors, and to do so with a minimum amount of time and effort. If testing is conducted successfully (according to the objectives stated previously), it will uncover er rors in the software. As a secondary benefit, testing demonstrates that software functions appear to be working according to specification, that behavioral and performance requirements appear to have been met.

In addition, data collected as testing is conducted provide a good indication of software reliability, and som e indication of software quality as a whole. But testing cannot show the absence of errors and defects, it can show only that software errors and defects are pr esent. It is important to keep this (rather gloomy) statement in mind as testing is being conducted. (ii) Testing Principles Before applying methods to design effective test cases, a software engineer must understand the basic principles that guide software testing. Davis [DAV95] sugg ests a set of testing principles that have been adapted for use in this book: All tests should be traceable to customer requirements. As we have seen, the obj ective of software testing is to uncover errors. It follows that the most severe defects (from the customers point of view) are those that cause the program to f ail to meet its requirements. Tests should be planned long before testing begins. Test planning can begin as s oon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated.

Q2.Discuss the CMM 5 Levels for Software Process?

Answer-The SEI approach provides a measure of the global effectiveness of a compa ny's software engineering practices, and establishes five process maturity level s that are defined in the following manner: Level 1: Initial. The software process is characterized as ad hoc and occasional ly even chaotic. Few processes are defined, and success depends on individual ef fort. Level 2: Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. Level 3: Defined. The software process for both management and engineering activ ities is documented, standardized, and integrated into an organizationwide soft ware process. All projects use a documented and approved version of the organiza tion's process for developing and supporting software. This level includes all c haracteristics defined for level 2. Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively underst ood and controlled using detailed measures. This level includes all characterist ics defined for level 3. Level 5: Optimizing. Continuous process improvement is enabled by quantitative f eedback from the process and from testing innovative ideas and technologies. Thi s level includes all characteristics defined for level 4 by the SEI were derived as a consequence of evaluating responses to the SEI as sessment questionnaire that is based on the CMM. The results of the questionnair e are distilled to a single numerical grade that provides an indication of an or ganization's process maturity. The SEI has associated key process areas (KPAs) with each of the maturity levels . The KPAs describe those software engineering functions (e.g., software project planning, requirements management) that must be present to satisfy good practic e at a particular level. Each KPA is described by identifying the following char acteristics: Goals the overall objectives that the KPA must achieve.

 Commitments requirements (imposed on the organization) that must be met to achieve the goals, or provide proof of intent to comply with the goals. Abilities those things that must be in place (organizationally and technically) to enable the organization to meet the commitments. Activities the specific tasks required to achieve the KPA function. Methods for monitoring implementation the manner in which the activities are mon itored as they are put into place.

Q4. Discuss the Water Fall model for Software Development. Answer-Water Fall model sometimes called as classic life cycle the linear sequent ial model suggests a systematic, sequential approach to software development tha t begins at the system level and progresses through analysis, design, coding, te sting, and support. The linear sequential model for software engineering. Modele d after a conventional engineering cycle, the linear sequential model encompasses the following activities: System/information engineering and modeling because software is always part of a larger system (or business), work begins by establishing requirements for all s ystem elements and then allocating some subset of these requirements to software . This system view is essential when software must interact with other elements such as hardware, people, and databases. System engineering and analysis encompa ss requirements gathering at the system level, with a small amount of top level design and analysis. Information engineering encompasses requirements gathering at the strategic business level and at the business area level. a for the software, as well as required function , behavior, performance, and interface. Requirements for both the system and the software are documented and reviewed with the customer. Design Software design is actually a multistep process that focuses on four dist in attributes of a program: data structure, software architecture, interface representations, and procedural (algorithmic) detail. be accomplished mechanistically. Testing Once the code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested, and on the functional externals; that is, conducting test s to uncover errors and ensure that defined input will produce actual results th at agree with the required results.Support Software will undoubtedly undergo change after it is delivered to the customer (a possible exception is embedded software). or because the customer requires functional or performance enhancements. Software support/maintenance reapplies each of the preceding phases to an existing program rather than a new one. The linear sequential model is the oldest and the most widely used paradigm for software engineering. However, criticism of the paradigm has caused even active supporters to question its efficacy [HAN95]. Among the problems that are sometimes encountered when the linear sequential model is applied are: The linear sequential model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. 3. The customer must have patience.

Q5. Explain the Advantages of Prototype Model, & Spiral Model in Contrast to Water Fall model. Answer-Advantage of Prototype and Spiral Model in Contrast to Water Fall model, a re as follows: The basic difference in Prototype Model Vs Waterfall Model is that, Waterfall Mo del is more rigid compared to Prototyping approach. We take the inputs from the user/client only till the start of designing phase o f SDLC, while in prototype model we have constant interaction with the client an d his inputs and suggestions are taken into consideration. In prototyping we use evolutionary approach while in waterfall model we have a s ort of linear, conventional approach. Waterfall Model is implemented in the projects where conventional product/software has to be delivered to the client. In such cases user is sure and clear about his requirements. He states them clearly to the development team and chances of ambiguity is bare minimum. While Prototype model is usually used in online projects where client is not sure about his requirements, his expectations and preferences need to be taken care of. Before deciding which process to go for, study the client requirements. We should also try to read his mind in order to judge whether he is sure and clear about his requirements. In case he is not clear about them, it is advisable to go for prototyping model. Cost incurred in making a prototype is usually an issue, but one also needs to ensure that the end product should satisfy the customer and if the final product doesnt, then the whole activity of software development will be a waste of time a nd money. The prototyping model is suitable for projects for which either the user require ments or the underlying technical aspects are not well understood. This model i s especially popular for development of the user-interface part of the projects. Advantages of Spiral Model are as follows: 1. The spiral model is called a meta-model since it encompasses all other life c ycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to s everal kinds of risks. However, this model is much more complex than the other m odels. This is probably a factor deterring its use in ordinary projects. 2. Estimates (i.e. budget, schedule, etc.) become more realistic as work progres ses, because important issues are discovered earlier. 3. It is more able to cope with the (nearly inevitable) changes that software de velopment generally entails. 4. Software engineers (who can get restless with protracted design processes) ca n get their hands in and start working on a project earlier. Q6. Explain the COCOMO Model & Software Estimation Technique. Answer-COCOMO Model called as COnstructive COst MOdel. It has evolved into a more comprehensive estimation model, called COCOMO II [BOE 96, BOE00]. Like its predecessor, COCOMO II is actually a hierarchy of estimatio n models that address the following areas: Application composition model: Used during the early stages of software engineer ing, when prototyping of user interfaces, consideration of software and system i nteraction, assessment of performance, and evaluation of technology maturity are paramount. Early design stage model: Used once requirements have been stabilized and basic software architecture has been established. Post-architecture-stage model: Used during the construction of the software. Software Estimation Technique. Software project estimation is a form of problem solving, and in most cases, the problem to be solved we decompose the problem, re-characterizing it as a set of smaller (and

hopefully, more manageable) problems. The decomposition approach w as discussed from two different points of view: decomposition of the problem and decomposition of the process. Estimation uses one or both forms of partitioning . But before an estimate can be made, the project planner must understand the sc ope of the software to be built and generate an estimate of its size. (i) Software Sizing The accuracy of a software project estimate is predicated on a number of things: (1) the degree to which the planner has properly estimated the size of the prod uct to be built; (2) the ability to translate the size estimate into human effor t, calendar time, and dollars (a function of the availability of reliable softwa re metrics from past projects); (3) the degree to which the project plan reflect s the abilities of the software team; and (4) the stability of product requirements and the environment that supports the software engineering effort. (ii) Problem-Based Estimation Lines of code and function points were described as measures from which productivity metrics can be computed. LOC and FP data are used in two ways during software project estimation: (1) as an estimation variable to "size" each element of t he software and (2) as baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort projections. L OC and FP estimation are distinct estimation techniques. Yet both have a number of characteristics in common. The project planner begins with a bounded statemen t of software scope and from this statement attempts to decompose software into problem functions that can each be estimated individually. LOC or FP (the estima tion variable) is then estimated for each function. Alternatively, the planner m ay choose another component for sizing such as classes or objects, changes, or b usiness processes affected. Baseline productivity metrics (e.g., LOC/pm or FP/pm 9) are then applied to the appropriate estimation variable, and cost or effort f or the function is derived. Function estimates are combined to produce an overal l estimate for the entire project.