Introduction and History of Software Engineering PDF

Department of Computer Engineering and Sciences CSE 2410 Software Engineering Introduction to Software Engineering Read Chapter -1-...

Department of Computer Engineering and Sciences CSE 2410 Software Engineering Introduction to Software Engineering Read Chapter -1- Khaled Slhoub, PhD © 2012 Václav Rajlich Software Engineering: The Current Practice 1  Software is Everywhere “Software is a skin that surrounds our civilization” Mark Harman © 2012 Václav Rajlich Software Engineering: The Current Practice 2  What is Software? Software is everywhere – buying bread, driving car, washing clothes – synonyms: programs, applications The terms software and program are used interchangeably e.g., software that records names and addresses in a database Application is often software that is interacting with a human user People, who develop the software – software engineers, software developers, programmers – they possess skills and tools that allow them to develop and evolve software © 2012 Václav Rajlich Software Engineering: The Current Practice 3  What is Software Engineering (SE)? SE is a branch of engineering that deals with the development of software products. SE operates within a set of principles, best practices, and methods that have been carefully honed throughout the years, changing as software and technology change. SE leads to a product that is reliable, efficient, and effective at what it does. © 2012 Václav Rajlich Software Engineering: The Current Practice 4  What is Software Engineering? SE is the study of how software systems are developed, including topics such as requirements engineering, software design, project management, quality assurance, software testing and maintenance. How to design and build software in teams. You will learn about working with people (communication, management, working with non- technical customers), processes for developing software, and how to measure and analyze the software product and process. © 2012 Václav Rajlich Software Engineering: The Current Practice 5  What is Software Engineering? Software Engineering is a more hands-on project, focused to learn the overall life cycle of how software is built and maintained. A process model describes an approach to the production of software. Software process models are frequently called “software development life-cycle” models. It defines a set of activities and associated results that produce a software product © 2012 Václav Rajlich Software Engineering: The Current Practice 6  Software Eng. vs Computer Science CS is concerned with the theories and methods that underlie computers and software systems Choose CS if you like math, logic, or if you want to get into a specialized field in CS such as artificial intelligence, machine learning, security, or graphics. SE is concerned with the practical problems of producing software Choose SE if you are more interested in the hands-on approach, and if you want to learn the overall life cycle of how software is built and maintained. Some knowledge of computer science is essential for SE. Read https://www.indeed.com/career-advice/finding-a-job/computer-science-vs-software-engineering © 2012 Václav Rajlich Software Engineering: The Current Practice 7  Software Engineering: Definitions “An engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use.” - Ian Summerville “A systematic approach to the analysis, design, assessment, implementation, test, maintenance, and reengineering of software, that is, the application of engineering to software.” - Phillip laplante “Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” - Friedrich Bauer © 2012 Václav Rajlich Software Engineering: The Current Practice 8  Software Properties Software is a product, but it is very different from other products. It has certain properties that make it very different from other engineering products and other things in the world. Such properties make the work of software engineers challenging and unique.. © 2012 Václav Rajlich Software Engineering: The Current Practice 9  Software Properties Invisibility senses cannot be employed when trying to comprehend software visualizations, sonifications, require lots of work Complexity software is among most complex systems ever created by mankind our short-term memory accommodates only ~7 things Changeability software is constantly changing software is much harder to change it correctly yesterday’s comprehension may be obsolete © 2012 Václav Rajlich Software Engineering: The Current Practice 10  Software Properties Conformity Large system (hardware, stakeholders, domain) The program glues it all together, reflects the large system software has to conform to its domain This adds even more complexity Discontinuity People easily understand linear or semi-linear systems: shower Software is discontinuous, small change of input can result in an unexpected and huge change of output: password © 2012 Václav Rajlich Software Engineering: The Current Practice 11  Beginning of Software Z1 Software separated from the hardware in 1950’s – emerged as a distinct technology – became independent product ENIAC Original programmers recruited from the ranks of hardware engineers and mathematicians – used ad-hoc techniques from their former fields © 2012 Václav Rajlich Software Engineering: The Current Practice 12  Paradigm & Anomaly Paradigm – “Coherent tradition of scientific research” includes law, theory, application, instrumentation, terminology, research agenda, textbooks, norms, curricula, culture of the field… not only the ideas, but also investment in tools, textbooks, training, careers, and funding. Anomaly is an important fact that directly contradicts the old paradigm Ex: The transition from the geocentric model to the heliocentric model in astronomy © 2012 Václav Rajlich Software Engineering: The Current Practice 13  Paradigm Shift Dilemma: disregard anomaly vs. paradigm shift – to shift paradigm means to abandon large part of the investment – the anomaly must be compelling Paradigm shift is a fundamental change in the basic concepts and experimental practices of a scientific discipline © 2012 Václav Rajlich Software Engineering: The Current Practice 14  Birth of SE - Paradigm Shift of ~ 1970 Anomaly 1 – previous techniques did not scale up – the anomaly that caused the paradigm shift at that time was the increased complexity of software demands of the IBM new operating system OS/360 (1964) taxed the limits of the programmers, project managers, and the resources of the IBM corporation Paradigm shift established discipline of software engineering – dealt with complexity of software – software design established as an important consideration – special knowledge or special sets of skills were necessary for writing software – introduced the waterfall metaphor (first process model) © 2012 Václav Rajlich Software Engineering: The Current Practice 15  Software Crisis The notion of software engineering was first proposed in 1968 at the first international conference on SE (NATO), in Germany The early experience in building software systems demonstrated that informal software development was not good enough. – Software cost much more the predicted (over budget) – Software was unreliable (not defect-free) (may cause death or serious injury) – Software was complex (difficult to maintain) – Performed poorly – Late delivery – Did not behave as a user expected © 2012 Václav Rajlich Software Engineering: The Current Practice 16  Waterfall Model (Linear Process) It is the first published model of the software development process. A project using the waterfall model moves down a series of steps starting from an initial idea of a project to a final product. Because of the cascade from one phase to another, the model is known as the waterfall model. © 2012 Václav Rajlich Software Engineering: The Current Practice 17  Waterfall Process Model transfer to users © 2012 Václav Rajlich Software Engineering: The Current Practice 18  Exponential Cost of Change Major contributor to software cost 1200 1000 800 Cost 600 400 200 0 11 13 15 17 1 3 5 7 9 Time Late changes are much more expensive than early changes © 2012 Václav Rajlich Software Engineering: The Current Practice 19  Exponential Cost of Change Major contributor to software cost © 2012 Václav Rajlich Software Engineering: The Current Practice 20  Anomaly 2 - Requirements Volatility “about 30% of the requirements for Microsoft projects change during an average project ” - Cusumano and Selby Requirements for IT software change at a rate 2 – 3.5% per month - Caper Jones The volatility of the requirements is an anomaly that cannot be accommodated by the waterfall. If the requirements keep changing at these high rates, the design that is based on them must keep changing also, and all advantages of the waterfall disappear. © 2012 Václav Rajlich Software Engineering: The Current Practice 21  Why Are We Here? (Standish Group) In 1995 – 31% of all software projects were cancelled – 53% were “challenged” (completed only with great difficulty, with large cost or time overruns, or substantially reduced functionality) – only 16% could be called successful One just has to look to the City of Denver to realize the extent of this problem. – The failure to produce reliable software to handle baggage at the new Denver airport cost the city $1.1 million per day. Source: Standish Group White Paper: CHAOS: A Recipe for Success Obviously, the waterfall metaphor did not solve the problems of software development © 2012 Václav Rajlich Software Engineering: The Current Practice 22  Why Are We Here? Further, the Standish Group estimates that in 1995 American companies and government agencies spent $81 billion for canceled software projects. These same organizations paid an additional $59 billion for software projects that were completed but exceeded their original time estimates. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions Source: Standish Group White Paper: CHAOS: A Recipe for Success © 2012 Václav Rajlich Software Engineering: The Current Practice 23  Project Failure Factors Failure Factors % of Responses 1. Incomplete Requirements 13.1% 2. Lack of User Involvement 12.4% 3. Lack of Resources 10.6% 4. Unrealistic Expectations 9.9% 5. Lack of Executive Support 9.3% 6. Changing Requirements & Specifications 8.7% 7. Lack of Planning 8.1% 8. Didn't Need It Any Longer 7.5% 9. Lack of IT Management 6.2% 10.Technology Illiteracy 4.3% 11.Other 9.9% Standish Group Survey © 2012 Václav Rajlich Software Engineering: The Current Practice 24  Project Success Factors Success Factors % of Responses 1. User Involvement 15.9% 2. Executive Management Support 13.9% 3. Clear Statement of Requirements 13.0% 4. Proper Planning 9.6% 5. Realistic Expectations 8.2% 6. Smaller Project Milestones 7.7% 7. Competent Staff 7.2% 8. Ownership 5.3% 9. Clear Vision & Objectives 2.9% 10.Hard-Working, Focused Staff 2.4% 11.Other 13.9% Standish Group Survey © 2012 Václav Rajlich Software Engineering: The Current Practice 25  Paradigm Shift of ~ 2000 New life span models emphasize software evolution – staged model of software lifespan – based on data from long-lived systems Third Paradigm: Iterative development – Rational Unified Process (RUP) – Agile development SCRUM Extreme programming (XP programming) Test-Driven Development (TDD) The iterative paradigm is the mainstream of today’s industrial practice © 2012 Václav Rajlich Software Engineering: The Current Practice 26  Paradigm Shift of ~ 2000 The iterative paradigm is the mainstream of today’s industrial practice © 2012 Václav Rajlich Software Engineering: The Current Practice 27  SE: Huge Room for Improvement Despite this improvement, that’s awfully low! The top two reasons were Standish Group Survey - lack of user input/involvement - incomplete requirements © 2012 Václav Rajlich Software Engineering: The Current Practice 28  Safe and Secure Intelligent Software © 2012 Václav Rajlich Software Engineering: The Current Practice 29  Requirements Analysis © 2012 Václav Rajlich Software Engineering: The Current Practice 30  Software Design and Architecture © 2012 Václav Rajlich Software Engineering: The Current Practice 31  Software Coding/Implementation © 2012 Václav Rajlich Software Engineering: The Current Practice 32  Software Testing Methods © 2012 Václav Rajlich Software Engineering: The Current Practice 33  Summary of SE Paradigms 1. The ad hoc techniques were predominant at the very beginning of software engineering, and they never truly disappeared 2. The waterfall paradigm tried to freeze requirements for the duration of software development – led to too many project failures 3. The new paradigm emphasizes software evolution – volatility is a consequence of essential properties © 2012 Václav Rajlich Software Engineering: The Current Practice 34  All Three Paradigms Currently Coexist 1. Ad hoc paradigm still used by some single programmers programming as an art rather than engineering example: small games 2. Waterfall works if there is no volatility small or short-lived projects unusually stable requirements and environments some managers still insist on it 3. Evolutionary paradigm is the mainstream Agile Processes © 2012 Václav Rajlich Software Engineering: The Current Practice 35