软件工程双语 讲义 大纲模式
《软件工程（双语）》参考教材：《Software engineering》8th Edition Ian Sommervile，Pearson Education, 机械工业出版社，2006参考书目:1、Software Engineering Theory and Practice(Second Edition影印版), Shari Lawrence Pfleeger，Pearson Education, 20012、《软件工程》第四版张海藩清华大学出版社，20073、软件工程，王忠群主编中国科学技术大学出版社 2009-11-14、Software engineering : a practitioner's approach / Roger S. Pressman. 6th ed. Pressman, Roger S. China Machine Press, 2008说明:斜体部分是可选讲授内容, 带星号的习题为可选。
Chapter 1(1) Introduction●Getting started with software engineering1.1Objectives1.To introduce software engineering and to explain its importance2.To set out the answers to key questions about software engineering3.To introduce ethical and professional issues and to explain why they are of concern tosoftware engineers1.2Topics covered1.FAQs about software engineering2.Professional and ethical responsibility1.3Importance of Software engineering●The economies of ALL developed nations are dependent on software.●More and more systems are software controlled●Expenditure on software represents a significant fraction of GNP (gross National product) inall developed countries.( GNP与GDP的关系是：GNP等于GDP加上本国投在国外的资本和劳务的收入再减去外国投在本国的资本和劳务的收入。
)●Software costs often dominate computer system costs. The costs of software on a PC areoften greater than the hardware cost.●Software engineering is concerned with cost-effective software development1.4FAQs about software engineeringA.1What is software?Computer programs and associated documentationB.1Software products may be developed for a particular customer or may bedeveloped for a general marketB.2Software products may be●Generic - developed to be sold to a range of different customers●Bespoke (custom) - developed for a single customer according to their specificationA.2What is software engineering?●Software engineering is an engineering discipline which is concerned with all aspects ofsoftware production●Software engineers should adopt a systematic and organised approach to their work and useappropriate tools and techniques depending on the problem to be solved, the development constraints and the resources availableA.3What is the difference between software engineering and computer science?●Computer science is concerned with theory and fundamentals; software engineering isconcerned with the practicalities of developing and delivering useful software●Computer science theories are currently insufficient to act as a complete underpinning forsoftware engineeringA.4What is the difference between software engineering and system engineering?●System engineering is concerned with all aspects of computer-based systems developmentincluding hardware, software and process engineering. Software engineering is part of this processA.5What is a software process?A set of activities whose goal is the development or evolution of softwareB.1Generic activities in all software processes are:●Specification - what the system should do and its development constraints●Development - production of the software system●Validation - checking that the software is what the customer wants●Evolution - changing the software in response to changing demandsA.6What is a software process model?A simplified representation of a software process, presented from a specific perspectiveB.1Examples of process perspectives are●Workflow perspective - sequence of activities;●Data-flow perspective - information flow;●Role/action perspective - who does what.B.2Generic process models:●Waterfall●Evolutionary development●Formal transformation●Integration from reusable componentsA.7What are the costs of software engineering?●Roughly 60% of costs are development costs, 40% are testing costs. For custom software,evolution costs often exceed development costs●Costs vary depending on the type of system being developed and the requirements of systemattributes such as performance and system reliability●Distribution of costs depends on the development model that is usedA.8What are software engineering methods?Structured approaches to software development which include system models, notations, rules, design advice and process guidance.B.1Model descriptionsDescriptions of graphical models which should be produced;B.2RulesConstraints applied to system models;B.3RecommendationsAdvice on good design practice;B.4Process guidanceWhat activities to follow.A.9What is CASE (Computer-Aided Software Engineering)Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method supportB.1Upper-CASETools to support the early process activities of requirements and designB.2Lower-CASETools to support later activities such as programming, debugging and testingA.10What are the attributes of good software?The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usableB.1MaintainabilitySoftware must evolve to meet changing needsB.2DependabilitySoftware must be trustworthyB.3EfficiencySoftware should not make wasteful use of system resourcesB.4AcceptabilitySoftware must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.A.11What are the key challenges facing software engineering?B.1Heterogeneity•Developing techniques for building software that can cope with heterogeneous platforms and execution environments;B.2Delivery•Developing techniques that lead to faster delivery of software;B.3Trust•Developing techniques that demonstrate that software can be trusted by its users1.5Professional and ethical responsibility1.5.1Concept●Software engineering involves wider responsibilities than simply the application of technicalskills●Software engineers must behave in an honest and ethically responsible way if they are to berespected as professionals●Ethical behaviour is more than simply upholding the law.1.5.2Issues of professional responsibilityA.1ConfidentialityEngineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.A.2CompetenceEngineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence.A.3Intellectual property rightsEngineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.A.4Computer misuseSoftwa re engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).1.5.3ACM/IEEE Code of Ethics(Association for Computing Machinery/Institute of Electrical and Electronics Engineers)A.1Concept●The professional societies in the US have cooperated to produce a code of ethical practice.●Members of these organisations sign up to the code of practice when they join.●The Code contains eight Principles related to the behaviour of and decisions made byprofessional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.A.2Code of ethics - principlesC.1PUBLICSoftware engineers shall act consistently with the public interest.C.2CLIENT AND EMPLOYERSoftware engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.C.3PRODUCTSoftware engineers shall ensure that their products and related modifications meet the highest professional standards possible.C.4JUDGMENTSoftware engineers shall maintain integrity and independence in their professional judgment.C.5MANAGEMENTSoftware engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.C.6PROFESSIONSoftware engineers shall advance the integrity and reputation of the profession consistent with the public interest.C.7COLLEAGUESSoftware engineers shall be fair to and supportive of their colleagues.C.8SELFSoftware engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.1.5.4Ethical dilemmas●Disagreement in principle with the policies of senior management●Your employer acts in an unethical way and releases a safety-critical system without finishingthe testing of the system●Participation in the development of military weapons systems or nuclear systems1.6Key points1.Software engineering is an engineering discipline which is concerned with all aspects ofsoftware production.2.Software products consist of developed programs and associated documentation. Essentialproduct attributes are maintainability, dependability, efficiency and usability.3.The software process consists of activities which are involved in developing softwareproducts. Basic activities are software specification, development, validation and evolution.4.Methods are organised ways of producing software. They include suggestions for the processto be followed, the notations to be used, rules governing the system descriptions which are produced and design guidelines.5.CASE tools are software systems which are designed to support routine activities in thesoftware process such as editing design diagrams, checking diagram consistency and keeping track of program tests which have been run.6.Software engineers have responsibilities to the engineering profession and society. Theyshould not simply be concerned with technical issues.7.Professional societies publish codes of conduct which set out the standards of behaviourexpected of their members.1.7E xcercises(Homework): P18-191.3, 1.4, *1.7Chapter 2(4) Software processesCoherent sets of activities for specifying, designing, implementing and testing software systems 2.1Objectives1.To introduce software process models2.To describe a number of different process models and when they may be used3.To describe outline process models for requirements engineering, software development,testing and evolution4.To introduce CASE technology to support software process activities2.2Topics covered1.Software process models2.Process iteration3.Process activitiesputer-aided software engineering2.3The software processA.1 A structured set of activities required to develop a software systemB.1Specification;B.2Design;B.3Validation;B.4EvolutionA.2 A software process model is an abstract representation of a process. It presentsa description of a process from some particular perspective2.4Generic software process models2.4.1IntroductionA.1The waterfall modelSeparate and distinct phases of specification and developmentA.2Evolutionary developmentSpecification and development are interleavedA.3Component-based software engineeringThe system is assembled from existing componentsA.4Formal systems developmentA mathematical system model is formally transformed to an implementation2.4.2Waterfall modelB.1Waterfall model phases1.Requirements analysis and definition2.System and software design3.Implementation and unit testing4.Integration and system testing5.Operation and maintenanceWaterfall modelB.2●Inflexible partitioning of the project into distinct stages makes it difficult to respond tochanging customer requirements.●Therefore, this model is only appropriate when the requirements are well-understood andchanges will be fairly limited during the design process.●The waterfall model is mostly used for large systems engineering projects2.4.3Evolutionary developmentB.1Exploratory developmentObjective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirementsB.2Throw-away prototypingObjective is to understand the system requirements. Should start with poorly understood requirementsEvolutionary developmentConcurren tB.3●Lack of process visibility●Systems are often poorly structured●Special skills (e.g. in languages for rapid prototyping) may be requiredB.4Applicability●For small or medium-size interactive systems●For parts of large systems (e.g. the user interface)●For short-lifetime systems2.4.4Formal systems developmentB.1Concept●Based on the transformation of a mathematical specification through different representationsto an executable program●Transformations are ‘correctness-preserving’ so it is straightforward to show that the programconforms to its specification●Embodied in the ‘Cleanroom’ approach to software developmentFormal transformationsT1T2T3T4Proofs of transformation correctnessB.2Problems●Need for specialised skills and training to apply the technique●Difficult to formally specify some aspects of the system such as the user interfaceB.3ApplicabilityCritical systems especially those where a safety or security case must be made before the system is put into operation2.4.5Reuse-oriented developmentB.1Based on systematic reuse where systems are integrated from existingcomponents or COTS (Commercial-off-the-shelf) systemsB.2Intermediate process stages●Component analysis●Requirements modification●System design with reuse●Development and integrationemerged.2.5Process iteration2.5.1ConceptA.1System requirements ALWAYS evolve in the course of a project so processiteration where earlier stages are reworked is always part of the process for large systemsA.2Iteration can be applied to any of the generic process modelsA.3Two (related) approaches●Incremental development●Spiral development2.5.2Incremental developmentA.1Concept●Rather than deliver the system as a single delivery, the development and delivery is brokendown into increments with each increment delivering part of the required functionality●User requirements are prioritised and the highest priority requirements are included in earlyincrements●Once the development of an increment is started, the requirements are frozen thoughrequirements for later increments can continue to evolveA.2Incremental development advantages●Customer value can be delivered with each increment so system functionality is availableearlier.●Early increments act as a prototype to help elicit requirements for later increments.●Lower risk of overall project failure.●The highest priority system services tend to receive the most testing.2.5.3Spiral developmentA.1Concept●Process is represented as a spiral rather than as a sequence of activities with backtracking●Each loop in the spiral represents a phase in the process.●No fixed phases such as specification or design - loops in the spiral are chosen depending onwhat is required●Risks are explicitly assessed and resolved throughout the processSpiral model of the software processA.2Spiral model sectorsB.1Objective settingSpecific objectives for the phase are identifiedB.2Risk assessment and reductionRisks are assessed and activities put in place to reduce the key risksB.3Development and validationA development model for the system is chosen which can be any of the generic modelsB.4PlanningThe project is reviewed and the next phase of the spiral is planned2.6Process activites2.6.1Software specificationA.1ConceptThe process of establishing what services are required and the constraints on the system’s operation and developmentA.2Requirements engineering process1.Feasibility study2.Requirements elicitation and analysis3.Requirements specification4.Requirements validationThe requirements engineering processA.1The process of converting the system specification into an executable system A.2Software designDesign a software structure that realises the specificationA.3ImplementationTranslate this structure into an executable programA.4The activities of design and implementation are closely related and may beinter-leaved2.6.3Software validationA.1Concept●Verification and validation is intended to show that a system conforms to its specification andmeets the requirements of the system customer●Involves checking and review processes and system testing●System testing involves executing the system with test cases that are derived from thespecification of the real data to be processed by the systemThe testing processComponent testing Integration testing UsertestingA.2Testing stagesB.1Component or unit testing●Individual components are tested independently;●Components may be functions or objects or coherent groupings of these entities.B.2System testingTesting of the system as a whole. Testing of emergent properties is particularly important.B.3Acceptance testingTesting with customer data to check that the system meets the customer’s needs2.6.4Software evolution●Software is inherently flexible and can change.●As requirements change through changing business circumstances, the software that supportsthe business must also evolve and change●Although there has been a demarcation between development and evolution (maintenance)this is increasingly irrelevant as fewer and fewer systems are completely new2.7Automated process support (CASE)A.1ConceptB.1Computer-aided software engineering (CASE) is software to supportsoftware development and evolution processesB.2Activity automation●Graphical editors for system model development●Data dictionary to manage design entities●Graphical UI builder for user interface construction●Debuggers to support program fault finding●Automated translators to generate new versions of a programA.2Case technologyB.1Case technology has led to significant improvements in the software processthough not the order of magnitude improvements that were once predicted●Software engineering requires creative thought - this is not readily automatable●Software engineering is a team activity and, for large projects, much time is spent in teaminteractions. CASE technology does not really support theseA.3CASE classificationB.1ConceptClassification helps us understand the different types of CASE tools and their support for process activitiesC.1Functional perspectiveTools are classified according to their specific function.C.2Process perspectiveTools are classified according to process activities that are supported.C.3Integration perspectiveTools are classified according to their organisation into integrated units.B.2Functional perspectiveTools are classified according to their specific functionFunctional tool classificationB.3Process perspectiveTools are classified according to process activities that are supportedActivity-based classificationB.4Integration perspectiveTools are classified according to their organisation into integrated unitsC.1CASE integrationD.1ToolsSupport individual process tasks such as design consistency checking, text editing, etc.D.2WorkbenchesSupport a process phase such as specification or design, Normally include a number of integrated toolsD.3EnvironmentsSupport all or a substantial part of an entire software process. Normally include several integrated workbenchesTools, workbenches, environments2.8Key points1.Software processes are the activities involved in producing and evolving a software system.They are represented in a software process model2.General activities are specification, design and implementation, validation and evolution3.Generic process models describe the organisation of software processes4.Iterative process models describe the software process as a cycle of activities5.Requirements engineering is the process of developing a software specification6.Design and implementation processes transform the specification to an executable program7.Validation involves checking that the system meets to its specification and user needs8.Evolution is concerned with modifying the system after it is in use9.CASE technology supports software process activities2.9Excercises(Homework): P914.1, *4.3, *4.12Chapter 3(6) Software Requirements 3.1Objectives1.To introduce the concepts of user and system requirements2.To describe functional and non-functional requirements3.To explain how software requirements may be organised in a requirements document3.2Topics covered1.Functional and non-functional requirementser requirements3.System requirements4.Interface specification5.The software requirements document3.3Software Requirements3.3.1What is a requirement?B.1It may range from a high-level abstract statement of a service or of a systemconstraint to a detailed mathematical functional specificationB.2This is inevitable as requirements may serve a dual function●May be the basis for a bid for a contract - therefore must be open to interpretation●May be the basis for the contract itself - therefore must be defined in detail●Both these statements may be called requirements3.3.2Requirements engineering●The process of establishing the services that the customer requires from a system and theconstraints under which it operates and is developed●The requirements themselves are the descriptions of the system services and constraints thatare generated during the requirements engineering process3.3.3Types of requirementB.1User requirementsStatements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customersB.2System requirementsA structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor3.4Functional and non-functional requirementsA.1Functional requirementsStatements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.B.1Examples of functional requirements●The user shall be able to search either all of the initial set of databases or select a subset fromit.●The system shall provide appropriate viewers for the user to read documents in the documentstore.●Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be ableto copy to t he account’s permanent storage area.A.2Non-functional requirementsconstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.B.1Non-functional classificationsC.1Product requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.C.2Organisational requirementsRequirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.C.3External requirementsRequirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.B.2Non-functional requirements examplesC.1Product requirement4.C.8 It shall be possible for all necessary communication between the APSE(Ada Programming Support Environment) and the user to be expressed in the standard Ada character setC.2Organisational requirement9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95C.3External requirement7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the systemB.3Requirements measuresExample: Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.A.3Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domainB.1examplesC.1Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.C.2The deceleration of the train shall be computed as:Dtrain = Dcontrol + Dgradientwhere Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.3.5M ethords:3.5.1Natural language specificationsA.1Examples of functional requirementsB.1The user shall be able to search either all of the initial set of databases orselect a subset from it.B.2The system shall provide appropriate viewers for the user to read documentsin the document store.B.3Every order shall be allocated a unique identifier (ORDER_ID) which theuser shall b e able to copy to the account’s permanent storage area.A.2Problems with NL specificationB.1AmbiguityThe readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult.B.2Over-flexibilityThe same thing may be said in a number of different ways in the specification.B.3Lack of modularisationNL structures are inadequate to structure system requirements.3.5.2Structured language specificationsDo CaseCase1 Lamp=greenkeep going;Case2 Lamp=redstop;Case3 Lamp=yellowcalfullly keep going;otherwisetake action upon yourself;End Case3.5.3Form-based specificationsForm-based node specificationECLIP SE/W orkstati on/Tool s/DE/FS/3.5.1Function Add nodeDescripti on Adds a node to an exi st ing design. The user sel ects t he type of node, and it s posi ti on. When added to the design, the node becomesthe current select ion. The user chooses the node posi ti on by movi ng t he cursor t o the area where t he node is added.Inputs Node type, Node posit ion, Design ident if i er.Source Node type and Node posit ion are i nput by the user, Desi gn i denti f ier from the database. Outputs Design ident if i er.Desti nati on The design database. The design is committ ed t o the database on compl et ion of the operati on.Requires Design graph rooted at input design ident if i er.Pre-conditi on The design is open and displ ayed on the user's screen.Post-condi tion The design is unchanged apart f rom t he addit ion of a node of the specified t ypeat t he given posi tion.Side-ef fects NoneDef init ion: ECLIPSE/W orkstati on/Tools/DE/RD/3.5.13.5.4Graphical models●Graphical models are most useful when you need to show how state changes or where youneed to describe a sequence of actions.●Different graphical models are explained in Chapter 8.3.5.5Interface specificationA.1ConceptB.1Most systems must operate with other systems and the operating interfacesmust be specified as part of the requirements.B.2Three types of interface may have to be defined●Procedural interfaces;●Data structures that are exchanged;●Data representations.B.3Formal notations are an effective technique for interface specification.A.2PDL interface description (Program description language)。
软件工程(9v)(30+10)双语 讲义 大纲模式
《软件工程（双语）》1.1参考教材：《Software engineering》9th Edition Ian Sommervile，Pearson Education, 机械工业出版社，20111.2参考书目:1、Software Engineering Theory and Practice(Second Edition影印版), Shari Lawrence Pfleeger，Pearson Education, 20012、《软件工程》第四版张海藩清华大学出版社，20073、软件工程，王忠群主编中国科学技术大学出版社 2009-11-14、Software engineering : a practitioner's approach / Roger S. Pressman. 6th ed. Pressman, Roger S. China Machine Press, 20081.3说明:斜体部分是可选讲授内容, 带星号的习题为可选。
1.4课程地位1.5双语背景1.6教材特点1.7联系方式Chapter 1(1) Introduction●Getting started with software engineering1.1Topics coveredA.1Professional software developmentWhat is meant by software engineeringA.2Software engineering ethicsA brief introduction to ethical issues that affect software engineering.1.2Importance of Software engineering●The economies of ALL developed nations are dependent on software.●More and more systems are software controlled●Expenditure on software represents a significant fraction of GNP (gross National product) inall developed countries.( GNP与GDP的关系是：GNP等于GDP加上本国投在国外的资本和劳务的收入再减去外国投在本国的资本和劳务的收入。
软件工程大纲
《软件工程》教学大纲英文名称：Software Engineering学分：2.5学分学时：40学时先修课程：操作系统、数据结构、数据库原理、面向对象的程序设计教学对象：计算机科学与技术专业本科生教学目的：本课程是计算机科学与技术专业本科生的专业必修课。
通过本课程的学习，使学生能够掌握软件工程的基本理论、技术和方法，并能在今后的软件活动中自觉、科学、合理地运用这些知识。
教学要求：本课程采用双语教学，要求学生熟悉软件工程活动内容；掌握软件过程活动中系统建模方法，掌握软件的分析、设计、测试的主要方法和技术；了解软件计划、管理、维护等内容；熟悉软件工程领域的英文术语表示。
教学内容：第1章软件工程和软件过程（4学时）1．软件工程概念2．软件过程和过程模型3．自动过程支持基本要求：了解软件工程的基本概念，掌握软件过程活动和过程模型，了解CASE。
重点：软件工程、软件过程活动内容、典型的软件过程模型等概念。
难点：软件过程模型第2章软件需求（4学时）1．功能和非功能性需求2．用户需求3．系统需求4．软件需求文档基本要求：理解需求定义的具体内容；掌握需求的不同类型和定义方法；了解需求文档的形式和内容；掌握需求分析和导出方法；重点:功能和非功能性需求的内容，用户需求和系统需求的区别，需求分析和导出方法；难点:非功能性需求的理解，用户需求和系统需求的区别，需求分析和导出方法；。
第3章系统模型（4学时）1．系统建模概念2．行为模型3．数据模型4．对象模型基本要求：了解建模和模型的分类，初步了解UML，掌握典型的系统模型：Context 模型，数据流模型，状态机模型，E-R模型，继承模型，聚合模型，交互模型等，具有构建上述模型的能力。
重点：结构和行为模型的区分，模型的实质和建模方法难点：构建模型第4章体系结构设计（6学时）1．构建系统结构2．系统控制模型3．模块分解4．特定领域系统体系结构基本要求：了解软件体系结构是系统的基本框架，掌握体系结构设计中应产生系统结构模型，控制模型和模块分解模型。
软件工程(双语)3.1
SC图中模块调用关系的表示
数据字典（DD）
对软件中的每个数据规定一个定义条目。
加工说明（PSPEC）
对数据流图中出现的每个加工/处理的功能描述 主要工具：结构化语言，判定树或判定表
1. 概述 --SD模型的组成与描述
•包含数据设计、体 系结构设计、接口 设计与过程设计。
•体系结构设计是用 来确定软件结构的， 其描述工具为结构 图，简称SC图。
结构化分析与设计最初系由结构化程序设计扩展而来
瀑布模型的首次实践 SA与SD的流程
结构化分析（工具：DFD、PSPEC） 分析模型（分层DFD图） + SRS
结构化设计（工具：SC图） 映射 初始设计模型（初始SC图） 初始设计模型（初始SC图） 优化 最终设计模型（最终SC图）
数据对象说明 E-R图 DD
加工说明 DFD图
STD图
控制说明 （CSPEC）
结构化分析模型的描述工具
数据流图（DFD）
指明数据在系统中移动时如何被变换，描述对数据流进行变 换的功能和子功能。
组成符号
圆框代表加工； 箭头代表数据的流向，数据名称总是标在箭头的边上； 方框表示数据的源点和终点； 双杠（或单杠）表示数据文件或数据库
第三章 结构化分析与设计
概述 结构化系统分析 结构化系统设计 模块化设计
1. 概述 --结构化分析与设计的由来
结构化分析与设计最初系由结构化程序设计扩展而来
瀑布模型的首次实践 SA与SD的流程
结构化分析（工具：DFD、PSPEC） 分析模型（分层DFD图） + SRS
基本任务与指导思想
结构化分析
建立分析模型 编写需求说明
软件工程(双语)7.1
弱耦合
非直接 耦合
模块1
模块2
数据耦合 模块3
特征耦合（参数表 传递数据结构）
模块4
公共耦合
Ａ
Ｌ
Ｂ
Ｃ
Ｎ
Ｄ
第7章 面向对象设计
软件设计概述 面向对象设计建模 系统架构设计 系统元素设计 面向对象设计示例
1. 软件设计概述
软件设计的概念
模块与构件 抽象与细化 信息隐藏 软件复用
软件设计的任务
把分析阶段产生的分析模型转换为用适当手段表示 的软件设计模型
软件设计一般都包括数据设计、体系结构设计、接 口设计和过程设计等
内聚
弱强１２３ Nhomakorabea４ ５ ６７
低内聚
中内聚
高内聚
内聚 cohesion
１.偶然性内聚 coincidental cohesion ２.逻辑性内聚 logical cohesion ３.时间性内聚 temporal cohesion ４.过程性内聚 procedural cohesion ５.通讯性内聚 communicational cohesion ６.顺序性内聚 sequential cohesion ７.功能性内聚 functional cohesion
C为问题的复杂度，E为解题需要的工作量
软 件
最小成本区
总成本
开
M
发
接口成本
工
作
量
模块成本
模块数
模块独立性（module independence）
内聚（cohesion）
模块内部各成分之间
耦合（coupling）
一个模块与其它模块之间
模块的独立性高
软件工程(双语)(最全)word资料
软件工程(双语)(最全)word资料软件工程（双语）Software Engineering课程编号：B0301101S学分： 3开课学院：计算机学院课内学时：48课程类别：专业基础课课程性质：必修一、课程的性质和目的Curriculum nature：The course is professional required course of Software Engineering Major.Object：The Software Engineering is the basis course of computer and related sciences. It is an engineering discipline where software engineers use methods and theory from computer science and apply it cost-effectively to solve difficult problems. This course presents a broad perspective on software engineering, such as software lifecycle, qualities of software, design, specification and verification of software, programming environments and tools, structural oriented programming and object oriented programming. Furthermore, the quality management, process improvement, software change, configuration management are also discussed.二、课程教学内容及基本要求（一）课程教学内容及知识模块顺序KNOWLEDGE UNIT 1: INTRO TO SOFTWARE ENGINEERING (2h)(1)Knowledge point 1 The Evolving Role of Software(2)Knowledge point 2 The Nature of Software(3)Knowledge point 3 Legacy SoftwareBasic requirement: Understand the basic conception of software engineering, master the Nature of software, master the definition of software engineering.KNOWLEDGE UNIT 2: A GENERIC VIEW OF PROCESS (4h)(1)Knowledge point 1 A Layered Technology(2)Knowledge point 2 A Process Framework(3)Knowledge point 3 The Capability Maturity Model IntegrationBasic requirement: Understand the conception of software processes, master the basic processes of software analyze,design, implement and test, understand the definition of CMMI.KNOWLEDGE UNIT 3: PROCESS MODELS (2h)(1)Knowledge point 1 Prescriptive Models(2)Knowledge point 2 Waterfall Model(3)Knowledge point 3 Incremental Process, Evolutionary Process(4)Knowledge point 4 Unified Process, Agile ProcessBasic requirement: Understand the various process models, such as waterfall model, Unified Process and Agile Process.KNOWLEDGE UNIT 4: REQUIREMENTS ENGINEERING (4h)(1)Knowledge point 1 Bridge to Design and Construction(2)Knowledge point 2 Requirements Engineering Tasks(3)Knowledge point 3 Initiating the Requirements Engineering Process(4)Knowledge point 4 Eliciting RequirementsBasic requirement: Master the steps of requirements engineering process, understand the role of abridge to design.KNOWLEDGE UNIT 5: THE ANAL YSIS MODEL (6h)(1)Knowledge point 1 Requirements Analysis Modeling(2)Knowledge point 2 Data, functional and Behavioral(3)Knowledge point 3 Flow-Oriented Modeling(4)Knowledge point 4 Object-Oriented ModelingBasic requirement: Master the conception and method of requirement analyze, understand the user requirement and system requirement, master the main content of Flow-Oriented and Object-Oriented Modeling.KNOWLEDGE UNIT 6: DESIGN ENGINEERING (4h)(1)Knowledge point 1 Design Process and Design Quality(2)Knowledge point 2 Design Concepts(3)Knowledge point 3 Design Model(4)Knowledge point 4 Design PatternBasic requirement: Master the steps of design engineering process, understand the role of a bridge to construction, understand the conception of design pattern.KNOWLEDGE UNIT 7: ARCHITECTURAL DESIGN (4h)(1)Knowledge point 1 Software Architecture(2)Knowledge point 2 Data Design(3)Knowledge point 3 Architectural Design(4)Knowledge point 4 Mapping Data Flow into a Software ArchitectureBasic requirement: Master the Structural Design method, including data flow diagram, data dictionary, and control models, understand the software design specification.KNOWLEDGE UNIT 8: COMPONENT-LEVEL DESIGN (6h)(1)Knowledge point 1 Designing Class-Based Components(2)Knowledge point 2 Conducting Component-Level Design(3)Knowledge point 3 Designing Conventional ComponentsBasic requirement: Understand the conception of components, Master the modular decomposition KNOWLEDGE UNIT 9: TESTING STRA TEGIES (4h)(1)Knowledge point 1 Software Testing Strategic(2)Knowledge point 2 Test Strategies for Conventional Software(3)Knowledge point 3 Test Strategies for Object-Oriented Software(4)Knowledge point 4 Validation Testing(5)Knowledge point 5 System TestingBasic requirement: Understand the basic definition of verification and validation, Master the steps of software testing process, Master the conventional software test strategies, understand the Object-Oriented Software test strategies.KNOWLEDGE UNIT 10: TESTING TACTICS (6h)(1)Knowledge point 1 Software Testing Fundamentals(2)Knowledge point 2 Black-Box and White-Box Testing(3)Knowledge point 3 Object-Oriented Testing MethodsBasic requirement: Understand the basis of software testing fundamentals, master the main contents of unit testing and integration testing, master the design of black-box and white-box testing. KNOWLEDGE UNIT 11: QUALITY MANAGEMENT (2h)(1)Knowledge point 1 Software Quality(2)Knowledge point 2 Software Quality Assurance(3)Knowledge point 3Software ReliabilityBasic requirement: Understand the definition of software Quality Management, master the basic method of software quality control.KNOWLEDGE UNIT 12: CHANGE MANAGEMENT (4h)(1)Knowledge point 1 Software Configuration Management(2)Knowledge point 2 SCM Process(3)Knowledge point 3 Version ControlBasic requirement: Understand the basic requirements of software change, understand the definition of software configuration management, master the version control.（二）课程的重点、难点及解决办法Curriculum focuses on the establishment of the basis theory of software engineering，and it is difficulty to design a suitable practical activity for the most students in software development process, making it better able to establish the basic theory and methods of software engineering. Therefore, students are organized in small groups as a unit. Teachers and students jointly build a development issue, gradually expand the development of practice activities, and use classroom-style assessment. The teach model can initiative to mobilize the students as possible.三、实验实践环节及基本要求1．实验实践教学环节在本课程中的作用及要求（实验教学大纲单独编写）The experimental practices of this course need to complete the software development process the main part of the three major activities and a supporting framework, including requirements analysis, software design, unit test and software configuration management. These experiments content is all software development activities have to be resolved, can be well reflected in software engineering theory, software development process needs of the technology practice.2．实验项目(具体要求见实验教学大纲)Experiment 1: Designing and Writing Software Requirements Specification (2h)Experiment 2: Designing and Writing Software Design Specification (2h)Experiment 3: Software Unit Testing (2h)Experiment 4: Software Configuration management (2h)四、本课程与其它课程的联系与分工The prep course of this course is data structure. This course is a follow-up to other professional courses on the basis of software engineering major.五、对学生能力培养的要求Through the course of study, students can establish the basic theories and methods of software engineering, master a certain requirement analysis, software design, development and testing capabilities, and master the basic theory of teamwork developed.六、课程学时分配Total 48 hours, including lectures 40 hours, experiments 8 hours. The main contents and distribution of course see the course hour’s allocation table.七、建议教材和教学参考书目1．教材《Software Engineering: A Practitioner’s Approach(英文精编版，第6版)》, Roger S. Pressman, 机械工业出版社,20202．主要参考书[1]《Software Engineering (8th Edition)》，Ian Sommerville，机械工业出版社，2020.[2]《软件工程（第8版）》，程成，陈霞，机械工业出版社，2020.[3]《软件工程：实践者的研究方法（本科教学版）》Roger S. Pressman，机械工业出版社，2020八、课程考核The course use close examination pattern. The academic performance mainly results from the final examination and the usual performance, which accounted for 70% of the final examination, usually performance accounted for 30%. Usually performance is mainly decided by working projects of the courses, supplemented by after-school work and attendance.九、说明In the teaching process, it is need to the divided students into a group of 3-6 people. They need to complete a software development project collaboratively with courses progress.执笔人：宗平审核人：陈志教学院长：孙力娟编写完成时间：2009年10月20日软件工程专业介绍培养目标：本专业培养适应社会发展需求，德、智、体、美全面发展，具有扎实的计算机应用理论和知识基础，掌握软件工程领域的前沿技术和软件开发方法，具有较强的实践能力和创新精神，具备较强的软件项目的系统分析、设计、开发和测试能力，能够按照工程化的原则和方法从事软件项目开发和管理的应用型人才。
软件工程双语教学大纲
《软件工程》（双语）教学大纲课程编号：06301525 课程性质：必修课程名称：软件工程概论学时/ 学分：48/2.5英文名称：Software Engineering 考核方式：开卷考试选用教材：《Software Engineering –A Practitioner’sApproach》Fifth Edition, R.S.Pressman, McGraw Hill，清华大学出版社影印大纲执笔人：顾春华先修课程：高级语言程序设计、数据库原理大纲审核人：适用专业：计算机科学与技术一、教学基本目标《软件工程》是计算机科学与技术专业本科生的一门的专业基础课，旨在使学生掌握软件工程的基本概念、原理和方法，从软件开发技术、软件工程管理和软件工程环境等几个方面了解如何将系统的、规范化的和可以度量的工程方法运用于软件开发和维护中。
要求学生通过本门课的学习，掌握结构化方法、面向对象方法等软件开发技术，初步了解软件复用的概念及基于构件的开发方法，同时对软件工程管理和环境等内容有一个总体的了解。
二、教学基本内容第一章绪论（Introduction）本章主要介绍软件的基本概念、软件危机、软件工程学的范畴、传统软件工程和面向对象软件工程以及软件工程的应用。
重点掌握：学习软件工程的意义，软件工程的范畴。
第二章软件生存期和软件开发模型(Software Lifecycle and Software Development Model) 本章从叙述软件生存周期开始，介绍了传统的软件开发模型（瀑布模型、快速原型模型）、软件演化模型（增量模型、螺旋模型）、面向对象过程模型（构件集成模型）、基于形式化方法的软件开发模型（转换模型、净室模型）等。
重点掌握：各种软件开发模型的内容，不同开发模型的特点比较。
第三章软件需求分析(Software Requirement Analysis )需求分析是软件生存周期中的一个重要阶段，本章在介绍了软件需求分析的任务、步骤后，分别按结构化和面向对象两类方法，给出了需求分析模型和它们的描述工具，并结合实例进一步阐述了结构化分析和面向对象分析的过程。
软件工程专业外语教学大纲
《软件工程专业外语》教学大纲课程编号：00000407课程中文名称：软件工程专业外语课程英文名称：Soft Engineering English总学时：32 实验学时：0 上机学时：0学分：2适用专业：软件工程专业一、课程性质、目的和任务（300字内）《软件工程专业外语》是软件工程专业学生的一门重要专业基础课。
其基本任务是使学生不仅能掌握一定数量的专业词汇和习惯表达方式，而且能阅读相关的外文技术文献。
通过对本课程的学习，拓展了学生对英语在专业知识方面的应用，激发了对专业知识的兴趣，达到理解使用计算机过程中提示信息和专业说明书等英文资料，提高了学生英语阅读和翻译能力，达到了从英文资料中获取专业知识和信息的专业英语水平。
二、课程教学内容及学时分配（每章均包括以下三项内容）1.Chapter 1 Mobile Computers教学内容: Mobile computers overview, smartphones, and Android operating system教学重点、难点：Smartphones and Android Architecture学时：42.Chapter 2 Software Reengineering教学内容: Software engineering, software reengineering, and reverse engineering教学重点、难点：A Software Reengineering Model学时：43.Chapter 3 Main Memory Databases.教学内容: The evolution of main memory database and the key technology of main memory databases教学重点、难点：The Key Technology of Main Memory Databases学时：24.Chapter 4: Networking and Security教学内容: LAN, TCP/IP, and security教学重点、难点：Ethernet LAN and IP Address学时：45.Chapter 5 Artificial Intelligence教学内容: The Birth of Artificial Intelligence and Major Researches on AI教学重点、难点：Natural Language Processing学时：66.Chapter 6 Big Data教学内容: Big Data and its Properties, Categories and Big Value of Big Data教学重点、难点：Four Dimensions of Big Data学时：47.Chapter 7 Mobile Internet教学内容: Basic Concepts, Standards and Business Patterns of Mobile Internet 教学重点、难点：Characteristics and Business Patterns学时：38.Chapter 8 Internet of Things教学内容: Definition, Technologies, and Applications of Internet of Things,教学重点、难点：Common Definition of Internet of Things.学时：5三、教材及教学参考书教材：《软件工程专业英语》郭晓红、谢红薇主编，人民邮电出版社参考书：《计算机专业英语》J.O’ Leary 主编，高等教育出版社《计算机专业英语》华中科技大学出版社《计算机专业英语教程（第二版）》金志权等编著，电子工业出版社。
软件工程专业英语教学大纲
软件工程专业英语教学大纲软件工程专业英语教学大纲随着信息技术的快速发展，软件工程专业在当今社会的重要性日益凸显。
作为一门综合性学科，软件工程专业需要掌握一定的英语技能，以便与国际合作伙伴进行有效的沟通和合作。
因此，软件工程专业英语教学大纲的制定变得至关重要。
一、背景介绍软件工程专业英语教学大纲的制定是为了培养软件工程专业学生的英语交流能力和专业知识。
通过系统化的英语教育，学生将能够更好地理解和运用软件工程领域的专业术语和概念，提高软件开发过程中的沟通效率。
二、教学目标1. 提高学生的听说读写能力，使其能够流利地进行英语交流；2. 培养学生在软件工程领域的专业词汇和表达能力；3. 培养学生的跨文化交流和团队合作能力；4. 培养学生的信息获取和处理能力。
三、教学内容1. 英语基础知识：语法、词汇、听力、口语、阅读、写作等；2. 软件工程专业知识：软件开发过程、软件测试、软件质量保证等；3. 专业英语词汇和表达：需求分析、软件设计、编码、调试等；4. 跨文化交流与团队合作：国际软件项目管理、跨文化沟通技巧等；5. 科技文献阅读与写作：论文写作、文献综述、报告撰写等。
四、教学方法1. 综合教学法：结合听说读写，注重培养学生的综合能力；2. 案例教学法：通过实例分析，培养学生的实际应用能力；3. 互动教学法：鼓励学生参与课堂讨论和小组活动，培养学生的团队合作能力；4. 多媒体教学法：利用多媒体技术，提供丰富的教学资源和实例。
五、教学评估1. 课堂表现：包括参与度、发言能力、团队合作等；2. 作业和考试：包括听力、口语、阅读、写作等方面的评估；3. 项目实践评估：通过实际项目的完成情况评估学生的综合能力。
六、教材选择1. 通用英语教材：如《大学英语》、《新编大学英语》等；2. 专业英语教材：如《软件工程英语教程》、《软件工程专业英语教程》等；3. 学术论文和科技文献：如国际期刊、会议论文等。
七、教学资源1. 多媒体教室：配备计算机、投影仪等设备，方便教师进行多媒体教学；2. 学术数据库：提供学生进行科技文献检索和阅读的资源；3. 实验室设备：提供学生进行软件开发和测试的实验环境。
软件工程(双语)2
软件生存周期 传统的软件过程 软件演化模型 形式化方法模型 统一过程和敏捷过程 软件可行性研究
2. 传统的软件过程
传统的过程模型
瀑布模型
waterfall model 基于软件生存周期的线性开发模型
快速原型模型
rapid prototype model 基于原型的迭代化开发模型
瀑布模型
W.Royce于1970年提出 线性开发模型 强调软件文档
每一个阶段必须完成规定的 文档 每一个阶段都要复审完成的 文档
用户要求
系统测试
需求分析
需求规格说明
软件分析 与总体设计
软件结构图
确认测试 综合测试
详细设计
模块说明
单元测试
编码
程序清单
图2.2 瀑布模型的阶段与文档
瀑布模型
种类
渐进型：对原型补充和修改获得最终系统 抛弃型：原型废弃不用
应防止的偏向
和依赖性 推迟实现的观点 质量保证的观点
存在问题
不适合需求模糊的系统 开发初始阶段很难彻底弄清软件需求
快速原型模型
需求
原型开发
用户 反馈
原型评价 最终系统设计
最终系统实现
快速原型模型
特点
“逼真”的原型可以使用户迅速作出反馈 循环回溯和迭代：非线性模型 使用快速开发工具
《软件工程专业英语》课程教学大纲
《软件工程专业英语》课程教学大纲一、课程基本信息注：1.课程类别：选填“通识核心课/通识拓展课/通修课/学科基础课/专业主干课/专业选修课/专业实践/素质拓展”2.课程性质：选填“选修/必修”3.授课语言：选填“中文/双语/全英文或其他语种”二、课程目标注：1.支撑毕业要求指标点：选填项。
需要进行专业认证，有毕业要求指标点可参照的课程必填，无明确毕业要求指标点可参照的可不填。
三、理论教学内容注：1.思政融入点：至少写3条，简述该课程教学中将思政教育内容与专业教育内容有机融合的知识点（下同）。
2.学生学习预期成果：描述学生在学完本节内容后应获得的知识、能力或素养水平（下同）3.教学方式:包括讲授、讨论、案例、演示等，但不限于所列，根据课程实际需要列举四、课程评价（一）考核内容、考核方式与课程目标对应关系注：1. 课程目标在考核方式及占比：主要根据课程目标自行设计和制定多元化考核方式，表中所列仅为参考（红色数据可删除）。
但所列考核方式必须覆盖全体学生，可根据当学期具体教学情况酌情调整。
2. 各考核方式占总成绩权重：根据课程实际情况对各考核方式占总成绩的权重予以赋值。
（二）考核方式评分标准1．课程作业评分标准2．期末考试评分标准（笔试类评分标准可在大纲中按以下格式予以说明，也可在通过“试卷分析表”予以说明）……注：考核方式和课程目标在考核方式中占比应与“（一）考核内容、考核方式与课程目标对应关系”一致。
所列考核环节，除了笔试类均须依次给出评分标准，格式同上。
笔试类课程考核评分标准可以在本课程大纲里进行说明，也可以通过提交“试卷分析表”予以说明。
五、参考书目及学习资料1.计算机专业英语教程.高教出版社.宋德富等.2008年.第3版.2.计算机专业英语.机械工业出版社.张强华等.2007年.。