请问如何分配安排一个大的程序

[爱吃肉的悟空]

第一次接受一个大工程，下面分大约15个大模块，我自己写了一个主逻辑（还没写完）

现在想根据每一个模块的输入输出写一个文档，请问这样的文档叫什么？

我希望开发人员看到我的文档之后就知道要怎么写函数，然后我直接拿过来拼接到我的逻辑中就可以了

[源代码大师]

得先学习项目技术管理，望采纳，不懂的可以关注私信我。

[顾小白xx]

引用 1 楼 丁劲犇 的回复:

函数级别的集成是颗粒度很小的集成了。按照你的“大工程‘理解，15个大的模块，要从下面几个方面考虑。 如果你做的是一种基于网络的信息化系统 1. 大工程的需求部分，是啥子。比如，远程医学，那就有各种工作台位和职能，牵扯到化验结果、影像、病案多种品类的数据交互和可视化呈现，还有管理层面的药计、财务审批等等。承担这些职能的GUI背后，是体现工作流中实体-对象约束的数据模型。因此，一般设计一个大的系统，可以从数据建模开始，把数据流程搞清楚，再考虑具体的呈现。 2.你的团队使用的工具链。是采用WEB的，还是C/S的。数据库本身选型，你的数据是关系的还是非关系的。团队能不能Hold住这些工具链，解决各种坑。有没有能力做独立的事务接口隔离数据仓库和前端？如果没有，又是互联网的公共环境，则额外要考虑安全问题。 3.如果不熟悉软件工程的标准开发流程，对UML不是很熟悉也无所谓。找几个妹子，深入到客户那里共同工作几个礼拜，和客户一起，把各个台位上应该有的界面的样子、行为用WPS或者Office的幻灯片变成界面示意图，按钮就是矩形，列表敲一些视图上去，按钮的跳转体现界面的跳转。每页的备注里，注明数据来源、提交结果的请求接口，或者直接标明SQL语句。 4.有了这些，就可以外包给各个团队了。 如果你做的是桌面版本的开发工具，比如CAD、Photoshop之类的专业的生产工具，则： 1. 切分主体工作的算法模块、可视化模块、数据后台。 2. 算法模块，抽象出接口。比如把所有图像处理都抽象为滤波、变换之类的矩阵操作。这里要考虑到你的团队的技术水平。一般用各种底层手段实现插件式可扩展的算法接口比较好。如果水平差，直接代码集成。如果水平好，或者几个开发部门需要独立保留知识产权，则进行一定的二进制封装。简单是DLL，复杂的可以做为本地服务或者RPC。考虑到工具链的兼容性，尽量使用标准CAPI接口，避免使用C++，以便未来升级时候，编译器版本的兼容性。 如果害怕扯皮，最好做成独立进程的后台服务，用DBUS或者消息总线通信，这样一个进程挂了，错误容易定位，边界清晰好测试。 3.界面模块，取决于你的工具链。基本现在主流的GUI都支持MVC，但如果把界面部分包给各个组，则存在风格、扯皮的问题。界面只做最基础的数据收集，和最末端的显示。所有非末端数据，都在算法里做完。比如，你要显示声音的频谱，则最后把要显示的FFT后的数据提交界面即可。 4. 数据部分：采用与工具链比较合拍的数据引擎。考虑到升级与部署，是用轻量的文件数据库(Sqlite)，绿色版本的All in one，还是独立的Sql Server。采用不同的结构，有可能影响到软件在不同环境下的部署。 对跨进程、跨机器的网络化的应用，建议不要从头开始设计你的交互协议，而采用数据库、消息队列等成熟的技术来完成交换。除非有能力Hold住协议设计和维护。

好厉害看的我一愣一愣的

[狐帝]

引用 楼主 施垚 的回复:

第一次接受一个大工程，下面分大约15个大模块，我自己写了一个主逻辑（还没写完） 现在想根据每一个模块的输入输出写一个文档，请问这样的文档叫什么？ 我希望开发人员看到我的文档之后就知道要怎么写函数，然后我直接拿过来拼接到我的逻辑中就可以了

你这个就是概要设计说明书，专门用来规定软件的架构、各组成部分之间的关系、各模块的主要功能和输入输出。如果再把各模块的详细算法逻辑写进去，那就是详细设计说明书。这两种文件的写法在GB8567中都有说明。

[跑马溜溜的山上]

函数级别的集成是颗粒度很小的集成了。按照你的“大工程‘理解，15个大的模块，要从下面几个方面考虑。 如果你做的是一种基于网络的信息化系统 1. 大工程的需求部分，是啥子。比如，远程医学，那就有各种工作台位和职能，牵扯到化验结果、影像、病案多种品类的数据交互和可视化呈现，还有管理层面的药计、财务审批等等。承担这些职能的GUI背后，是体现工作流中实体-对象约束的数据模型。因此，一般设计一个大的系统，可以从数据建模开始，把数据流程搞清楚，再考虑具体的呈现。 2.你的团队使用的工具链。是采用WEB的，还是C/S的。数据库本身选型，你的数据是关系的还是非关系的。团队能不能Hold住这些工具链，解决各种坑。有没有能力做独立的事务接口隔离数据仓库和前端？如果没有，又是互联网的公共环境，则额外要考虑安全问题。 3.如果不熟悉软件工程的标准开发流程，对UML不是很熟悉也无所谓。找几个妹子，深入到客户那里共同工作几个礼拜，和客户一起，把各个台位上应该有的界面的样子、行为用WPS或者Office的幻灯片变成界面示意图，按钮就是矩形，列表敲一些视图上去，按钮的跳转体现界面的跳转。每页的备注里，注明数据来源、提交结果的请求接口，或者直接标明SQL语句。 4.有了这些，就可以外包给各个团队了。 如果你做的是桌面版本的开发工具，比如CAD、Photoshop之类的专业的生产工具，则： 1. 切分主体工作的算法模块、可视化模块、数据后台。 2. 算法模块，抽象出接口。比如把所有图像处理都抽象为滤波、变换之类的矩阵操作。这里要考虑到你的团队的技术水平。一般用各种底层手段实现插件式可扩展的算法接口比较好。如果水平差，直接代码集成。如果水平好，或者几个开发部门需要独立保留知识产权，则进行一定的二进制封装。简单是DLL，复杂的可以做为本地服务或者RPC。考虑到工具链的兼容性，尽量使用标准CAPI接口，避免使用C++，以便未来升级时候，编译器版本的兼容性。 如果害怕扯皮，最好做成独立进程的后台服务，用DBUS或者消息总线通信，这样一个进程挂了，错误容易定位，边界清晰好测试。 3.界面模块，取决于你的工具链。基本现在主流的GUI都支持MVC，但如果把界面部分包给各个组，则存在风格、扯皮的问题。界面只做最基础的数据收集，和最末端的显示。所有非末端数据，都在算法里做完。比如，你要显示声音的频谱，则最后把要显示的FFT后的数据提交界面即可。 4. 数据部分：采用与工具链比较合拍的数据引擎。考虑到升级与部署，是用轻量的文件数据库(Sqlite)，绿色版本的All in one，还是独立的Sql Server。采用不同的结构，有可能影响到软件在不同环境下的部署。 对跨进程、跨机器的网络化的应用，建议不要从头开始设计你的交互协议，而采用数据库、消息队列等成熟的技术来完成交换。除非有能力Hold住协议设计和维护。

[跑马溜溜的山上]

另外，作为团队的Leader，准备一个基础的版本控制工具，比如Git、SVN是有效的，要求大家做Doxygen文档也是必要的。这样团队的进度，可以直接跟踪、回滚。如果大家在一个办公室，则很方便，直接当面沟通最有效。小团队，避免采用标准的软工的各种文档，会大量牵扯精力。