第一范文网 - 专业文章范例文档资料分享平台

软件工程(9v)(30+10)双语 讲义 大纲模式 - 图文

来源:用户分享 时间:2025/6/1 18:46:01 本文由loading 分享 下载这篇文档手机版
说明:文章内容仅供预览,部分内容可能不全,需要完整文档或者需要复制内容,请下载word后使用。下载word有问题请添加微信号:xxxxxxx或QQ:xxxxxx 处理(尽可能给您提供完整文档),感谢您的支持与谅解。

3. Focus on functional rather than non-functional requirements such as reliability and security

B.2 Throw-away prototypes

C.1 Prototypes should be discarded after development as they are not a good

basis for a production system:

1. 2. 3. 4.

It may be impossible to tune the system to meet non-functional requirements; Prototypes are normally undocumented;

The prototype structure is usually degraded through rapid change;

The prototype probably will not meet normal organisational quality standards.

2.5.3 Incremental delivery

1. Rather than deliver the system as a single delivery, the development and delivery is broken

down into increments with each increment delivering part of the required functionality.

2. User requirements are prioritised and the highest priority requirements are included in early

increments.

3. Once the development of an increment is started, the requirements are frozen though

requirements for later increments can continue to evolve.

B.1 Incremental delivery advantages

1. Customer value can be delivered with each increment so system functionality is available

earlier.

2. Early increments act as a prototype to help elicit requirements for later increments. 3. Lower risk of overall project failure.

4. The highest priority system services tend to receive the most testing.

B.2 Incremental delivery problems

C.1 Most systems require a set of basic facilities that are used by different parts

of the system.

As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.

C.2

The essence of iterative processes is that the specification is developed in conjunction with the software.

However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract.

2.5.4 Boehm’s spiral model

Page 17 of 91

A.1 Concept

1. Process is represented as a spiral rather than as a sequence of activities with backtracking. 2. Each loop in the spiral represents a phase in the process.

3. No fixed phases such as specification or design - loops in the spiral are chosen depending on

what is required.

4. Risks are explicitly assessed and resolved throughout the process.

Determine objectivesalternatives andconstraintsEvaluate alternativesidentify, resolve risksRiskanalysisRiskanalysisRiskanalysisREVIEWRequirements planLife-cycle planRiskanaylsisProto-type 1Concept ofOperationPrototype 3Prototype 2Opera-tionalprotoypeSimulations, models, benchmarksS/WrequirementsProductdesignDevelopmentplanIntegrationand test planPlan next phaseCodeUnit testDesignV&VIntegrationtestAcceptancetestDevelop, verifyServicenext-level productRequirementvalidationDetaileddesign

A.2 Spiral model sectors

B.1 B.2 B.3 B.4

Objective setting

Risk assessment and reduction Development and validation Planning

Specific objectives for the phase are identified.

Risks are assessed and activities put in place to reduce the key risks.

A development model for the system is chosen which can be any of the generic models. The project is reviewed and the next phase of the spiral is planned.

A.3 Spiral model usage

1. Spiral model has been very influential in helping people think about iteration in software

processes and introducing the risk-driven approach to development.

2. In practice, however, the model is rarely used as published for practical software

development

Page 18 of 91

2.6 Key points

1. Software processes are the activities involved in producing a software system. Software

process models are abstract representations of these processes.

2. General process models describe the organization of software processes. Examples of these

general models include the ‘waterfall’ model, incremental development, and reuse-oriented development.

3. Requirements engineering is the process of developing a software specification.

4. Design and implementation processes are concerned with transforming a requirements

specification into an executable software system.

5. Software validation is the process of checking that the system conforms to its specification

and that it meets the real needs of the users of the system.

6. Software evolution takes place when you change existing software systems to meet new

requirements. The software must evolve to remain useful.

7. Processes should include activities to cope with change. This may involve a prototyping

phase that helps avoid poor decisions on requirements and design.

8. Processes may be structured for iterative development and delivery so that changes may be

made without disrupting the system as a whole.

2.7 Excercises(Homework): P54

2.1, *2.4

Page 19 of 91

Chapter 3 (4) Requirements Engineering

3.1

1. 2. 3. 4. 5. 6. 7.

Topics covered

Functional and non-functional requirements The software requirements document Requirements specification

Requirements engineering processes Requirements elicitation and analysis Requirements validation Requirements management

3.2 Requirements engineering

3.2.1 What is a requirement?

B.1

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification B.2 This 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 requirements

3.2.2 Requirements engineering

? The process of establishing the services that the customer requires from a system and the

constraints under which it operates and is developed

? The requirements themselves are the descriptions of the system services and constraints that

are generated during the requirements engineering process

3.2.3 Types of requirement

B.1

User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

B.2 System requirements

A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor

Page 20 of 91

软件工程(9v)(30+10)双语 讲义 大纲模式 - 图文.doc 将本文的Word文档下载到电脑,方便复制、编辑、收藏和打印
本文链接:https://www.diyifanwen.net/c701d9110j29pg7z7h9u8_5.html(转载请注明文章来源)
热门推荐
Copyright © 2012-2023 第一范文网 版权所有 免责声明 | 联系我们
声明 :本网站尊重并保护知识产权,根据《信息网络传播权保护条例》,如果我们转载的作品侵犯了您的权利,请在一个月内通知我们,我们会及时删除。
客服QQ:xxxxxx 邮箱:xxxxxx@qq.com
渝ICP备2023013149号
Top