Software Engineering期末复习总结.docx

发布时间：2022-06-09 发布人：admin 分类：说明书资料大小：0.60M 资料格式：docx 举报版权申诉

fortianyou-5060081-4744302543335892258.docx.pdf-第1页.png

第1页 / 共18页

fortianyou-5060081-4744302543335892258.docx.pdf-第2页.png

第2页 / 共18页

fortianyou-5060081-4744302543335892258.docx.pdf-第3页.png

第3页 / 共18页

fortianyou-5060081-4744302543335892258.docx.pdf-第4页.png

第4页 / 共18页

fortianyou-5060081-4744302543335892258.docx.pdf-第5页.png

第5页 / 共18页

fortianyou-5060081-4744302543335892258.docx.pdf-第6页.png

第6页 / 共18页

fortianyou-5060081-4744302543335892258.docx.pdf-第7页.png

第7页 / 共18页

fortianyou-5060081-4744302543335892258.docx.pdf-第8页.png

第8页 / 共18页

1.2 Software Engineering

2.2 Process Models

3.3 Agile Process

3.4 Extreme Programming

4.1 Requirement Engineering

4.4 Developing Use cases

4.5Building Requirement Model

Elements of the Requirements Model

5.1 Requirement Analysis

5.2 Scenario based Modeling

6.2 Flow Oriented Modeling

7.3 Design concepts

9.2 Designing class based component

Basic Design Principles

Cohesion

Coupling

10.4 Interface design steps

11.2 Software quality

11.3 The software Quality Dilemma

12.6 Formal Technical Reviews（FTR正式技术评审）

13.3SQA Tasks, Goals and metrics

13.4Formal Approaches to SQA

14.1A Strategic Approach to software Testing

14.3Test Strategies for Conventional Software

14.5Validation Testing（确认测试）

14.6System Testing

15.3White-Box Testing

15.4Basis path testing

15.5 Control Structure Testing

15.6Black Box testing

16.3Object-Oriented Testing Strategies

Unit testing

Integration Testing

Validation Testing

18.1The Management Spectrum（管理涉及的范围）

Effective software project management focuses on t

19.2Software Measurement

20.2The Project Planning Process（项目策划过程）

20.4Resources

1.2 Software Engineering  Software has become embedded into every aspect of daily lives.  The information technology requirement demanded by individuals, business, and governments grows complex with each passing year.  Individuals, business, and governments increasingly rely on software for strategic and tactical decision making as well as day-to-day operations and control.  As the perceived value of a specific application grows, the likelihood is that its user base and longevity will also grow. (随着应用程序应用价值的提升，其用户基础和寿命也会增长) What is SE? (1) The application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; I.e. the application of engineering to software. (2) The study of approaches as in (1) above. Software engineering is a layered technology.  The bedrock that supports Software engineering is a quality focus.  The foundation for SE is the Process layer. Process defines a framework that must be established for effective delivery of SE technology.(过程定义了传递 SE 技术的框架)  SE methods provide the technical how to build software.  SE tools provide automated or semi-automated support for the process and methods. 2.2 Process Models Waterfall model: also called classic life cycle  Communication: Project initiation, requirement gathering.  Planning: estimating, scheduling, tracking  Modeling: analysis, design  Construction: code test  Deployment: delivery, support, feedback Waterfall model strength  Easy to understand, easy to use  Provide structure to inexperienced stuff  Milestones are well understand  Set requirements stability  Good for management control  Work well when quality is more important than cost and schedule Waterfall deficiencies  All requirement must be known upfront  Inhibits flexibility

 Can give a false impression of the progress  Didn’t reflect the problem  It’s a big bang when integration  Little opportunity for customers. When to use waterfall  The requirements are well known.  The production definition is stable.  Technology is understood.  A new version of existing production  Porting an existing production to a new platform Structured evolutionary prototype model steps  A preliminary project plan is developed 定义一个最初的工程计划  An partial high-level paper model is created 创建部分的高级模型  The model is source for a partial requirements specification 这个模型是需求规格说明的来源  A prototype is built with basic and critical attribute 利用基本和关键的属性构建原型  The designer builds the database, user interface, and algorithmic function 设计者设计数据库，用户接口，算法功能  The designer demonstrates the product to customer for evaluation of the problems and feedbacks.设计师展示产品，来获取客户评价和反馈  Loop until the customer satisfied 继续上诉过程知道客户满意 Prototype model strengths  Customer can “see” the system requirement(用户能够看到系统需求)  Designer learn from customer（设计者可以从客户学习）  A more accurate end product（开发出更精确的产品）  Unexpected requirements are accommodated（会有意想不到的需求）  Allows for flexible design and development（允许灵活的设计和开发）  Steady, visible signs of progress produced(产生了稳定的，可视化的过程标识)  Interaction with the prototype simulate awareness of additional needed functionality（用原型进行交流，激励了对额外的功能需求的意识） Weakness  Tendency to abandon structured program development for “code-and-fix” development(具有因修补开发而放弃结构化程序开发的倾向。)  Bad reputation for “quick and dirty” methods. 方法太过快捷/脏乱  Overall maintainability may be overlooked。总体的维护可能被忽略  Customer may want prototype delivered。客户会要求提交原型  Process may continue forever。开发可能永无止境 3.3 Agile Process Agile principle

 Highest priority is satisfy customer  Welcome requirement changing  Deliver working software frequently  Business people and developer work together  Build project around motivated individuals(围绕个人积极性构建项目)  Emphasize face-to-face communication  Working software is primary measure of progress(可运行的软件是进度的首要度量)  Agile processes promote sustainable development.(提倡可持续开发)  Continuous attention to technical excellence and good design enhances agility.(不断地关注优秀的技术和好的设计会增强敏捷能力)  Simplicity is essential(尽量减少不必要的工作)  The best architectures, requirements, designs emerge from self-organizing team.(自组织的团队)  The team tunes and adjusts its behavior accordingly.(团队有根据地自我协调行为) Human factors  Competence  Common focus(共同的目标)  Collaboration（协作）  Decision making ability  Fuzzy problem solving  Mutual trust and respect（互相信任和尊重）  Self-organization（自我组织） 3.4 Extreme Programming XP uses an object-oriented approach as its preferred development paradigm(范例)。 Framework activities 1 Planning  Begin with the creation of a set of stories  Each story is write by customer and placed on an index card  Customer assigns a value to the story  Agile team asses each story and assigns a cost  Stories are grouped for a delivery incremental  A commitment is made on deliver date.(承诺提交日期)  After the first project release delivered, its “project velocity” is used to help define the subsequent delivery date. 2 3 Design  Follow the “keep it simple” principle  Encourage usage of CRC cards  For difficult design problem, suggest create a prototype(spike solutions)  Design occurs both before and after coding commences. Coding

4  Recommends create a set of unit tests for each story, before coding commences  Encourage pair programing  Needs to integrate with other portions continuously, which provides “smoke testing” Test  Use a framework to implement unit test, to make testing automated.  Integration and validation testing can occur in daily basis  Acceptance tests, also called customer test, are specified by the customer and executed to assess customer visible functionality(用于评估用户可见的功能)  Acceptance tests are derive from user stories 4.1 Requirement Engineering 1 2 3 4 5 6 7 Inception  Basic understanding of the problem  Know who need the solution  The nature of the solution that is desired  The effectiveness of the preliminary communication and collaboration of the developer and customer Elicitation Elicit requirements from all stakeholders Elaboration Create an analysis model that identifies data, function and behavioral requirements. Negotiation Agree on deliverable system that is realistic for developers and customers. Specification:文档，模型，数学公式，用例，原型 Validation：确认是否有误，有遗漏缺失，是否一致 Requirement management 4.4 Developing Use cases  The first step in writing a use case is to define a set of “actors” that will be involved in the story.  An actor and an end user are not necessary the same thing. An actor represents a class of external entities.  Because requirements elicitation is an evolutionary activity, not all actors are identified during the first iteration. 4.5Building Requirement Model  The intent of the analysis model is to provide a description of the required informational,

functional, and behavioral domains for a computer-based system.  There are many different ways to look at the requirements for a computer-based system.  Different modes of representation force you to consider requirements from different viewpoints—an approach that has a higher probability of uncovering omissions, inconsistencies, and ambiguity. Elements of the Requirements Model Scenario-based elements  The system is described from the user’s point of view using a scenario-based approach.  Scenario-based elements of the requirements model are often the first part of the model that is developed. Class-based elements Each usage scenario implies a set of objects that are manipulated as an actor interacts with the system. These objects are categorized into classes—a collection of things that have similar attributes and common behaviors. Behavioral elements The behavior of a computer-based system can have a profound effect on the design that is chosen and the implementation approach that is applied. Flow-oriented elements Information is transformed as it flows through the computer-based system. Analysis Pattern

5.1 Requirement Analysis  Scenario-based models of requirements from the point of view of various system “actors”.  Data models that depict the information domain for the problem.  Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve system requirements.  Flow-oriented models that represent the functional elements of the system and how they transform data as it moves through the system.  Behavioral models that depict how the software behaves as a consequence of external “events”. The requirements model is a bridge between the system description and the design model. The analysis model(即需求模型) and requirements specification provide a means for assessing quality once the software is built. The requirements model Must Achieve (1) to describe what the customer requires (2) to establish a basis for the creation of a software design (3) to define a set of requirements that can be validated once the software is built. 5.2 Scenario based Modeling 6.2 Flow Oriented Modeling DFD 采取了系统的输入-处理-输出观点。数据对象用箭头表示，转换用圆圈表示（或者说是 Bubble）第 0 层的 DFD 图把系统当作一个整体。认为 DFD 已经过时不适用是一种错误的观念。在分析时，它很有用来描述需求的潜力。导出数据流图（DFD）的指导原则： 1. 第 0 层的数据流图应该吧软件或系统描述为一个泡泡。 2. 应该仔细标注壮阳药的输入和输出。 3. 通过把选定的处理、数据对象和数据存储分离为下一层表示而开始精化。 4. 应使用有意义的名称标记所有的箭头和泡泡。 5. 当从一个层转到另一个层时要保持信息流的连续性。 6. 一次精化一个泡泡。 A large class of applications are “driven” by events rather than data, produce control information rather than reports or displays( 而不是报告或者显示信息 ), and process information with heavy concern for time and performance. (关注时间和性能)。这类应用程序需要使用的 control flow modeling. 控制规格说明(Control specification, CSPEC)使用两种不同的方式表现系统的行为。The CSPEC

contains a state diagram（状态图） that is a sequential specification of behavior（行为的序列说明） . It can also contain a program activation table （程序激活表） —a combinatorial specification of behavior（行为的组合说明）。 7.3 Design concepts 9.2 Designing class based component Basic Design Principles 使用如下原则定义软件组件 The Open-Closed Principle(OPC):对扩展开放，而对修改关闭。无需组件自身修改过就可以进行扩展的方式来说明组件。可以通过接口实现。 The Liskov Substitution Principle(LSP)基类的组件可以使用子类的功能。 Dependency Inversion Principle(DIP)依赖于抽象，而非具体实现类。 The Interface Segregation Principle(ISP)如果不同的客户使用相同的方法，应该为不同的客户定制专用的接口。接口分离原则。使用如下原则打包软件组件 The Release Reuse Equivalency Principle, 复用的粒度(granule)就是发布的粒度。使得开发者在发布新版是能够重用旧版组件用非重写。 The Common Closure Principle, Classes that will change together belongs together. The Common Reuse Principle, Classes that aren’t reused together should not be grouped together. Cohesion Functional Cohesion(功能内聚) :有操作来体现，由一个模块来完成某一组特定操作并返回结果。 Layer Cohesion(分层内聚)：由包，组件和类来体现。高层能够访问底层服务，而底层不能访问高层服务。 Communicational Cohesion(通信内聚)：访问相同数据的所有操作被定义在一个类中。 Coupling Content Coupling: Occurs when one component “surreptitiously( 暗中 ) modifies data that is internal to another component”。 Common Coupling: Occurs when a number of components all make use of a global variable.

Control Coupling Stamp Coupling:参数调用 Data Coupling:传递长串数据 Routine( 例程调用) Call Coupling: Certain types of coupling occur routinely in object-oriented programming. Type Use Coupling: A 中使用 B 作为属性 Inclusion or Import Coupling：组件 A 中 import 了组件 B 的包或者内容 External Coupling:组件之间进行通信 10.4 Interface design steps The Golden Rules of User Interface Design Place the User in Control:用户操纵控制 Reduce the User's Memory Load：减少用户记忆规则 Make the Interface Consistent：保持界面一致 General steps for user interface design 1) Using information developed during user interface analysis, define user interface objects and actions (operations) 2) Define events (user actions) that will cause the state of the user interface to change; model this behavior 3) Depict each interface state as it will actually look to the end user（描述每个界面状态） 4) the interface（简要说明用户如何从界面提供的界面信息来解释系统状态） Indicate how the user interprets the state of the system from information provided through Interface objects and actions  Interface objects and actions are obtained from a grammatical parse（词汇分析） of the use cases and the software problem statement(从用例文本中获得的动词和名词)  Interface objects are categorized into types: source, target, and application（源、目标和应用对象）  After identifying objects and their actions, an interface designer performs screen layout（进行界面布局） Design Issues to Consider  System response time (both length and variability)  User help facilities  Error handling (more on next slide)  Menu and command labeling (more on upcoming slide) Many software engineers do not address these issues until late in the design or construction process, it result to unnecessary iteration, project delays and customer frustration.

分享到：

赞收藏

资料库

Software Engineering期末复习总结.docx

相关推荐

课程资源

热门标签

最新资料