前言:一篇好文章的诞生,需要你不断地搜集资料、整理思路,本站小编为你收集了丰富的人员需求分析报告主题范文,仅供参考,欢迎阅读并收藏。
引言是对这份软件产品需求分析报告的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。
1.1 编写目的
说明这份软件产品需求分析报告是为哪个软件产品编写的,开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格,包括修正和(或)发行版本号,从而对该软件产品进行准确的定义。
如果这份软件产品需求分析报告只与整个系统的某一部分有关系,那么只定义软件产品需求分析报告中说明的那个部分或子系统。
1.2 项目风险
具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括:
任务提出者;
软件开发者;
产品使用者。
1.3 文档约定
描述编写文档时所采用的标准(如果有标准的话),或者各种排版约定。排版约定应该包括:
正文风格;
提示方式;
重要符号;
也应该说明高层次需求是否可以被其所有细化的需求所继承,或者每个需求陈述是否都有其自己的优先级。
1.4 预期读者和阅读建议
列举本软件产品需求分析报告所针对的各种不同的预期读者,例如,可能包括:
用户;
开发人员;
项目经理;
营销人员;
测试人员;
文档编写入员。
并且描述了文档中,其余部分的内容及其组织结构,并且针对每一类读者提出最适合的文档阅读建议。
1.5 产品范围
说明该软件产品及其开发目的的简短描述,包括利益和目标。把软件产品开发与企业目标,或者业务策略相联系。
描述产品范围时需注意,可以参考项目视图和范围文档,但是不能将其内容复制到这里。
1.6 参考文献
列举编写软件产品需求分析报告时所用到的参考文献及资料,可能包括:
本项目的合同书;
上级机关有关本项目的批文;
本项目已经批准的计划任务书;
用户界面风格指导;
开发本项目时所要用到的标淮;
系统规格需求说明;
使用实例文档;
属于本项目的其它己发表文件;
本软件产品需求分析报告中所引用的文件、资料;
相关软件产品需求分析报告;
为了方便读者查阅,所有参考资料应该按一定顺序排列。如果可能,每份资料都应该给出:
标题名称;
作者或者合同签约者;
文件编号或者版本号;
发表日期或者签约日期;
出版单位或者资料来源。
2. 综合描述
这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。
2.1 产品的状况
描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况:
是否是产品系列中的下一成员;
是否是成熟产品所改进的下一代产品;
是否是现有应用软件的替代品(升级产品);
是否是一个新型的、自主型的产品。
如果该软件产品需求分析报告定义的软件系统是:
大系统的一个组成部分;
与其它系统和其它机构之间存在基本的相互关系。
那么必须说明软件产品需求分析报告定义的这部分软件是怎样与整个大系统相关联的,或者(同时)说明相互关系的存在形式,并且要定义出两者之间的全部接口。
2.2 产品的功能
因为将在需求分析报告的第4部分中详细描述软件产品的功能,所以在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能,在描述功能时应该 针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能,在陈述本软件产品主要功能的作用领域时,也需要对应陈述本软件产品的非作用领域,以利 读者理解本软件产品。
为了很好地组织产品功能,使每个读者都容易理解,可以采用列表的方法给出。也可以采用图形方式,将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示,这种表示方法是很有用的。
参考用户当前管理组织构架,了解各个机构的主要职能,将有助于陈述软件产品的主要功能。
2.3 用户类和特性
确定有可能使用该软件产品的不同用户类,并且描述它们相关的特征。往往有一些软件需求,只与特定的用户类有关。描述时,应该将该软件产品的重要用户类与非重要用户类区分开。
用户不一定是软件产品的直接使用者,通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、或者机构也有他们的需求。所以,应该将这些外部需求视为通过报表、应用程序接口、系统硬件接口附加给软件产品的附加用户类。
2.4 运行环境
描述了本软件的运行环境,一般包括:
硬件平台;
操作系统和版本;
支撑环境(例如:数据库等)和版本;
其它与该软件有关的软件组件;
与该软件共存的应用程序。
2.5 设计和实现上的限制
确定影响开发人员自由选择的问题,并且说明这些问题为什么成为一种限制。可能的限制包括下列内容:
必须使用的特定技术、工具、编程语言和数据库;
避免使用的特定技术、工具、编程语言和数据库;
要求遵循的开发规范和标准
例如,如果由客户的公司或者第三方公司负责软件维护,就必须定义转包者所使用的设计符号表示和编码标准;
企业策略的限制;
政府法规的限制;
工业标准的限制;
硬件的限制
例如,定时需求或存储器限制;
数据转换格式标淮的限制。
2.6 假设和约束(依赖)
列举出对软件产品需求分析报告中,影响需求陈述的假设因素(与己知因素相对立)。如果这些假设因素不正确、不一致或者被修改,就会使软件产品开发项目受到影响。这些假设的因素可能包括:
计划使用的商业组件,或者其它软件中的某个部件;
假定产品中某个用户界面将符合一个特殊的设计约定;
有关本软件用户的若干假定(例如:假定用户会熟练使用SQL语言。);
有关本软件开发工作的若干假定(例如:用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。);
有关本软件运行环境的一些问题;
此外,确定本软件开发项目对外部约束因素所存在的依赖。有关的约束可能包括:
工期约束;
经费约束;
人员约束;
设备约束;
地理位置约束;
其它有关项目约束;
3. 外部接口需求
通过本节描述可以确定,保证软件产品能和外部组件正确连接的需求。关联图仅能表示高层抽象的外部接口,必须对接口数据和外部组件进行详细描述,并且写入数 据定义中。如果产品的不同部分有不同的外部接口,那么应该把这些外部接口的全部详细需求并入到这一部分实例中。
注意:必须将附加用户类的特征与外部接口需求加以区分,附加用户类的特征描述的是通过接口取得软件产品的数据和服务的人的需求;而外部接口需求描述的是接口本身的需求。
3.1 用户界面
陈述需要使用在用户界面上的软件组件,描述每一个用户界面的逻辑特征。必须注意,这里需要描述的是用户界面的逻辑特征,而不是用户界面。以下是可能包括的一些特征:
将要采用的图形用户界面(GUl)标准或者产品系列的风格;
有关屏幕布局或者解决方案的限制;
将要使用在每一个屏幕(图形用户界面)上的软件组件,可能包括:
选单;
标准按钮;
导航链接;
各种功能组件;
消息栏;
快捷键;
各种显示格式的规定,可能包括:
不同情况下文字的对齐方式;
不同情况下数字的表现格式与对齐方式;
日期的表现方法与格式;
计时方法与时间格式;
等等。
错误信息显示标准;
对于用户界面的细节,例如:一个特定对话框的布局,应该写入具体的用户界面设计说明中,而不能写入软件需求规格说明中。
如果采用现成的、合适的用户界面设计规范(标准),或者另文描述,可以在这里直接说明,并且将其加入参考文献。
3.2 硬件接口
描述待开发的软件产品与系统硬件接口的特征,若有多个硬件接口,则必须全都描述。接口特征的描述内容可能包括:
支持的硬件类型;
软、硬件之间交流的数据;
控制信息的性质;
使用的通讯协议;
3.3 软件接口
描述该软件产品与其它外部组件的连接,这些外部组件必须明确它们的名称和版本号以资识别,可能的外部组件包括:
操作系统;
数据库;
工具;
函数库;
集成的商业组件
说明:这里所说的“集成的商业组件”,是指与系统集成的商业组件,而不是与软件产品集成的商业组件。例如:中间件、消息服务,等等。
描述并且明确软件产品与软件组件之间交换数据或者消息的目的。描述所需要的服务,以及与内部组件通讯的性质。确定软件产品将与组件之间共享的数据。如果必 须使用一种特殊的方法来实现数据共享机制,例如:在多用户系统中的一个全局数据区,那么就必须把它定义为一种实现上的限制。
3.4 通讯接口
描述与软件产品所使用的通讯功能相关的需求,包括:
电子邮件;
WEB浏览器;
网络通讯标准或者协议;
数据交互用电子表格;
必须定义相关的:
消息格式;
通讯安全或加密问题;
数据传输速率;
同步和异步通讯机制;
4. 系统功能需求
需要进行详细的需求记录,详细列出与该系统功能相关的详细功能需求,并且,唯一地标识每一项需求。这是必须提交给用户的软件功能,使得用户可以使用所提供 的功能执行服务或者使用所指定的使用实例执行任务。描述软件产品如何响应己知的出错条件、非法输入、非法动作。
如果每一项功能需求都能用一项,也只需要用一项测试用例就能进行验证,那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例,或者必须使用多项测试用例才能验证,那么该项功能需求的描述必然存在某些问题。
功能需求是根据系统功能,即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容,也可以便用这些元素的组合。总而言之,必须选择一种是读者容易理解预期产品的组织方案。
用简短的语句说明功能的名称,例如:“4.1系统参数管理”。按照服务组织的顺序,逐条阐述系统功能。无论说明的是何种功能,都应该针对该系统功能重复叙述4.1~ 4.3这三个部分。
可以通过各种方式来组织这一部分内容,例如采用:使用实例、运行模式、用户类、对象类、功能等级等,也可以采用它们的组合。其最终目的是,让读者容易理解 即将开发的软件产品。一般来说,每个使用实例都对应一个系统功能,因而按照使用实例来组织内容比较容易让用户理解。
对应一些被共享的独立使用实例,可以定义一些公用系统功能。
必须特别注意的是,在2.2节“产品的功能”中描述的全部需求,以及它们的规格说明;必须在某个系统功能描述中有所反映,而且不应重复。
4.1 说明和优先级
对该系统功能进行简短的说明,并且指出该系统功能的优先级是:高、中、还是低。需要的话,还可以包括对特定优先级部分的评价,例如:利益、损失、费用和风险,其相对优先等级可以从1(低)到9(高)。
4.2 激励/响应序列
列出输入激励(用户动作、来自外部设备的信号或者其它触发)并且定义针对这——功能行为的系统响应序列,这些序列将与使用实例中相关的对话元素相对应。
描述激励/响应序列时,不仅需要描述基本过程,而且应该描述可选(扩充)过程,包括例外(引起任务不能顺序完成的情况称为例外)。疏忽了可选过程,有可能影响软件产品的功能;如果遗漏例外过程,则有可能会引发系统崩溃。
如果采用流程图来描述激励/响应序列,比较容易让用户理解。
4.3 输入/输出数据
列出输入数据(用户输入、来自外部接口的输入或者其它输入)并且定义针对这些输入数据的处理(计算)方法,以及相应地输出数据,描述对应区别:输入数据和输出数据。
当有大量数据需要描述时,也可以分类描述数据,并且注明各项数据的输入、输出属性。
对于每一项数据,均需要描述:
数据名称;
实际含义;
数据类型;
数据格式;
数据约束;
对于复杂的处理方法,仅仅给出算法原理是不够的,必须描述详细的计算过程,并且列出每一步具体使用的实际算式;如果计算过程中涉及查表、判断、迭代等处理方法,应该给出处理依据和相关数据。如果计算方法很简单,也可以将其从略,不加描述。
5. 其它非功能需求
在这里列举出所有非功能需求,主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。
5.1 性能需求
阐述不同应用领域对软件产品性能的需求,并且说明提出需求的原理或者依据,以帮助开发人员做出合理的设计选择。尽可能详细地描述性能需求,如果需要,可以针对每个功能需求或者特征分别陈述其性能需求。在这里确定:
相互合作的用户数量;
系统支持的并发操作数量;
响应时间;
与实时系统的时间关系:
容量需求
存储器;
磁盘空间;
数据库中表的最大行数。
5.2 安全措施需求
详尽陈述与软件产品使用过程中可能发生的损失、破坏、危害相关的需求。定义必须采取的安全保护或动作,以及必须预防的潜在危险动作。明确软件产品必须遵从的安全标准、策略、或规则。
5.3 安全性需求
详尽陈述与系统安全性、完整性问题相关的需求,或者与个人隐私问题相关的需求。这些问题将会影响到软件产品的使用,和软件产品所创建或者使用的数据的保 护。定义用户身份认证,或备授权需求。明确软件产品必须满足的安全性或者保密性策略。也可以通过称为完整性的质量属性来阐述这些需求。一个典型的软件系统 安全需求范例如下:“每个用户在第一次登录后,必须更改他的系统预置登录密码,系统预置的登录密码不能重用。”
5.4 软件质量属性
详尽陈述对客户和开发人员至关重要的在软件产品其它方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点,例如:易用性优于易学性,或者可移植性优于有效性。
5.5 业务规则
列举出有关软件产品的所有操作规则,例如:那些人在特定环境下可以进行何种操作。这些本身不是功能需求,但是他们可以暗示某些功能需求执行这些规则。一个 业务规则的范例如下:“进行达到或者超过10,000,00元人民币的储蓄业务时,必须通过附加的管理员认证。”
列举业务规则时,可以根据规则的数量,选取合适的编目方式。
5.6 用户文档
列举出将与软件产品一同交付的用户文档,并且明确所有己知用户文档的交付格式或标准,例如:
安装指南
纸质文档,16开本;
用户手册
纸质文档,16开本;
在线帮助
电子文档,与软件产品一同分发、配置;
使用教程电子文档,与软件产品一同分发、配置。
6. 词汇表
列出本文件中用到的专业术语的定义,以及有关缩写的定义(如有可能,列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士阅读软件产品需求分析 报告,要求使用非软件专业或者非计算机专业的术语描述软件需求。所以这里所指的专业术语,是指业务层面上的专业术语,而不是软件专业或者计算机专业的术 语。但是,对于无法回避的软件专业或者计算机专业术语,也应该列入词汇表并且加以准确定义。
7. 数据定义
数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档,其中对每个数据元素和结构都准确描述:含义、类型、数据大小、格式、计量单位、精度 以及取值范围。数据定义的维护独立于软件需求规格说明,并且在软件产品开发和维护的任何阶段,均向风险承担者开放。
如果为软件开发项目创建一个独立的数据定义,而不是为每一项特性描述有关的数据项,有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告,容 易遗漏数据,也不方便阅读。因此还是建议为每个特性描述有关的数据项,汇总数据项创建数据定义,再根据数据定义复核全部数据,使得它们的名称和含义完全一 致。必须注意的是,为了避免二义性,在汇总数据项时应该根据数据项所代表的实际意义汇总,而不是根据数据项的名称汇总。
在数据定义中,每个数据项除了有一个中文名称外,还应该为它取一个简短的英文名称,该英文名称应该符合命名规范,因为在软件开发时将沿用该英文名称。可以使用等号表示数据项,名称写在左边,定义写在右边。常见数据项的描述方式如下:
原数据元素
一个原数据元素是不可分解的,可以将一个数量值赋给它。定义原数据元素必须确定其
含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行
注释文本,描述原数据元素的定义。
选择项
选择项是一种只可以取有限离散值的特殊原数据元素,描述时一一枚举这些值,并用方
括号括起来写在原数据元素的定义前。在两项离散值之间,使用管道符分隔。
组合项
组合项是一个数据结构或者记录,其中包含了多个数据项。这些数据项可以是原数据元
素,也可以是组合数据项,各数据项之间用加号连接。其中每个数据项都必须是数据定
义中定义过的,结构中也可以包括其它结构,但是绝对不允许递归。如果数据结构中有
可选项,使用圆括号把该项括起来。
重复项
重复项是组合项的一种特例,其中有一项将有多个实例出现在数据结构中,使用花括号
把该项括起来。如果知道该项可能允许的范围,就按“最小值:最大值”的形式写在花
括号前。
8. 分析模型
这是一个可选部分,包括或涉及到相关的分析模型,例如:
数据流程图;
类图;
状态转换图;
实体-关系图。
关键词:网站建设;项目管理
中图分类号:TP393文献标识码:A文章编号:1009-3044(2008)22-617-02
随着互联网的迅猛发展,网站建设业已兴起,越来越多的网站任务需要专门的网络公司来完成。在计算机专业的教学与实践中,网页设计、网站建设与规划、网站管理与维护等课程成为学生的首选课程,而且成为学生择业、就业的一个主要方向。
通过网络技术专业建设、课程设计和毕业设计,尤其是对网络公司的项目实施、网站建设过程的跟踪,我们发现,越来越多的问题出现在网站建设过程中,而且带有普遍现象,例如:网络公司不能按期完成制作,网站不能使客户满意,设计费用超出预算,网站维护不及时等等。
对各种问题及其产生过程进行仔细分析,不难发现,主要原因有以下几点:
1)轻视项目进度监督,公司不重视项目管理,只着重抓合同,忽视开发进程,导致不能按期交付网站作品;
2)忽视客户的需求变化,网络公司在项目承接和建设中只考虑客户提出的具体要求,对潜在需求及未来发展的分析不足,与客户沟通不够,导致客户满意度不高;
3)没有保留历史文档作参考,技术人员只注重程序、网页的保存,忽略了文档是软件的一个重要组成部分,往往导致修改维护费时费力、费用超支、客户不满意;
4)忽视不断的测试和修改。公司对项目的跟踪不够,过分依赖于项目验收;
5)没有使用专业的项目管理软件,主要依靠主观决策、行政命令。
有没有一个比较好的解决办法可以减少失误、控制和管理网站建设过程呢?
网站建设是一个复杂的系统工作,可以看作一个项目来管理。项目管理是研究在时间和资金一定的条件下,如何通过科学地计划、控制和组织达到既定目标的科学。对网络公司来说,项目管理就是对网站建设项目的全过程管理,是一个动态的过程。
通过深入研究项目管理理论,结合项目实施中的具体经验,针对网站建设的特点和重点,在专业教学中不断实施、补充、完善后,我们整理出一套以项目管理方式实施的、切实可行的网站建设管理和控制的方法,称之为网站建设项目管理。
网站建设项目管理是网站建设项目的管理和控制方法,要根据特定的规范,在预算范围内按时完成网站开发任务。这是一种特殊的、标准的操作程序,能够强化管理,改善经营机制,提高网站质量,促进资金合理运用,降低经营风险,提高经济效益。
网站建设项目管理的实行,不但使客户得益,保护投资,而且使网站制作行业趋向于规范化,效益提升,更使从业人员得益,包括项目经理、网页设计师、程序员、网页编辑人员和测试员等。
要提高计算机专业学生的网站建设综合水平,教学中应该强化课程设计,模拟项目的具体实施过程,把学生分组后再分成客户、网络公司甲乙双方,按照网站项目从洽谈到提交完成的顺序,指导学生分布实施网站建设项目管理。
1 客户需求分析
一个优秀的网站建设项目是建立在对客户需求的详细了解、分析、研究的基础上的,通常需要经过以下二个过程完成:
1.1 成立项目小组
网络公司在接到客户的网站业务咨询后,双方有关人员要不断接洽和了解,通过基本的可行性讨论,初步达成网站建设协议,这时要指导学生进行项目立项。
比较好的做法是在学生小组中成立一个专门的项目小组,成员分派项目经理、网页设计人员、程序员、测试员、编辑/文档人员等必需人员。项目小组成立后应该首先明确每个人的职责,实行项目经理责任制,这样能有效实施监管,保障项目顺利进行。
1.2 需求分析报告
网站建设项目首先需要客户提供一个完整的需求分析报告。
很多客户对自己的需求并不是很清楚,需要不断引导,帮助他们分析。
经常出现的状况是,询问客户做网站的目的,客户回答“没什么,别的公司有,我也得有!”。这就需要技术人员耐心说明,仔细分析,挖掘出客户潜在的真正需求。
要配合客户写一份详细、完整的需求分析报告会花很多时间,也是很费力的,但这样做是值得的,而且一定要让客户满意,签字认可。把好这一关,就可以杜绝很多因客户需求不明确或双方理解偏差而造成的失误和无效劳动,进而避免项目失败。
高质量的网站必然有一份优秀的需求分析报告,这就要求项目小组从实际出发,通过实地调研、用户座谈、汇总归纳、系统分析等多角度入手,至少达到以下要求:
正确性,每个功能模块都必须清楚地描述出交付客户时应具备的功能;
可行性,确保在当前的资金、开发能力和系统环境下可以实现客户的每个需求;
必要性,提出的功能是否必须交付,是否可以推迟实现的时间,是否可在削减开支时“砍”掉;
简明性,为了使双方的理解一致,必须把意思表达清楚,最好不要使用专业术语;
检测性,项目开发完毕,客户应该如何根据提出的需求进行检测,检测方法必须是简单、可行的。
2 系统设计
2.1 网站总体规划设计
完成客户的需求分析报告以后,紧接着并不是直接开始制作,而是需要对项目进行总体规划设计、详细设计,拿出一份完整的网站建设方案给客户。
总体规划设计是项目建设非常关键的一步,是为即将建设的网站提出一套完整的设想,要依据需求分析报告确定网站需要实现的功能、网站开发软件、硬件环境、人力资源、时间、需要遵循的规则和标准等。
总体规划设计对网站的功能完善、安全可靠、性能先进至关重要,报告至少应包括网站的栏目和版块、网站的功能和应具备的相应的程序、网站的链接结构、数据库的概念设计、网站的交互性和用户友好设计等。
2.2 网站建设方案
总体规划设计报告完成后,通常需要给客户提供一个网站建设方案。
很多网络公司在接洽业务时就被客户要求提供方案,但那时的方案一般比较笼统,而且是在客户需求不是十分明确的情况下提交的,往往和实际制作后的结果有很大的差异。因此,应该尽量取得客户的理解,在明确需求并进行总体规划设计后再次提交网站建设方案,这样对双方都有好处。
网站建设方案应该包括有关的图表、图片、网页设计草图等,一般应具备以下内容:
1)客户分析,实事求是地剖析客户的现状与发展,尤其要挖掘客户的潜在需求,为客户需求说明书奠定基础;
2)网站的目的和目标,由此产生功能模块的设计和形象设计;
3)网站形象说明,从艺术的角度分析,一般需要美编对客户进行较深入的了解,结合客户公司的产品和企业理念进行设计;
4)网站的栏目、版块和结构,最好提供简介明了的结构图;
5)网站内容的安排、相互间的链接关系,尤其要注意知识产权问题,还要注意链接网站的安全问题;
6)使用的软件、硬件、技术分析说明,要突出技术的先进性与实用性,要考虑实际应用效果,不要一味求新、求异;
7)开发时间进度表,在用户能够接受的基础上,要留有一定的时间富裕度,以避免突发事件的影响;
8)网站宣传推广方案,要做好与客户的商务部门的联系;
9)网站维护方案,要明确区分免费维护期、收费维护期的费用、升级费用等,界定维护期和维护响应时间;
10)制作费用,要兼顾双方的财务制度,并与合同相吻合;
11)本公司简介,包括公司理念,成功的作品,技术、人才说明等内容。
方案通过客户的认可,签订正式合同(一般由销售经理或项目经理起草)后才可以开始着手建设网站,但这还不是真正意义上的制作,还要进行详细设计。
3 网站详细设计
总体设计阶段以比较抽象、概括的方式提出解决问题的方法,详细设计阶段的任务就是把解决问题的方法具体化。
网站详细设计是公司的内部技术资料,主要是针对程序开发而言,却不是真正地编写程序,而是由项目经理组织项目小组设计出程序的详细规格说明,其作用类似于工程领域中工程师经常要使用的工程蓝图,应该包含必要的细节,如程序界面、表单、模块接口、需要的数据等等。
本阶段务必规定统一的软件接口,以避免增加程序链接、调试的工作量。
4 项目实施
4.1 整体形象设计
网页设计师负责设计网站的整体形象和首页。整体形象设计包括标准字、标准色彩、Logo、广告语等。首页设计包括版面、色彩、图像、动态效果、图标等风格设计及banner、菜单、标题、版权等模块设计。
首页一般要设计2-3个不同的风格,完成后方便客户选择。一定要注意的是,在客户确定首页风格之后,务必请客户签字认可。这样,客户以后一般不会再对版面的风格做大的改动,否则将被视为二次设计。
4.2 程序开发与网页制作
详细设计、整体形象设计得到客户确认以后,程序员根据详细设计进行编程,网页设计师开始制作网页。
需要提醒项目小组的是,测试人员要随时测试网页与程序,发现Bug后立刻记录并反馈给有关技术人员进行修改,一定不要等到完全制作完毕后再测试,那样会浪费大量的时间和精力。
项目经理要经常了解项目的进度,协调、沟通程序员与网页设计师的工作。
4.3 网站调试与完善
网站初步完成以后,要上传到服务器,对网站进行全范围的测试,包括速度、兼容性、交互性、链接正确性、程序健壮性、超流量测试等,发现问题应记录下来,交项目小组及时解决。
(下转第623页)
(上接第618页)
网站项目是一个不断充实和完善的过程,文档必须详细记录并保存,通过不断发现问题、解决问题、修改补充文档,使网站建设流程趋向于规范化,趋向于合理性。
4.4 网站宣传推广
网站宣传推广方案可以独立进行,也可以与企业宣传活动同步进行,一般采用与企业的策划、公关及商务宣传活动同期、同时进行,可以一举多得。
网站宣传推广的方法有多种,设置适当的META标签、登录搜索引擎、发表新闻稿件、使用Email邮件列表、广告条交换、付费广告等,这些方法的使用一定要事先与客户沟通,得到客户的确认。
至此,网站项目建设完毕,项目小组将有关网址、使用操作说明、验收要求及相关文档等内容提交客户进行验收。如果客户需要,还应另行签订网站维护合同。
4.5 网站管理与维护
网站成功推出是长期维护工作的开始,与客户签订网站维护合同后,公司应该指派专门的技术人员或固定的文员负责响应全部或大部分客户的网站维护工作。
1) 及时响应客户反馈,可以采取Email自动回复方式,在1-3个工作日内(具体可与网站建设方案中的维护响应时间一致,必须与合同一致)解决问题,然后再次回复客户,并征求客户意见;
2) 网站流量统计分析和相应对策,客服人员要关注客户网站的使用,发现问题及时处理,并对客户提出有价值的建议;
3) 尽量推广和使用所设计的网址,包括在客户的宣传材料、产品介绍、名片、电子邮件上注明客户网址,与客户沟通后一般会得到积极响应;
4) 网站内容的及时更新和维护,要注意内容的合理性、合法性和观赏性,要与客户的发展和商务活动相结合。
5 网站建设应遵循的规范
网站建设项目管理要求制定一系列的规范:目录规范、文件命名规范、接口规范、尺寸规范、首页head区代码规范、连接结构规范等,并在项目实施中严格遵循。
在逐步建立网站建设项目管理规范的基础上,最终要形成网络公司统一的网站建设规范,为下一步的网站建设项目提供统一的技术标准,这样,就能够在未来的网站建设、维护中节省大量的时间和人财物,极大地提高公司的经济效益与社会美誉度。
参考文献:
关键词:软件工程;需求分析与管理
中图分类号:TP311文献标识码:A文章编号:1007-9599 (2010) 15-0000-01
The Requirements Analysis and Management of Software
Huang Degui
(Communications Information Branch,Zhanjiang Port(Group)Co.,Ltd.,Zhanjiang524019,China)
Abstract:In the process of software development requirements analysis and management,there are some problems.This paper analyzes the problems and issues reference for these recommendations and solutions.
Keywords:Software engineering;Requirements analysis and management
在软件项目开发过程中,需求分析与管理十分重要。但在实际的软件项目开发的需求分析与管理过程中存在一些问题,如果不重视这些问题,往往导致项目开发进度延期、超出项目预算甚至项目开发失败。
在软件工程理论中,需求分析是指构建一个新的系统或者完善现有系统时,确定系统的目标、范围、功能需求和非功能性需求等方面所涉及的工作。
需求分析是软件工程的一个关键过程,也是软件项目开发的一个关键阶段。软件需求分析人员需要准确、清晰和形象的表达和描述用户的真实需求。需求分析阶段的工作是否准确和充分、提交的软件需求说明书是否完善和规范、需求管理的方法是否正确将直接影响和决定整个项目开发是否能够按照时间进度和在项目预算范围内完成。
在项目开发过程中,经常出现如下情况:软件需求分析人员描述的用户需求不完整、用户需求经常发生变化、软件需求分析人员与系统设计人员的沟通障碍、开发人员边做需求分析边做开发、用户需求管理混乱、缺少专业的需求分析与管理工具等。这些情况的出现使整个项目管理风险加大、系统代码返工率高、项目团队士气日益低下和用户对项目开发进度的抱怨越来越多,最终可能导致整个项目开发失败。
软件需求分析人员描述的用户需求不完整主要原因:一种情况是没有专职的软件需求分析人员,兼职的软件需求分析人员同时担当该模块的设计及开发,导致需求分析没有真正从业务的角度来考虑,而是从技术实现的角度考虑。有的即使有专职的软件需求分析人员,该软件需求分析人员也不具备该行业的业务知识和经验,对行业术语不了解,有的甚至聘用刚刚毕业的学生去做需求分析,导致整个需求分析不准确甚至出现偏差。另外一种情况是专职的软件需求分析人员没有系统的学习和掌握软件需求分析的基本方法、原则和技巧,了解的业务需求不能准确直观的表达和描述,编制的软件需求说明书过于简单和形式化,导致项目开发的其他人员不能很好的理解用户需求,有的甚至要重新做软件需求分析。
为详细和准确的描述用户需求,需要注意以下几个方面:
首先需要由专职的人员担任需求分析工作,而且软件需求分析人员需要系统的学习和掌握需求分析的基本方法、原则和技巧。例如获取业务需求常用的方法有用户访谈、速记、谈话录音、会议纪要等;其中用户访谈的要点包括确定访谈的时间、访谈的对象、设计用户访谈计划并提前发送给用户等;速记要求软件需求分析人员能够快速准确的记录用户描述的业务需求和业务流程。谈话录音和会议纪要是为了更准确记录用户描述的业务需求,便于分析和理解用户需求;软件需求分析人员最好具备该行业的业务经验和知识或者聘请该行业的业务专家指导,这样有助于软件需求分析人员准确分析和理解行业术语、行业业务需求和行业业务流程。
其次,描述的软件需求说明书内容应该包括系统的目标、范围、功能需求、非功能性需求和系统界面原型等方面。非功能性需求主要包括系统界面的可用性、易用性、操作便捷、时间效率高、出错率低和操作系统需要的专业领域知识少等方面;系统界面原形是指使用专业界面原形工具(Axure等)或者直接使用开发工具(Visual Studio等)编制系统的初始用户界面,便于软件需求分析人员、系统设计人员和开发人员更直观和形象的与用户沟通和明确需求。非功能性需求和系统界面原形在需求分析阶段非常重要,我们在项目开发过程中应该注重非功能性需求和系统界面原形。
最后,对于软件需求分析人员编制的软件需求说明书要做好需求验证工作,参加需求验证工作的成员应该包括项目组所有成员、该行业的业务专家和最终用户。在需求验证会议上提供的需求验证材料应该简单、清晰、直观和明确,不能笼统的提供一些复杂的业务流程及繁琐的文字说明。在需求验证会议上可以通过情景模拟和系统界面原形的方式演示。情景模拟是根据不同业务角色模拟整个业务办理的情况。系统界面原形能让用户切身感受到系统的界面效果,便于直观、形象的沟通和交流业务细节和业务流程。
在项目开发过程中,用户需求发生变化的情况经常出现。我们不能避免和逃避用户需求变化情况的出现,但应该控制和管理用户需求变化,应该有需求变更的流程、需求变更的团队、需求变更的平台、需求变更的影响分析以及固定的需求变更周期。对于用户提出的需求变更,我们首先应该做好详细的记录,然后将需求变更的记录通过需求变更的流程提交给需求变更团队评估和确认,最终在需求变更的平台中反映出来,同时要做好需求变更的影响分析报告并及时反馈给用户。需要注意的是对于需求变更我们要有固定的需求变更周期,不能用户有需求变更马上要求项目团队及时更改系统,这样会加大项目管理的风险和影响项目团队的士气。
因此,很多企业都会利用Hadoop实现数据存储,再通过其他工具实现对大数据的高速捕获和实时分析。这里,我们将通过艾瑞咨询集团的一个真实案例,解读一下敏捷BI如何和Hadoop进行互补,帮助其实现互联网大数据分析的。
定制化项目效率低下
艾瑞咨询集团(iResearch)是一家专注于网络媒体、电子商务、网络游戏、无线增值等新经济领域,深入研究和了解消费者行为,并为网络行业和传统行业客户提供市场调查研究和战略咨询服务的专业市场调研机构。
目前,艾瑞咨询集团可以向企业提供线下报告和软件两种定制化咨询报告服务。但是,企业客户的定制化需求非常多变,艾瑞咨询集团生成一份线下报告交付周期需要3至4周,提供软件的交付周期则需要半年。再加上项目所需人工成本升高、迭代周期延长,艾瑞咨询集团往往不敢承接太多定制化项目。
通过调研,笔者发现了艾瑞咨询集团的真正需求:根据时间维度和网站汇总对用户的来源地区、来路域名、页面访问次数、停留时间、有效访问次数、跳出率、回访者、新访问者、回访次数和回访相隔天数等相关数据进行统计分析,并且还能够在动态添加条件之后,通过对监测用户行为获得的数据进行分析,以最终得出更加详细、清楚的用户行为习惯。
因此,艾瑞咨询集团迫切需要一种更加敏捷、高效的大数据分析工具提升定制化业务的效率。
大数据面前:敏捷BI PK传统BI
在解决艾瑞咨询集团面临的难题时,传统BI的做法是,IT人员事先根据需求分析进行建模,建好二次表或打Cube并提前汇总好数据,业务人员才能在前端查看到分析结果的报表。虽然这种做法很成熟,但是解决不了艾瑞咨询集团的难题。
首先,业务人员查看的报表相对静态,分析的维度和度量的计算方式已在建模时预先设定好,不能更改。例如,定好了求和或求平均数,再想改成求方差必须再去修改模型。
其次,分析需求变更时,业务人员不能直接调整报表,需要IT人员重新建模或修改已有分析模型,耗时较长,响应速度较慢。
最后,有些企业的数据量很小,也需要按照此流程和架构来进行大费周折的数据分析。
造成这些问题的本质原因是,过去的技术架构针对海量数据的计算能力不足,企业用户需要通过建模、二次表、Cube提前进行数据运算汇总。
艾瑞咨询集团希望为企业客户提交这样一份分析报告,不仅能看还能动态分析。对于艾瑞咨询集团来说,数据展现应该是起点而不是终点。看到了数据,要能交互式分析、深入向下挖掘,要能发现问题并找到答案,还要能采取行动。与数据交互的过程要足够快,如果用户每次点击需要等三五分钟才出结果,就无法进行交互分析。
并且,分析报告应能让非IT部门的同事直接在分析平台上做出来。不能把所有的分析报告需求都提交到IT部门,这样会严重增加IT部门的工作负担。同时,敏捷BI的实施和操作要简单化,让业务人员可直接使用。
同时,分析报告需求经常需要牵涉到数据层的改动,需要IT部门去改进数据层和业务层,传统BI平台需要一两个月才能完成模型梳理。敏捷BI无需事先建模,可以在分析过程中灵活调整分析维度和报表展现,需求变更可以在一天之内响应,提升企业的洞察力决策力。
与传统BI的重量建模、统一视图不同,敏捷BI采取轻量建模、N个视图的方法,不建二次表和Cube,数据导入后可以直接进行分析,并且业务人员可以实时调整分析的维度和度量的计算方式,极大地增加了灵活性,真正做到和数据对话。
既然有这么便捷的方式,为何传统BI不采用这种架构呢?那是因为,传统技术架构没有引入大数据技术,面对海量数据无法在用户点击后的几秒内就展现企业客户需要的分析结果,因此必须通过建模提前把数据汇总好,才能保证分析报表展现时的速度。
因此,实现敏捷BI的前提是采用新架构处理数据,其涉及的技术包括分布式计算、内存计算、列存储、库内计算等。敏捷BI可以通过更低的成本、更短的上线周期,快速让企业洞察到数据的含义和价值。
业务效率数倍提升
深入研究艾瑞咨询集团要分析的数据,笔者发现,艾瑞咨询集团每天要分析的数据量达几千万条,且不同企业客户的分析需求各不相同。因此,复杂多变的多维度分析需求对分析工具的分析性能提出了更高的挑战,而传统的数据库和Hadoop架构已经无法满足高性能和即时分析的需求。
为此,艾瑞咨询集团考察过国外一些知名的产品,但是当他们获知产品的价格和后续的服务费用之后只能放弃。而国内大多数的分析工具大多是上一代BI,需事先建模再进行分析,难以应对灵活的多维度分析变化需求,且针对大数据量的处理能力不能满足要求。
最终,艾瑞咨询集团选择了永洪敏捷BI技术。当艾瑞咨询集团将三个月的细节数据(约50亿条)导入敏捷BI系统,直接就可以展现出定制分析报告。对比原先基于Excel和SQL编程的分析方法,艾瑞咨询集团的业务效率获得数倍的提升:线下报告交付周期从3至4周缩短至小于1周,软件交付从半年缩短至一个月。
同时,艾瑞咨询集团原来由于担心需求变化导致没有能力交付的很多项目被收入囊中。采用敏捷BI工具后,艾瑞咨询集团可以在几天内快速搭建原型向客户展示,任意的需求变更都可以一周内调整完毕。这种快速原型试错的方式,使得艾瑞咨询集团有能力承接很多此类项目。
由于业务效率的极大提升,有能力承接更多的项目,艾瑞咨询集团的收入空间也出现了数倍的增长。与此同时,艾瑞咨询集团的客户满意度也稳步提升。
不仅如此,为了提供更加直观可交互的分析报告,提升企业用户体验,艾瑞咨询集团基于敏捷BI工具,构建了一个新型SaaS平台。艾瑞咨询集团把企业客户用Hadoop架构存储的数据,通过敏捷BI提供的接口导入到数据集市内,然后通过敏捷BI快速呈现出结果。
事实上,Hadoop和敏捷BI都有各自适用的不同业务场景,两者是相互补充的关系。当前,很多企业都采用Hadoop实现数据的存储,然后把Hadoop数据导入敏捷BI基于分布式内存计算的高性能数据集市中,之后再进行数据可视化分析。鉴于现在Hadoop在企业的应用相当广泛,永洪敏捷BI产品也支持Hadoop数据源的连接。
关键词:网络 设计 实验 应用
一、引言
随着计算机技术以及网络技术的迅速发展,拥有计算机、应用网络已经成为人们生活中的重要组成部分。网络应用型人才被社会广泛欢迎,探索培养网络应用型人才的有效方法成为摆在计算机相关专业教育部门的课题。
二、社会网络人才需求状况
在我国,越来越多的政府机构和行业企业都开始依赖网络技术进行各自的生产、经营和管理。可以说,没有网络,就无法进入真正的计算机时代;没有网络,企业就无法实现信息化。由此看来,网络化已经成为现今社会竞争和发展的关键因素,计算机网络技术人才的培养,也随之成为当前网络化建设的当务之急。就目前的状况来看,实施网络化建设的部门严重缺乏从事网络系统的构建、运行和维护等工作的专业网络技术人员。全国的高等院校每年为社会输送区区几万计算机网络专业的毕业生,而整个社会需要的却是数以百万计的具有专业技能的网络技术人员,人才供应能力远远小于实际的社会需求。
三、高校网络人才培养情况
一直以来,高等院校的学历教育偏重于网络技术的基本理论和基础知识的传授,缺乏网络技术应用的实际操作技能和经验,无法满足所在单位对网络技术人员的工作要求。这就造成了一种现象,一方面,用人单位求贤若渴;另一方面,毕业生的就业困难,这已经成为了一种严重并且普遍的社会问题。
网络技术是理论和实践结合十分紧密的一门学问,网络技术人才市场,越来越关注技术人员的实际经验和动手操作能力。学生也有迫切接触社会、提高工作技能的需求。因此,针对高等院校中普遍存在着理论强、实践弱的现象,很多高校组建了网络实验室,在网络实验室里提供了真实的网络环境,可以让学生亲自动手调试、配置网络,从而让学生直观、全方位地了解各种网络设备和应用环境,真正加深对网络原理、协议、标准的认识。通过在网络实验室的学习,能真正提高学生的网络技能和实战能力,同时具有扎实的理论基础和较强的实践动手能力,
(一)开展网络设计性实验的意义
网络实验室虽然提供了一个很好的实验平台,但学校平常上课的时候,是一节实验课讲一个具体的实验,比如这节课讲VLAN划分,下节课讲动态路由。学生可能每节课都学得不错,可是到了学期结束的时候,他们整体运用所学知识解决问题的能力如何,就不清楚了。开展设计性实验是解决这一问题的好办法。
设计性实验,是指给定实验目的要求和实验条件,由学生自行设计实验方案并加以实现的实验。在网络实验室中开设设计性实验,能够综合以往所学的基础理论知识和单项实践技能,通过贴近实际的设计题目,一方面,增强了学生解决实际问题的能力;另一方面,在一定程度上也积累了实践经验。
(二)网络设计性实验的实施方案
为使网络设计性实验达到培养应用型人才的初衷,制定了切实可行的实施方案。
首先,明确实验目的。即通过了解不同网络的需求和功能,研究网络的布线方案等环节,写出网络的总体需求分析报告,绘制网络结构图,进行布线选型和设备选型,确定IP地址分配方案以及网络管理方案,并在模拟环境下进行测试。
其次,合理拟定设计题目。经过对目前各行各业网络应用状况的认真考察和研究,共设题目五个,分别是:校园网络设计、智能小区网络设计、政府办公网络设计、企业网络设计和校园公共机房网络设计。五个题目的内容大致包括了目前网络组建的几种不同的应用形式,学生可以了解各种条件下的网络在需求上的特点,对建网初期最重要的需求分析有了更深刻的认识。
再次,根据各设计题目的应用特点,分别策划各设计任务的背景条件。如校园网题目的背景为“一所学校有6栋5层楼宇,平均每栋楼宇有节点150个,具有一般校园网络的基本需求,其中教务管理节点30,分布在6栋楼宇的不同楼层;另外某台分布层交换机上连接有提供学习资料的服务器,以及学生宿舍楼和教工宿舍楼,学校规定学生只能访问学习资料服务器,但不能访问教工宿舍楼。”等,使题目的设计更真实,针对性更强。
最后,完成设计方案。要求学生根据各自题目的具体要求,了解相关网络的建设情况,写出网络的总体需求分析报告,确定网络逻辑结构并绘制网络结构图,进行布线选型和设备选型,根据情况进行IP地址设计(划分的原则、方法及地址列表),写出网络管理方案(要注重网络安全的考虑),在模拟环境下测试关键技术的网络连通情况,并练习使用专业网络测试议进行线路测试。
在这个设计性实验方案中,学生需根据任务背景中的一些特殊组网要求,在网络实验室的实验条件下进行连接配置,由于所设计的关键技术实验内容都是一些网络建设过程中的常见问题,所以对提高学生解决实际问题的能力有一定益处。整个过程突出了实用性和操作性。
(三)网络设计性实验的实施效果
通过网络设计性实验的实施,一方面提升了学生的网络专业技术技能,使学生对各种常见网络的搭建环境有了直接的认识,掌握了不同环境要求下的组网方法。从学生的反馈可以看出,95%以上的学生认为,通过这样的设计性实验达到了理论联系实际的目的,真正了解了网络组建的步骤,增强了实践操作技能。另一方面提高了学生的就业竞争力,比如企业中的网络技术人员要承担网络设计、系统集成、综合布线、系统测试等类工作,大的企业会设立不同的岗位,各自分派专人负责,而中小企业往往要求一岗或一人身兼数职。经过网络设计性实验的学习,学生掌握了网络建设工程中从需求分析、物理设计、逻辑设计,到设备选型、布线施工、网络安全设计、网络管理方案,再到测试验收等建设网络各环节的流程及其设计方法,对于未来的求职从业来说,从技能的训练方面会有更多的优势,从择业的范围上会有更多的适应性。
四、结束语
在社会对于网络专业人员迫切需求的前提下,在高校相关专业理论教学的基础上开展网络设计性实验,能有效地提高学生的网络设计和操作技能,对于应用型人才的培养起到了促进作用。
参考文献
胡胜红,《网络工程原理与实践教程》,人民邮电出版社,2005
张凤翔,《局域网组建与维护》,上海交通大学出版社,2004
蒋丽,《局域网、企业网实现》,电子工业出版社,2003
1.1建设原则
安全生产信息系统建设应遵循以下几个基本的原则:与其它的业务系统相比,安全生产信息系统定制性更高,要根据单位的实际情况以及各不同层级用户的业务流程,来规划应用系统和功能模块。因此,在建设过程中,要充分结合企业系统每层级用户的具体需求。安全生产信息系统建设是一项复杂的系统工程,基本涵盖了企业安全管理的所有内容。因此,在进行安全生产信息系统建设时,必须做好总体规划,分阶段、分层级、分重点推动,避免出现“全盘端,全盘乱”的情况。安全生产信息系统建设除了涉及集团内各个部门,还牵涉到与下属成员单位之间的沟通与对接。因此,采取自上而下的建设模式,有利于各方面的协调,保证项目建设进度和组织项目实施。企业信息资源的有效整合,成为当前信息化建设的主流。安全生产信息系统作为企业信息化战略的组成部分,在建设中必须要遵守标准化、规范化的要求,从而更好的为企业信息资源的整合打下基础。
1.2建设方法
目前,企业建设安全生产信息系统归结起来,主要有以下三种方法:企业安排内部的或招聘新的信息系统专业人员开发自己的信息系统。自主开发方式的优点包括:①有利于与用户协调,减少需求的不确定性;②开发人员可以经常性地与用户部门进行交流,因此项目的可控性较好,用户的适应性也比较理想。缺点包括:①系统性及质量较难保证,开发周期比较长;②开发环境相对比较封闭,不利于推动组织变革;③需要较多的信息开发人员,实际的开发投入不一定会减少。由企业和委托方共同开发,两者的配合与互补是取得成功的关键。一般情况下,以外部力量为主,内部力量为辅,前者重点放在技术问题上,后者重点放在与用户的联系与协调上。合作开发可扬长补短,是目前较普遍采用的开发方式。通过合作开发,企业可在实践中培养出一批信息管理人员,这比自己摸索或外送培训都要好得多。外包是一种为了抓好自己的核心业务而将非核心业务委托外部机构来完成的新模式。外包开发优点包括:①比较经济和实惠,成本较低;②服务质量和开发进度有保证。缺点是:①存在信息系统的控制权问题;②信息系统中的商业秘密安全性问题;③对外包服务商有较强的依赖性。
2典型建设流程
根据笔者多年来为企业提供信息化解决方案的经验,企业安全生产信息系统建设的基本流程如图1所示。
2.1总体规划
对于安全生产信息系统的开发设计工作来说,总体规划是不可或缺的。受信息系统项目本身特点的影响,安全生产信息系统项目的开发是一项复杂的系统工程。在建设过程中,由于各类人员之间的协调工作不到位,往往容易导致做大量的修改工作,甚至有些系统集成后,修改工作量太大,无法进行修改而被迫宣布重新再来。因此,只有在统一的总体规划指导下,这种分散的功能模块,才能被有机结合起来,构成一个有效的大系统。总体规划的一般步骤主要包括:①准备系统建设前期基础性材料,如安全管理组织架构、业务流程梳理等;②开展安全管理现状调研;③提出安全生产信息系统建设总体目标;④提出系统的总体框架和各子系统构成;⑤按照轻重缓急,确定各子系统的开发优先顺序;⑥制定建设进度安排和预算;⑦编制系统建设实施工作方案。
2.2需求分析
据统计资料显示,在信息系统建设失败案例中,超过90%以上都要归结于需求分析不深入。因此,需求分析的质量对安全生产信息系统开发的影响是深远的、全局性的,高质量需求对软件开发往往起到事半功倍的效果。需求分析做得好,那么项目就相当于做完了一半,好的需求分析会为项目的顺利开发奠定基础,减少大量开发成本,减小开发风险。在开展需求分析时,可以从以下四个方面进行:①人的分析。主要分析企业是否具备安全生产信息系统建设方面的相关人才、合作方的建设能力是否满足需要等;②物的分析。主要分析企业是否具备了开展安全生产信息化建设的物质条件,如基础的网络条件、硬件设备条件等。③环境的分析。主要分析企业各层级人员对安全生产信息化的需求、态度等。④管理的分析。主要分析企业在管理制度、机构和措施等方面,是否能保障安全生产信息化建设顺利开展。
2.3系统设计
安全生产信息系统的系统设计主要包括总体设计和详细设计两个方面,如图2所示。安全生产信息系统的系统设计应充分体现企业的参与,特别是在总体设计及子系统设计环节,需要企业指定专门的人员负责与系统开发方进行沟通交流,确保系统设计科学、实用,满足企业日常安全管理工作的需求。
2.4组织实施
系统的组织实施主要由系统开发方来完成,主要包括以下几个方面的内容:①代码开发。完成软件系统的代码编写工作。②系统测试。组织测试人员,对完成的系统进行测试、完善循环流程。③系统安装。在企业信息平台上,安装经过测试的系统,并进行企业培训。④系统转换。经过一段时间的试运行后,在试运行系统与正式系统之间进行转换。
2.5运行评估
系统正式投入运行后,对企业安全管理工作而言,安全生产信息化建设工作才正式开始。因此,企业必须组织相关专业人员,定期对系统运行情况进行评估(见图3),发现运行中出现的问题,联系开发方进行解决,保证系统稳定、可靠运行。
3系统建设案例
3.1企业基本情况
该企业为大型集团型企业,集团的安全管理架构为“集团-二级单位-基层单位”三级管理模式,共有二级单位29家,基层单位178家,员工7万余人。
3.2系统总体架构
通过对该企业进行的5次近3个月的需求分析,完成了安全生产信息系统建设需求分析报告,确定了如图4所示的系统功能框架。
3.3系统实现
经过系统设计、测试、试运行、正式运行等流程后,最终的系统实现如图5所示。
4结论
关键词:管理信息系统 需求分析报告 系统可行性分析报告 系统设计报告 用户使用说明书
笔者曾长期从事计算机的开发与应用,对于计算机在管理上的应用、计算机在办公自动化方面的应用、计算机数据库的开发、计算机网络的开发与应用,都进行过具体的设计工作。从事《管理信息系统》的教学工作中,非常希望把自己以往的工作经验及教训传授给学生,借此诚恳地希望有关专家给与批评指正。
一、《管理信息系统》的课程特色:
《管理信息系统》的课程特色主要有以下几点:
1、综合性强,牵涉学科较多
牵涉学科有《管理信息系统》综合了管理学、工程学、数学、计算机科学、电子通讯等学科的相关知识等。比如:在系统的整体构建时要体现管理科学的艺术性,要针对现有系统所存在的问题,提出解决的方案,解决方案要符合管理科学的要求;在具体构建《管理信息系统》时,要体现工程学的严密性,符合软件工程建设的规范,各阶段性文档的形成要经过严格的认证,系统的结构要模块化以便于调试与维护,也便于系统开发的分工合作;在建立系统的逻辑模型时,要学会使用数学的方法,把一个现实世界的问题转化为一个数学模型,以便于计算机的实施;在信息管理上,使用计算机的相关知识,建立数据库,把信息集中起来管理,为共享数据提供技术保障;为了满足不同地域的人们对信息共享的需求,《管理信息系统》较多地使用计算机网络技术、电子通讯技术来实现信息的传递。
2、理论性强,学生易懂,难掌握
往往是上课听明白了,下课又糊涂了,知其然,不知其所以然。《管理信息系统》偏重于理论层面的研究,而我们的学生基本不具备社会实践经验,对于企业或信息机构基本上是一无所知,不理解为什么要采取这样或那样的管理策略,这就要求教师在教学时一定要理论联系实际,要多距离,通过实例的讲解让学生理解学科的科学性与基本知识,要求做到教师举一,学生反三。
二、《管理信息系统》的教学难点
《管理信息系统》的教学难点第一是难掌握,主要表现在不会用;第二是相关知识点太多,学生知识面不够。对于第二点,如果在制定教学计划时,相关课程的教学已经完成,应该是没有问题的。《管理信息系统》的相关课程有:计算机基础知识、计算机网络、计算机数据库。我们的教学尝试主要是针对第一点来讨论的。
三、教学尝试
为了解决《管理信息系统》教学中,学生易懂难掌握的特点,在教学中我们要求学生运用所学知识完成如下报告:1、需求分析报告,2、可行性分析报告,3、系统设计报告,4、用户使用说明书;参考格式如下:
1、×××需求分析报告格式
一、提要:要求说明项目名称、项目用途、项目简介
二、项目背景:要求说明项目作者、用户、项目所需软硬件环境、项目开发目的
三、参考资料:书名、作者、出版社、出版时间
四、定义:对文中术语、简称给与说明
正文:
一、系统现状的描述及现系统的不足之处(重点是不足之处,这是项目立项、产生需求的根本)
二、解决问题的方案(建立解决问题的新系统的逻辑模型或者称为数学模型,要求不光有文字叙述还有原理图/示意图的辅助说明)
三、前景及展望(可以分别从长期、中期、短期进行展望)
正文部分要求叙述清楚,表达准确,在系统现状的描述中可以附相关的谈话记录、调查问卷、现系统运作的相关文档资料;要求学员学会调研项目需求,为下面的系统开发打下基础。
2、×××系统可行性分析报告格式
一、提要:要求说明项目名称、项目用途、项目简介
二、项目背景:要求说明项目作者、用户、项目所需软硬件环境、项目开发目的
三、参考资料:书名、作者、出版社、出版时间
四、定义:对文中术语、简称给与说明
正文:
一、系统的描述(指新系统的方案)
二、系统的经济可行性分析:
1、系统的投资:
a、基建、装潢的费用
b、仪器、设备的购置费用,仪器、设备折旧
c、人员工资
d、办公费用,其他费用
2、毛利润:
3、净利润:毛利润-各项费用
4、投资回报:分一年期,三年期,五年期及以后期
5、投资回报率
三、系统的技术可行性分析
1、系统设计的概略图
2、系统的设计方案
3、系统的原理图
4、关键技术说明
四、系统的社会环境可行性分析(主要从社会习俗、道德、人文背景方面进行分析)
五、系统的法律可行性分析(与现行法律法规有无违背)
六、可选择的其他系统方案(如果有,列出具体方案,然后比较方案之间的优缺点)
七、结论(系统可行或者是不可行)
3、××× 系统设计报告格式
一、提要:要求说明项目名称、项目用途、项目简介
二、项目背景:要求说明项目作者、用户、项目所需软硬件环境、项目开发目的
三、参考资料:书名、作者、出版社、出版时间
四、定义:对文中术语、简称给予说明
正文
一、系统设计说明
二、系统的功能结构图(静态)
三、系统的数据流程图及数据字典(动态)
四、系统的程序流程图(针对每个模块编写)
五、系统的测试用例(针对每个模块编写)
六、系统的联调方案
七、系统的维护(主要说明维护要求)
八、用户界面的设计(输入、输出)
九、用户培训
十、附原程序清单(学生做练习时可以略,只写标题然后注明略)
4、×××系统用户使用说明书格式
一、提要:要求说明项目名称、项目用途、项目简介
二、项目背景:要求说明项目作者、用户、项目所需软硬件环境、项目开发目的
三、参考资料:书名、作者、出版社、出版时间
四、定义:对文中术语、简称给与说明
正文:
一、系统说明
二、系统安装
三、系统的运行
四、系统的主要功能介绍
五、系统常见故障及处理方法
六、技术支持及联系方式
通过四个报告的编写,首先是让学生了解《管理信息系统》开发的过程及具体开发系统的方法;其次是使学生学会具体开发工作中的细节,如用户需求调查,可行性研究的调查及系统设计方案的编写;第三是使学生熟练地掌握数据流程图及数据字典的编写方法,学会使用模块化设计的方法自顶向下层层进行系统分解,最后产生系统的功能模块图;第四是使学生掌握每个模块的程序流程图的设计方法。这样《管理信息系统》的几个主要的开发工具都得到了练习。
四、教学效果
通过教学尝试,我们惊喜地发现,学生对本课程的理解加深了,学习兴趣提高了,师生之间的互动增强了。从学生交上来的报告可以看出:学生的思维开阔了,看问题的角度更加清晰;有的报告已经具备了一定的实用性。比如说:有的学生建议把学生的食堂改为定餐管理的方法,学校把每天的菜单编号公布,学生通过计算机网络定餐,食堂使用计算机统计定餐后烹制,这样就避免了浪费;另外定餐后还可以送饭上门,这样也缓解了学生就餐时餐位不够的矛盾。还有的学生设计了火车票、汽车票网上订购系统,用以解决寒暑假期学生购票难的问题等等。尽管学生的设计不尽如人意,可是通过练习学生的思维活跃了,好的点子不断涌现。
五、教学总结
通过教学尝试,我们增强了让学生理论联系实际的信心,对于《管理信息系统》的教学起到了很好的辅助作用。今后我们认为应该不断地总结经验,完善教学手段,让《管理信息系统》的教学更加生动、活泼、受到学生的欢迎;对于学生能力的培养,提高就业技能起到更好的作用。
参考文献:
1、《信息管理系统》,中央广播电视大学出版社,主编:侯炳辉 副主编:刘世峰
2、《管理信息系统基础与开发技术》,人民邮电出版社,主编:陈承欢、彭勇
关键词:成本控制;成本控制决策支持系统
1 引言
当今,企业竞争环境瞬息万变,能否快速和正确地做出反应并制定相应策略,是企业取得市场竞争优势的关键。随着企业规模不断扩大,内部数据迅猛增加,管理人员分析数据,利用分析结果辅助决策的需求越来越大。通常,生产型企业都具有制造环节复杂、产品周期长等特点,容易形成信息分割、信息重复采集等弊端,造成信息量大,支持决策不佳的窘境。自上世纪八九十年代开始,就有人开始探索利用决策支持技术进行企业生产成本控制,如Michael J.A.Berry等人探索了基于DM的企业生产成本控制DSS的分析与设计;胥悦红,顾培亮等人将神经网络理论应用于产品的成本预测,探讨了一种基于BP神经网络模型的产品成本估计模式;彭永洪研究了以BOM(物料清单)为基础,通过市场层次、产品层次、零部件层次规划建立ERP系统目标成本决策模型。PHILIPS公司从2000年开始一直在探索适合自己的成本控制管理系统[1] 。虽然专家学者和企业的研究已经取得了显著的成果,但市场化的生产成本控制决策支持系统产品还较少。
企业急切盼望提高决策的质量和稳定性。在企业资源计划中,成本管理数据的统计是比较齐全的,他们基本都有连续的收集和整理,并且有统一单位,使用起来比较方便。本文通过分析ERP基础数据,辅助决策工作,为完善决策支持系统进行了尝试性的研究。
2 成本控制决策支持系统的需求分析
市场变化日益频繁,依靠人工计算产品成本所耗用的时间较长、结果简单,据此进行结构和趋势分析比较困难;用手工很难算出每笔订单的成本,企业不能充分了解现有生产情况。而在ERP系统中,已经收集了大量的统一格式的基础数据,因此构建基于ERP信息的生产成本控制决策支持系统,可以有效支持生产成本控制。
成本控制流程由料、工、费驱动,结合库存信息,以及在产品信息,进行成本归集和成本控制分析。在生产成本控制决策支持系统中,决策者可以调用ERP中的基础资料,比如:原材料消耗信息、工资信息、应付福利费信息、累计折旧信息、无形资产信息等等。输送到决策支持系统,并按照一定的成本归集方法进行成本归集和成本分析,从而提高决策活动质量。
成本控制工作主要包括:产品成本计算、标准成本计算、预测订单成本、计算成本差异、订单盈利分析、成本信息之间相关性分析等等。
2.1 产品成本计算
产品的成本受许多因素影响,其中主要由料、工、费组成。本文选取构成成本的主要因素,比如:外购物料单价、自制物料单价、工时、产量、工作率等。物料采购情况影响产品成本计算,产品成本对成本差异分析产生进一步影响,从而影响成本差异分析报告,影响决策质量。
2.2 标准成本计算
标准成本方案设置影响标准成本的计算。标准成本又会影响成本差异分析和订单成本预测,从而间接影响成本差异分析报告和成本定价决策。
2.3 预测订单成本
根据产品成本计算模型,可以预测出订单的成本,订单成本与生产过程实际成本比较,进一步进行定价决策和订单盈利分析、预测。预测订单成本有效地帮助管理者预测盈利空间,使生产、销售工作持续稳定。
2.4 计算成本差异
分析实际成本与预测产品成本之间的差异,生成成本差异报告。成本差异分析主要受到标准成本和实际成本的影响。
2.5 订单盈利分析
进行订单成本预测与订单实际发生适时比较,分析差异,快速实现订单盈利分析,并产生订单盈利分析报告。
3 成本控制决策支持系统的结构
经过对生产成本控制流程进行分析,提出了基于ERP基础的生产成本控制决策支持系统结构。
图4.4 成本控制DSS功能结构
3.1 人机交互接口
人机交互接口主要处理两类信息录入,分别是ERP内部的信息转入服务、外部信息录入工作。信息录入接口模块要结合知识管理服务对不完整的信息进行简单处理,并且对信息进行归集和分类存入数据库;生产过程内外环境信息查询功能,能提供ERP中销售信息、采购信息、库存信息、财务状况信息、质量信息、人员情况信息等的综合查询;能够对信息查询和知识共享做出响应。
3.2 运算处理部分
根据DSS的信息和决策者的要求,进行处理运算。运算处理部分包括:产品成本计算合法性检验、产品成本计算、标准成本计算、成本差异计算、预测订单成本。
3.3 信息分析
信息分析模块是对信息录入模块的结果进行深层次处理。生产计划分析是根据生产情况、材料供应情况、仓库储存情况进行评估,进而对生产计划做出决定的依据。因素之间相关性分析是对构成生产成本的因素进行分析,找出各个因素之间是否有相关性,从而降低成本分析的难度,达到控制和降低成本的目的。成本差异分析包括量差分析和价差分析,从中找出成本差异的原因,为提高成本控制水平提供依据。订单盈利分析是适时比较订单预测成本和实际发生成本,分析差异,快速实现订单盈利分析。
3.4 成本控制决策
决策者根据决策支持系统信息和运算处理结果以及信息处理分析结果,进行成本控制决策。成本控制决策包括:成本计算策略选择、标准成本设置方案选择、定价决策、订单盈利分析决策、生产计划制定。
3.5 成本控制绩效评估
成本控制绩效评估是根据生产计划执行情况,生产合同完成效果,以及生产策略选择的正确与否,以及采购部门和销售部门进行综合评价,是改进DSS的必要步骤,并对数据库、模型库、规则管理库中信息产生影响,是再次生成生产成本控制信息和修正成本控制策略的重要依据。
参考文献
[1]魏士银,制造业成本控制方法和实施的探索,D,首都经济贸易大学,2008,6.
关键词:企业管理;内部控制;信息化;采购管理
中图分类号:F270.7 文献标识码:A 文章编号:1001-828X(2012)12-00-01
一、管理信息系统在采购过程中的实现
企业以赢利为目的采购物资、服务等用于生产经营活动,由此决定了企业采办要面临一定的采购风险,为有效地控制采购风险,必须建立一系列内部控制规则从而实现对采购风险的有效控制;对于石油企业所处的能源行业,采购支出一般占整体营业额的30%-50%左右,采购管理是石油企业尤其是集团企业内部控制中最为重要的一环,根据企业战略规划及管理要求建立采办管理模式,在此基础上设立现代的采购管理制度,并通过管理信息系统等信息化的手段将采购管理制度、管理流程贯彻到每一个过程与控制节点,成为现代石油企业实现采购内部控制的重要途径。下述将就国内某石油公司构建采购管理信息系统的实现过程,力求在采购管理信息系统与采购内控管理的有机结合方面作探索。
(一)采购管理信息系统建设的组织
采购管理信息系统与采购内部控制制度的建立是企业采购管理的两个重要子系统,其相互独立而又相互关联,实施起来牵扯到企业管理的各个部门及各个层次,需要大家的共同配合,因此两个子系统的实施必须有企业最高领导者的深入理解与支持,必须成立一个最高领导负责的组织机构,调动各方面的资源,保证系统的顺利进行。
采购管理信息系统建设组织机构的建立,要考虑企业的规模与当前企业的管理现状,信息化建设项目多为阶段性项目,因此其建设一般模式是项目组建设模式,即组织机构多为项目组、项目部等形式,通过项目运作,待项目完成成熟后移交到企业内部信息化部门或专业运行维护机构进行运行维护。现在石油企业多为集团化企业,集团下设多个分公司,项目组的组成要以集团内位于核心管理层的采购部门及信息管理部门人员为主,其中要包括管理信息系统的策划分析人员、程序员等及采购管理人员。项目组一般由集团总经理、CEO或级别相当的人员担任项目经理,以此确保采购管理信息系统的顺利推动。
(二)系统需求调研与企业采购管理流程重塑
在内控管理上为适应采购管理信息系统,企业管理工作必须逐步完善以下工作: 管理工作的程序化;管理业务的标准化;表单、记录及报表文件的统一化;基础数据资料的完善化和代码化。这样才能实现通过采购管理信息系统对企业管理节点、过程及流程的有效控制,避免风险,确保内控原则的落实。
采购信息系统项目组首先要对企业的发展战略及采购战略有一个了解,对企业的组织机构进行分析,确定企业目前的采购管理模式。系统需求调研与企业采购管理流程的重新塑造主要采用调研问卷、走访座谈及查看资料三种形式结合。
调研问卷的内容包括企业目前的组织机构、采购管理模式、采购管理流程、采购管理人员及采购从业人员关注的问题等进行初步的了解,调研问卷的发放范围应确保覆盖全部采购部门,其他采购相关部门也应有一定的覆盖面。
“过程方法”是组织内诸过程的系统的应用,连同这些过程的识别、相互作用及管理。在采购管理流程重新塑造中应用“过程方法”,就是要按照:采购管理过程的识别、采购管理流程的梳理、流程改造、形成新的采购管理流程,这样一个轨迹去逐步推进。在各个阶段的工作中贯穿始终的原则是:以“过程方法”为核心思想,做到“纵向到底,横向到边”。对企业所属所有分支机构的采购过程、流程进行充分辨识。绘制企业整体的采购管理流程图,考虑控制环境、控制活动两个内控因素,各风险点的控制。对流程进行优化、合并,形成新的采购管理流程。并以此为依据,重新以体系化、标准化的形式编写采购管理制度,统一记录表格及统计报表的格式。形成采购管理信息系统应用的基础。
在“体系化”采购管理制度应用的基础上,将采购管理风险点、过程控制及流程控制等内部控制贯穿在整个需求分析报告中,涵盖以下具体内容:采购管理流程的业务描述、功能需求、数据需求、性能需求及运行需求。需求分析报告作为采购管理信息系统实施的基础性文件,编写完成后,经过项目组初步审核,经公司主管采购业务领导审核并批准。
(三)系统程序及结构特点
下图为采购信息管理系统总体设计的逻辑模型。
采购管理信息系统采用B/S的架构模式,方便该管理信息系统的部署、维护和升级工作。在软件业务流程上,根据采购管理信息系统特点定制了“工作流”引擎,其具有组织机构设置灵活,能实现复杂多变的流程设置。在管理信息系统电子化流程时,把采购管理的流程分拆成若干各关键工作过程,由系统把这些关键工作过程串联起来,对于单个工作过程根据需要穿插以审批“工作流”,这样就形成了对采购各管理流程的信息化实现。“工作流”推动的模式在实际应用中收到了很好的效果,提高采购效率在18%左右。
二、结束语
随着企业信息化的进程不断推进,采购管理水平的不断提高,会不断地改进和重写管理流程。这也给管理信息系统的不断提升提供了一个新的问题,如何开发出一套应用性更强、软件业务重组更开阔的管理信息系统解决方案。随着企业信息化水平的提高,软件工程的不断进步,相信企业管理信息系统将会与企业的内控结合的更加紧密,为企业内控管理,风险管理起到更大的作用。
参考文献: