【精品】教学管理系统

《【精品】教学管理系统》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、只参考本文的书写模式，和写作规范，具体软件开发实习的格式请严格按照“格式・doc”进行编写!切勿复制本文内容，否则成绩无效!2727章绪言丄

2、第二章需求分析t2.1需求获取模式・・2.2业务需求2.3用户需求2.4功能性需求2.5非功能性需求……

3、第三章系统架构设计3」架构的忖标和约束3.2系统技术架构设计

4、第四章系统详细设计4」系统概述4.2数据库设计4/批注［uij：该部分主要描述系统开发/的背景、系统的国内外发展现状、系<统所解决的主要问题等□一一「一批注［U2］:需求分析阶段主要是主要6用例的分析及设计，包播用例图、用例描述；可以从

5、各个模块屮挑选一个8模块进行详细描述，需求的制品包括补充规格说明书、词汇表、业务规则I11132021批注［U3］:对系统逻紺架构进行描/述，包括系统设计的包图、系统设计中层的设计；23批注［U4］:系统的详细设计部分,可以针对其中的某个模块针对动态和挣态进行建模，得到某个模块的交互图（顺序图和通信图〉,静态模型包括包图和类图32批注［U5］:可以加入类的数据库设计致谢综合教务管理系统第一章绪言木课题主要研究实现针対公司员工的个人口志网站。包括•查看口志、添加FI志、管理H志、填写计划等基本功能。主管人员作为管理员登陆系统后进行员工信息添加

6、和权限分配等。一般一个□志系统就是一个页面，它公司工作口志网站是一个十分简易的公司内部工作计划与工作日志信息发布的平台，让任何人都可以像免费电子邮件的注册、书写和发送一样，简单快速地完成个人□志信息与工作计划的创建、发布和更新，用户可以通过该系统发布日志、工作计划等各种信息，是一个方便的供公司内员工相互交流的平台，也是公司内各工作计划跟踪处理的平台。通常由简短而经常更新的日志文章构成，所有文章都是按照H期排列，现在流行的博客就是口志系统的具体表现。看上去平淡无奇，毫无可炫耀Z处，但它可以让每个人零成本地创建自己的网络媒体，每个人都可以随时把

7、自己的想法和灵感在口志系统站点上更新。它的人性化和平民视角使得它提供的消息更贴近人们的生活，而且它搜集的新闻资料人多是第一手资料。简言Z,该系统具有友好的用户界而、简单易懂的操作方式、强大的功能，有广泛的应用空间和无可比拟的价值。第二章需求分析对大多数人来说，若耍建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明口完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起來。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell1997)。可许多组织仍

8、在那些基本的项口功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟(期望差异)一开发者开发的与用户所想得到的软件存在着巨大期望差异。鉴于此，本人在对该系统开发设计前，进行了详细的需求分析。可综括为四个层级需求，BP：业务需求，用户需求，功能性需求，非功能性需求。2.1需求获取模式需求分析的主要任务就是要通过软件开发人员与用户的交流和讨论，准确的获取用户对系统的具体要求。需求分析中任何的含混不清或微小的遗漏都可能会造成系统开发屮的重大问题甚至导致失败。在正确理解用户需求的前提下，软件人员还需要将这些需求准确的以文档的形式表达出来，作为设

9、计阶段的依据。需求分析阶段结束吋需要提交的主耍文档是软件规格说明书。由于需求分析研究的对象是用户对开发项目的要求，在实现这一阶段任务时必须要注意两个问题。问题之一在于：一个项H的参与者即包括软件设计开发人员，又包括用户，他们Z间交流的难题会给软件的开发留下隐患。用户往往在软件交付使用时，才会发现系统存在一系列问题。这就要求双方必须在需求分析过程中加强沟通和协调。一方而，软件设计人员应尽量使用通俗的语言与用户进行交流；另一方面，川户应积极主动的配合软件设计人员的工作。问题之二在于：为了保证需求阶段能够提岀完整，准确的系统逻辑模型，开发人员必须

10、花费足够的时间，全而了解用户的需要，决不能在需求模糊的情况下仓促进行软件的设计和编程。根据国外的统计资料，在典型环境下开发软件，需求分析阶段的工作量人约要占到整个系统开发工作量的20%左右。IEEE软件工程标准词汇表（1997年）屮定义需求为“（1）用户解决问题或达到忖标所需的条件或权能（Capability）o（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。（3）—种反映上而（1）或（2）所描述的条件或权能的文档说明”。简而言之，需求是对一个产品的需要或耍求的描述。任何一项工作在开始以前，首先应该明确工作

11、的冃标和工作成果（制晶）是什么？如果事先没有进行H标和工作成果的定义，则该项工作一定会发散而失去约束。按照传统的软件工程理论，需求分析的冃标就是要确定“干什么？”，而不是“怎么干