Chapter-1_Why-Software-Engineering

1、Why Software Engineering?信息技術(shù)學(xué)院軟件工程系信息技術(shù)學(xué)院軟件工程系郭郭 燁燁2014年09月一、軟件工程學(xué)科介紹一、軟件工程學(xué)科介紹 軟件工程學(xué)科發(fā)展歷史軟件工程學(xué)科發(fā)展歷史 三個(gè)階段：概念提出、學(xué)科雛形、學(xué)科確立三個(gè)階段：概念提出、學(xué)科雛形、學(xué)科確立 第一階段：概念提出第一階段：概念提出 1968 年年 NATO 會(huì)議會(huì)議(北大西洋公約組織的計(jì)算機(jī)科學(xué)家的國(guó)際會(huì)議）北大西洋公約組織的計(jì)算機(jī)科學(xué)家的國(guó)際會(huì)議）提出提出“軟件工程軟件工程”概念。概念。 當(dāng)時(shí)對(duì)當(dāng)時(shí)對(duì)“軟件工程軟件工程”代表性定義：為了經(jīng)濟(jì)地獲代表性定義：為了經(jīng)濟(jì)地獲得在真實(shí)機(jī)器上可靠工作的軟件而制定和使

2、用的得在真實(shí)機(jī)器上可靠工作的軟件而制定和使用的合理工程原則和方法。合理工程原則和方法。 1972 年年 IEEE 學(xué)會(huì)的計(jì)算機(jī)分會(huì)學(xué)會(huì)的計(jì)算機(jī)分會(huì) IEEE 一一 CS 第第一次出版了一次出版了“軟件工程學(xué)報(bào)軟件工程學(xué)報(bào)”第二階段：學(xué)科雛形第二階段：學(xué)科雛形 上世紀(jì)上世紀(jì) 70 年代末，美國(guó)將軟件工程教程列入研究年代末，美國(guó)將軟件工程教程列入研究生教育計(jì)劃。生教育計(jì)劃。 1980 年代末和年代末和 1990 年代初，軟件工程教育得到年代初，軟件工程教育得到卡內(nèi)基一梅隆大學(xué)軟件工程研究所（卡內(nèi)基一梅隆大學(xué)軟件工程研究所（ CMU / SEI ）的支持。）的支持。 1991 年，年，“軟件工程軟件

3、工程”被被 ACM （美國(guó)計(jì)算機(jī)協(xié)會(huì)）（美國(guó)計(jì)算機(jī)協(xié)會(huì)）和和 IEEE / CS 列為計(jì)算學(xué)科的九個(gè)知識(shí)領(lǐng)域之一。列為計(jì)算學(xué)科的九個(gè)知識(shí)領(lǐng)域之一。 1993 年，年， IEEE 一一 CS 和和ACM 為了把軟件工程為了把軟件工程建設(shè)成為一個(gè)專業(yè)，建立了建設(shè)成為一個(gè)專業(yè)，建立了 IEEE 一一 CS / ACM 聯(lián)合指導(dǎo)委員會(huì)。聯(lián)合指導(dǎo)委員會(huì)。 第三階段：學(xué)科確立第三階段：學(xué)科確立 2004 年年 8 月，月，IEEE 一一 CS 和和 ACM 給出：給出： 軟件工程知識(shí)體（軟件工程知識(shí)體（ SWEBOK , Software Engineering Body of Knowledge ) 軟

4、件工程教育知識(shí)體軟件工程教育知識(shí)體（ SEEK ) 最終版，標(biāo)志著最終版，標(biāo)志著軟件工程學(xué)科在世界范圍正式確軟件工程學(xué)科在世界范圍正式確 立。立。 軟件工程、計(jì)算機(jī)科學(xué)、計(jì)算機(jī)工程、信息系統(tǒng)軟件工程、計(jì)算機(jī)科學(xué)、計(jì)算機(jī)工程、信息系統(tǒng)、信息技術(shù)并列成為計(jì)算學(xué)科下的獨(dú)立學(xué)科。、信息技術(shù)并列成為計(jì)算學(xué)科下的獨(dú)立學(xué)科。 軟件工程知識(shí)體軟件工程知識(shí)體（ SWEBOK ) ：全面描述了軟：全面描述了軟件工程實(shí)踐所需的知識(shí)。件工程實(shí)踐所需的知識(shí)。SWEBOK （軟件工程知識(shí)體（軟件工程知識(shí)體 10 個(gè)領(lǐng)域個(gè)領(lǐng)域l 軟件需求軟件需求l 軟件設(shè)計(jì)軟件設(shè)計(jì)l 軟件構(gòu)造軟件構(gòu)造l 軟件測(cè)試軟件測(cè)試 l 軟件維護(hù)軟件

5、維護(hù)l 軟件配置管理軟件配置管理l 軟件工程管理軟件工程管理l 軟件工程過(guò)程軟件工程過(guò)程l 軟件工程工具和方法軟件工程工具和方法l 軟件質(zhì)量軟件質(zhì)量參考資料：參考資料：1 白征白征 SWEBOK ：軟件工程知識(shí)體，計(jì)：軟件工程知識(shí)體，計(jì)算機(jī)科學(xué)，算機(jī)科學(xué)， 2001 年年 07 期期 2 萬(wàn)江平軟件工程知識(shí)體系指南綜述，萬(wàn)江平軟件工程知識(shí)體系指南綜述，計(jì)算機(jī)應(yīng)用研究，計(jì)算機(jī)應(yīng)用研究， 2006 年年 10 期期SWEBOK詳細(xì)結(jié)構(gòu)（詳細(xì)結(jié)構(gòu)（1）軟件工程與其他學(xué)科的關(guān)系軟件工程與其他學(xué)科的關(guān)系 1 、軟件工程是計(jì)算學(xué)科、軟件工程是計(jì)算學(xué)科 9 個(gè)領(lǐng)域之一個(gè)領(lǐng)域之一 算法和數(shù)據(jù)結(jié)構(gòu)算法和數(shù)據(jù)結(jié)構(gòu)

6、 計(jì)算機(jī)系統(tǒng)結(jié)構(gòu)計(jì)算機(jī)系統(tǒng)結(jié)構(gòu) 人工智能和機(jī)器人學(xué)人工智能和機(jī)器人學(xué) 數(shù)據(jù)庫(kù)和信息檢索數(shù)據(jù)庫(kù)和信息檢索 人一機(jī)交互人一機(jī)交互 操作系統(tǒng)操作系統(tǒng) 程序設(shè)計(jì)語(yǔ)言程序設(shè)計(jì)語(yǔ)言 軟件方法學(xué)和軟件工程軟件方法學(xué)和軟件工程 數(shù)字和符號(hào)計(jì)算數(shù)字和符號(hào)計(jì)算2 、8 個(gè)相關(guān)學(xué)科知識(shí)域個(gè)相關(guān)學(xué)科知識(shí)域計(jì)算機(jī)工程計(jì)算機(jī)工程 計(jì)算機(jī)科學(xué)計(jì)算機(jī)科學(xué)數(shù)學(xué)數(shù)學(xué) 管理學(xué)管理學(xué)項(xiàng)目管理項(xiàng)目管理 質(zhì)量管理質(zhì)量管理系統(tǒng)工程學(xué)系統(tǒng)工程學(xué) 軟件人類工程學(xué)軟件人類工程學(xué) 其中：計(jì)算機(jī)科學(xué)、數(shù)學(xué)是基礎(chǔ)工程學(xué)科、其中：計(jì)算機(jī)科學(xué)、數(shù)學(xué)是基礎(chǔ)工程學(xué)科、管理學(xué)科也非常重要管理學(xué)科也非常重要軟件工程是一門什么樣的學(xué)科？軟件工程是一門什么樣的學(xué)科？

7、 是是指導(dǎo)計(jì)算機(jī)軟件開(kāi)發(fā)與維護(hù)指導(dǎo)計(jì)算機(jī)軟件開(kāi)發(fā)與維護(hù)的一門的一門工程工程學(xué)科。學(xué)科。 工程：將科學(xué)及數(shù)學(xué)原理運(yùn)用于實(shí)際用途的應(yīng)用手段，如工程：將科學(xué)及數(shù)學(xué)原理運(yùn)用于實(shí)際用途的應(yīng)用手段，如：設(shè)計(jì)、制造、機(jī)器操縱、構(gòu)架等。：設(shè)計(jì)、制造、機(jī)器操縱、構(gòu)架等。 典型的傳統(tǒng)工程：建筑工程、機(jī)械工程、電力工程等。典型的傳統(tǒng)工程：建筑工程、機(jī)械工程、電力工程等。 概括的說(shuō)，軟件工程即用工程、科學(xué)和數(shù)概括的說(shuō)，軟件工程即用工程、科學(xué)和數(shù)學(xué)的原則和方法研制、維護(hù)計(jì)算機(jī)軟件的學(xué)的原則和方法研制、維護(hù)計(jì)算機(jī)軟件的有關(guān)技術(shù)及方法，其優(yōu)點(diǎn)是以較小的代價(jià)有關(guān)技術(shù)及方法，其優(yōu)點(diǎn)是以較小的代價(jià)開(kāi)發(fā)高質(zhì)量的軟件并有效地維護(hù)它。

8、開(kāi)發(fā)高質(zhì)量的軟件并有效地維護(hù)它。二、學(xué)習(xí)目標(biāo)二、學(xué)習(xí)目標(biāo)(1) 掌握軟件工程的基礎(chǔ)知識(shí)和理論，對(duì)軟件掌握軟件工程的基礎(chǔ)知識(shí)和理論，對(duì)軟件工程學(xué)有一個(gè)全貌的了解；工程學(xué)有一個(gè)全貌的了解； 熟悉軟件項(xiàng)目開(kāi)發(fā)和維護(hù)的一般過(guò)程；熟悉軟件項(xiàng)目開(kāi)發(fā)和維護(hù)的一般過(guò)程； 熟練掌握軟件需求分析、設(shè)計(jì)、編碼和測(cè)熟練掌握軟件需求分析、設(shè)計(jì)、編碼和測(cè)試等階段的主要思想和技術(shù)方法；試等階段的主要思想和技術(shù)方法；二、學(xué)習(xí)目標(biāo)二、學(xué)習(xí)目標(biāo)(2) 通過(guò)學(xué)習(xí)及課程設(shè)計(jì)，真正運(yùn)用和體會(huì)軟通過(guò)學(xué)習(xí)及課程設(shè)計(jì)，真正運(yùn)用和體會(huì)軟件工程的思想方法，轉(zhuǎn)變對(duì)軟件開(kāi)發(fā)的認(rèn)件工程的思想方法，轉(zhuǎn)變對(duì)軟件開(kāi)發(fā)的認(rèn)識(shí)：從個(gè)人的單純編程活動(dòng)轉(zhuǎn)移到進(jìn)行系

9、識(shí)：從個(gè)人的單純編程活動(dòng)轉(zhuǎn)移到進(jìn)行系統(tǒng)分析與設(shè)計(jì)方面上來(lái)統(tǒng)分析與設(shè)計(jì)方面上來(lái) 轉(zhuǎn)變思維定式：轉(zhuǎn)變思維定式： 程序員程序員 系統(tǒng)工程師（系統(tǒng)分析員）系統(tǒng)工程師（系統(tǒng)分析員） 1.鄭人杰，殷人昆，陶永雷著，鄭人杰，殷人昆，陶永雷著，實(shí)用軟件工程實(shí)用軟件工程，清華大學(xué)出版社，清華大學(xué)出版社2.Roger S. Pressman， Software Engineering: A Practitioners Approach, Fourth Edition, McGraw-HillRoger S. Pressman著，著，軟件工程軟件工程-實(shí)踐者的研究方法實(shí)踐者的研究方法，機(jī)械工業(yè)出版，機(jī)械工業(yè)出版社社

10、3.Eric J. Braude著，著，Software Engineering An Object-Oriented Perspective面向?qū)ο蟮能浖こ蹋娮庸I(yè)出版社（影印版）面向?qū)ο蟮能浖こ?，電子工業(yè)出版社（影印版）4.軟件軟件工程導(dǎo)論工程導(dǎo)論( (第五版第五版) )張海藩編著張海藩編著 , ,清華大學(xué)出版社清華大學(xué)出版社三、部分參考資料三、部分參考資料14 四、課程特點(diǎn)和學(xué)習(xí)的注意事項(xiàng)四、課程特點(diǎn)和學(xué)習(xí)的注意事項(xiàng) 1 、知易行難、知易行難 要將理論知識(shí)與實(shí)踐運(yùn)用結(jié)合，進(jìn)行對(duì)照，以要將理論知識(shí)與實(shí)踐運(yùn)用結(jié)合，進(jìn)行對(duì)照，以加深理解和掌握。加深理解和掌握。 2 、內(nèi)容紛雜、內(nèi)容紛雜

11、軟件工程涉及計(jì)算機(jī)科學(xué)、數(shù)學(xué)、工程科學(xué)和軟件工程涉及計(jì)算機(jī)科學(xué)、數(shù)學(xué)、工程科學(xué)和管理科學(xué)等多個(gè)領(lǐng)域。其中：管理科學(xué)等多個(gè)領(lǐng)域。其中： 計(jì)算機(jī)科學(xué)和數(shù)學(xué)用于構(gòu)造模型與算法；計(jì)算機(jī)科學(xué)和數(shù)學(xué)用于構(gòu)造模型與算法； 工程科學(xué)用于制定規(guī)范、設(shè)計(jì)范型、評(píng)估成本及確定工程科學(xué)用于制定規(guī)范、設(shè)計(jì)范型、評(píng)估成本及確定權(quán)衡權(quán)衡 管理科學(xué)用于計(jì)劃、資源、質(zhì)量和成本的管理。管理科學(xué)用于計(jì)劃、資源、質(zhì)量和成本的管理。Agenda 1.1 What is Software Engineering? 1.2 How Successful Have We Been? 1.3 What Is Good Software? 1.

12、4 Who Does Software Engineering? 1.5 A System Approach 1.6 An Engineering Approach 1.7 Members of the Development Team 1.8 How Has Software Engineering Changed?Objectives What we mean by software engineering Software engineerings track record What we mean by good software Why a system approach is im

13、portant How software engineering has changed since 1970s1.1 What is Software EngineeringSolving Problems Software products are large and complex Development requires analysis and synthesis Analysis: decompose a large problem into smaller, understandable pieces abstraction is the key Synthesis: build

14、 (compose) a software from smaller building blocks composition is challenging1.1 What is Software EngineeringSolving Problems The analysis process1.1 What is Software EngineeringSolving Problems The synthesis process1.1 What is Software EngineeringSolving Problems Method: refers to a formal procedur

15、e; a formal “recipe” for accomplishing a goal that is typically independent of the tools used Tool: an instrument or automated system for accomplishing something in a better way Procedure: a combination of tools and techniques to produce a product Paradigm: philosophy or approach for building a prod

16、uct (e.g., OO vs structured approaches)1.1 What is Software EngineeringWhere Does the Software Engineer Fit In? Computer science: focusing on computer hardware, compilers, operating systems, and programming languages Software engineering: a discipline that uses computer and software technologies as

17、a problem-solving tools1.1 What is Software EngineeringWhere Does the Software Engineer Fit In? Relationship between computer science and software engineering1.2 How Successful Have We Been? Perform tasks more quickly and effectively Word processing, spreadsheets, e-mail Support advances in medicine

18、, agriculture, transportation, multimedia education, and most other industries Many good stories However, software is not without problems1.2 How Successful Have We Been?Sidebar 1.1 Terminology for Describing Bugs A fault: occurs when a human makes a mistake, called an error, in performing some soft

19、ware activities A failure: is a departure from the systems required behaviour1.2 How Successful Have We Been?Examples of Software Failure IRS hired Sperry Corporation to build an automated federal income tax form processing process An extra $90 M was needed to enhance the original $103M product IRS

20、lost $40.2 M on interests and $22.3 M in overtime wages because refunds were not returned on time Malfunctioning code in Therac-25 killed several people Reliability constraints have caused cancellation of many safety critical systems Safety-critical: something whose failure poses a threat to life or

21、 health1.3 What Is Good Software?Sidebar 1.2 Perspective on Quality The transcendental view: quality is something we can recognize but not define The user view: quality is fitness for purpose The manufacturing view: quality is conformance to specification The product view: quality tied to inherent p

22、roduct characteristics The value-based view: depends on the amount the customers is willing to pay for it1.3 What is Good Software? Good software engineering must always include a strategy for producing quality software Three ways of considering quality The quality of the product The quality of the

23、process The quality of the product in the context of the business environment1.3 What Is Good Software?The Quality of the Product Users judge external characteristics (e.g., correct functionality, number of failures, type of failures) Designers and maintainers judge internal characteristics (e.g., t

24、ypes of faults) Thus different stakeholders may have different criteria Need quality models to relate the users external view to developers internal view1.3 What Is Good Software?The Quality of the Product (continued) McCalls quality model1.3 What Is Good Software?The Quality of the Process Quality

25、of the development and maintenance process is as important as the product quality The development process needs to be modeled Modeling will address questions such as Where to find a particular kind of fault How to find faults early How to build in fault tolerance What are alternative activities1.3 W

26、hat Is Good Software?The Quality of the Process (continued) Models for process improvement SEIs Capability Maturity Model (CMM) ISO 9000 Software Process Improvement and Capability determination (SPICE)1.3 What Is Good Software?The Quality in the Context of the Business Environment Business value is

27、 as important as technical value Business value (in relationship to technical value) must be quantified A common approach: return on investment (ROI) ROI is interpreted in different terms: reducing costs, predicting savings, improving productivity, and costs (efforts and resources)1.4 Who Does Softw

28、are Engineering? Customer: the company, organization, or person who pays for the software system Developer: the company, organization, or person who is building the software system User: the person or people who will actually use the system1.4 Who Does Software Engineering? (continued) Participants

29、(stakeholders) in a software development project COTS Subcontractor turnkey system: a complete system of hardware and software designed for a specific use and delivered to the customer in a ready-to-run condition.1.5 System Approach Hardware, software, interaction with people Identify activities and

30、 objects Define the system boundary Consider nested systems, systems interrelationship1.5 System ApproachThe Element of a System Activities and objects An activity is an event initiated by a trigger Objects or entities are the elements involved in the activities Relationships and the system boundari

31、es A relationship defines the interaction among entities and activities System boundaries determine the origin of input and destinations of the output1.5 System ApproachThe Element of a System (continued) Example of systems: a human respiratory system1.5 System ApproachThe Element of a System (conti

32、nued) A computer system must also be clearly described: System definition of a paycheck production1.5 System ApproachInterrelated Systems Some systems are dependent to other systems The interdependencies may be complex It is possible for one system to exist inside another system If the boundary defi

33、nitions are detailed, building a larger system from the smaller ones is relatively easy1.5 System ApproachInterrelated Systems (continued) A layered system1.6 Engineering ApproachBuilding a System Requirement analysis and definition System design Program design Writing the programs Unit testing Inte

34、gration testing System testing System delivery Maintenance1.7 Members of the Development Team Requirement analysts: work with the customers to identify and document the requirements Designers: generate a system-level description of what the system is supposed to do Programmers: write lines of code t

35、o implement the design Testers: catch faults Trainers: show users how to use the system Maintenance team: fix faults that show up later Librarians: prepare and store documents such as software requirements Configuration management team: maintain correspondence among various artifacts1.7 Members of t

36、he Development Team (continued) Typical roles played by the members of a development team1.8 How Has Software Engineering Changed?The Nature of the Change Before 1970s Single processors: mainframes Designed in one of two ways as a transformation: input was converted to output as a transaction: input

37、 determined which function should be performed After 1970s Run on multiple systems Perform multi-functions1.8 How Has SE Changed?Wassermans Seven Key FactorsCritically of time-to-market Shifts in the economics of computingAvailability of powerful desktop computingExtensive local- and wide-area netwo

38、rkingAvailability and adoption of object-oriented technologyGraphical user interfaces Unpredictability of the waterfall model of software development1.8 How Has SE Changed?Wassermans Seven Key Factors (continued)1.8 How Has SE Changed?Wassermans Discipline of Software Engineering Abstractions Analys

39、is and design methods and notations User interface prototyping Software architecture Software process Reuse Measurement Tools and integrated environments1.8 How Has SE Changed?Abstraction A description of the problem at some level of generalization Hide details1.8 How Has SE Changed?Analysis and Des

40、ign Methods and Notations Provide documentation Facilitate communication Offer multiple views Unify different views1.8 How Has SE Changed?User Interface Prototyping Prototyping: building a small version of a system Help users identify key requirements of a system Demonstrate feasibility Develop good

41、 user interface1.8 How Has SE Changed?Software Architecture A systems architecture describes the system in terms of a set of architectural units and relationships between these units Architectural decomposition techniques Modular decomposition Data-oriented decomposition Event-driven decomposition O

42、utside-in-design decomposition Object-oriented decomposition1.8 How Has SE Changed?Software Process Many variations Different types of software need different processes Enterprise-wide applications need a great deal of control Departmental applications can take advantage of rapid development1.8 How

43、Has SE Changed?Software Process (continued) Pictorial representation of differences in development processes1.8 How Has SE Changed?Software Reuse Commonalities between applications may allow reusing artifacts from previous developments Improve productivity Reduce costs Potential concerns It may be f

44、aster to build a smaller application than searching for reusable components Generalized components take more time to build Must clarify who will be responsible for maintaining reusable components Generality vs specificity: always a conflict1.8 How Has SE Changed?Measurement Objective: describe quali

45、ty goals in a quantitative way1.8 How Has SE Changed?Tools and Integrated Environments Platform integration (on heterogeneous networks) Presentation integration (commonality of user interface) Process integration (linking tools and the development process) Data integration (to share common data) Control in