Chapter-1_Why-Software-Engineering

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

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

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

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

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

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

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

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

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

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

11、軟件工程涉及計算機(jī)科學(xué)、數(shù)學(xué)、工程科學(xué)和軟件工程涉及計算機(jī)科學(xué)、數(shù)學(xué)、工程科學(xué)和管理科學(xué)等多個領(lǐng)域。其中：管理科學(xué)等多個領(lǐng)域。其中： 計算機(jī)科學(xué)和數(shù)學(xué)用于構(gòu)造模型與算法；計算機(jī)科學(xué)和數(shù)學(xué)用于構(gòu)造模型與算法； 工程科學(xué)用于制定規(guī)范、設(shè)計范型、評估成本及確定工程科學(xué)用于制定規(guī)范、設(shè)計范型、評估成本及確定權(quán)衡權(quán)衡 管理科學(xué)用于計劃、資源、質(zhì)量和成本的管理。管理科學(xué)用于計劃、資源、質(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