新書推薦：
《
索恩丛书·北宋政治与保守主义：司马光的从政与思想（1019~1086）
》
售價：NT$
345.0
《
掌故家的心事
》
售價：NT$
390.0
《
农为邦本——农业历史与传统中国
》
售價：NT$
340.0
《
郊庙之外：隋唐国家祭祀与宗教 增订版 （三联·哈佛燕京学术丛书）
》
售價：NT$
480.0
《
小麦文明：“黄金石油”争夺战
》
售價：NT$
445.0
《
悬壶杂记全集：老中医多年临证经验总结（套装3册） 中医医案诊疗思路和处方药应用
》
售價：NT$
614.0
《
无法忍受谎言的人：一个调查记者的三十年
》
售價：NT$
290.0
《
战争社会学专论
》
售價：NT$
540.0
|
| 編輯推薦： |
|
作者用380张图表，以小故事的方式讲解软件工程各种设计方法如何在实际工作中落地，解决以往图书只讲理论，读完不知如何落地的痛点。
|
| 內容簡介： |
本书通过定制系统和标准产品的开发案例，介绍如何结合软件工程和项目管理的知识，按照标准化、工程化的方式协同完成软件的开发。其中定制系统的开发案例涉及售前咨询、项目准备、需求分析与设计、测试验证、上线培训等，给出了每个环节需要的理论、方法、工具、标准和交付物。标准产品的研发案例则涉及构建具有随需应变能力系统的设计思路、建模方法等。
本书是《大话软件工程—需求分析与软件设计》一书的姊妹篇，本书主讲案例，后者主讲方法，本书是后者中理论和方法的落地实践。
数字化转型是现今企业IT发展的新目标，数字化转型需要大量培养数字化时代所需的人才和技能，本书可作为培养软件公司和客户企业双方人才的培训教材，如软件工程师（包括需求、设计、开发、实施）、产品经理、项目经理、企业数字化转型的业务骨干人才等。
|
| 關於作者： |
资深需求咨询顾问，具有十年的工程管理经验，近三十年从事管理信息化咨询、需求分析、系统的规划架构以及软件工程的培训经历。
作者专注于研究软件工程实用化的理论、方法、标准等，研究的重点有两个方向：一是探索建立软件“工程化设计”的方法体系，让软件工程从一门 “高深的知识”转化为一套可以 “实操的技术” ；二是研究以客户价值为导向的软件设计方法，提出在软件工程中加入“业务设计”和“应用设计”的环节及相关的设计方法。
在进行企业管理信息化咨询工作的同时，致力于软件工程化设计方法的完善、验证和推广。
|
| 目錄：
|
第1篇 概 要 说 明
第1章 基础知识 2
1.1 软件开发 2
1.1.1 软件开发的过程 2
1.1.2 软件开发的基础知识 3
1.1.3 软件开发常见问题与对策 4
1.2 软件工程 5
1.2.1 软件工程的概念 5
1.2.2 软件工程的4个子工程 5
1.2.3 软件工程的两阶段法 8
1.2.4 软件设计的3个层次 10
1.2.5 软件工程的常见问题与对策 12
1.3 项目管理 12
1.3.1 项目管理的概念 13
1.3.2 项目管理的5个过程组 14
1.3.3 项目管理的3大目标 16
1.3.4 项目管理的常见问题与对策 17
1.4 软件的标准化 18
1.4.1 软件标准化的困局 18
1.4.2 软件标准化的思路 21
1.4.3 标准化要求的文档 24
1.4.4 标准化与软件工程 26
1.4.5 标准化与项目管理 27
1.4.6 标准化与软件开发 28
1.5 标准化与项目质量 29
1.5.1 影响项目质量的因素 29
1.5.2 对策1：分析与设计的标准化 30
1.5.3 对策2：记录文档的标准化 32
1.6 标准化与项目进度 33
1.6.1 影响项目进度的因素 33
1.6.2 对策1：路线图与计划 34
1.6.3 对策2：复用与标准化 37
1.7 标准化与项目成本 38
1.7.1 影响项目成本的因素 38
1.7.2 对策1：交付物的标准化 38
1.7.3 对策2：人才能力的标准化 39
第2章 案例设定 40
2.1 案例的设定信息 40
2.1.1 案例设计思路 40
2.1.2 案例项目的信息 40
2.1.3 客户的基本信息 44
2.1.4 软件公司的基本信息 46
2.2 案例双方的准备 47
2.2.1 任务的设定（客户） 47
2.2.2 任务的设定（软件公司） 47
2.2.3 项目组成员介绍（客户） 48
2.2.4 项目组成员介绍（软件公司） 49
2.3 案例的框架说明 52
2.3.1 软件工程与项目管理框架 52
2.3.2 输入与输出框架 52
2.4 关于软件公司 53
2.4.1 公司的分类 53
2.4.2 岗位的分类 54
2.4.3 组织的形式 58
2.4.4 开发的方式 59
2.5 关于客户企业 61
2.5.1 企业的基本构成 61
2.5.2 企业信息中心 66
2.5.3 存在问题与解决方法 67
2.5.4 信息化主导权的回归 68
第2篇 前 期 准 备
第3章 售前咨询 72
3.1 准备知识 72
3.1.1 目的与内容 73
3.1.2 实施方法论 75
3.1.3 角色与能力 78
3.2 准备工作 79
3.2.1 作业方法的培训 80
3.2.2 作业模板的准备 80
3.2.3 作业路线图的规划 80
3.3 咨询准备 80
3.3.1 项目背景介绍 81
3.3.2 项目资料收集 84
3.3.3 项目可行性研究 86
3.3.4 交流策略与计划 89
3.3.5 交流资料的编制 92
3.4 客户交流 95
3.4.1 信息中心的交流 95
3.4.2 企业高层的交流 97
3.4.3 关键用户的交流 100
3.5 解决方案 102
3.5.1 解决方案的框架 103
3.5.2 解决方案中的案例 110
3.5.3 解决方案的评审 114
第4章 项目准备 116
4.1 准备知识 116
4.1.1 目的与内容 117
4.1.2 实施方法论 117
4.1.3 角色与能力 119
4.2 项目开发实施方案 119
4.2.1 实施方案的结构 119
4.2.2 项目经理的选定 121
4.2.3 项目组的建立 122
4.2.4 路线与里程碑确定 123
4.2.5 项目执行计划编制 125
4.2.6 项目启动会 125
4.3 工作任务一览表 127
4.3.1 工作任务一览表的作用 127
4.3.2 工作任务一览表的编制 127
4.3.3 工作任务一览表的评审 129
4.4 项目管理规范 129
4.4.1 作业规范的制定 129
4.4.2 项目问题管理 132
4.4.3 需求变更问题 132
4.5 项目成员的培训 134
4.5.1 软件公司培训 134
4.5.2 客户培训目的 134
4.5.3 客户培训内容 135
4.6 补充1：定制型开发与产品型开发的
区别 136
4.6.1 定制型开发 137
4.6.2 产品型开发 137
4.6.3 问题与对策 138
4.7 补充2：合同金额与工作量计算 139
4.7.1 合同金额评估的误区 140
4.7.2 确定合同金额的依据 140
第3篇 需 求 工 程
第5章 需求调研 146
5.1 准备知识 146
5.1.1 目的与内容 147
5.1.2 实施方法论 148
5.1.3 角色与能力 155
5.2 准备工作 157
5.2.1 作业方法的培训 157
5.2.2 作业模板的准备 157
5.2.3 作业的规划 160
5.2.4 基线流程的制定 161
5.3 调研展开 165
5.3.1 公司级的调研 166
5.3.2 部门级的调研 169
5.3.3 用户级的调研 173
5.4 需求调研资料汇总 176
5.4.1 汇总整理来源 176
5.4.2 汇总资料结构 176
第6章 需求分析 178
6.1 准备知识 178
6.1.1 目的与内容 179
6.1.2 实施方法论 179
6.1.3 角色与能力 186
6.2 准备工作 186
6.2.1 作业方法的培训 186
6.2.2 作业模板的准备 187
6.2.3 作业路线的规划 190
6.3 需求分析的展开 190
6.3.1 架构的整理 190
6.3.2 功能的整理 192
6.3.3 数据的整理 194
6.3.4 需求的转换 194
6.3.5 需求的联查 196
6.4 其他类型的需求 198
6.4.1 功能性需求 198
6.4.2 非功能性需求 198
6.5 《需求规格说明书》的编制 199
6.5.1 说明书的结构 199
6.5.2 说明书的编写 201
6.5.3 说明书摘要 207
6.6 《需求规格说明书》的确认 207
6.6.1 确认对象与方法 207
6.6.2 公司层需求的确认 208
6.6.3 部门层需求的确认 209
6.6.4 用户层需求的确认 210
第4篇 设 计 工 程
第7章 概要设计—总体 212
7.1 准备知识 212
7.1.1 目的与内容 213
7.1.2 实施方法论 214
7.1.3 角色与能力 218
7.2 准备工作 218
7.2.1 作业方法的培训 219
7.2.2 作业模板的准备 219
7.2.3 作业路线的规划 221
7.3 理念与主线 222
7.3.1 设计理念的确定 222
7.3.2 业务主线的确定 225
7.3.3 管理辅线的确定 227
7.4 业务规划 230
7.4.1 架构层规划 230
7.4.2 功能层规划 233
7.4.3 数据层规划 235
7.5 其他规划 240
7.5.1 业务建模 240
7.5.2 管理规划 241
7.5.3 价值规划 241
7.5.4 用例规划 241
7.5.5 技术规划 242
7.6 《概要设计规格书》的编制 242
7.6.1 规格书的结构 242
7.6.2 规格书的编写 244
7.6.3 规格书的摘要 247
7.7 《概要设计规格书》的评审 247
7.7.1 项目组内部的自评 248
7.7.2 软件公司内部的评审 248
7.7.3 客户及第三方的评审 248
第8章 概要设计—建模 249
8.1 准备知识 249
8.1.1 建模需求的解读 249
8.1.2 建模思路与方法 250
8.1.3 建模的能力要求 254
8.1.4 作业方法的培训 255
8.2 业务分析的建模 256
8.2.1 项目周期的规划 256
8.2.2 项目功能的规划 257
8.3 管理分析的建模 259
8.3.1 过程管理的规划 259
8.3.2 协同管理的规划 261
8.3.3 管理强度的规划 262
8.4 业务 管理的建模 263
8.4.1 用排比图标出成本构成 263
8.4.2 用分解图标出成本层级 266
8.4.3 用流程图标出流程控点 267
8.4.4 用原型图标出业务管理 268
8.5 建模方法的总结 270
8.5.1 图形类建模 270
8.5.2 文字类建模 272
8.5.3 数据类建模 273
第9章 概要设计—管理 274
9.1 准备知识 274
9.1.1 管理需求的解读 274
9.1.2 信息化管理的思路 276
9.1.3 项目管理信息化的思路 281
9.1.4 作业方法的培训 281
9.2 目标管理（项目策划） 282
9.2.1 需求分析 282
9.2.2 目标管理的思路 283
9.2.3 目标管理的方法 284
9.3 进度管理（进度计划） 285
9.3.1 需求分析 285
9.3.2 进度管理的思路 286
9.3.3 进度管理的方法 286
9.4 成本管理（成本达标） 287
9.4.1 需求分析 287
9.4.2 成本管理的思路 288
9.4.3 成本管理的方法 290
9.5 风险管理（风险控制） 293
9.5.1 需求分析 293
9.5.2 风险管理的思路 295
9.5.3 风险管理的方法 295
9.6 管理规划的总结 300
第10章 概要设计—价值 302
10.1 准备知识 302
10.1.1 价值需求的解读 303
10.1.2 信息化价值的思路 303
10.1.3 作业方法的培训 305
10.2 系统门户方案 305
10.2.1 整体规划 305
10.2.2 功能查找 306
10.2.3 待办事项 307
10.2.4 通知汇总 309
10.3 时间管理方案 309
10.3.1 时限设定表 309
10.3.2 工作日历 310
10.4 界面操作方案 311
10.4.1 规则检查 311
10.4.2 参考信息 312
10.4.3 沟通确认 313
10.5 自检/帮助方案 313
10.5.1 企业知识库的建立 313
10.5.2 企业知识库的应用 314
10.5.3 自检功能 315
10.6 信息展示方案 315
10.6.1 企业领导的看板 315
10.6.2 项目经理的看板 316
10.6.3 专业岗位看板 316
10.7 价值设计总结 317
第11章 详细设计 320
11.1 准备知识 320
11.1.1 目的与内容 321
11.1.2 实施方法论 321
11.1.3 角色与能力 322
11.2 准备工作 323
11.2.1 作业方法的培训 323
11.2.2 作业模板的准备 324
11.2.3 作业路线的规划 327
11.3 架构层的详细设计 327
11.3.1 业务层面 327
11.3.2 管理层面 331
11.4 功能层的详细设计 332
11.4.1 业务层面 332
11.4.2 管理层面 336
11.4.3 价值层面 338
11.5 数据层的详细设计 340
11.5.1 需求来源 341
11.5.2 建模思路 342
11.5.3 建模计算 342
11.6 业务用例的设计与验证 348
11.6.1 用例场景 348
11.6.2 用例导图 348
11.6.3 用例数据 349
11.6.4 验证结果 350
11.7 详细设计规格书 351
第12章 应用设计 353
12.1 准备知识 353
12.1.1 目的与内容 354
12.1.2 实施方法论 356
12.1.3 角色与能力 359
12.2 准备工作 359
12.2.1 作业方法的培训 360
12.2.2 作业模板的准备 361
12.2.3 作业路线的规划 362
12.3 架构层的应用设计 362
12.3.1 框架图的设计 362
12.3.2 流程图的设计 363
12.3.3 流程机制的设计思路 364
12.4 功能层的应用设计 365
12.4.1 组件设计 366
12.4.2 接口设计 366
12.4.3 界面设计 368
12.5 数据层的应用设计 369
12.5.1 数据需求 370
12.5.2 机制设计 371
12.6 应用用例的设计与验证 372
12.6.1 用例场景 373
12.6.2 用例导图 373
12.6.3 用例数据 375
12.6.4 验证结果 375
12.7 应用设计规格书 376
第13章 交底与验证 378
13.1 准备工作 378
13.1.1 作业方法的培训 379
13.1.2 交底文档的准备 379
13.1.3 作业路线的规划 380
13.2 设计交底 381
13.2.1 交底的作用 381
13.2.2 交底的内容 383
13.2.3 交底的方法 385
13.3 设计验证 389
13.3.1 验证的作用 389
13.3.2 验证的内容 391
13.3.3 验证的方法 392
第5篇 其 他 综 合
第14章 标准与培训 396
14.1 准备知识 397
14.1.1 目的与内容 397
14.1.2 实施方法论 398
14.1.3 角色与能力 399
14.2 准备工作 399
14.2.1 作业文档的准备 400
14.2.2 作业路线的规划 400
14.3 标准制定 401
14.3.1 统一认知 402
14.3.2 统一方法 403
14.3.3 统一标准（业务） 404
14.3.4 统一标准（数据） 405
14.3.5 统一标准（管理） 406
14.3.6 统一标准（组织） 407
14.4 用户培训 408
14.4.1 培训目的 408
14.4.2 培训内容 410
14.4.3 培训方式 411
14.4.4 培训效果 412
14.5 交付物 414
14.5.1 信息系统（软件） 414
14.5.2 数据库 414
14.5.3 设计文档 414
第15章 项目总结 417
15.1 项目相关方的收获 418
15.1.1 客户方面的收获 418
15.1.2 软件公司方面的收获 421
15.1.3 项目组成员的收获 423
15.2 标准与文档库的建立 426
15.2.1 知识体系的结构 426
15.2.2 开发过程的结构 427
15.2.3 文档归集的结构 428
15.2.4 文档归集1：模板类 430
15.2.5 文档归集2：模型类 430
15.2.6 文档管理的系统 434
15.3 基础知识相关的问题 436
15.3.1 软件工程有实用价值吗 436
15.3.2 设计是不可或缺的环节 436
15.3.3 瀑布与敏捷，孰优孰劣 437
15.3.4 业务的连续性与功能的碎片化 439
15.4 项目前期的Q&A 440
15.4.1 关于售前咨询 440
15.4.2 关于开发合同 442
15.5 需求工程的Q&A 443
15.5.1 与用户的沟通 443
15.5.2 有关需求的表达和识别 444
15.5.3 有关快速理解业务 444
15.5.4 关于需求的变化 446
15.5.5 关于需求文档 446
15.6 设计工程的Q&A 449
15.6.1 如何与技术人员沟通 449
15.6.2 业务与技术的差异 450
15.6.3 程序员需要什么样的文档 451
15.6.4 标准模型与架构方法的区别 451
15.6.5 企业的数字化转型 452
第16章 产品设计 455
16.1 准备知识 455
16.1.1 目的与内容 456
16.1.2 实施方法论 456
16.1.3 角色与能力 458
16.1.4 作业方法的培训 458
16.2 产品的需求 459
16.2.1 客户的需求 459
16.2.2 软件公司的需求 460
16.2.3 标准产品的需求 461
16.3 产品的原理 466
16.3.1 设计思路 466
16.3.2 基干原理 467
16.3.3 组件 机制的应用 472
16.4 产品的规划 474
16.4.1 标准产品的开发思路 474
16.4.2 基线系统的架构方法 475
16.4.3 基线系统的设计思路 476
16.5 产品的实现 480
16.5.1 软件开发的现状 480
16.5.2 软件开发工业化的概念 481
16.5.3 软件开发工业化的实现方式 482
16.5.4 软件工业化开发小结 487
16.6 产品开发总结 488
附 录
附录A 逻辑的思维和表达 490
A.1 逻辑表达和逻辑思维的关系 490
A.1.1 表达和思维的差异 490
A.1.2 逻辑表达的培训在先 491
A.2 能力培训方法的选择 491
A.2.1 利用语言进行逻辑表达能力的训练 491
A.2.2 利用文字进行逻辑表达能力的训练 492
A.2.3 利用图形进行逻辑表达能力的训练 492
A.3 能力培训的内容 492
A.3.1 用图形进行逻辑表达能力的训练 492
A.3.2 逻辑能力训练的过程 494
附录B 软件工程能力评估 495
B.1 售前咨询的能力要求 497
B.2 需求工程的能力要求 499
B.3 设计工程的能力要求 502
附录C 索引 505
参考文献 506
|
| 內容試閱：
|
1. 本书的内容
本书的内容主要包括两个案例，其中主案例是一个定制系统的开发（也称为项目开发、项目），次案例是一个标准产品的研发（也称为产品研发、产品），其中，
定制系统的开发：以一个软件项目（定制系统）的开发过程为主线，讲解开发过程中每个环节需要的理论、方法、工具、标准和交付物，开发过程包括售前咨询、项目准备、需求工程、设计工程、对编码工程的交底、对测试工程成果的验证、上线准备、实施培训等环节。开发过程涉及软件工程和项目管理的相关知识。
标准产品的研发：重点介绍研发一款标准产品的思路、理论和基本方法，包括产品的需求分析、规划方法、建模方法等，特别详细介绍让产品具有随需应变能力的建模概念和方法。标准产品的研发涉及模块化、平台化系统的设计知识。
2. 本书的背景
能够按质、按量、按时完成软件开发任务，是所有的软件工程师、特别是项目经理和产品经理追求的最高目标，同时也是客户方的最大期望。
近年来各个行业（如建筑业、制造业等）都发生了巨大的变化，软件行业利用IT技术为其他所有行业进行赋能，为其他行业的变化提供动力，已经形成了没有软件行业的支持任何一个行业的持续向上发展都是不可想象的局面，同时下一个发展阶段也已经开始，深度实现了信息化管理的企业又开始向数字化企业转型。
软件行业自身也是一种制造业（虽然产品特殊），但在经过了二三十年的发展后，软件自身的开发方式却没有太令人印象深刻的变化（而同期其他传统行业却在IT技术的加持下发生了非常显著的变化），特别是在软件行业的重要领域“企业管理信息化”方面，还在沿用已经重复了多年的、低效低质的开发方式。可以说软件开发用着最先进的硬件工具（计算机、网络等），但开发方式却是落后的手工作坊式。在公司中常遇到以下的问题，参见图1。
图1 交付的系统与预想的不一样
需求分析师抱怨客户：不清楚要做什么系统，总说不清楚需求，而且需求老在变，等等。
需求工程师抱怨程序员：听不懂需求，总不能按照我说的要求完成开发，等等。
程序员抱怨需求工程师：交底时说不清楚需求，业务逻辑不清楚，需要反复进行沟通，等等。
用户抱怨软件公司：交付的系统与预想的不一样，这不是我想要的系统，等等。
在软件行业出现这种认知偏差的场景已是常态，总是不断地被重复，与系统开发密切相关的人都在抱怨其他人“不清楚在说什么，不清楚在做什么”，试想这样的系统质量能好吗？客户的满意度能高吗？这样开发出来的系统成功率能有多少？
不论是建筑业还是制造业，出现如此频繁的偏差都不可能是常态（企业会破产）。未来各个行业对管理信息化、数字化转型的需求会越来越多，业务需求也会越来越多样、复杂，因此软件行业也急需像其他行业一样，在“开发、管理”方面有一个根本性的变化。
大多数有一定规模的软件企业都在不断探索如何建立软件开发过程的标准化体系，为此也耗费了大量的人力、时间和管理成本，但由于没有找到正确的方法，因此最终未能获得预期的效果。这使得软件企业处于非常纠结的状态：不推进标准化不行（存在的大量问题都是缺乏标准化带来的），花大力气推进标准化又没有获得期望的结果，问题出在哪里？应该如何进行软件开发过程的标准化呢？
3. 本书的目的
本书的目的就是通过项目开发的案例，探索出现上述问题的原因并给出解决方案。
造成上述问题的关键在于软件行业的历史短，特别是软件开发的前期工作，如需求调研、需求分析和软件设计等方面缺乏标准化的方法、工具，且从事标准化推进工作的担当人缺乏相应的知识和经验。要想解决这个问题，站在软件行业的纯技术立场或纯业务立场都不足以找到理想的解决方案。利用跨界思维可能会带来不同的方法和效果。向建筑、制造等传统工程行业学习、借鉴它们成熟的经验，有助于快速、高效地找到一套适合解决软件开发与管理的标准化解决方案。
本书以《大话软件工程—需求分析与软件设计》一书中提出的理论、方法、工具、标准等知识为基础，通过定制系统/标准产品的开发案例，将上述知识应用在开发过程中，并讲述如何借鉴传统行业的经验将这些知识进行标准化，探索如何为软件公司建立一套有实用价值的知识体系。
4. 本书的特点
本书以一个定制系统的开发过程为主线，由本书作者担任案例中指导顾问的角色，对项目开发过程中的各阶段、各环节提供帮助指导，包括作为咨询师和架构师参与开发过程、对各个阶段所需作业知识和方法的培训、需求分析和设计模板的使用指导，并对开发过程中的各种做法进行点评和答疑。这样可以做到一边引导读者观看软件开发的执行、管理过程，一边详细地讲述案例开发过程中每个步骤与《大话软件工程—需求分析与软件设计》一书中的理论、方法、标准和模板的关联关系，让读者通过对本书的阅读可以体验一遍“理论 实践”的实战过程。
案例以软件公司和客户企业的双视角展开。做好一款软件，需要客户与软件公司双方紧密配合才能实现，这就需要双方相互了解对方的想法和做法，由于软件开发的过程是以软件公司为主、客户为辅进行的，所以本书的内容是以软件公司视角为主，客户视角为辅展开的，尝试着从两个视角来看一个软件项目的实施过程。让读者同时了解双方在每个阶段的想法和对策。
1）软件公司一方（包括项目经理、需求工程师、架构师/设计师、程序员等）
不但要清楚地知道自己应该如何做，而且也应该对客户的想法和做法有所了解，只有如此才能在售前咨询阶段、项目执行阶段与客户的相关部门和业务骨干做好配合。为什么这样说呢？因为常常有人吐槽说：怎么讲解用户都不明白，而且总在改需求，不知道需求什么时候才能稳定下来。此时就要从双方的立场看问题，客户方参与信息化的人也有很大的压力，由于双方在信息化知识方面的不对称，客户方面的担当者说不清楚需求。另外，他们是系统的用户或信息中心的员工，在客户企业中也没有很高的地位和话语权，很多问题不能（或不敢）做决定，因为一旦出了问题这些人是要负责的，所以软件工程师必须要理解客户的情况。
2）客户企业一方（信息中心、系统用户、高层领导等）
需要知道软件公司是如何进行项目的启动、规划、执行和监控等工作的。只有如此才能配合软件公司高效、高质地完成系统的开发和导入工作。帮助客户方了解软件公司的业务运作过程是很重要的，例如，客户经常会说，不就是让你改一下，有那么难吗？客户不知软件的架构设计、开发就如同制造一部复杂的机器一样，某一部分改动了，有可能引起其他部分一连串的变动，造成系统不稳定或缺陷（Bug）频出的问题。所以，在开发过程中要利用一切机会向客户说明自己的工作，取得客户的理解。
5. 本书的对象
本书的读者对象可以是从事下述各领域工作的人（因企业不同定义也不同，仅作参考）。
1）软件公司
本书提供两个案例：定制系统的开发和标准产品的研发，讲述在开发过程中各个岗位的工作方法以及工作人员是如何协调工作的，适合本书的岗位如下。
项目经理：定制系统开发相关的组织、规划、计划、执行、验收以及项目收尾。
产品经理：标准产品的需求分析、产品的架构思路、设计方法等。
业务人员：包括售前咨询师、需求工程师、软件架构师、业务设计师、实施工程师等，他们所从事的工作包括需求调研、需求分析、业务设计，应用设计的方法、标准。
技术人员：包括编程工程师、测试工程师等希望学习需求分析、软件设计内容的技术人员，以及希望从技术岗转行到业务岗的人员。
2）企业信息中心
由于国家积极推进企业管理信息化和企业数字化转型，企业建设的信息系统越来越多，规模和复杂度也越来越大，且部分企业还成立了具有需求分析、软件设计和编码测试能力的部门，因此非常需要具有需求分析和软件设计能力的专业人才。
3）培训机构
可以培训教授相关课程的老师以及从事软件公司各类岗位的学员。采用本书提供的知识体系和项目案例，可以大幅度地缩短培训周期，增加学员的实战能力。
4）大学
作为软件工程专业、信息管理专业等学生的辅助教材，帮助学生了解软件的研发过程以及所需要的理论、方法、标准和模板，可以让学生在进入企业前掌握一定的实战能力。
本书讲述的内容是基于作者常年从事咨询、架构、培训过程中的实战经验总结整理而成的，并在多年的实践中进行了验证，希望能够给读者以有益的启发和参考。本书建立了交流社群（QQ：816940768），欢迎读者进群交流，相互促进，共同提高。
李鸿君
2024年2月于北京
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
