5,388
社区成员
发帖
与我相关
我的任务
分享分布式协作开发
我在计划写一个分布式软件协作开发环境，但不知道现在的分布式软件开发中究竟有些什么需求,我希望这个系统既能够适应大教堂和市集等不同的分式布开发模式，也能够适应商业上的分布式开发和开放源码的分布式开发，我真的希望这个系统能够在实际中发挥出它的用处来。希望大家能给我点建议，万分感激。
下面是我的一些想法：
目的和需求：
大规模的软件必然是通过团队的力量来产生。在集中的环境下由于参与整个项目的工作人员可以很方便地交流及共享某些资源，很容易管理，但在分布式环境下就必须要有一个可靠的环境来支持整个软件的开发过程，协调各工作人员之间的工作。据我现有的资料分析，这种需求可能包括以下几个方面：
1、 交流
2、 资料库管理
3、 开发流程管理
4、 安全性
所以本软件的目的是实现分布式环境下对协作开发的支持。
详细分析：
一、 交流
交流可能是软件协作开发过程中最重要的一部分，为此我准备提供以下几种办法：
1、 公告板。公告板是用来发送通告的地方。每个人都会收到这种通告，目的是让每个人能及时了解最新的更新信息，它分为系统通告和用户通告两种。用户通告是由开发组内的人员发送的；系统通告则是系统本身发出，提示某些资料的更新及进度的完成情况。例如：市场调查人员在文档区（下面叙述）发布了一份新的调查报告，这时系统就会自动发送这条通告，让每个人知道这一更新信息。该公告板的信息会被长期保存到数据库中。
2、 会议室。会议室是一个在线讨论的地方。人们在这里发表言论，讨论开发的问题。这里很像一个聊到室，但我想让它能够在上面发送HTML的文本（假若不能，就外加一缓冲来存放非文本信息）。讨论记录会保留一段时间（例如一个星期）来允许工作人员作出会议记录，但不会长期保存，当这些记录被删除时将会发出一系统通告。
3、 在线呼叫。这是一种即时呼叫方式，类似于ICQ，它允许开发人员作出即时的交流。提供的功能与会议室类似，但所有的信息均不被保留也不发系统通告。
4、 电子邮件。当呼叫人不在时使用的另一种通讯方式，但本系统不提供任何的邮件客户或服务器，所有这些功能均通过外部程序来完成。
二、 资料库管理
资料库管理主要分开源代码区，发布区，文档区和共享资料库。管理员也可以另外建立新的区域来存放不同的数据。但这些新建区域都将与文档区使用相同的结构。
1、 源代码区。源代码区之所以分开是因为它要提供版本控制的功能。这里保留的只是开发过程的中间版本，而不是最终版本。最终版本将会在发布区中发布。提供该区域的目的是利于程序员能够得到自己每一次的修改信息。由于这里要提供版本控制，而不是一般的数据库，所以我打算采用GNU的CVS系统。这里不发送系统通告。
2、 发布区。显然，这里将会保存开发人员完成的最终版本。如：源代码，组件，二进制数据，用户手册等等。可按发布时间，开发作者，名称，版本号等来分类索引查询。索引信息将会保存到服务器端的数据库中，但具体文件内容将会保存在服务器端的文件系统中。当每一版本发布时将发出一系统通告。
3、 文档区。这里记录了不同开发阶段，不同角色所产出的文档。可根据需要作出进一步的分类。当中可能有市场调查报告，开发模型论述，用户手册等等。也按时间，作者，名称等来分类索引。索引信息保存在服务器端的数据库中，具体文档内容保存在服务器端的文件系统中。
4、 共享资料库。这里保存的是开发组的一些共享开发资料。例如：开发库，第三方组件，参考手册等等。它们都是以文件存储于服务器中。必然的索引信息及描述将保存到数据库。因为里面很多资料很可能是以URL的形式存在于别的服务器上。
这些资料大部分以压缩的形式存在于服务器上，而且均可设置它们的读、写权限，以允许本开发组成员或其它工作组的成员访问（参看安全性）。
三、 开发流程管理
开发流程的管理中我借用了RUP（Rational Unified Process）的二维结构。因为我觉得分布式协作环境必须能够使用现代软件工程的思想，有科学、合理的组织和管理模式，即使这种模式是因不同的企业而异的。
1、 进度表（横轴）。进度表预示着整个开发的计划流程。这是由项目经理来制定，各个工作人员都必须充分了解的。里面保存着开发各阶段的起始时间，预期目的，完成情况及总结信息。既预示着未来，也记录着历史。系统会根据各阶段的接近，完成来发出相应的通告，项目经理也能根据实际情况对进度表进行调整。这些信息将长期保存。
2、 工作流（纵轴）。工作流是项目主管建立的一系列并行的工作序列。如RUP中就提及到分析设计工作流，实现工作流，测试工作流，分发工作流等9个核心工作流。在这些工作流中项目主管将会定义不同角色将要在何时完成何种任务，目标是什么，产物是什么，以及必要时会同步这些工作流。系统通告也会来协助这一过程。例如实现工作流，项目主管通过查看某程序员的任务状态，知道他前面的任务已经完成，于是主管给他一个新的任务，要求他在规定时间内写出实现某一功能的类。这时系统就会把这一任务放入该程序员的任务属性中，同时系统通告也会给该程序员发出一信息，让程序员能够知道这种变化。完成后他将这一任务提交，至此任务完成。这个过程的产出或者程序的中间版本会相应地保存到源代码区和发布区。系统会记录程序这一切的过程。当以后要查看这些历史时，则可通过时间，角色以及产物等来进行多方面的索引查询。
这2点想法是我对RUP的抽象。但是不同的公司其开发模式必定不相同，所以我在这里只是提供了一个载体及模板，而不能够限制其活动。
四、 安全性
安全性显然有着至关重要的意义。除了软件本身的结构，服务器及数据库的安全外，我提供以下两种控制方法：
1、 对于组内成员，项目主管可以根据成员的工作性质而把成员划分到组来进行管理。可以设定各组员的登录帐号及密码，各成员或小组对于上述各个区域的权限。同时可以添加或删除组员，设定各组员的一些参数，如e-mail等。这样方便开发过程中突然的人员变更。
2、 对于组外成员，即需要相互交流合作的工作组（如Windows工作组与Office工作组），则提供一种组与组之间的信赖关系，使组外成员可以访问由权限设定的某些资料，如共享资料库。
实现概要：
本软件的实现我打算采用CORBA来作为中间件，既支持C/S模式，也支持对等模式。一切的中间接口都用IDL来定义，使每一部分都具有分布的可移动性。其中Server将利用Linux作为操作系统，Client将暂且使用Windows，但以后可能会发展到其它平台。具体的实现过程有待以后详细研究。
下面是我的一些想法：
目的和需求：
大规模的软件必然是通过团队的力量来产生。在集中的环境下由于参与整个项目的工作人员可以很方便地交流及共享某些资源，很容易管理，但在分布式环境下就必须要有一个可靠的环境来支持整个软件的开发过程，协调各工作人员之间的工作。据我现有的资料分析，这种需求可能包括以下几个方面：
1、 交流
2、 资料库管理
3、 开发流程管理
4、 安全性
所以本软件的目的是实现分布式环境下对协作开发的支持。
详细分析：
一、 交流
交流可能是软件协作开发过程中最重要的一部分，为此我准备提供以下几种办法：
1、 公告板。公告板是用来发送通告的地方。每个人都会收到这种通告，目的是让每个人能及时了解最新的更新信息，它分为系统通告和用户通告两种。用户通告是由开发组内的人员发送的；系统通告则是系统本身发出，提示某些资料的更新及进度的完成情况。例如：市场调查人员在文档区（下面叙述）发布了一份新的调查报告，这时系统就会自动发送这条通告，让每个人知道这一更新信息。该公告板的信息会被长期保存到数据库中。
2、 会议室。会议室是一个在线讨论的地方。人们在这里发表言论，讨论开发的问题。这里很像一个聊到室，但我想让它能够在上面发送HTML的文本（假若不能，就外加一缓冲来存放非文本信息）。讨论记录会保留一段时间（例如一个星期）来允许工作人员作出会议记录，但不会长期保存，当这些记录被删除时将会发出一系统通告。
3、 在线呼叫。这是一种即时呼叫方式，类似于ICQ，它允许开发人员作出即时的交流。提供的功能与会议室类似，但所有的信息均不被保留也不发系统通告。
4、 电子邮件。当呼叫人不在时使用的另一种通讯方式，但本系统不提供任何的邮件客户或服务器，所有这些功能均通过外部程序来完成。
二、 资料库管理
资料库管理主要分开源代码区，发布区，文档区和共享资料库。管理员也可以另外建立新的区域来存放不同的数据。但这些新建区域都将与文档区使用相同的结构。
1、 源代码区。源代码区之所以分开是因为它要提供版本控制的功能。这里保留的只是开发过程的中间版本，而不是最终版本。最终版本将会在发布区中发布。提供该区域的目的是利于程序员能够得到自己每一次的修改信息。由于这里要提供版本控制，而不是一般的数据库，所以我打算采用GNU的CVS系统。这里不发送系统通告。
2、 发布区。显然，这里将会保存开发人员完成的最终版本。如：源代码，组件，二进制数据，用户手册等等。可按发布时间，开发作者，名称，版本号等来分类索引查询。索引信息将会保存到服务器端的数据库中，但具体文件内容将会保存在服务器端的文件系统中。当每一版本发布时将发出一系统通告。
3、 文档区。这里记录了不同开发阶段，不同角色所产出的文档。可根据需要作出进一步的分类。当中可能有市场调查报告，开发模型论述，用户手册等等。也按时间，作者，名称等来分类索引。索引信息保存在服务器端的数据库中，具体文档内容保存在服务器端的文件系统中。
4、 共享资料库。这里保存的是开发组的一些共享开发资料。例如：开发库，第三方组件，参考手册等等。它们都是以文件存储于服务器中。必然的索引信息及描述将保存到数据库。因为里面很多资料很可能是以URL的形式存在于别的服务器上。
这些资料大部分以压缩的形式存在于服务器上，而且均可设置它们的读、写权限，以允许本开发组成员或其它工作组的成员访问（参看安全性）。
三、 开发流程管理
开发流程的管理中我借用了RUP（Rational Unified Process）的二维结构。因为我觉得分布式协作环境必须能够使用现代软件工程的思想，有科学、合理的组织和管理模式，即使这种模式是因不同的企业而异的。
1、 进度表（横轴）。进度表预示着整个开发的计划流程。这是由项目经理来制定，各个工作人员都必须充分了解的。里面保存着开发各阶段的起始时间，预期目的，完成情况及总结信息。既预示着未来，也记录着历史。系统会根据各阶段的接近，完成来发出相应的通告，项目经理也能根据实际情况对进度表进行调整。这些信息将长期保存。
2、 工作流（纵轴）。工作流是项目主管建立的一系列并行的工作序列。如RUP中就提及到分析设计工作流，实现工作流，测试工作流，分发工作流等9个核心工作流。在这些工作流中项目主管将会定义不同角色将要在何时完成何种任务，目标是什么，产物是什么，以及必要时会同步这些工作流。系统通告也会来协助这一过程。例如实现工作流，项目主管通过查看某程序员的任务状态，知道他前面的任务已经完成，于是主管给他一个新的任务，要求他在规定时间内写出实现某一功能的类。这时系统就会把这一任务放入该程序员的任务属性中，同时系统通告也会给该程序员发出一信息，让程序员能够知道这种变化。完成后他将这一任务提交，至此任务完成。这个过程的产出或者程序的中间版本会相应地保存到源代码区和发布区。系统会记录程序这一切的过程。当以后要查看这些历史时，则可通过时间，角色以及产物等来进行多方面的索引查询。
这2点想法是我对RUP的抽象。但是不同的公司其开发模式必定不相同，所以我在这里只是提供了一个载体及模板，而不能够限制其活动。
四、 安全性
安全性显然有着至关重要的意义。除了软件本身的结构，服务器及数据库的安全外，我提供以下两种控制方法：
1、 对于组内成员，项目主管可以根据成员的工作性质而把成员划分到组来进行管理。可以设定各组员的登录帐号及密码，各成员或小组对于上述各个区域的权限。同时可以添加或删除组员，设定各组员的一些参数，如e-mail等。这样方便开发过程中突然的人员变更。
2、 对于组外成员，即需要相互交流合作的工作组（如Windows工作组与Office工作组），则提供一种组与组之间的信赖关系，使组外成员可以访问由权限设定的某些资料，如共享资料库。
实现概要：
本软件的实现我打算采用CORBA来作为中间件，既支持C/S模式，也支持对等模式。一切的中间接口都用IDL来定义，使每一部分都具有分布的可移动性。其中Server将利用Linux作为操作系统，Client将暂且使用Windows，但以后可能会发展到其它平台。具体的实现过程有待以后详细研究。
...全文
请发表友善的回复…
发表回复
