你带孩子先走-
软件工程实例 报告 文档 程序 都有
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%， 技术、经济、操作都有可行性，可以进行开发. 以上为包含步骤，供你参考！！
人们常常认为软件工程让我们炮制大量的文档,从而使软件开发进度...
不知道你说的那个“人们”指的是谁，如果他们只是要个小项目，或许不需要文档；但是正式的开发，多多少少需要文档；尤其是大中型项目，不写开发文档，简直无法进行。
你就问他，如果你是个建筑师的话，你不做图就开始盖楼吗？软件工程根据要求的成本和周期，制作可重用、可维护、可移植、能够满足用户需求的软件，对于我这边开发岗位而言，最直接的就是文档了。
工欲善其事必先利其器，写开发文档不是为了拖时间，相反，是为了提高开发效率，降低开发难度，编码按照开发文档写，能够减少错误，提高质量；后期维护，文档是不可或缺的。
对于各软件公司而言，开发文档的编制，还能够有效应对人员流动，适应迭代开发的需要。
记得有次我们这研发部接到一个项目，我接手了一部分数据模型的工作，我问有没有文档，结果只给了一个封装数据的说明，一个只有三页的需求文档，连数据库说明书都没有，我当时真想搬起椅子砸过去，我都不知道你想要实现什么功能，怎么给你写？一般来说，编码所用的时间在整个开发过程中，只占一部分时间，譬如一个六个月的项目，编码时间也就两三个月；于是有些人就误以为时间都浪费在了不相干的事上，其实不是这样的，需求分析、系统分析、测试等等这些环节都不可或缺。
软件工程要求对软件的设计进行严格的管理和评审，生产什么产品的企业不是这样呢？哪里是只有软件行业才特殊？难道盖房子、造汽车就不需要投标，设计，审查，质检，验收这些工作了吗？软件工程看上去繁琐，但是是必要不可或缺的。
有人说，开发人员既烦恼文档，又烦恼没有文档。
为什么许多软件开发团队与个人都不（爱）写开发文档
展开全部 不写文档的原因很多很复杂，有合理的，也有不合理的，有主观原因，也有客观原因，待我述来。
<img src=＂https://pic3.zhimg.com/50/v2-c825065a661914ea80aa946d68306f21_hd.jpg＂ data-rawwidth=＂948＂ data-rawheight=＂890＂ class=＂origin_image zh-lightbox-thumb＂ width=＂948＂ data-original=＂https://pic3.zhimg.com/v2-c825065a661914ea80aa946d68306f21_r.jpg＂>； 诸如 MS、Oracle、IBM 之类的一流大厂的软件开发文档写得怎么样，大家有目共睹，不用我赘述。
三流组织是指那些连管理层的基本诚信都有问题的企业或团队，组织的文化、管理与技术基本上是可以用“烂”字来形容的（可能个别的技术还不错），所以普遍的是没有文档，即使有的话也极难读。
如果您不幸落入了三流团队，不写文档（以免给自己的利益带来损害），我当然是举双手赞成的，不但尽量不要写、少写，而且要赶紧跑，跳出坑。
麻烦的是二流组织。
根据以上分布模型，江湖上最多的其实是中不溜秋的二流组织，文化、管理与技术都处于中游水平。
我们重点来谈谈二流组织。
一般二流团队的领导与员工都知道软件工程管理与开发文档的重要性，但由于内部文化、管理、技术上的一些欠缺，加上外部市场（与一流企业）的竞争压力，导致软件工程与研发管理的整体水平不高，开发文档的质量管理上或多或少都存在着一些问题。
常见的不写（或忽视）文档的原因，我归纳主要有以下几点： 不知道怎么写，写不好；嫌写文档、更新文档麻烦；以为代码+注释完全可以取代文档；团队的软件工程管理水平差，成熟度低；团队的氛围差，用心写文档不仅吃力不讨好，还有损个人利益；受到近十几年来敏捷运动中某些极端思想的影响；无脑跟风与装 X；不写或少写文档是某些知名开源软件的商业补贴模式；初创小团队代码优先，开发文档的优先级不高；当前开发的产品与代码确实很简单，大家都懂，没必要写文档；...不写或少写文档的合理原因 原因 9 许多初创团队不写文档或文档少，这是合理的，因为都赶着要尽快正式发布一个初始产品以争取市场份额与关注度，而在产品需求、架构都还很不稳定的情况下，如果要在代码+注释之外再拿出详细的开发文档，确实时间与精力都不够。
与原因 5 相似，楼里佚名也提到： 还有就是个人写并不代表团队写.很多时候有些东西写出来自己和公司的制衡也就丢失了不少....他说出了很重要的一点。
二流企业团队中这种情况是比较突出（大家心照不宣）的：个人与团队、公司之间存在的一种微妙的博弈（制衡）关系。
你用心把文档写好了，让大家都迅速看懂了，领导、同事、用户都很满意，真的、必然对自己有好处和好报吗？不一定吧。
在一些不太有利的商业环境下，出于个人职业保护的目的，不写、少写文档或者把文档写得模糊、晦涩一点，让想了解的人自己去看复杂的源码而不是立马就明白了，这我是赞成的，尤其是某些二乙、二丙团队。
为啥许多知名开源软件文档少？ 原因 8，许多知名开源软件表面上看着都是代码，独立的文档少，还有一个潜藏的原因（设计）： 你想尽快看懂的话，让你去买作者们写的书（付书费），参加各种技术大会与培训（付报名费、会议费和培训费），最好再找作者咨询（付咨询费），这其实是一种比较流行的开源商业（赚钱或补贴）模式。
当然，也可以把这些详细解读的书看作文档，只不过要付费获得。
如果采用这种模式，当然是免费的文档越少越好。
软件工程是开发、运行、维护和修复软件的系统化方法,它包含哪些要...
展开全部 软件工程包括三个要素：方法、工具和过程。
软件工程方法为软件开发提供了“如何做”的技术。
它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。
软件工具是指为了支援软件人员的开发和维护活动而使用的软件。
例如项目估算工具、需求分析工具、设计工具、编程和调试工具、测试工具和维护工具等。
使用了软件工具后可以大大提高软件的生产率和质量。
软件工程的过程则将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。
...
做软件项目设计文档怎么写啊
展开全部 按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~ 详细设计文档规范 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 补充信息 （如果有需要特别说明的）
软件工程和软件开发,软件编程 这些专业一样吗？
展开全部 软件的供应方有可能是开发者，也可能是卖软件的，就像你购买微软windows系统，你可以通过其它许多正规途径购买，这跟一件商品与生产厂家关系一样，能生产不一定直销，至于开发模式，不知道你指的是什么？是软件结构还是软件适用平台之类，随着移动技术的普及，软件也变得多样化，比如一个生产销售一体化的ERP，员工可以通过在考勤机上打卡上下班考勤，实时通过手机看到打卡记录，生产的商品通过手机扫码能入到ERP系统中，如果不是学者类，没必要把这些区分得那么细，毕竟现在的大型软件各个功能都是你中有我，我中有你一样。
...
转载请注明出处51数据库 » 软件工程 电梯 开发文档
