目前，我们一接到新需求，就马上直接在代码里改，然后自己稍微测试，就直接返回给客户，一个任务就算完成了。其实这里面有太多的隐患：你把需求理清了吗？需求之间的关联明确了？它对以前的功能有什么影响？能有更好的方法扩展新需求吗？没有新需求的文档，别人怎么知道你改了什么？没有设计描述，别人如何知道你怎么改的？如何移交项目？没有他人测试，你的改动是不是确实完成了任务？有没有引入新的问题？······等等。
我们扪心自问，我们的开发效率和质量如何？
软件开发的重点已经从技术转到管理和质量控制了。
我们应该如何管理和控制质量？
下图为《系统分析与设计方法（原书第6版）》FAST方法学的构件图。
系统参与者：
1> 系统所有者，为要构造和运行的系统付费，设置系统的目标和优先级；
2> 系统用户，为系统定义业务需求和预期；
3> 系统设计人员，将业务需求转换成可行的技术方案；
4> 系统构造人员，构造、部署和维护信息系统。
系统开发过程：
是一种活动、方法、最佳实践、交付成果和自动化工具，系统开发的关联人员用它们来开发和维护信息系统及软件。包括：
1> 系统启动，即确定问题、规划问题方案；
2> 系统分析，即分析和理解问题、确定方案需求和预期；
3> 系统设计，确定替代方案，选择最佳方案，设计所选方案；
4> 系统实现，实现所选方案，评估结构；
5> 系统支持和持续改进。
信息系统架构框架：
不同关联人员对信息系统具有不同的视角或视图，系统所有者和系统用户更关心：
1> 改进业务知识的目标。知识是信息和数据的产品。
2> 改进业务过程和服务的目标。
3> 改进业务通信和人际协作的目标。
系统设计人员和构造人员更技术化，他们更关注：
1> 支持企业积累和使用业务知识的数据库技术；
2> 自动化业务过程和服务的软件技术；
3> 支持业务通信和协作的接口技术。
“知识”构件
1> 系统所有者的“知识”视图：其使用与业务实体和规则有关的问题、机会和限制条件进行定义；
2> 系统用户的“知识”视图：用户是描述业务数据的专家，能对业务实体和规则进一步细化或者扩展；
3> 系统设计人员的“知识”视图：把系统所有者、系统用户的业务实体和规则转化成数据结构、数据库模式、域、索引等技术组成件；
4> 系统构造人员的“知识”视图：把概念数据库转换成物理数据库。
“过程”构件
1> 系统所有者的“过程”视图：业务功能；
2> 系统用户的“过程”视图：业务过程，即工作流；
3> 系统设计人员的“过程”视图：软件规格说明；
4> 系统构造人员的“过程”视图：应用程序。
“通信”构件
1> 系统所有者的“通信”视图：与各单位各部门的协作、与第三方系统的接口等；
2> 系统用户的“通信”视图：用户参与的输入和输出；
3> 系统设计人员的“通信”视图：用户界面和系统间的接口技术设计；
4> 系统构造人员的“通信”视图：使用“接口技术”构造、安装、测试并实现用户界面和系统间接口。
FAST方法学囊括系统关联人员、系统开发各阶段以及各关联人员在各阶段的视图，并提出多种可实践的方法。这样，在整个项目开发周期内，我们能十分明确的熟悉什么时候该做什么事，怎么做，有哪些方式方法和工具。同时，为项目管理、过程管理和质量控制提供了依据和考核手段。真是胸有成竹啊！
从上面信息系统构件图，我们能得出很多很多有用的信息。比如，从技术视角，可以得出，软件分四部分：数据存储、业务、网络（接口）通信、用户交互（接口）。进一步分析得出，数据存储——即SQL数据库、Oracle数据库、Access数据库、二进制文件、文本文件等数据存储技术；网络——网口、串口、CAN等网络通信技术；用户交互——WinForm、GID/GDI+、浏览器等交互技术；至于业务，即实际开发的项目的业务规则。这样分解，为初学者提供了学习方向。进一步得出，前三者都是可复用的成熟的技术，所以成熟的软件企业有了技术积累，做的就不是技术，而是业务，业务，业务。同时得出，一个有经验的程序员，一般技术已经不是问题，开发项目的难点是管理和质量控制，而对象就是能熟练的分析和理解业务需求。