开发者社区> 华章计算机> 正文

《需求设计:构建用户想要和需要的产品》—— 导读

简介: 在对IT应用程序开发思考了大约15年之后,我终于写出了这本书。20世纪90年代后期,我开始做IT架构,当时写了一本名叫《IT Architecture and Middleware: Strategies for Building Large, Scalable Systems》的书(那本书的第2版是与Peter Bye合写的,于2004年出版,现在还可以买到)。
+关注继续查看


<a href=https://yqfile.alicdn.com/6ec696e3acab5ead903c7f9a25ac9ef090aeb814.png
" >


26fa084970ff9647d01059c26d5b0043cabd80a0

前  言
Designing the Requirements: Building Applications that the User Wants and Needs
在对IT应用程序开发思考了大约15年之后,我终于写出了这本书。20世纪90年代后期,我开始做IT架构,当时写了一本名叫《IT Architecture and Middleware: Strategies for Building Large, Scalable Systems》的书(那本书的第2版是与Peter Bye合写的,于2004年出版,现在还可以买到)。那本书讲的是构建集成应用程序(integrated application)所需的技术,以及怎样确保应用程序的可扩展性、高可用性以及安全性。那时还有其他一些人也持有类似想法,由于我们的基本思路是向开发者提供一些可复用的服务,使其能够通过集成技术来迅速拼装应用程序,因此,业界把Peter与我所提出的那种解决方案称为面向服务的架构(Service Oriented Architecture,SOA)。SOA显然有很多优势,但实际上并没有发挥太大作用,因为其中好像缺了点什么。我从一开始就怀疑,缺少的那个东西,应该是应用程序的开发。换句话说,我们没办法很好地回答“怎样开发SOA应用程序”这个问题。此问题也可以表述为:“有人向我提出了一些要求,我该怎样确保最后得到的是一套SOA解决方案,而不是一个单独的应用程序呢?”接下来的几年里,我对于架构问题想得少了一些,而对应用程序的开发问题,则想得比较多。
我刚开始编写应用程序,是在20世纪70年代后期。从那以后,我主要是在系统与环境软件的领域中进行bug修复及设计工作,我花了很多时间去修整数据管理软件,偶尔也会修复几个编译器或操作系统的bug。在这个过程中,我对系统软件的设计与编程有所接触。其后,我开始从事数据库和资源库的设计工作(对于版本控制问题,我有很多话要讲,但奇怪的是,没几个人愿意听)。到2000年的时候,我对计算机技术的很多方面都已经有了一些经验,但由于自己并没有直接从事大量的应用程序设计与编程工作,因此我还无法坦然地走到应用程序开发者面前,指出他们的做法是彻底错误的。
那时的程序开发专家对架构并没有多少兴趣,而是在开发方法上面彼此较劲。有些人崇尚BDUF(big design up front,大设计先行),他们提倡根据UML(Unified Modeling Language,统一建模语言)来做设计,提倡要安排好设计的结构,要用良好的文档描述这套设计,并且要在质量控制流程的监督之下完成整个设计。还有一些人崇尚敏捷(agile),他们认为应该尽快交付软件,然后通过一系列短期的迭代来对软件进行完善,使其满足利益相关者的需求。这两派的关键分歧,在于开发者与利益相关者之间究竟是什么关系。BDUF派认为两者是契约关系,认为软件开发项目应该有一个正规的需求收集环节,而敏捷派则认为应该把软件的功能分成小块,只有在准备实现某个小块的时候,才需要去制定详细的需求,而且认为应该在当前这一小块完工之后,就尽快把可用的软件拿给利益相关者去看。他们希望能够从利益相关者那里不断地获得反馈意见,并据此对软件开发的走向持续进行微调,以便最终实现出正确的产品。笔者试着把这种敏捷开发方法讲给IT领域之外的人听,那些人觉得这不太可靠,然而敏捷派对BDUF派的批评,则确实引起了共鸣。因为利益相关者在没有看到实际运行的软件之前,确实不太了解他们当时提出的那个程序到底会做成什么样。合约并没有一种神奇的能力,可以保证做出来的IT程序一定会讨人喜欢。
前言
[第1章 情境驱动设计入门
1.1 对需求进行设计](https://yq.aliyun.com/articles/109062)
[1.2 什么是设计
1.2.1 专项的设计
1.2.2 有计划的设计
1.2.3 工程化的设计
1.2.4 设计方法小结](https://yq.aliyun.com/articles/109073)
1.3 像工程学那样来开发IT应用程序
1.4 重视IT架构
1.5 小结
[第2章 设计体系
2.1 为什么应该建立设计体系](https://yq.aliyun.com/articles/109290)
[2.2 情境设计
2.2.1 任务
2.2.2 用户组
2.2.3 数据表
2.2.4 任务之间的消息
2.2.5 任务之间的依赖关系
2.2.6 把所有元素统合起来
2.2.7 对情境设计做分析](https://yq.aliyun.com/articles/109296)
2.3 集成设计
2.4 技术设计
2.5 用户界面设计
2.6 数据库设计
2.7 实现
2.8 这样做真的是工程化的设计吗
2.9 小结
[第3章 复用现有的方法及做法
3.1 敏捷
3.1.1 个体与交互胜过流程与工具
3.1.2 可行的软件胜过繁杂的文档
3.1.3 客户协作胜过合同谈判
3.1.4 响应变化胜过遵循计划
3.1.5 小结](https://yq.aliyun.com/articles/109321)
3.2 逆向设计
[3.3 用例
3.3.1 原子性
3.3.2 设计层次不明确
3.3.3 用例本身比较模糊
3.3.4 大型的用例文档难以理解
3.3.5 用例对工程化的设计起不到帮助作用
3.3.6 小结](https://yq.aliyun.com/articles/109326)
3.4 成本估算问题
3.5 BDUF为什么如此笨重
3.6 迭代
3.7 品质
3.8 测试与检验
3.9 把现有的做法运用到情境驱动设计之中
3.10 学习型的组织
3.11 小结
第4章 大型应用程序所面临的问题
4.1 应用程序的大小体现在多个维度上
4.2 大型项目所面临的问题
4.2.1 需求问题
4.2.2 缺乏终端用户的支持
4.2.3 技术设计有问题
4.2.4 采购与外包
4.3 能够避免大型的项目吗
4.4 小结
第5章 应用程序与业务的关系
5.1 理解业务流程
5.2 不能表示为流程的应该怎么办
5.2.1 业务服务
5.2.2 资源管理
5.2.3 评审与监测
5.3 用更广阔的视角来观察
5.4 将商业策略运用到应用程序的开发中
5.4.1 开发速度
5.4.2 在成本、性能、可用性之间权衡
5.4.3 试验性的商业计划
5.4.4 利益要等多久才能变现
5.4.5 安全需求
5.4.6 针对现有的企业文化来做设计
5.4.7 为公司所追求的文化气氛而做设计
5.4.8 为计划的变更留出余地
5.4.9 为打造学习型的组织提供支持
5.4.10 非商务型的应用程序
5.5 分析
5.5.1 流程的格式是否正确
5.5.2 对依赖关系进行分析
5.5.3 目标分析
5.6 小结
第6章 应用程序与用户的关系
6.1 添加详情
6.1.1 任务细节
6.1.2 任务片段
6.1.3 共同目标组
6.1.4 数据表
6.1.5 消息
6.1.6 非功能型的需求
6.1.7 使用情境设计的人
6.2 确定各类用户
6.2.1 办理业务流程的用户
6.2.2 对工作进行监控的管理型用户
6.2.3 使用本程序数据的其他应用程序的用户
6.2.4 执行数据分析的用户
6.2.5 执行应用程序管理工作的用户
6.3 对情境设计进行分析
6.3.1 流程层面的分析
6.3.2 任务细节分析
6.3.3 数据表详情分析
6.3.4 用户组详情分析
6.3.5 消息详情分析
6.4 对情境设计进行评审
6.5 小结
第7章 应用程序与其他IT项目的关系
7.1 集成设计
7.1.1 应用程序
7.1.2 服务
7.1.3 数据库
7.2 服务接口设计
7.2.1 定义服务接口
7.2.2 设计可复用的服务
7.3 现有的应用程序
7.3.1 确定现有的应用程序
7.3.2 替换现有的应用程序
7.3.3 用现有的应用程序来制作服务
7.4 回顾设计流程
7.5 小结
第8章 用户界面设计与易用性
8.1 逻辑用户界面
8.2 把任务描述转化为单击操作
8.3 易用性
8.3.1 功能
8.3.2 信息
8.3.3 导航
8.3.4 文本
8.3.5 帮助
8.3.6 直观而亲切的应用程序
8.3.7 针对易用性进行设计
8.3.8 监测易用性
8.4 事务与任务完整性
8.5 用户界面设计与其他细节设计之间的关系
8.6 小结
第9章 数据库设计
9.1 数据库设计
9.2 数据库设计理论
9.3 程序员与数据库设计者之间的关系
9.4 数据访问服务
9.5 NoSQL
9.6 小结
第10章 技术设计的原则
10.1 单服务器环境下的高性能原则
10.1.1 缓存
10.1.2 多线程与多元处理
10.2 多服务器环境下的高性能原则
10.2.1 前端并行
10.2.2 后端并行
10.3 高弹性原则
10.4 测试与性能评估的必要性
10.5 技术设计的流程
10.6 小结
第11章 技术设计的结构
11.1 程序结构
11.2 什么是框架
11.3 各种编程语言
11.4 选择编程语言及框架
11.4.1 选择与公司的技能组合相匹配的语言
11.4.2 选择可以满足应用程序性能目标的语言
11.4.3 选择可以满足集成需求的语言
11.4.4 如果需要进行小组合作,请选择有利于小组合作的语言
11.4.5 在选择编程语言的同时,选择相应的版本控制软件及项目管理软件
11.4.6 选择与自己的开发方法相协调的语言
11.5 对框架进行扩展
11.6 实现通用的功能
11.7 小结
第12章 安全设计
12.1 IT应用程序的安全原则
12.1.1 认证
12.1.2 访问控制
12.1.3 用户管理
12.1.4 安全保护
12.1.5 安全监控
12.2 每一种设计之中的安全因素
12.2.1 情境设计
12.2.2 集成设计
12.2.3 用户界面设计
12.2.4 数据库设计
12.2.5 技术设计
12.3 安全编程
12.4 小结
第13章 应用程序开发展望
13.1 情境驱动设计如何改变应用程序开发
13.2 情境驱动设计的机遇
13.2.1 新工具
13.2.2 情境设计与驱动设计
13.2.3 用户界面设计与数据库设计
13.2.4 技术设计
13.3 应用程序开发所面对的挑战
13.3.1 灵活性
13.3.2 运营
13.3.3 正确性
13.3.4 品质
13.3.5 职业精神
13.4 小结
附录A 情境设计核对表
参考资料

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,云吞铺子总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系统盘、创建快照、配置安全组等操作如何登录ECS云服务器控制台? 1、先登录到阿里云ECS服务器控制台 2、点击顶部的“控制台” 3、通过左侧栏,切换到“云服务器ECS”即可,如下图所示 通过ECS控制台的远程连接来登录到云服务器 阿里云ECS云服务器自带远程连接功能,使用该功能可以登录到云服务器,简单且方便,如下图:点击“远程连接”,第一次连接会自动生成6位数字密码,输入密码即可登录到云服务器上。
31895 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
13793 0
阿里云服务器安全组设置内网互通的方法
虽然0.0.0.0/0使用非常方便,但是发现很多同学使用它来做内网互通,这是有安全风险的,实例有可能会在经典网络被内网IP访问到。下面介绍一下四种安全的内网互联设置方法。 购买前请先:领取阿里云幸运券,有很多优惠,可到下文中领取。
17440 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
17590 0
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
18094 0
10059
文章
0
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
OceanBase 入门到实战教程
立即下载
阿里云图数据库GDB,加速开启“图智”未来.ppt
立即下载
实时数仓Hologres技术实战一本通2.0版(下)
立即下载