软件项目标准开发流程.doc

1、1、需求分析是怎样做的？（自己理解着说） 需求分析是构建软件系统的一个重要过程。 一般，把需求类型分成三个类型： 1、业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。 2、用户需求 (user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。 3、功能需求 (functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务， 从而满足了业务需求。 业务需求和用户需求是软件需求分析的基础，也是软件构建的前提

2、。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨 ,使系统更加详尽 ,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。 4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。 客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情

3、况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。 总结： 良好的需求分析是软件成功的基础。以上是作者对需求分析工作实践的一次小结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一 步得以提高。 2、 6 周 （比较合理的代码行数是多少，如果多了，我是怎么切割的） 500 行，例如：实现数据3、如何将用户登录的信息保存？ 用户登陆页面将每个用户的信息使用 session 保存下来 , 例如 : session.setAttrib

4、ute(“UserID“,“ytang“); 如果用到用户的登陆信息，再从 session 根据 session.getAttribute(“userID“)所存储的信息 例如在项目 1 中的应用 4软件项目开发流程应该是什么样子的？ 1。需求分析和获取； 2。界面的设 计和修改，直到用户可以接受； 3。后台数据库的建立，做成几张表，写几个存储过程； 4。前台模块的编写和调试； 5。项目的实施和维护； 5、 有哪些人员干什么工作，你参与过什么工作？ 1、项目经理 2、系统分析员 3、开发人员 4、测试人员 5、维护培训人员 1、项目经理：具备项目管理经验，领导才能，协调能力，丰富的技术知识，善

5、于与用户沟通协调，能够承担工作压力 2、系统分析员：具备丰富的行业应用知识，系统分析设计能力，具备丰富的项目开发经验，做过多种软件系统，熟悉系统分析设计规范 3、开发人员：具备专业 开发技术，熟练掌握一种开发工具，熟知常见的各种管理系统的开发过程，能够读懂设计文档和需求文档，有很好的编码规范和习惯，善于沟通和交流 4、测试人员：熟知各种测试技术，熟练掌握一种工具，具备丰富的项目开发经验，熟知测试规范 5、维护培训人员：熟悉操作系统配置管理，具备基本的网络知识，善于编写培训手册，善于讲解，能够很好地与用户沟通，熟知项目开发过程 6、 你是怎样设计 o/r-mappinmg 的。 用 Hibern

6、ate 实现 。例如在 Letdoo 网的开发中，用户和他对应的爱好，我使用了多对多映射的方式，这种方 式在数据库中体现出来的是，产生一个关联表，存放用户 id 和爱好 id的对应关系。（在映射文件中的体现是，在每个类的映射中都建立与关联表的对应关系） 7、 第一个项目中用户权限你是怎么设计的？ 需求陈述 不同职责的人员，对于系统操作的权限应该是不同的。 优秀的业务系统，这是最基本的功能。 可以对 “ 组 ” 进行权限分配 。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对 “ 组 ” 进行操作的概念，将权限一致的

7、人员编入同一组，然后对该组进行权限分配。 权 限管理系统应该是可扩展的 。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。 传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 关于设计 在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是 “ 组 ” 操作的概念，还是整套 权限管理系统的重用性，都在于数据

8、库的设计。 首先， action 表（ 以下简称为 “ 权限表 ” ）， gorupmanager 表（ 以下简称为 “ 管理组表 ” ），以及master 表（ 以下简称为 “ 人员表 ” ），是三张实体表，它们依次记录着 “ 权限 ” 的信息， “ 管理组 ” 的信息和 “ 人员 ” 的信息 。 这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。 由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使 用另外两张表来完成。而这两张表起着映射的作用，分别是

9、 “actiongroup” 表 （以下简称 “ 权限映射表 ” ） 和 “mastergroup” 表 （以下简称 “ 人员映射表 ” ） ，前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。 另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是 “ 权限分栏表 ” 。 综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住 “ 变更 ” 考验的。 此套系统的重点在于，三张 实体表 牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其 难点在于，理解映射表的工作，它记录着关系，并且实现了 “ 组 ” 操作的概念。而系统总体的设

10、计是本着可以在不同的 MIS 系统中 “ 重用 ” 来满足不同系统的功能权限设置。 1、需求分析是怎样做的？（自己理解着说） 需求分析是构建软件系统的一个重要过程。 一般，把需求类型分成三个类型： 1、业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。 2、用户需求 (user requirement) 文档描述了用户使用产品必须要完成的任务，这在使 用实例文档或方案脚本说明中予以说明。 3、功能需求 (functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任

11、务，从而满足了业务需求。 业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨 ,使系统更加详尽 ,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。 4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。 客户的负面影响可能对于能够在预算内按时完成项目产生很大的

12、影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。 总结： 良好的需求分析是软件成功的基础。以上是作者对需求分析工作实践的一次小结以及综合性的思考，是对需 求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一步得以提高。 2、 6 周 （比较合理的代码行数是多少，如果多了，我是怎么切割的） 500 行，例如：实现数据3、如何将用户登录的信息保存？ 用户登陆页面将每个用户的

13、信息使用 session 保存下来 , 例如 : session.setAttribute(“UserID“,“ytang“); 如果用到用户的登陆信息，再从 session 根据 session.getAttribute(“userID“)所存储的信息 例如在项目 1 中的应用 4软件项目开发流程应该是什么样子的？ 1。需求分析和获取； 2。界面的设计和修改，直到用户可以接受； 3。后台数据库的建立，做成几张表，写几个存储过程； 4。前台模块的编写和调试； 5。项目的实施和维护； 5、 有哪些人员干什么工作，你参与过什么工作？ 1、项目经理 2、系统分析员 3、开发人员 4、测试人员 5、维

14、护培训人员 1、项目经理：具备项目管理经验，领导才能，协调能力，丰富的技术知识，善于与用户沟通协调，能够承担工作压力 2、系统分析员：具备丰富的行业应用知识，系统分析设计能力，具备丰富的项目开发经验，做过多种软件系统，熟悉系统分析设计规范 3、开发人员：具备专业开发技术，熟练掌握一种开发工具，熟知常见的各种管理系统的开发过程，能够读懂设计文档和需求文档，有很好的编码规范和习惯，善于沟通和交流 4、测试人员：熟知各种测试技术，熟练掌握一种工具，具备丰富的项目开发经验，熟知测试规范 5、维护培训人员：熟悉操作系 统配置管理，具备基本的网络知识，善于编写培训手册，善于讲解，能够很好地与用户沟通，熟知

15、项目开发过程 6、 你是怎样设计 o/r-mappinmg 的。 用 Hibernate 实现 。例如在 Letdoo 网的开发中，用户和他对应的爱好，我使用了多对多映射的方式，这种方式在数据库中体现出来的是，产生一个关联表，存放用户 id 和爱好 id的对应关系。（在映射文件中的体现是，在每个类的映射中都建立与关联表的对应关系） 7、 第一个项目中用户权限你是怎么设计的？ 需求陈述 不同职责的人员，对于系统操作的权限应该是不同的。 优秀的业务 系统，这是最基本的功能。 可以对 “ 组 ” 进行权限分配 。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时

16、且不够方便的事情。所以，系统中就提出了对 “ 组 ” 进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的 。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。 传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而 另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 关于设计 在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及

17、其重要，无论是 “ 组 ” 操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 首先， action 表（ 以下简称为 “ 权限表 ” ）， gorupmanager 表（ 以下简称为 “ 管理组表 ” ），以及master 表（ 以下简称为 “ 人员表 ” ），是三张实体表，它们依次记录着 “ 权限 ” 的信息， “ 管理组 ” 的信息和 “ 人 员 ” 的信息 。 这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。 由于这三张表之间存在着多对多的关系

18、，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是 “actiongroup” 表 （以下简称 “ 权限映射表 ” ） 和 “mastergroup” 表 （以下简称 “ 人员映射表 ” ） ，前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。 另外，还需 要一张表来控制系统运行时左侧菜单中的权限分栏，也就是 “ 权限分栏表 ” 。 综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住 “ 变更 ” 考验的。 此套系统的重点在于，三张 实体表 牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理

19、解映射表的工作，它记录着关系，并且实现了 “ 组 ” 操作的概念。而系统总体的设计是本着可以在不同的 MIS 系统中 “ 重用 ” 来满足不同系统的功能权限设置。 1、需求分析是怎样做的？（自己理解着说） 需求分析是构建软件系统的一个重要过程。 一般，把需求类 型分成三个类型： 1、业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。 2、用户需求 (user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。 3、功能需求 (functional

20、requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过 对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨 ,使系统更加详尽 ,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。 4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常

21、陷入客户自己的矛盾之中。 客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需 要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。 总结： 良好的需求分析是软件成功的基础。以上是作者对需求分析工作实践的一次小结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一步得以提高。 2、 6 周 （比较合理的代码行数是多少，如果多了，我是怎么切割的）

22、500 行，例如 ：实现数据3、如何将用户登录的信息保存？ 用户登陆页面将每个用户的信息使用 session 保存下来 , 例如 : session.setAttribute(“UserID“,“ytang“); 如果用到用户的登陆信息，再从 session 根据 session.getAttribute(“userID“)所存储的信息 例如在项目 1 中的应用 4软件项目开发流程应该是什么样子的？ 1。需求分析和获取； 2。界面的设计和修改，直到用户可以接受； 3。后台数据库的建立，做成几张表，写几个存储过程； 4。前台模块的 编写和调试； 5。项目的实施和维护； 5、 有哪些人员干什么工作

23、，你参与过什么工作？ 1、项目经理 2、系统分析员 3、开发人员 4、测试人员 5、维护培训人员 1、项目经理：具备项目管理经验，领导才能，协调能力，丰富的技术知识，善于与用户沟通协调，能够承担工作压力 2、系统分析员：具备丰富的行业应用知识，系统分析设计能力，具备丰富的项目开发经验，做过多种软件系统，熟悉系统分析设计规范 3、开发人员：具备专业开发技术，熟练掌握一种开发工具，熟知常见的各种管理系统的开发过程，能够读懂设计文档和需求文档，有 很好的编码规范和习惯，善于沟通和交流 4、测试人员：熟知各种测试技术，熟练掌握一种工具，具备丰富的项目开发经验，熟知测试规范 5、维护培训人员：熟悉操作系

24、统配置管理，具备基本的网络知识，善于编写培训手册，善于讲解，能够很好地与用户沟通，熟知项目开发过程 6、 你是怎样设计 o/r-mappinmg 的。 用 Hibernate 实现 。例如在 Letdoo 网的开发中，用户和他对应的爱好，我使用了多对多映射的方式，这种方式在数据库中体现出来的是，产生一个关联表，存放用户 id 和爱好 id的对应关系。（在映射文件中的体现 是，在每个类的映射中都建立与关联表的对应关系） 7、 第一个项目中用户权限你是怎么设计的？ 需求陈述 不同职责的人员，对于系统操作的权限应该是不同的。 优秀的业务系统，这是最基本的功能。 可以对 “ 组 ” 进行权限分配 。对

25、于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对 “ 组 ” 进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的 。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不 断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。 传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 关于设计 在设计阶段，系统设计人员无须考虑

26、程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是 “ 组 ” 操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 首先， action 表（ 以下简称为 “ 权限表 ” ）， gorupmanager 表（ 以下简称为 “ 管理组表 ” ），以及master 表（ 以下简称为 “ 人员表 ” ），是三张实体表，它们依次记录着 “ 权限 ” 的信息， “ 管理组 ” 的信息和 “ 人员 ” 的信息 。 这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多

27、个管理组，而一个管理组中也可能同时包含多个人员。 由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是 “actiongroup” 表 （以下简称 “ 权限 映射表 ” ） 和 “mastergroup” 表 （以下简称 “ 人员映射表 ” ） ，前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。 另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是 “ 权限分栏表 ” 。 综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住 “ 变更 ” 考验的。 此套系统的重点在于，三张 实体表 牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理解映射表的工作，它记录着关系，并且实现了 “ 组 ” 操作的概念。而系统总体的设计是本着可以 在不同的 MIS 系统中 “ 重用 ” 来满足不同系统的功能权限设置。