"Introduction to Software Engineering: concepts, processes, and methodologies."

"Introduction to Software Engineering: concepts, processes, and methodologies."

1. S oftware Engineering ECS-602 B.Tech CS/Year-III Sem -VI Term: 2014-2015 UNIT-1 Text Books : 1.Software Engineering, A practitioner’s approach Roger s. Pressman 6 th edition McGraw-Hill 2.Software Engineering, Pankaj Jalote , Wiley. 3.Software Engineering, New Age International, K.K Agarwal and Yogesh Singh, 3 rd edition 4.Fundamentals of Software Engineering, Rajib Mall, PHI Publication 1

2. Introduction to Software Engineering C h a ng e in n a tu r e & c o m pl e xity of s o f t w a r e C on ce pt o f on e “gu r u ” is ov e r We a ll w ant i m p r ov e m e nt Rea d y for c h a ng e 2

3. Engineering approach to develop software C ontractor is not really expert in house building. If he will be agree to build a large 50-storeyed commercial complex, he will surely fail. In s/w engineering also, failure is certain if large projects are build without application of software engineering. 3

4. Software Crisis 4 Pressure to produce complex, advanced code can be a significant contributor to a software crisis. A software crisis is a mismatch between what software can deliver and the capacities of computer systems, as well as expectations of their users. This became a growing problem in the 20th century

5. Software Crisis 5 By the end of the 1960s, hardware costs had fallen exponentially, and were continuing to do so, while the cost of software development was rising at a similar rate

6. Factors contributing to the Software Crisis 6 Late delivery, over budget, Product does not meet specified requirements Lack of adequate training in software engineering Low productivity improvements.

7. Software Crisis As per the IBM report, “31%of the project get cancelled before they are completed, 53% over-run their cost estimates by an average of 189% and for every 100 projects, there are 94 restarts”. 7

8. Software Crisis 8 success 16% failure 31% over budget 53% Software industry is in Crisis!

9. Some Software Failures 9 Ariane 5 I t took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the commercial space business. The rocket was destroyed after 39 seconds of its launch, at an altitude of two and a half miles along with its payload of four expensive and uninsured scientific satellites.

10. Some Software Failures 10 When the guidance system ’ s own computer tried to convert one piece of data the sideways velocity of the rocket from a 64 bit format to a 16 bit format; the number was too big, and an overflow error resulted after 36.7 seconds. When the guidance system shutdown, it passed control to an identical, redundant unit, which was there to provide backup in case of just such a failure. Unfortunately, the second unit, which had failed in the identical manner a few milliseconds before.

11. Some Software Failures 11 Y2K Problem It was simply the ignorance about the adequacy or otherwise of using only last two digits of the year.    The 4-digit date format, like 1964, was shortened to 2-digit format, like 64.

12. Some Software Failures 12 The Patriot Missile First time used in Gulf war Used as a defense from Iraqi Scud missiles Failed several times including one that killed 28 US soldiers in Dhahran, Saudi Arabia. Reasons: A small timing error in the system’s clock accumulated to the point that after 14 hours, the tracking system was no longer accurate. In the Dhahran attack, the system had been operating for more than 100 hours.

13. Some Software Failures 13 Financial Software   Many companies have experienced failures in their accounting system due to faults in the software itself. The failures range from producing the wrong information to the whole system crashing.

14. Some Software Failures 14 Windows XP Microsoft released Windows XP on October 25, 2001. On the same day company posted 18 MB of compatibility patches on the website for bug fixes, compatibility updates, and enhancements. Two patches fixed important security holes.  

15. “No Silver Bullet” The hardware cost continues to decline drastically. However, there are desperate cries for a silver bullet something to make software costs drop as rapidly as computer hardware costs do. But as we look to the horizon of a decade, we see no silver bullet. There is no single development, either in technology or in management technique. 15

16. “No Silver Bullet” The hard part of building software is the specification, design and testing of this conceptual construct, not the labour of representing it and testing the correctness of representation.    We still make syntax errors, to be sure, but they are trivial as compared to the conceptual errors (logic errors) in most systems. That is why, building software is always hard and there is inherently no silver bullet. 16

17. “No Silver Bullet” The blame for software bugs belongs to:    Software companies Software developers Legal system Universities 17

18. Problem Domain The Problem Domain is the software that solves some problems of some users where larger systems or businesses may depend on the software, and where problems in the software can lead to significant direct and indirect loss. 18

19. Software Misconception : Software is Program Various differences between Program and Software are given in the tabular form as follows: 19 Program Software 1 Programs are developed by individuals for their personal use. A software is usually developed by a group of engineers working in a team. 2 Usually small in size Usually large in size 3 Single user Large number of users 4 Lacks proper documentation Good documentation support 5 Lack of user interface Good user interface 6 Have limited functionality Exhibit more functionality

20. Software Software is the collection of programs, documentation, and operating procedures by which computers can be made useful to people . 20

21. Software Components 21 Programs Documentation Operating Procedures Program : source code, object code Operating Procedures : user manual, operational manual. (instructions / scripts to set up and use the program ; instructions on how to treat failures ; instructions/scripts on how to test the program Documentation : requirement specification document, design document, test document etc. Components of a software system

22. Software Product Software products may be developed for a particular customer or may be developed for a general market   Software products may be   – Generic Products - developed to be sold to a range of different customers   – Customized Products - developed for a single customer according to their specification   22

23. Software Product Software product is a product designated for delivery to the user

24. Difference between Student Software & Industrial Strength Software Student Software is not used for solving any real problem of any organization. An Industrial Strength Software is used by the client’s organization for operating some part of business e.g, inventories, finances etc. This kind of software system needs to be of high quality. 24

25. Software is Expensive Expensive due to the fact that s/w development is extremely labor-intensive. Cost is the manpower employed. Productivity is measured in terms of LOC per person-month. 25

26. Late & Unreliable When budget and schedule are out-of-control, this is a run-away condition. Unreliability means that the software does not do what it is supposed to do or does something it is not supposed to do. e.g , Software Failures. 26

27. Maintenance and Rework Corrective Maintenance Adaptive Maintenance Rework and Change is the major contributor to the Software Crisis . Thus, Software Engineering deals with Problem Domain. 27

28. Software Engineering Software engineering is an engineering discipline which is concerned with all aspects of software production   Software engineers should  – adopt a systematic and organised approach to their work  – use appropriate tools and techniques depending on • the problem to be solved,  • the development constraints and  – use the resources available   28

29. Software Engineering At the first conference on software engineering in 1968, Fritz Bauer defined software engineering as “The establishment and use of sound engineering principles in order to obtain economically developed software that is reliable and works efficiently on real machines”.   Stephen Schach defined the same as “A discipline whose aim is the production of quality software, software that is delivered on time, within budget, and that satisfies its requirements”.   Both the definitions are popular and acceptable to majority. However, due to increase in cost of maintaining software, objective is now shifting to produce quality software that is maintainable, delivered on time, within budget, and also satisfies its requirements.   29

30. Goal of Software Engineering   30 To improve quality of software products. To increase the productivity, and To give job satisfaction to the software engineers.

31. Software Characteristics 1. Software does not wear out.   31

32. Software Characteristics Failure curve for software   32

33. Software Characteristics Important Points that shows Software does not wear out are- Software becomes reliable over time instead of wearing out. It may be retired due to environmental changes, new requirements, new expectations etc. When a hardware component wears out, it is replaced by a spare part. But, there are no software spare parts. Hence, software maintenance require more complexity than hardware maintenance.   33

34. Software Characteristics 2. Software is not manufactured, it is developed. 3. Reusability of components. 4. Software is flexible.   34

35. Software Characteristics 35 Sr. Constructing a bridge Writing a program No 1. The problem is well understood Only some parts of the problem are understood, others are not 2. There are many existing bridges Every program is different and designed for special applications. 3. The requirement for a bridge typically do Requirements typically change during all not change much during construction phases of development. 4. The strength and stability of a bridge can be Not possible to calculate correctness of a calculated with reasonable precision program with existing methods. 5. When a bridge collapses, there is a When a program fails, the reasons are often detailed investigation and report unavailable or even deliberately concealed. 6. Engineers have been constructing bridges Developers have been writing programs for thousands of years for 50 years or so. 7. Materials (wood, stone,iron, steel) and Hardware and software changes rapidly. techniques (making joints in wood, carving stone, casting iron) change slowly.

36. SE Challenges The problem of producing software to satisfy user needs drives the approaches used in SE. Important Factors that affect the SE approaches selected to solve the problem are-   36 Scale Quality and Productivity Consistency and Repeatability Change Fig: Primary Challenges for Software Engineering

37. Scale   37 Fig: The problem of scale. SE must deal with problem of scale methods for solving small problems do not scale up for large problems industrial strength S/W problems tend to be large e.g , Counting the number of people in a room vs taking a census Two clear dimensions in this engineering methods project management For small, both can be informal or ad-hoc, for large both have to be formalized

38. Productivity   38 An engineering project is driven by cost and schedule. Cost: In s/w, cost is mainly manpower cost; hence, it is measured in person-months Schedule is in months/weeks – very important in business context Productivity captures both Cost and Schedule If P is higher, cost is lower If P is higher, time taken can be lesser Approaches used by SE must deliver high Productivity

39. Quality   39 Quality is the other major driving factor Developing high Quality S/W is a basic goal Quality of S/W is harder to define Approaches used should produce a high Quality software ISO standard has six software quality attributes -

40. Consistency & Repeatability   40 Sometimes a group can deliver one good software system, but not a second Key SE challenge: how to ensure that success can be repeated ? SE wants methods that can consistently produce high Quality SW with high Productivity A SW org, wants to deliver high Q&P consistently across projects Frameworks like Inter. Org. for Standardization (ISO-9001) and Capability Maturity Model (CMM) focus on this aspect

41. Change   41 In today’s world change in business is very rapid. It is therefore expected that software supporting businesses should respond to the changes in order to achieve the task is meant to do. Rapid change has a special impact on software. Therefore, one challenge for software engineering is to accommodate and embrace change.

42. Software Engineering Approach   42 Q&P are the basic objectives to be achieved Consistently for large scale problems Q&P achieved during a project depend upon three main forces - people, processes, and technology, often called the IRON TRIANGLE.

43. SE Methodology SE focuses mostly on processes for achieving the goals Process must be systematic SE separates process for developing s/w from the developed product ( i.e the s/w) Premise: Process largely determines Q&P, hence suitable processes will lead to high Q&P

44. Software Process   44 Software Processes include those activities, methods, practices and transformations that are used to create and maintain software products. The software process is the way in which we produce software. Process is what takes us from user needs to the software that satisfies the needs.

45. Process Specification   45 Process is generally a set of phases Each phase performs a well defined task and generally produces an output Intermediate outputs – work product At top level, typically few phases in a process How to perform a particular phase – methodologies have been proposed

46. ETVX Specification   46 ETVX approach to specify a step Entry criteria: what conditions must be satisfied for initiating this phase Task: what is to be done in this phase Verification: the checks done on the outputs of this phase eXit criteria: when can this phase be considered done successfully A phase also produces information for management

47. ETVX Approach for Process Specification   47

48. Characteristics of Software Process   48 Is any process suitable to use? As a process may be used by many projects, it needs characteristic beyond satisfying the project goals. Predictability Support Testability and Maintainability Support Change Early Defect Removal Process Improvement and Feedback

49. Software Engineering Process   49 A Software engineering process is the model chosen for managing the creation of software from initial customer inception to the release of the finished product . The chosen process usually involves techniques such as - • Analysis, • Design, • Coding, • Testing and • Maintenance In this engineering process, we trying to prevent the error at the time of software development.

50. Conventional Engineering Process   50 Conventional engineering process is the process in which first we make a program and if any error is found in it then we try to resolve it. It is decomposition in nature. For example, Car

51. Similarity from Conventional Engineering Process   51 The steps of engineering design process are used in the process of problem solving in the field of engineering . These steps, which are mostly iterative, are: (1) Problem formulation, (2) Problem analysis, (3) Search for alternatives, (4) Decision, (5) Specification, and (6) Implementation. The set of three key elements—methods, tools and procedures which enable the manager to control the process of software development. According to Pressman, methods provide the technical “how to” for building software; tools provide automated or semi-automated support for methods; and procedures define the sequence of applying the methods, the deliverables, the controls, and the milestones.

52. Differences from Conventional   52 Difference between software engineering and traditional software engineering – Software engineers often apply new and untested elements in software projects while traditional software engineers generally try to apply known and tested principles and limit the use of untested innovations to only those necessary to create a product that meets its requirements. Software engineers emphasize projects that will live for years or decades whereas some traditional engineers solve long-ranged problems that ensure for centuries . Software engineering is about 50 years old whereas traditional engineering as a whole is thousands of years old. Software engineering is often busy with researching the unknown ( eg . To drive an algorithm) right in the middle of a project whereas traditional engineering normally separates these activities . A project is supposed to apply research results in known or new clever ways to build the desired result. Both disciplines requires maintenance but in different ways. Software engineers construct non-real(abstract) artefacts , whereas traditional engineers construct real artefact.

53. Software Development Life Cycle (SDLC)   53 Software-development life-cycle is used to facilitate the development of a large software product in a systematic, well-defined, and cost-effective way. An information system goes through a series of phases from conception to implementation. This process is called the Software-Development Life-Cycle. Various reasons for using a life-cycle model include: – Helps to understand the entire process – Enforces a structured approach to development – Enables planning of resources in advance – Enables subsequent controls of them – Aids management to track progress of the system

54. Software Development Life Cycle (SDLC)   54 Feasibility study: - The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product . Requirements analysis and specification: - The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely Requirements gathering and analysis, this phase ends with the preparation of Software requirement Specification (SRS) Design: - The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language . Design specification Document is outcome of this phase. Coding and unit testing:- The purpose of the coding and unit testing phase (sometimes called the implementation phase) of software development is to translate the software design into source code . Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested. Code Listings are generated after this phase.

55. Software Development Life Cycle (SDLC)   55 Integration and system testing: - Integration of different modules is undertaken once they have been coded and unit tested During each integration step , the partially integrated system is tested and a set of previously planned modules are added to it . Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document . Test Reports are generated after this phase. Maintenance: - Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratio. This phase continues till the software is in use.

56. Software Development Life Cycle (SDLC)   56 Different software life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows: 1. Classical Waterfall Model 2. Iterative Model 3. Prototyping Model 4. Evolutionary Model 5. Spiral Model 6. Rapid Application Development model (RAD)

57. Classical Waterfall Model   57 Though the classical waterfall model is elegant and intuitively obvious, it is not a practical model in the sense t hat it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software. But all other life cycle models are essentially derived from the classical waterfall model. So, in order to be able to appreciate other life cycle models it is necessary to learn the classical waterfall model. Classical waterfall model divides the life cycle into the following phases as shown in fig: 1. Feasibility Study 2. Requirements Analysis and Specification 3. Design 4. Coding and Unit Testing 5. Integration and System Testing 6. Maintenance

58. Classical Waterfall Model   58