软件开发流程概要(笔记)
2008-04-06 02:01
316 查看
一、Feature List(功能列表) 和Use Case Diagrams(用例图)
需求分析的第一步要么是确定功能列表(Feature List),要么是得出用例图(Use Case Diagrams)。
不断的和用户交流,界定清楚各个主要的Feature和主要的用例,尽可能的准确界定系统需要做到的和实现的功能。
不必追求一次得到完整的列表或用例,随着迭代次数的增加,自然会得到完善的。这样你就清楚系统需要做些什么以及用户会如何使用这个系统。
二、Break Up the Problem(瓦解问题)
知道要做些什么功能后,就把这些功能按照相互关系进行分类,把系统分成几个模块。
尽量使模块之间的交互减少,接口清晰(应用像封装,单责任等OO的设计原则)。
一个规模比较大的系统,如果有科学的模块划分,能很大程度上提高并行开发的效率,减少由于某个模块交付延期对于其他模块的影响。
三、Requirement(需求)
开始某个功能或用例开发之前,需要对问题有准确的理解,然后再次和用户交流,进行针对某个细化用例或功能的分解。第一次迭代时,功能点或用例的选取就要找最根本的,最核心的,被别的部分依赖最多的一个来开始进行开发的迭代。
这里就有两种开发模式:功能驱动(Feature Driven)或是用例驱动(Use Case Driven)。
功能驱动开发颗粒度比用例驱动要小一些。选择哪一种路径决定下一步得到什么。
选择用例驱动就要写用例(Use Case),用例有很多种表现形式:用例图、自然语言描述、步骤分解等。最终都要把主要路径,其他路径都能包括进来,也就是各种场景(Scenario)都要包括。
用例的用处是为了和用户进行交流,以用户熟悉的方式,确认我们对于需求的理解是正确的,完整的。
四、Domain Analysis(领域分析) 和Design(设计)
领域分析:是指把用例中名词和最终系统中的实体类进行映射,动词和方法进行映射。
当然这种映射没有一一对应的关系,需要根据具体情况进行增删改。最终把这些类和方法组装成类图(Class Diagram)。类图是软件开发中一个关键的中间产品,能够让其他关心你系统的程序员快速的对系统架构有整体的了解。
系统[b]设计:[/b]也就是参照实际情况和一些设计原则、设计模式,对类图上的各个类进行分解、组合、抽象、细化等操作。一个结构合理,功能清晰,兼顾维护性和扩展性的类图对于后续开发工作的贡献是不言而喻的。
五、Implementation(实现)
实现看起来只是参照类图和其他的现有代码,进行一些类似堆叠代码的工作,其实却远不止如此。第一、需要有良好的编码风格,使代码具有很好的可读性。
第二、要有足够的单元测试保证(现在测试驱动(Test Driven)已经非常受重视)。
第三、要考虑代码重用,能够最大限度的采用已有方法或算法进行功能的实现。
第四、要有随时重构(Refactoring)的意识,以保证代码能够在不断增长的过程中保持简洁、高效、可读、可维护、可扩展、可重用。
第五、对于OO的基本规则,要有切合实际的应用(比如:OCP,SRP,DRY等这些规则)。
六、Iteration(迭代)
一般是在实现完一个功能或是用例之后,再选取另一个功能或用例应用前几个步骤进行迭代的开发,直到所有的功能或用例全部实现。
其中可能会不时的对系统的功能列表、用例图等进行修改和更新。也就需要和客户有通畅清晰的沟通,保证所开发的系统就是用户所想要的。
七、Delivery(交付)
有了以上这些步骤的保证,最终就可以把软件进行交付。
学习来源:/article/5765603.html
需求分析的第一步要么是确定功能列表(Feature List),要么是得出用例图(Use Case Diagrams)。
不断的和用户交流,界定清楚各个主要的Feature和主要的用例,尽可能的准确界定系统需要做到的和实现的功能。
不必追求一次得到完整的列表或用例,随着迭代次数的增加,自然会得到完善的。这样你就清楚系统需要做些什么以及用户会如何使用这个系统。
二、Break Up the Problem(瓦解问题)
知道要做些什么功能后,就把这些功能按照相互关系进行分类,把系统分成几个模块。
尽量使模块之间的交互减少,接口清晰(应用像封装,单责任等OO的设计原则)。
一个规模比较大的系统,如果有科学的模块划分,能很大程度上提高并行开发的效率,减少由于某个模块交付延期对于其他模块的影响。
三、Requirement(需求)
开始某个功能或用例开发之前,需要对问题有准确的理解,然后再次和用户交流,进行针对某个细化用例或功能的分解。第一次迭代时,功能点或用例的选取就要找最根本的,最核心的,被别的部分依赖最多的一个来开始进行开发的迭代。
这里就有两种开发模式:功能驱动(Feature Driven)或是用例驱动(Use Case Driven)。
功能驱动开发颗粒度比用例驱动要小一些。选择哪一种路径决定下一步得到什么。
选择用例驱动就要写用例(Use Case),用例有很多种表现形式:用例图、自然语言描述、步骤分解等。最终都要把主要路径,其他路径都能包括进来,也就是各种场景(Scenario)都要包括。
用例的用处是为了和用户进行交流,以用户熟悉的方式,确认我们对于需求的理解是正确的,完整的。
四、Domain Analysis(领域分析) 和Design(设计)
领域分析:是指把用例中名词和最终系统中的实体类进行映射,动词和方法进行映射。
当然这种映射没有一一对应的关系,需要根据具体情况进行增删改。最终把这些类和方法组装成类图(Class Diagram)。类图是软件开发中一个关键的中间产品,能够让其他关心你系统的程序员快速的对系统架构有整体的了解。
系统[b]设计:[/b]也就是参照实际情况和一些设计原则、设计模式,对类图上的各个类进行分解、组合、抽象、细化等操作。一个结构合理,功能清晰,兼顾维护性和扩展性的类图对于后续开发工作的贡献是不言而喻的。
五、Implementation(实现)
实现看起来只是参照类图和其他的现有代码,进行一些类似堆叠代码的工作,其实却远不止如此。第一、需要有良好的编码风格,使代码具有很好的可读性。
第二、要有足够的单元测试保证(现在测试驱动(Test Driven)已经非常受重视)。
第三、要考虑代码重用,能够最大限度的采用已有方法或算法进行功能的实现。
第四、要有随时重构(Refactoring)的意识,以保证代码能够在不断增长的过程中保持简洁、高效、可读、可维护、可扩展、可重用。
第五、对于OO的基本规则,要有切合实际的应用(比如:OCP,SRP,DRY等这些规则)。
六、Iteration(迭代)
一般是在实现完一个功能或是用例之后,再选取另一个功能或用例应用前几个步骤进行迭代的开发,直到所有的功能或用例全部实现。
其中可能会不时的对系统的功能列表、用例图等进行修改和更新。也就需要和客户有通畅清晰的沟通,保证所开发的系统就是用户所想要的。
七、Delivery(交付)
有了以上这些步骤的保证,最终就可以把软件进行交付。
学习来源:/article/5765603.html
相关文章推荐
- 软件开发流程概要(笔记)
- 软件开发流程概要(笔记)
- 软件产品开发流程概要总结
- STM32学习笔记之软件开发流程
- 软件开发过程学习笔记(一)之软件开发流程 分类: 开发过程 2015-07-08 12:43 9人阅读 评论(0) 收藏
- 软件开发过程学习笔记(一)之软件开发流程
- 软件开发过程学习笔记之软件开发流程
- 软件开发流程概要(1)-《Head First OOA&D》读书笔记
- 软件工程基础学习笔记--软件开发模型
- 【PM】信息化系统软件开发流程
- 软件开发的流程及微软的产品开发实践(节选)
- 构建高效软件开发流程和团队 [转]
- 软件开发流程
- 软件开发流程
- 游戏系统开发笔记(二)——开发流程和项目管理
- 敏捷开发:高效软件开发之道 (学习笔记1)
- 软件开发流程
- 软件项目开发流程
- 软件项目开发流程及配置人员
- 工作笔记2.软件开发常用工具