软件工程文档怎么写 大学生软件开发项目
- 作者: 奇花易操
- 来源: 51数据库
- 2020-04-15
软件工程文档如何管理？
文档管理混乱是上个项目最为致命和混乱的，我个人认为，如果一个项目小组进行开发一个系统的时候没有文档的开发个人认为是可怕的，而在系统的开发中没有对文档进行有效管理是恐怖的，我们要做的是一个产品，而不是自娱自乐的一个试验品，作为产品，必须要标准，无论是客户给我们的标准还是开发小组给自己的标准，关于标准将在后面做详细讨论。
而有标准就必要有相关的文档，关于文档的好处大家都清除，无论在软件开发部署以及维护的任何阶段它都扮演着很重要的角色，关于文档我觉得它不是形式一个开发小组的负责人对文档的态度就觉得乐这个系统的成败（说的夸张些）。
除了认真做各个阶段的相关文档外，还要对文档进行有效管理，下面将说一下这几年来对文档管理的一些开发，仅仅是抛砖引玉，欢迎大家补充和牌砖。
1文档必须需要版本。
像软件一样，如果不对文档进行版本管理和控制，文档的修改将造成文档的混乱，尤其是比较大的项目，一定对文档的管理进行版本控制，不然每次文档修改，想找到什么时候做乐什么修改，为什么做这次的修改都搞不清楚，后面的程序员的工作就很难开展。
2文档需要专人负责。
如果一个小组的人手足够多的话，希望能有一个人来专门负责对文档管理，如果开发小组的人手紧张需小组某一个人简直负责，不能每个人都随意的对所有的文档都拿来拿去。
3文档的修改要有严格的章程控制。
文档一旦形成，不能随意修改，当然形成正式版本的文档之前一定要认真讨论确定文档，一旦文档确定后，不能随意修改，尤其是前期文档，如需求分析，需求分析一变后面的设计文档都要变，这样变来变去会影响到系统的整体进度与软件的质量。
每次修改都要做好记录为什么要做这个修改，修改乐哪些部分 会影响到哪些文档一定要注明还要包括文档修改的发起人和批准人。
4文档的份数。
个人认为一个十人以内的开发小组每个版本的文档只需要一份，尤其是开发阶段流传在程序员手中的文档尽量只有一份，大家以互相传阅的方式进行查阅文档，并不是每个人一份文档会给项目的进度带来有利的影响，上一个项目中每次文档修改后，都给每个人打印一份近千页的文档，一是造成了巨大的浪费，二是由于没有对版本控制好，每个人手里的文档不止一份，开始的时候大家还比较清楚到最后，大家都快搞不清应该以哪一份文档为准了。
做软件项目设计文档怎么写啊
按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~ 详细设计文档规范 1.0概述 这部分提供对整个设计文档的概述。
描述了所有数据，结构，接口和软件构件级别的设计。
1.1 目标和对象 描述软件对象的所有目标。
1.2 陈述范围 软件描述。
主要输入，过程功能，输出的描述，不考虑详细细节。
1.3 软件内容 软件被置于商业或者产品线中，讨论相关的战略问题。
目的是让读者能够对“宏图”有所了解。
1.4 主要系统参数 任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范。
2.0 数据设计 描述所有数据结构包括内部变量，全局变量和临时数据结构。
2.1 内部软件数据结构 描述软件内部的构件之间的数据传输的结构。
2.2 全局数据结构 描述主要部分的数据结构。
2.3 临时数据结构 为临时应用而生成的文件的描述。
2.4 数据库描述 作为应用程序的一部分，描述数据库结构。
3.0 结构化和构件级别设计 描述程序结构。
3.1 程序结构 详细描述应用程序所选定的程序结构。
3.1.1 结构图 图形化描述结构。
3.1.2 选择性 讨论其它可供考虑的结构。
选定3.1.1中结构类型的原因。
3.2 构件描述 详细描述结构中的每个软件构件。
3.2.1 构件过程叙述（PSPEC） 描述构件的过程。
3.2.2 构件接口描述 详细描述构件的输入和输出。
3.2.3 构件执行细节 每个构件的详细演算描述。
3.2.3.1 接口描述 3.2.3.2 演算模型（e.g., PDL） 3.2.3.3 规范/限制 ]3.2.3.4 本地数据结构 3.2.3.5 在3.2.3.6设计中包含的执行结果 3.3 软件接口描述 软件对外界的接口描述 3.3.1机器对外接口 与其他机器或者设备的接口描述。
3.3.2系统对外接口 对其它系统、产品和网络的接口描述。
3.3.3与人的接口 概述软件与任何人的界面。
4.0 用户界面设计 描述软件的用户界面设计。
4.1 描述用户界面 详细描述用户界面，包括屏幕显示图标、图片或者类型。
4.1.1 屏幕图片 从用户角度描述界面。
4.1.2 对象和操作 所有屏幕对象和操作的定义。
4.2 界面设计规范 用户界面的设计和实现的规范和标准。
4.3 可见构件 实现的GUI可见构件说明。
4.4 UIDS描述 用户界面开发系统描述。
5.0约束、限制和系统参数 会影响软件的规格说明、设计和实现的特殊事件。
6.0测试标准 测试策略和预备测试用例描述。
6.1 测试的类别 规定实施测试的类别，包括尽量详细的描述。
这里是针对黑盒测试现象的描述。
6.2期待软件反馈 测试期待的结果描述。
6.3执行界线 特殊执行需要的说明。
6.4 重要构件确认 决定性构件或者需要特殊注意的构件的测试确认。
7.0附录 设计说明的补充信息。
7.1系统可跟踪矩阵 一个定期回归系统规格跟踪软件需求的矩阵。
7.2 产品战略 如果规格说明书是为一个产品设计的，描述相关的产品战略。
7.3 使用分析算法 描述所有分析活动所使用到的分析算法。
7.4 补充信息 （如果有需要特别说明的）
符合软件工程思想的软件说明文档怎么写
用户需求报告、软件设计说明书、软件模块分析、软件模块设计和检测、软件整体统调和测试。
整个过程一般会包括。
根据软件著作权登记的要求，这些过程中形成的对软件本身起说明性作用的文档，均可以作为软件著作权登记中的文档提交。
一般会提交设计说明书或者操作手册（即用户手册）。
所以，编写方法可以参见软件工程的相关教材软件著作权申请中的文档，就是在软件设计过程中形成的文档。
根据软件工程的要求，在软件设计制作过程中，会形成多个文档、生成用户操作手册等...
软件工程 文档编写工具 有哪些
如果我们知道软件文档的价值，那么为什么不经常使用它呢？对于新手，大多数软件文档都存在很多下面提到的这些问题： · 糟糕的语法和/或拼写错误的词语 · 不完整 · 过期或不准确 · 篇幅太长 http://www.mscto.com · 首字母缩写没有解释或术语不专业 http://www.mscto.com · 难于找到信息或在文档中定位 软件开发网 存在这些问题的主要原因是软件文档通常没有被给予足够的重视。
项目预算被迫将主要活动花在了开发工作上，在那里管理层很容易看到他们的收益。
值得投入成本的文档工作通常都是主观的，而且通常被刻画为需要避免的成本，因为它们被认为不能产生投资回报（ROI）。
很多项目经理将客户所需要的最少文档看作是“镀金”。
软件开发网 软件文档的另外一个麻烦来源是文档的作者。
很多应用程序开发经理觉得软件文档是开发工作的一个标准部分，因此，要求他们的开发人员在编码时也编写软件文档。
虽然这在理论上是说得过去的，但是不应该将开发人员看成文档作者。
很简单，技术人员只被培训如何开发，而没有被培训如何写文档。
为了解决这一问题，很多应用程序开发经理尝试通过聘请一些技术性写手或商业分析人员来提高他们的软件文档的质量。
这就导致出现了一个相反的问题：技术写手和商业分析人员通常只有有限的技术技能。
解决方案依赖于文档，文档应该迎合其潜在读者的口味。
这方面的通用规则是要求使用一个协同工作方法来编写文档，这种方法允许开发人员和写手发挥他们的长处。
例如，如果潜在的读者是系统设计人员，那么开发人员应该提供详细的输入，但是允许技术写手去组织和编辑内容以使文档符合语法。
不管潜在的读者还是被选中的读者，软件文档的质量与其可使用性相关，以下六个属性可以用来测量软件文档的可使用性： · 适用性：文档提供了相关的信息吗？ · 合时性：文档所提供的是当时的信息吗？ · 正确性：文档所提供的信息正确吗？ · 完整性：文档是不是足够详细？ · 可用性：文档随手可用吗？ · 可使用性：能够快速直观地找希望能助你一臂之力 展开
软件工程实例 报告 文档 程序 都有
1 引言。
1编写目的： 可行性研究的目的是为了对问题进行研究，以最小的代价在最短的时间内确定问题是否可解 经过对此项目进行详细调查研究，初拟系统实现报告，对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。
明确开发风险及其所带来的经济效益。
本报告经审核后，交软件经理审查。
1.2 项目背景： 开发软件名称：超市进销存系统。
项目任务提出者：老师。
项目开发者：shu408157847。
用户：超市。
实现软件单位：学校 项目与其他软件，系统的关系： 本项目采用客户机/服务器原理，客户端的程序是建立在Windows NT 系统上以Microsoft Visual C++为开发软件的应用程序，服务器端采用Linux 为操作系统的工作站，是采用Oracle 8的为开发软件的数据库服务程序。
1.3 定义： [专门术语]： [缩写词]： 1.4 参考资料： 《软件工程导论》，张海藩，清华大学出版社。
《实用软件工程》，郑人杰等，清华大学出版社。
2.可行性研究的前提 2.1要求 主要功能： 性能要求： 对服务器上的数据必须进行及时正确的刷新。
输出要求：数据完整，详实。
输出要求：简捷，快速，实时。
安全与保密要求：权限不同 完成期限：预计六个月，即截止2007年12月8日。
2.2目标： 系统实现后，大大提高旅游局的机票预定服务效率超市的管理水平。
降低误差，减少开销 2.3条件，假定和限制 建议软件寿命：5年。
经费来源：。
硬件条件：服务器sun工作站，终端为pc机。
运行环境：Linux 数据库：Oracle8 投入运行最迟时间：2000/04/04 2.4可行性研究方法 2.5决定可行性的主要因素 1 经济可行性 成本/效益分析结果，短期-长期利益分析。
技术可行，现有技术可完全承担开发任务。
操作可行，软件能被原有工作人员快速接受。
3.技术可行性分析 3.1系统简要描述 3.2处理流程和数据流程 3.3环境可行性 3.4 人员可行性：操作宜学 3.5 效益分析 投资回收周期 2.3年 4.5敏感性分析 设计系统周期为五年， 估计最长可达10年 处理速度：一般查询速度<4秒 关键数据查询速度： <2秒 5。
法律因素 6。
其他可供选择的方案 7.结论意见 由于投资效益比远大于100%， 技术、经济、操作都有可行性，可以进行开发. 以上为包含步骤，供你参考！！
软件工程中需要多少文档
可行性分析1.经济可行性 ：估算新系统的成本效益分析 1.1. 系统初期投资 1.2. 货币的时间价值 1.3. 投资回收期 1.4. 纯收入2.技术可行性 ：根据系统的目标来衡量所需的技术是否具备3.操作可行性 ：系统交付后是否易于使用并能够创造价值4.业务流程图 ：各个模块的业务流程...
