Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

Master of Business Administration - MBA Semester III

MI0033 Software Engineering - 4 Credits Assignment - Set- 2 (60 Marks)

1. Write a note on myths of Software.

There are many myths that are associated with the software development world. Unlike ancient myths which provide human lessons, software myths transmit confusion. Various Software Myths are given below: Software can work right at the first time: We cannot expect software to work properly at the first time. For example, you go to an aeronautics engineer, and ask him to build a jet fighter; he will quote us the price. But if we demand it to be put into production without building its prototype, then he will refuse the job. Software engineers are often asked to do that sort of work that is quite unexpected. Software is easy to change: Well, source code of the software is easy to edit, but is quite different from saying that it is easy to change. Because changes made in software without introducing problems are very difficult. Verification of the complete system is needed after every change. Therefore software is not easy to change and proper care is needed during every change. Software with more features is better software: It is a totally false statement that software with more features is better software. Best software is that which does one task well. Reusing Software increases safety: Reusing software does not increase safety. Reusing code can helps in improving the development efficiency, but it needs a lot of analysis to check its suitability and testing to see if it works. Addition of more software engineers will cover up the delay: It is not true in all the cases. Sometimes, by adding more software engineers during the project, we may further delay the project. Therefore it is not true in our case, but adding more people can certainly cover up the delay in civil engineering work. Software myths list is endless. Various other software myths are like computer provides greater reliability than the device they replaced; testing errors can remove the errors etc.

Roll Number: 571018818

Page 1

Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

2. Explain Version Control & Change Control.

Version Control: A version control system (also known as a Revision Control System) is a repository of files, often the files for the source code of computer programs, with monitored access. Every change made to the source is tracked, along with who made the change, why they made it, and references to problems fixed, or enhancements introduced, by the change. Version control systems are essential for any form of distributed, collaborative development. Whether it is the history of a wiki page or large software development project, the ability to track each change as it was made, and to reverse changes when necessary can make all the difference between a well managed and controlled process and an uncontrolled 'first come, first served' system. It can also serve as a mechanism for due diligence for software projects. Version control has been closely studied and understood in the software engineering community for a long time. The solutions are stable, robust and well-supported. There are various systems suitable for small local teams and for large distributed teams, making them ideal for coordinating software development, and for mitigating differences in culture and time zone. Version control is provided at sites such as SourceForge and Google Code. These sites typically build a suite of services around version control: archiving, release downloads, mailing lists, bug trackers, web hosting and build farms. This range of functionality makes them particularly attractive for those projects that do not have the resources to maintain their own server for version control. CVS used to be the most widely used open source version control system but these days Subversion has overtaken it and is very commonly used in open source projects. However, some newer open source version control systems such as Arch and Git have made significant inroads. The basic capabilities of these systems are very similar, but they offer different security, networking and abstraction functionality, and different licenses. There are also many proprietary solutions available from a range of suppliers. Change Control: Change control is a systematic approach to managing all changes made to a product or system. The purpose is to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted and that resources are used efficiently. Within information technology (IT), change control is a component of change management. The change control process is usually conducted as a sequence of steps proceeding from the submission of a change request. Typical IT change requests include the addition of features to software applications, the installation of patches, and upgrades to network equipment. Here's an example of a six-step process for a software change request: 1. Documenting the change request: When the client requests the change, that request is categorized and recorded, along with informal assessments of the importance of that change and the difficulty of implementing it. Roll Number: 571018818 Page 2

Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

2. Formal assessment: The justification for the change and risks and benefits of making/not making the change are evaluated. If the change request is accepted, a development team will be assigned. If the change request is rejected, that fact is documented and communicated to the client. 3. Planning: The team responsible for the change creates a detailed plan for its design and implementation, as well as a plan for rolling back the change should it be deemed unsuccessful. 4. Designing and testing: The team designs the program for the software change and tests it. If the change is deemed successful, the team requests approval and a date for implementation. 5. Implementation and review: The team implements the program and stakeholders review the change. 6. Final assessment: If the client is satisfied that the change was implemented satisfactorily, the change request is closed. If the client is not satisfied, the project is reassessed and steps may be repeated.

3. Discuss the SCM Process.

Configuration Identification: Software is usually made up of several programs. Each program, its related documentation and data can be called as a "configurable item"(CI). The number of CI in any software project and the grouping of artifacts that make up a CI is a decision made of the project. The end product is made up of a bunch of CIs. The status of the CIs at a given point in time is called as a baseline. The baseline serves as a reference point in the software development life cycle. Each new baseline is the sum total of an older baseline plus a series of approved changes made on the CI A baseline is considered to have the following attributes Functionally complete: A baseline will have a defined functionality. The features and functions of this particular baseline will be documented and available for reference. Thus the capabilities of the software at a particular baseline are well known. 1. Known Quality: The quality of a baseline will be well defined. i.e. all known bugs will be documented and the software will have undergone a complete round of testing before being put define as the baseline. 2. Immutable and completely re-creatable A baseline, once defined, cannot be changed. The list of the CIs and their versions are set in stone. Also, all the CIs will be under version control so the baseline can be recreated at any point in time.

Roll Number: 571018818

Page 3

Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

Configuration Control: The process of deciding, co-coordinating the approved changes for the proposed CIs and implementing the changes on the appropriate baseline is called Configuration control. It should be kept in mind that configuration control only addresses the process after changes are approved. The act of evaluating and approving changes to software comes under the purview of an entirely different process called change control. Configuration Status Accounting: Configuration status accounting is the bookkeeping process of each release. This procedure involves tracking what is in each version of software and the changes that lead to this version. Configuration status accounting keeps a record of all the changes made to the previous baseline to reach the new baseline. Configuration Authentication: Configuration authentication (CA) is the process of assuring that the new baseline has all the planned and approved changes incorporated. The process involves verifying that all the functional aspects of the software are complete and also the completeness of the delivery in terms of the right programs, documentation and data are being delivered.

Explain
i.

Software doesnt wear out. ii. Software is engineered & not manufactured.

Software doesnt wear out. The figure 1.1 shows the relationship between failure rate and time. Consider the failure rate as a function of time for hardware. The relationship is called the bathtub curve, indicates that hardware exhibits relatively high failure rates early in its life, defects are corrected and the failure rate drops to a steady-state level for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. So, stated simply, the hardware begins to wear out.

Roll Number: 571018818

Page 4

Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

Figure 1.1 Relationship between failure rate and time

Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the idealized curve like a zig-zag form. Undiscovered defects will cause high failure rates early in the life of a program. However, the implication is clear software doesn't wear out. But it does deteriorate. Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the Minimum failure rate level begins to risethe software is deteriorating due to change.

Figure 1.2 Idealized and actual failure curves for software

The idealized curve is a gross oversimplification of actual failure models for software. However, the implication is clearsoftware doesn't wear out. But it does deteriorate. This seeming contradiction can best be explained by considering the actual curve shown in Figure.2. During its life, software will undergo change (maintenance). As changes are made, it is likely that some new defects will be introduced, causing the failure rate curve to spike as shown in Figure 2. Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to risethe software is deteriorating due to change. Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, software maintenance involves considerably more complexity than hardware maintenance. Software is engineered & not manufactured: Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both activities are dependent on the people, but the Roll Number: 571018818 Page 5

Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

relationship between people applied and work accomplished is entirely different. Both activities require the construction of a "product" but the approaches are different. Software costs are concentrated in engineering. This means that software projects cannot be managed as if they were manufacturing projects. When computer software succeedswhen it meets the needs of the people who use it, when it performs flawlessly over a long period of time, when it is easy to modify and even easier to use it can and does change things for the better. But when software failswhen its users are dissatisfied, when it is error prone, when it is difficult to change and even harder to usebad things can and do happen. We all want to build software that makes things better, avoiding the bad things that lurk in the shadow of failed efforts. To succeed, we need discipline when software is designed and built. We need an engineering approach. The role of computer software has undergone significant change over a time span of little more than 50 years. Dramatic improvements in hardware performance, profound changes in computing architectures, vast increases in memory and storage capacity and wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and complexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build complex systems. The lone programmer of an earlier era has be replaced by a team of software specialists, each focusing on one part of the technology required to deliver a complex application. And yet, the same questions asked of the lone programmer are being asked when modern computer-based systems are built:
   

Why does it take so long to get software finished? Why are development costs so high? Why cant we find all the errors before we give the software to customers? Why do we continue to have difficulty in measuring progress as software is being developed? These, and many other questions, are a manifestation of the concern about software and the manner in which it is developed-a concern that has lead to the adoption of software engineering practice. Software is pervasive, and yet, many people in position of responsibility have little or no real understanding of what it really is, how its built, or what it means to the institutions that they control. More importantly, they have little appreciation of the dangers and opportunities that software offers.

Roll Number: 571018818

Page 6

Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

4. Explain the Different types of Software Measurement Techniques.

Types of Software Measurement Techniques: Most estimating methodologies are predicated on analogous software programs. Expert opinion is based on experience from similar programs; parametric models stratify internal data bases to simulate environments from many analogous programs; engineering builds reference similar experience at the unit level; and cost estimating relationships (like parametric models) regress algorithms from several analogous programs. Deciding which of these methodologies (or combination of methodologies) is the most appropriate for your program usually depends on availability of data, which is in turn depends on where you are in the life cycle or your scope definition. Analogies: Cost and schedule are determined based on data from completed similar efforts. When applying this method, it is often difficult to find analogous efforts at the total system level. It may be possible, however, to find analogous efforts at the subsystem or lower level computer software configuration item/computer software component/computer software unit (CSCI/CSC/CSU). Furthermore, you may be able to find completed efforts that are more or less similar in complexity. If this is the case, a scaling factor may be applied based on expert opinion (e.g., CSCI-x is 80% as complex). After an analogous effort has been found, associated data need to be assessed. It is preferable to use effort rather than cost data; however, if only cost data are available, these costs must be normalized to the same base year as your effort using current and appropriate inflation indices. As with all methods, the quality of the estimate is directly proportional to the credibility of the data. Expert (engineering) opinion: Cost and schedule are estimated by determining required effort based on input from personnel with extensive experience on similar programs. Due to the inherent subjectivity of this method, it is especially important that input from several independent sources be used. It is also important to request only effort data rather than cost data as cost estimation is usually out of the realm of engineering expertise (and probably dependent on non-similar contracting situations). This method, with the exception of rough orders-of-magnitude estimates, is rarely used as a primary methodology alone. Expert opinion is used to estimate lower-level, low cost, pieces of a larger cost element when a labor-intensive cost estimate is not feasible. Parametric models: most commonly-used technology for software estimation is parametric models, a variety of which are available from both commercial and government sources. The estimates produced by the models are repeatable, facilitating sensitivity and domain analysis. The models generate estimates through statistical formulas that relate a dependent variable (e.g., cost, schedule, resources) to one or more independent variables. Independent variables are called cost drivers because any change in their value results in a change in the cost, schedule, or resource estimate. The models also address both the development (e.g., development team skills/experience, process Roll Number: 571018818 Page 7
The

Assignment Set 2

Software Engineering

Name: Pradeep KR Roll Number: 571018818

maturity, tools, complexity, size, domain, etc.) and operational (how the software will be used) environments, as well as software characteristics. The environmental factors, used to calculate cost (manpower/effort), schedule, and resources (people, hardware, tools, etc.), are often the basis of comparison among historical programs, and can be used to assess on-going program progress.

5. Write a Note on Spiral Model

The Spiral Life Cycle Model is a type of iterative software development model which is generally implemented in high risk projects. It was first proposed by Boehm. In this system development method, we combine the features of both, waterfall model and prototype model. In Spiral model we can arrange all the activities in the form of a spiral. Each loop in a spiral represents a development phase (and we can have any number of loops according to the project). Each loop has four sections or quadrants: 1. To determine the objectives, alternatives and constraints. We try to understand the product objectives, alternatives in design and constraints imposed because of cost, technology, schedule, etc. 2. Risk analysis and evaluation of alternatives. Here we try to find which other approaches can be implemented in order to fulfill the identified constraints. Operational and technical issues are addressed here. Risk mitigation is in focus in this phase. And evaluation of all these factors determines future action. 3. Execution of that phase of development. In this phase we develop the planned product. Testing is also done. In order to do development, waterfall or incremental approach can be implemented. 4. Planning the next phase. Here we review the progress and judge it considering all parameters. Issues which need to be resolved are identified in this phase and necessary steps are taken. Subsequent loops of spiral model involve similar phases. Analysis and engineering efforts are applied in this model. Large, expensive or complicated projects use this type of life cycle. If at any point of time one feels the risk involved in the project is a lot more than anticipated, one can abort it. Reviews at different phases can be done by an in-house person or by an external client.

Spiral Model Diagram

Roll Number: 571018818

Page 8