软件思想范文

软件思想范文（精选10篇）

软件思想 第1篇

UCD说起来好像是一个很神奇的字眼, 在设计领域, 她像灯塔一样受到很多人的信任, 甚至信仰。但是对于初识者来说, 她就像一位窈窕的蒙着面纱带着魔力的姑娘, 纤手一抬, 指到哪里, 哪里就有鲜花盛开。你不知道她的真实样貌, 也不知道如何才能接近她, 更不知道如何才能获得她的青睐, 只能任凭自己的想象力飞驰, 朦胧中, 她的形象因为不可触摸而越发显得神秘。

现在, 让我们像她所有信徒一样, 从慢慢接近她, 认识她开始, 在实践中渐渐熟悉她, 信仰她吧。

一、UCD介绍

在传统的软件开发中, 我们更注重的是功能特性或是特性, 而相对较少关注用户在使用这个产品过程中的体验。

UCD (User Centered Design) 是指以用户为中心的设计, 其目的是让用户在使用产品的过程中感受到愉悦性, 即不但让用户感觉产品“能用”, 还要让用户认为“好用、爱用”。

这里需要明确的是:UCD不是一套全新的流程, 只是一种“思想”。应用UCD思想进行设计, 改善用户体验, 不需要也不允许对原有流程进行“革命性的变化”。我们只需在原有流程的基础上进行一些必要的“改良”而已。

更好的用户体验总是首先由用户使用, 通过与产品交互, 然后才能谈体验。我们以用户参与度比较高, 或者说用户和产品的交互比较多的软件开发过程为例, 了解UCD思想在软件开发项目中是如何被应用, 从而改善用户体验的。

二、软件开发标准阶段

一个标准的软件开发项目阶段如图1所示:

图1所示内容是一个标准的软件开发项目可能经历的所有阶段, 所以我们称之为“标准的……阶段”。但是在实际工作中, 大多数的软件项目都没有那么复杂, 可能不必经历所有阶段就能最终完成项目的工作。即使一个项目确实需要经历所有阶段, 如果结合项目实际, 则会发现不同规模、目的、背景的项目在相同的阶段内, 要完成的任务也不完全是一样的。所以, 为了节省成本, 通常在项目启动之始, 我们会根据行业特点、规模大小、项目特点等情况综合考虑, 对上述标准阶段进行变更或者删除, 这个过程称为“裁剪”。

尽管标准软件开发项目阶段会在实际工作中被裁剪, 但是大多数情况下, 作为开发主体的几个重要阶段——可行性分析、系统规划、需求分析、系统设计、编码实现、测试, 我们只是对其中的具体工作做必要的简化或者变更处理, 通常不会把这个阶段完全裁剪掉。

软件项目一般由几个子项目组成。如果软件项目涉及的范围比较大或者比较复杂, 通常会根据实际情况把相对独立的成果作为开发目标, 建立一些子项目, 分别成立团队, 并行地进行工作。例如, 目标软件既包含前台的HMI1, 也包含后台的Application2, 甚至包含数据库和底层的驱动程序等。通常, 为了降低复杂度, 还会建立HMI开发子项目、Application开发子项目;又如, 软件开发面临某个关键性课题, 而这个课题相对独立, 和其他工作之间的联系也非常少, 那么可以把这一课题作为一个子项目单独进行管理;再如, 在研发性项目的可行性分析阶段, 分析结果决定项目是否继续进行, 那么, 就可以把这个阶段作为一个子项目。当然, 为了项目整体的一致性, 在一些关节点上, 不同子项目团队之间需要进行沟通协调, 以确保各子项目之间、子项目和主项目之间理解一致、目标一致。

图2项目职能流程图用矩阵式结构说明了在项目的各个主要的开发阶段, 担任不同职能的人 (或者是团队) 是如何协同工作的。

三、软件开发过程中应用UCD的核心步骤

在软件开发的过程中, 应用UCD进行开发的项目成为UCD项目。UCD项目和传统的软件开发项目相比, 主要增加了用户研究员、交互设计师和视觉设计师。

用户研究员:主要研究用户的使用习惯、喜好, 对产品的需要和期待, 以及对产品的真实感受和意见等;交互设计师, 负责把用户需要的功能有效地转化成一系列的界面展现给用户, 凡是涉及到表达、传达的问题, 都由交互设计师来做;视觉设计师, 主要负责创建可识别的图像, 充分利用相关的显示媒体, 用艺术的界面外观, 形象地表达功能, 保证产品在布局和视觉感觉上的一致性 (在传统的软件项目中, 有些项目也会有比较原始的“界面视觉设计”的工作。但是通常这样的工作都是在项目后期, 以“把界面美化一下”的要求下发下去的。这项工作要求“设计”的成分很少, 担当这项工作的角色通常被称为“美工”, 在这里不做讨论) 。

UCD项目可以区分为5个主要阶段, 或者称为5个核心步骤:计划、研究、设计、实现和度量。

UCD项目不论是涉及的角色还是阶段, 都必须在原有项目职能的基础上进行调整和增加, 不能独立进行。否则, UCD就失去了物质基础, 变成空中楼阁, 失去了原本的意义了。

对传统的软件开发流程和组织结构进行必要地改进后, 新流程和职能如图3所示:

UCD项目的5个核心步骤和项目阶段是能够一一对应的。

1. 计划:

对应于两个阶段, 分别是“可行性分析”阶段和“系统规划”阶段。

a) 在“可行性分析”阶段, 主要是对可行性分析工作进行支持, 支持工作本身需要制定目标、有行动计划 (在“图3UCD项目职能流程图”中, 这个计划本身并未作为独立活动进行呈现) 。

b) 在“系统规划”阶段, 在进行“项目规划”“项目计划”活动的时候, 需要把UCD活动考虑进去, 并且在项目实施过程中进行跟踪。UCD活动主要指“图3UCD项目职能流程图”中绿色和黄色背景的部分。

2. 研究:

主要对应于“可行性分析”阶段, 为项目前期的策划和构思提供支持。具体工作包括:

a) 竞品分析:

分析竞争对手的产品, 从中找到可借鉴和可改进的部分, 并且出具书面的《竞品分析报告》, 报告中应该包含具体的解决方案。

b) 可用性分析:

分析自己的产品, 从中找出可改进的部分, 并且出具书面的《可用性分析报告》, 报告中包含具体的解决方案。

c) 用户研究:

通过用户访谈, 实地考察等方法, 了解用户, 以获取用户特征和角色关系、用户期望、任务目标和使用场景等一系列信息, 并且出具书面的《用户研究报告》, 报告中应该包含用户特征库、场景库。

d) 设计草图:

根据初步需求、用户研究结果、竞品分析报告、可用性分析报告等输入资料的要求, 设计概念化的产品原型草图, 称为“概念原型”。概念原型要求只包含最重要的信息, 不应涉及任何细节。因为过早的呈现细节容易分散人们的注意力, 所以原型必须以迭代的方式逐步细化。

3. 设计:

主要对应“需求分析”阶段。在这个阶段, 主要进行迭代式的“交互设计”和“视觉设计”两项工作。原本的“确认需求”活动作为下一个迭代的输入。

a) 交互设计:

根据需求, 合理设计产品的用户界面框架、交互方式;开发原型, 由HMI开发团队、Application开发团队、视觉设计师共同对交互方式、交互原型进行可行性评估。

b) 视觉设计:

软件的用户界面视觉效果设计。

c) 迭代式设计:

交互设计完成之后, 在“确认需求”工作中, 对交互原型进行评估, 评估结果作为交互原型设计的下一个迭代的输入;在视觉设计完成之后, 对视觉设计的成果物进行评估, 评估结果作为视觉设计的下一个迭代的输入。

4. 实现:

主要对应“需求分析”阶段。在这个阶段, 主要进行“功能检查、设计评估工作”。“功能检查、设计评估工作”和“系统测试”看起来是类似的, 都是以项目的最终成果为检查对象, 但是它们的检查目的是不同的, 所以观察角度也不同。前者主要目的是判断系统是否按照最初的设计实现, 交互方式是否合理、视觉效果是否和设计初衷一致;后者关注的是系统功能是否完成、性能如何、还有多少bug、是否健壮等技术层面的问题。

5. 度量:

主要对应的是“测试”和“可行性分析”阶段。在测试阶段进行的“用户测试”活动和在可行性分析阶段进行的“可用性分析”活动, 两者的本质是一样的, 工作内容都是对产品的可用性进行评估, 成果都是《可行性分析报告》。

四、UCD在项目中的应用

在采用迭代式开发的UCD项目中, 上一迭代结束的时候进行的“用户测试”的输出成果 (可行性分析报告) , 可以直接作为下一个迭代的“可行性分析”阶段的输入资料。UCD的度量步骤和项目的测试活动把UCD项目的首尾连接起来, 形成一个能够不断自我完善的、闭合的良性循环, 如图4所示:

如上所述, 在实际的项目中, 应用UCD的活动归纳起来有如下几种:

●竞品分析

●可用性分析 (包括项目前期的可用性测试和项目测试阶段的用户测试)

●用户研究

●交互设计 (包含草图设计、交互原型设计和视觉设计)

但是, 并非每个项目都必须完成上述所有活动。在实际工作中, 可根据项目的实际情况, 综合分析哪些活动是合适的、必要的, 这很重要。不要盲目追求应用UCD来作项目。我们回到应用UCD作项目的初衷:让用户在使用产品的时候有更好的感受, 让用户“爱上”一款产品。但是, 在具体项目实施过程中, 我们很难面面俱到, 比较好的做法是主攻其中的某几方面。而在我们主攻的方向上, 有些UCD活动是有效的, 有些则不是。因此, 不要根据市场最流行什么, 我们就一定要做什么。应记住, “只选对的”就可以了。

此外, 要清楚“小进步也是进步”的道理。在给老产品做更新的时候, 用户相对稳定而且用户已经具有使用经验。这种现实情况下, 做用户测试, 进行可行性分析, 寻找“痛点” (痛点指用户用起来不舒服的地方) , 然后改善它。这个工作路径不论从时间上, 还是从成本上来说, 显然都比从“用户研究”开始入手更合适一些。

“他山之石可以攻玉”, 当我们要做一款产品的时候, 如果市场上已经有类似的产品出现, 我们不妨先分析一下, 这些竞争对手的产品有何特性, 优缺点何在?卖的最好的产品是哪一款, 为什么?用户最推崇的是哪一款, 为什么?知己知彼的情况下, 如果能够做到“扬长避短”, 则一样可以取胜。因此, 从“竞品分析”入手也是一个不错的选择。

软件工程实践者的思想[1] 第2篇

得其精而忘其粗，在其内而忘其外；见其所见，不见其所不见，视其所视，而遗其所不视“--《列子说符》

1.语言只是工具

我曾经是非常执着的开发人员，我有连续几天几夜做Coding的经历，也曾经为了一个技术问题耗上三、四个星期而导致项目一再延迟，还曾经为了一个实现细节与项目相关的人员逐一争论。

我也曾经像大多数开发人员一样热衷于争论语言之间孰优孰劣。我在论坛上写过一个简介，其中个人特长是”擅长TPascal、Delphi、TASM系列语言，痛恨C/C++“.我至今保留这段文字，因为那的确是真实的经历。

如今我已经不再专注于语言，正如我在第一章中写到的一样：成天讨论这门语言好，或者那门语言不好的人，是可悲的。

然而就在我写这段文字之前的一年，我还是无止尽地深入语言细节，深入操作系统细节，以及深入……开发的细节。

就在3月间，我接受一个朋友的邀请，去北京做一个专题培训。我用了近两周的时间，做了50页的幻灯，全面讲述Delphi和Delphi.NET.然而在临行前的一晚，我辗转反侧，思考着一个问题：我究竟做了些什么？或者说，我究竟想告诉学员些什么？

凌晨5点，我在幻灯的末页后插入了一张幻灯，标题是”语言只是工具“,而幻灯的内容是一张图。这是与培训完全无关的一张幻灯。然而，这是自我接触到管理，以及从我接触到工程以来，第一次正视”软件工程“这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系！

对于一个程序员，或者以程序员自命的人来说，看清楚这一切的第一步，竟是一句”语言只是工具“!

猿之于为人，”学会制作和使用工具“是最重要的标志。因而我不知道”语言只是工具“这句话，究竟是对语言的膜拜，还是漠视。然而从那一刻开始，我才真正地知道工程。

2.程序

在我的那个图中，在最内层的环里，是”程序=算法+结构“.这是编程的本源定义，也是原始的状态。与代码相关的任何工作，最终仍旧会落足于这样的一条规则。

编程的精义于此。从有开发行为开始，它就存在。挖山不止的愚公在数千年前就在用类似的行为做编程实践，而几十万年前的智人，也在循环与分支所构成的逻辑中打转。

3.方法

推动这种逻辑向前发展的是”方法“和”方法论“.长期编程实践，自然的推演与总结，必须沉淀为某种（软件开发）方法，于是”过程“出现了，”对象“出现了，相关的方法论也就出现了，

这是实践的成果。方法不是某个人或者某个组织创造的。瓜熟而蒂落，实践积累达到一定的程度，就算微软不提出某个方法，IBM也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。

方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如”模式“是一种方法，而模式就是你昨天书写代码的那个行为。只不过，GoF归纳、抽取、提升了这些行为的内在规律。你看不到你做事的行为，也就不能理解”模式“作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。

同理，理解过程也需要编程经验，理解对象也需要编程经验，理解MDA与SOA还是需要编程经验。

这可能就发生在你回顾上一行精彩的代码，或者上一个失败的项目的一瞬息。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。

有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。

GoF因为无数次的代码回顾而得道。

4.过程

过程随生工程出现。过程解决的是工程中角色间的关系问题。

过程说的是很多人（团队）如何组织在一起进行开发。它首先把工程中的各个环节分解出来。这样，有了环节，就有了角色；有了角色，就有了沟通。因此过程中的问题，就是角色、沟通和环节的.问题。

哪些环节更重要取决于具体的编程行为，也就是具体的项目。

例如产品开发的周期可以一再拖延，因为对产品来说，更重要的是其品质和技术壁垒。因此你可以看到暴雪公司的游戏总是一再跳票，而它从来都是将大量玩家测试和开发人员的个性特征放在第一位。相类同的，DOOM与QUAKE系列的灵魂就是在游戏引擎的开发和设计上。

如果用这样的模式去做项目，可能软件公司没死掉，工程需求方也被拖死。试问你有看见客户因为你对技术的远景描述而憧憬吗？不，你只会看到他们因为项目的一再延迟而懊恼，而沮丧，或……暴怒。

憧憬这种事情，只会发生在那些铁杆玩家身上。

分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。

角色的确定，以及角色间的沟通问题，在项目过程中同样重要。工程组织是否合理，相互协作是否紧密，是这个项目成功的保障。

探究软件编程中数学思想的应用 第3篇

关键词 软件程序 翻译 数学思想

中图分类号：TP31 文献标识码：A

在计算机软件复杂的编程难题当中，需要利用程序设计实现理论知识与现实题目的灵活转化，借助数学工具来促进抽象具象化，以期达到简化流程、模拟编程设计、进而推动软件编程更新换代之效。编程设计可概括为“所需解决事析——数量关系模型的构建——程序翻译算法语言”的进程，所以，借助数学知识寻求程序关系成为分析逻辑关基。

1数学对于推动软件编程的促进作用

数学化的程序编译思想在传统程序设计理论的基础上增加了更多数量化、抽象性数据结构特征。在将实际问题上升为数象的过程中将编程划分为前期的信息查询收集、中期的程序设计开发以及后期的跟踪性反馈维护机制，其中，数辑推理显得至关重要，这对于合理考量数据内在体系展开科学描述具有深刻内涵。数据结构的有力利用能够在促问题解决的同时将其逻辑化整合，采取数据对象选择鉴定的模式，寻找其内含的數学关系，因而在最大限度上依机技术科学落实程序的语言化，达到优化编程逻辑效果的目的。

2数学开发编程的典范列举

下面给出利用数学知识建立数学模型的典型实例。

2.1递进法数学推理

例：假设团队中的五个成员，第5个人比第4个人大2岁。问第4个人多少岁？他说比第3个人大2岁。问第3个人多少岁？他2个人大2岁。问第2个人多少岁？他说比第1个人大2岁。最后问第1个人多少岁？他说是10岁。请问第5个人多大？

求解：

#include

int age（int n）

{ if（n==1） return（10）；

else return age（n-1）+2；

}

void main（）

{ int n；

n=5；

printf（"The fifth age is %d.＼n"，age（n））；

}

2.2方程法推理函数逻辑

例：法律相关条例中要求行李的限制小于等于20KG，收费为0.12/KG；如果行李重量大于20KG的话，东西超过的部分其重为0.2元/KG，求解函数关系。

求解：

根据文字要求可得，假设旅客的东西为w千克，总计需要交纳y元费用，则题目中的函数数量关系表述如下：

y=0.12w当w≤20时

y=2.4+0.2（w-20） 当w>20时

依据不同乘客所携带东西的w重量值存在差异进行计算方法的筛选，形成数学建模。

2.3假设的利用巧妙分解数据

例：如果题目在告诉我们abc+cba=1333的前提下，要求表示出所有满足a，b，c条件的数字排列组合，编程的求解如下。

求解：

#include

#include

void main（）

{

int num，a，b，c；

clrscr（）；

printf（"Press any key to calculate！＼n＼n"）；

getch（）；

for（num=101；num<1000；num++）

{

a=num/100；

b=num%100/10；

c=num%10；

if（num+c*100+b*10+a==1333）

printf（"＼n%d+%d=1333＼n"，num，c*100+b*10+a）；

}

while（！kbhit（）） ；

}

3探究数学与编程交互性的捷径

要实现数学与编程的有机统一就要通过分析综合来概括对比两者的相通与差异之处，灵活使用演绎推理与类比猜测的思建二者的相关性。

3.1计算机编程设计的普适性架构

为解决现实需求的指令程序语言是软件编程。设计的过程由数学模型的构建、特定算法的编译等环节构成。数学思想抽可借鉴性与高效用性决定了从编程思想的数学化过程可以分析出，实现程序的具体化、现实化主要困境在于如何有问题抽象出数学假设进而构建模型；怎样依靠数学方法规划题目的治理；尝试论证数学思维的工具作用验证其度。

3.2落实数学编程的改良途径

编程中数学的运用直接决定于数学架构能否可靠精确地反馈现存的问题，进而推动计算机软件解决原有现象效用是实现终落实程序实用性与有效性的整合。建立在透彻剖析现状的基础上，搭配数量间的关系，再将其转化为通用的数进行表述，最终实现系统性地抽象数学模型。

3.3数学性编程的价值实现机制

编程数学化的进程可简化为以下步骤：①在充分收集有效信息的前提下了解所构建程序之间的数量关系；②依据因果关设力图将程序题目数学数字化；③在已有数学模型的基础上选取恰当的逻辑结构表征程序间内在的关系；终究借内容的诠释推动程序关系的解释。

总之，编程设计解决实际问题的关键在于数学关系能否恰当构建，真正掌握实际问题抽象为数学模型的逻辑方法成为了程困境的捷径。因此，要在更新数学思想的基础上实现信息技术系统性处理，最终推动现代软件编程事业发展。

参考文献

[1] 李天平， 苏小兵. 面向对象编程思想在 PLC 编程中[J]. 微计算机信息， 2011， （31）： 223-224.

[2] 祝冰. 面向对象的现代工业控制系统实用设计技术[M]. 北京：清华大学出版社， 2011. 77-79.

软件开发中的数据驱动设计思想 第4篇

计算机软件是用来刻画现实世界,解决现实世界中的问题的。编程语言是实现的工具。算法是解决方案。数据结构是现实世界的数据模型。数据结构和算法是计算机软件开发的基础。不管是采用结构化、模块化编程,还是面向对象编程,良好的数据结构设计决定了算法的复杂程度,也决定了程序代码的复杂程度。

2 数据驱动设计思想

软件开发中的数据驱动就是尽可能的将设计的复杂度从程序代码转移至数据。也就是相对于用程序逻辑解决问题,采用的是很好地设计数据结构,而程序只是简单地表达、解释数据的内容。反过来也可以说,是数据驱动了程序的运行。它不是一个全新的编程模型:而只是一种设计思路,它既可以应用到结构化编程模型中去,也可以应用到面向对象编程模型中去。

通过一个示例来解释数据驱动设计思想。假设有一个程序,需求就是简单地根据错误代码输出相应的错误信息。

很可能会这样处理:

这样的处理方式是首先想到的,通过switch...case语句,根据错误代码输出相应的错误信息。也就是用程序逻辑解决问题。错误信息常常有几十个,甚至更多。可想程序会很长。如果错误信息的代码或内容发生更改,将不得不更改程序。

下面换一种思考的方式,采用数据驱动的方法解决问题。如果错误代码是连续的,那么程序将是这样:

也就是事先把错误信息排好顺序放进数组中,这样程序就变得非常简单。也就是在软件开发中通过数据结构设计,降低了程序的复杂度。

即使错误代码不是连续的,也可以采用数据驱动的设计思想:

这样设计了一个更加完备的数据结构,完美地解决了问题。

这种思路的优势:

(1)可读性更强,信息处理流程一目了然。

(2)更容易修改,要增加新的信息,只要修改数据即可,不需要修改流程。

(3)重用,就是将这种相同的逻辑提取出来,而把容易发生变化的部分提到外面。

3 数据驱动在测控领域软件设计中的应用

在测控领域,经常需要一种设备对某个产品进行测试。这种测试设备往往是由一个工控计算机以及计算机中附加的各种AD、DA、IO板卡,和信号调理单元组成。在工控机上运行的测控软件控制各种板卡,通过调理单元,把信号加载到被测试的产品上,并从产品上采集信号。

在测控软件的开发中可以广泛采用数据驱动的设计思想。比如可以将工控机中各种板卡的配置信息做成硬件配置信息表格存储在计算机上,软件只需要根据这个表格来发出指令或采集数据,而不需要直接操作某个板卡的某个端口。这样编写的程序可读性更强。

也可以将各种状态下的测试流程函数做成函数表,通过查表调用相应的测试函数,来完成各种不同的测试项目。这样编写的程序结构清晰,更容易修改。

下面详细介绍一下测试报表生成软件中数据驱动思想的应用。测试的数据常常有几十、甚至几百项。这些数据中,有些关键的数据需要出现在报表中,有些数据需要综合起来,在报表中给出正确或错误的结论。报表生成软件如何能够在报表中列出需要的关键数据,或综合性的数据?

在开发软件时,可以利用数据驱动的思想,将报表生成信息存储在电子表格中,并且事先准备好编辑好的报表Word文档。软件仅需要根据电子表格中的定义,把测试数据填写到Word文档中。下面给出这样一个电子表格,并做出解释。

上面表格中,第1列是序号,序号为0表示这一行不是实际的测量项目,而是其下各个测量项目的综合反映,也就是说下面各个测量项目全部正确时,它才正确,有一项错误,它就错误。

表格中最后一例定义了是否出现在报表中,以及实测值打印在报表中的位置。“0,0,0”表示不出现在报表中,“1,6,5”表示打印在第1个表格第6行第5列的位置。

表格中序号为0的行可以多次出现,每次出现都意味着其后的各个测量项目的综合结果由其表示。

以上定义了一个报表生成表格,这就是一个数据结构的设计。基于这个数据结构,可以采用结构化编程,或面向对象编程实现报表生成软件。可以预见这个报表生成软件具有简单的逻辑,同时又有广泛的适应性。报表内容的变化,仅仅需要修改报表生成表格就行了,不用更改程序代码。

4 结语

数据驱动在软件设计中具有重要意义。当程序员面对问题束手无策时,只有跳脱代码,直起腰,仔细思考数据才是最好的行动。数据比程序逻辑更易驾驭,尽可能把设计的复杂度从代码转移至数据是个好实践。数据驱动的设计思想既可以应用到函数级的程序设计中去,也可以应用在程序级的设计中。

摘要：主要阐述了数据驱动的设计思想和结构化编程、面向对象编程。通过一个简单的示例程序,介绍了数据驱动的概念,数据驱动在测控领域软件设计中的应用,指出了数据驱动设计思想在软件开发中的意义。

关键词：数据驱动,软件,编程

参考文献

[1]陈蓉,陈烽.软件工程中程序设计方法的比较.电脑知识与技术,2012,(02):333-334.

[2]Eric Steven Raymond,著.UNIX编程艺术.姜宏,等,译.北京:电子工业出版社,2011.

[3]夏杉,李博.面向过程知识重用的飞机设计过程ProA_K模型.航空制造技术,2012,(Z1):140-143.

软件思想 第5篇

经过陶四海老师对stata统计软件运用的教导，我对stata这个十分简便实用的统计软件有了初步入门的认识，并且通过对stata软件的学习与思考运用，加深了我对于统计学的概念及思想的认识。

统计学和统计软件是相辅相成的，没有统计学做统计基础思想个思维方式，统计软件对数据分析的运用将会是“盲人摸象”。而没有统计软件为大量的统计数据进行快速准确有意义的分析和处理，我们光掌握了统计思想和统计方法，也不能驾轻就熟的应对庞杂繁多的数据，将会造成统计结果偶然的偏差，影响到统计结果的可靠性。

正如陶老师说的，当今社会快速的经济、社会、文化等的发展，势必会需要大量的统计运用分析，而随着统计运用的需求也会造就许多优秀的统计软件。国外的统计软件发展是超过国内甚多的，spss，sas和stata，都是国外的优秀统计学家和软件工程师认可的优秀的统计软件。

统计软件重要的是统计思想来驾驭其迅速、高效，和其他的统计软件相比，stata的优点甚多。

运用stata进行统计数据的分析在步骤上和其他的统计软件是相类似的，在得到了相关的数据之后，软件运用者需要首先对数据进行的就是观察分析。在stata读取了数据之后，软件用户需要了解到数据的结构，数据的总体信息，如数据文件的路径和名称，大小规模，最后生成时间等等，软件用户需要对数据有个大概的认识，并对即将进行的统计数据分析思路进行有效的开展。

软件思想 第6篇

关键词：软件工程 多媒体课件 课件开发

中图分类号：G64 文献标识码：A 文章编号：1008-925X(2012)O8-0185-02

随着多媒体技术和网络技术的快飞发展，各类学科的课件应用而生。但在开发过程不乏出现一些共同的问题，如开发成本过高、软件质量低、重发开发等，这些问题给多媒体课件的开发和需求带来了严重的影响。要解决这些问题，就要有正确的软件开发理念。本文结合软件工程的思想，浅析一下如何能够更好地进行多媒体课件的开发与制作。

1、软件工程思想简述

人们曾从不同的角度，给软件工程下过各种定义。但是不论有多少种说法，它的中心思想，是把软件当作一种工业产品，要求“采用工程化的原理与方法对软件进行计划、开发和维护”[1]。软件工程是指导计算机软件开发和维护的工程学科，采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验证明正确的原理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。主要表现在软件开发费用和进度失控、软件的可靠性差、生产出来的软件难以维护等方面。

软件工程借助工程学和经济学的思想来指导软件开发的过程，大量软件开发实例证明了采用软件工程方法进行开发，可以消除或缓解日益严重的软件危机，从而提高软件开发的成功率和生产率。

2、软件工程和“课件工程”的对应关系

多媒体课件是指根据教学大纲的要求和教学的需要，经过严格的教学设计，并以多种媒体的表现方式和超文本结构制作而成的课程软件[2]。可以说多媒体课件是指与课程内容有着直接联系的计算机教学软件，多媒体课件作为一种教学软件，它属于计算机应用软件的范畴，适合软件开发的一般规律。当前，课件正在逐步向系列化方向发展，内容和规模不断扩大。这就要求蚕蛹科学规范的方法来开发和管理课件，软件工程的方法就是很好的选择，“课件工程”的发展趋向就是适应现实需要而产生的，其实质就是采用工程的概念、原理、技术和方法来开发和维护课件[3]。

在软件开发过程中一个重要的概念就是生命周期，按照事物从发生到消亡的规律，一般将软件生命周期划分为计划、分析、设计、编码、测试及运行维护等阶段。各阶段的工作又细化成细小的子任务，并产生一定规格的文档资料交付给下一阶段，下一阶段在上一阶段交付的文档资料的基础之上继续开展工作。这一思想应用到多媒体课件开发过程中非常必要的。

课件本身是个工程，要用工程的方法去处理。它也有自己的一个生命周期，下图是软件生命周期与多媒体课件设计开发各阶段的映射关系。

从图中的映射关系来看，多媒体课件作为一种辅助教学的软件，它的设计开发过程中无不渗透着软件工程的思想。课件开发不同于一般的软件开发，它要涉及教育、心理、专业知识等各个方面。从图中可以看出，将软件工程的原理运用于课件开发是较为自然合理的事情，开发人员在课件开发时应经历这样的一个过程：进行需求分析、按需准备材料（分析教学大纲，把握教学重点），概要设计（采集教学素材，编辑脚本），详细设计（选择好课件制作工具，程序设计），软件测试和维护。如何在较短的时间内投入较小的经费，获得无论是从数量还是质量上来说都比较令人满意的课件，引入软件工程思想是非常必要的，但是往往还需要注意一些问题。

3、用软件工程思想指导多媒体课件开发

3.1选题

选题是课件制作的关键。在制作之前，首先要研究分析课件的使用对象。以最大限度地符合使用对象的心里特征、认知结构，真正做到因材施教；其次要认真研究教材，做好选题论证工作，尽量减少不必要的投入。在选题时应注意结合设计工具特点。使得课件获得较佳教学效果。

3.2 分析

分析包括需求分析和可行性分析。需求分析主要是明确课件的学科内容及所要达到的目标，弄清楚使用对象对课件的全部需求，并用相应的文档准备的表达出来。可行性分析的目的是在选题之后，对问题的寻求一种在技术上可行、且经济上有效益的可操作的解决方案。在课件的分析阶段，要明确卡法课件所需要的经费、设备、人员以及时间做一个预算；明确课件是否具备运行的各种环境，包括硬件环境、软件环境和教学环境。

3.3设计

在多媒体课件工程的设计中，包含着教学设计和系统结构设计。设计的主要任务就是将前面的需求转变成软件的表示形式，在软件工程中又可以细分为总体设计和详细设计。用软件工程的思想指导课件设计，首先是以教学目标和教学对象的特点为出发点，规划、实施和评价教学活动的全过程；其次，多媒体课件信息量大，具有交互性、集成性、控制性等特点，我们需要根据教学设计的结果对整个课件的体系结构、数据结构、用户界面、交互方式进行分析设计，编写相应的文档。

3.4制作编辑

制作编辑主要包含工具的选取、素材准备和编码。这个阶段是软件集成阶段，在完成了前面的设计工作后，要编写相应的脚本，以此为依据来保证课件的质量、提高课件开发的效率。在多媒体课件制作中还涉及到素材的准备，因为多媒体课件是多种媒体信息的载体，在制作编辑课件时，需要采集制作相应的文本、图像、声音、视频、动画等素材。准备好足够的素材后，制作人员就要根据教学目标和教学对象特点来选择合适的开发工具或编程语言，将准备的这些多媒体要素组织成一个完整的，灵活的，具有科学性、教学性、艺术性的多媒体课件。

3.5 测试评价

测试和评价是开发时期的最后一个阶段，是保证软件质量的重要手段。按照不同的层次，测试又细分为很多种。在多媒体课件的设计制作中，要不断的对课件进行测试，使其正常运行。对编制好的课件也要在实际的教学环境中去实践，通过不断的测试来发现课件中存在的错误和不足，然后进行修改和进一步的测试。评价也是这一阶段重要的环节，对多媒体课件的评价是指依照一定的标准，检查它是否达到预期的教育、教学要求和技术要求。

3.6修改和复用

在这一阶段，制作人员主要是做好课件的修改和复用。在课件制作过程中，要根据评价结果合理地进行修改，以进一步提高课件质量和效果。复用这个词是现代软件工程中一个重要的概念，就是将已有的软件成分用于构造新的软件系统。多媒体课件开发中的重复劳动影响了课件开发的效率,引入构件复用能有效的缓解这一问题。通过构件复用，在课件开发中可以有效地利用已经开发出的课件，消除了包括分析、设计、编码、测试等在内的许多重复劳动，从而提高了课件开发的效率，同时，通过复用高质量的已开发的卡键，可以有效地避免重新开发可能引入的错误，从而提高了课件的质量。

结语

多媒体课件是现在教育教学领域中必不可少的辅助教与学的工具，也是一种重要的教学资源。把多媒体课件设计与制作看作是一个大型的软件项目，以软件工程思想为指导思想，在课件设计中，严格遵循软件工程学的各个原则，结合课件自身的特点，以此提高课件开发效率，提高课件质量。

参考文献：

[1]史济民.顾春华.李昌武.苑荣 软件工程——原理、方法与应用（第二版） 高等教育出版社

[2]黄映玲。陈丽霞。黄丹 现代教育技术教程 华南理工大学出版社[3] 龚玉清 基于软件工程的多媒体课件开发研究 华东师范大学

[4]周锐 浅谈多媒体课件开发中构件复用技术 2003

软件思想 第7篇

Scrum是一种迭代式增量软件开发过程,其名称来源于橄榄球术语。Scrum过程包括了一系列实践和预定义角色的过程骨架。每个过程有一系列冲刺(Sprint,同样来源于橄榄球术语)组成,在每个冲刺中,开发团队创造一个可用的软件增量。 围绕这个冲刺,控制和准备工作在Scrum框架中都有具体定义［１］。开发团队可以根据框架实施开发方案。

1.1 Sprint冲刺

Scrum项目过程由一系列Sprint组成。Sprint长度一般控制在1~4周,具体长度可以根据项目需求自定义, 但是通过固定的周期保持良好的节奏,利于团队成员适应。产品的设计、开发、测试都在Sprint期间完成。

1.2 Scrum的3种角色

Scrum的行动框架中只存在3种角色,分别是产品负责人、Scrum Master和团队。这3种角色对一个项目负责,不同的责任在他们之间分配。 另外,将不需要承担责任的其他人员定义为项目利益相关者(Stake Hold- er)［２］。

1.3 Scrum的4个会议

在Scrum流程中,会议是衡量软件开发进度的标志, 是Scrum项目开发中的里程碑。Scrum框架定义了4个会议,分别是:Sprint计划会议(Sprint Planning Meeting)、 每日站会(Daily Standup Meeting)、Sprint评审会议(Sprint Review)、Sprint回顾会议(Sprint Retrospec- tive)［３］。

2软件开发过程管理

过程理论的核心是把一个软件开发项目的每个阶段都抽象为一个过程。过程也可以称为流程。一个项目中的一组相互关联、相互作用活动将输入转化为有价值的目标输出,这组活动就称作一个过程。任何项目的目标都是产生符合预期的有价值输出,以此来满足客户需求。在一个过程中,人利用资源把项目的输入转化为输出。相对于过程与工具,Scrum敏捷开发特别强调“人”的作用,但是并不排斥过程管理,并认为过程是将人的精力集中于结果的组织化结构,反过来这种组织化结构将引导工作,并影响产品和组织中人的关系发展。本文基于Scrum敏捷开发思想,将软件开发过程管理分为业务流程设计、版本控制实现、版本日志控制、限制日志修改等。

2.1业务流程设计

业务流程设计见图1。

2.2版本控制实现

SVN提供了基本的版本控制功能,但在实际应用中, 需要对其进行二次开发和配置,以适应一些附加需求,其中很多功能需要借助SVN的钩子(hook)实现。SVN提供的钩子(hook),类似触发器的特性,在版本库的某些特定事务发生时将触发钩子程序运行。

2.3邮件提醒模块实现

实现SVN的邮件自动提醒功能,需要对post-com- mit.tmpl进行修改。在SVN的根目录下的hooks目录中,有它的模板文件post-commit.tmpl,拷贝一份模板文件并改名为post-commit,然后在post-commit中编写处理程序,在Unix平台上,需要另外的shell脚本、Python程序、编译好的C程序或者其它程序来配合工作的完成。

2.4版本日志控制

开发人员要遵守开发约定进行工作。在约定中,一般要求开发人员为自己修改的文件提供完整详尽的版本日志。这是非常重要的,因为日志不仅是其他成员了解此次修改的依据,也是今后维护此版本所提供的重要信息。如果提交到版本库中的文件不写日志,或者提交如:done,已修改,简单问题等之类无意义的日志,会导致无法追踪历史事件。按照开发规范,完整详尽的日志一般包括:本次修改的bug号、任务描述、版本信息和修改原因等。具体由开发人员根据情况选择,填写日志的出发点只需能够清楚描述此次修改即可。

2.5限制日志修改

SVN默认是不能修改日志的,用户如果试图修改以前的日志信息则会出现错误:DAV请求失败;可能是版本库的pre-revprop-change钩子执行失败或者不存在,至少有一个属性变更失败;版本库未改变DAV request failed;it's possible that the repository's pre-revprop- change hook either failed or is non-existent.At least one property change failed;repository is unchanged。但是,实践中往往又有此项需求,程序员可能觉得以前填写的日志信息不够准确需要补充,因此,在系统中添加此功能,并限制只有提交者本人才能修改自己的日志信息。

2.6版本自动发布系统功能实现

SVN服务器、管理发布系统、外部Web服务器设置见图2。

发布系统是采用B/S结构开发的一套管理系统,专门用来管理每次的发布任务,部署在内部的一个Web服务器上。在发布流程的各个阶段涉及到开发人员、测试人员、系统管理员、评审责任人、运维人员等相关人员,发布流程设计见图3。

根据版本发布业务流程的逻辑关系,将发布系统管理端分为以下几个模块:公共信息管理、业务管理、审批管理、权限管理。根据此分类,设计出系统的UML类图,具体包括底层的数据库类、发布模块类、日志信息记录类以及管理层面的模板驱动类、工作流类,见图4。

2.7缺陷控制

缺陷控制是保障软件质量的重要措施。在整个软件开发过程中,由于大量人员参与,不能保证万无一失,因此需要一个对工作进行纠错和验证的过程。这个过程可以贯穿整个软件开发过程,在不断的控制下,可以避免因工作误差带来的损失。

摘要：在信息技术飞速发展的今天,软件行业的产品需求日益复杂,版本迭代异常频繁,开发周期越来越短,对软件质量的要求也不断提高。为提高软件生产效率,同时保证软件质量,软件工程领域在不断的实践和创新过程中提出了软件过程管理的概念。从软件过程管理理论入手,分析了在Scrum开发框架下,如何利用现有技术设计合理的管理流程,实现高效的软件过程管理,并通过搭建改进后的软件过程管理系统,实现软件开发流程的半自动化管理,使软件过程在灵活性和稳定性上得到合理的配置。

软件思想 第8篇

精益思想 (Lean Thinking) 来源于20世纪80年代的日本丰田生产方式 (即精益生产) , 其核心价值是用整体优化的观点合理地配置和利用企业拥有的生产要素, 消除生产过程中一切不产生附加价值的劳动和资源, 提高经济效益, 也即减少浪费, 以尽可能少的投入创造出尽可能多的价值。精益思想包括精益生产、精益管理、精益设计和精益供应等, 精益制造是其核心, 精益思想应用的目的是实现公司和客户的双赢。

2 软件项目管理引入精益思想的必要性

现在软件项目越来越大, 合同金额大, 项目周期长, 投入的人力和物力也逐渐增长。软件项目也是一个系统工程, 它不仅仅是软件的开发, 更是一个创造过程。软件技术日新月异, 客户的需求瞬息万变, 传统的管理思想和开发模式已经不能适应现实的需求, 所以有必要引入精益思想, 创新管理模式, 改变以前的需求管理, 开发流程, 变更管理以及员工管理等, 从而提高了工作效率, 降低成本, 节省项目管理人员和开发人员的时间同时提高软件质量和客户的满意度。

3 精益思想在软件管理中的具体实现

3.1 转变观念

精益管理的目的是降低投入, 提高产出, 实现双赢。实现双赢的首要条件是观念的转变。以前的观念是我为客户开发软件, 客户付钱, 我们开发, 开发完成后交给客户, 收款然后项目结束。因为一个软件项目往往服务多个部门的员工, 有些需求是在软件的应用过程中才发现或者是随着时间的推移又有新的需求。所以在设计产品的时候要有主人翁的精神, 就当这个产品是为自己设计, 扮演一个领域专家的角色, 不仅满足客户提出的需求同时和客户探讨将来可能用到的功能并提供解决方案。这样不仅能提高公司的收入同时也能提高客户的满意度。实现客户利益最大化, 赢得客户的信赖。

3.2 工具文化和项目成员培训

软件设计和开发不仅是脑力劳动同时也是体力劳动, 软件工程师加班加点是司空见惯的事情。现在软件技术还不能实现自动化生产, 代码需要一行一行的写, 页面还是需要前端工程师一个像素一个像素的调试达到赏心悦目。如何减少工程师的劳动, 提高工作效率是引入精益思想要实现的目标。有句话是‘工欲善其事, 必先利其器’, 也就是说为了做好事情, 必需做好准备。一个软件项目涉及项目管理人员, 需求分析师, 开发工程师和测试工程师等。公司要建议一个软件开发的生态系统, 比如项目经理要负责整个项目, 他需要全面的了解项目的各个方面, 遇到问题应该被及时的通知到并且及时的反应。达到这个目的, 必要的工具不可少, 比如Burn Down图, Agile.zn等敏捷开发工具可以及时的了解项目的进展及项目中出现的问题。在项目开始之前, 围绕项目需要的技术对工程师进行培训是行之有效的提高效率的方法。软件开发需要用到非常多的技术, 遗憾的是工程师不可能精通所有的技术, 所以培训可以让工程师快速的熟悉用到的技术。再者, 要有一套开发工具。它包括代码规范工具、代码重构、集成工具、快速开发代码的工具和自动测试工具等。“工具文化”在美国硅谷非常盛行, 一个公司最优秀的工程师经常是设计和开发工具, 利用便捷的工具可以极大的提高程序员的开发速度和质量。

3.3 细化开发流程

精益制造在软件项目中的应用就是要细化开发流程, 关注每个具体步骤的质量来达到软件的高质量。首先, 把项目分成不同的功能模块, 把这个功能切分成不同的小的模块, 逐个实现。在实现一个小的模块的时候, 可以把它分成不同的阶段。比如一个现金存取功能, 其中有个汇率转换模块。如果把这个任务给一个工程师同时他还没开始做, 可以设置它的状态为考虑中 (thinking) ;当这个工程师开始做的时候, 可以设置为工作中 (working) ;工程师开发完成并通过单元测试, 可以设置为检验中 (verifying) ;这个模块通过了集成测试, 可以认为开发结束 (Archived) 。这个过程看似繁琐, 但是对保障项目质量是非常必要的。特别是一些公共模块, 设计上的不足往往导致项目后期的大规模的代码更改, 也是导致项目不能按时交付或者失败的罪魁祸首。正所谓细节决定成败。

3.4 代码审查

代码审查是软件项目管理的重要环节, 尤其需要应用精益思想管理。一个项目组有不同层次的工程师组成, 高级工程师有丰富的经验同时也经历过非常多的失败教训。有这些高级工程师检查项目代码, 不仅可以很快的发现代码的不足, 同时也可以给初级工程师一些建议。代码审查是一个很好的互相学习, 培养团队合作精神和提高团队凝聚力的的途径, 也必然会改善代码质量, 提高开发效率。

3.5 团队成员自我反省

在项目开发过程中, 我们可以积累经验, 同时因为技术或者客观原因, 也一定有做的不尽人意的地方。精益管理中主张自我反省, 这个反省不仅包括团队中每个成员, 同时也包括团队本身的自我反省。通过定期的自我反省, 总结好的方面和差的发面, 继续发扬优点, 摒弃不足, 团队成员可以不断成长, 项目可以顺利推进。

结语

精益思想在欧美企业里得到有效的宣传和推广, 有远见的国内企业家也积极的倡导精益思想, 把精益制造应用于企业的生产经营中, 并且取得不俗的效果。近年来云计算、移动互联网的迅速崛起也加速了IT行业的变革, 这次变革也使得软件项目管理更加复杂, 把精益思想应用于软件项目的管理中一定会起到事半功倍的效果。

参考文献

软件思想 第9篇

1 管理信息系统开发的内涵

管理信息系统主要是指以计算机作为平台, 对管理数据进行处理, 整合, 进而为决策者提供管理参考的信息的系统。其中计算机则是数据处理的主要工具, 同样也是信息采集的重要手段, 在数据处理方面有其高效的特点, 在提高管理效率, 优化管理资源方面有显著的作用。同样管理信息开发模式也是多种多样的, 在国外制造产业的生产管理信息系统中主要应用的模式为MRP-II模式, 此种开发模式概念比较简单, 但其计算量相对来说比较大, 而当前制造产品结构变得的日益复杂化, 大部分客户对管理的要求也在不断提升, 因此传统的MRP-II管理模式已不能满足现代发展的需要。管理信息系统的开发模式是随着网络技术的发展而发展的。

2 软件工程思想在开发管理信息系统应用中存在的问题

管理信息系统开发与其他领域一样, 尤其自身多个方面的特点, 例如开发过程复杂、规模比较大、开发受思想限制等等。但也正是因为这些原因, 当下的管理信息系统开发面临着多个方面的问题, 总结起来主要有以下几个方面:

2.1 模型呆板, 理论化严重

管理信息系统开发过程中软件工程思想应用所面临的问题有很多, 但是就笔者看来, 最为严重的一个问题就是其模式比较呆板, 不能跟上时代发展的步伐, 同时, 开发过程中过度的依赖理论化。而这两个问题就导致了管理信息系统在开发的过程中仅仅只是重视理论与技术, 却忽视软件工程思想的重要性, 而缺乏了软件工程思想的信息管理系统势必不能满足当下客户的普遍需求。因而, 在系统开发过程中, 模式呆板, 理论化、技术化严重成为了管理信息系统开发过程中一个老大难问题。

2.2 结构化分析无法解决复杂的技术和管理问题

结构化问题在管理信息系统开发的过程中也存在着很多的问题。这是由于管理信息系统的开发过程在理论分为三个阶段。第一阶段是十分重要的一个阶段, 也就是系统分析阶段, 在系统开发理论里, 也常被称为结构化分析。这种分析方法运用在管理信息系统的开发过程中可以在很大程度上使得分析变得简单化, 同时系统的开发也更加符合标准。但是, 这种结构分析法却又一个十分严重的弱点, 即一旦系统的使用环境发生变化, 那么一些软件将不能正常使用, 进而很可能会使得整个软件的开发陷入困境, 甚至导致软件开发失败。

2.3 缺少管理, 造成质量评估不准

虽然在管理信息系统开发的过程中, 技术以及相关理论的运用是十分重要的。但是, 如果没有进行有效的管理, 那么开发的过程就会变得比较混乱, 没有秩序可言, 同时也会很有可能导致对软件开发的质量评估不准确。在当下的管理信息系统开发过程中, 这种问题是普遍存在的。

2.4 闭门造车, 导致开发周期过长

软件工程思想在管理信息系统开发中运用存在的问题除了有以上几个方面外, 还有一个比较严重的问题就是闭门造车, 开发周期较长, 这一问题也是管理信息系统开发领域长期面临的一个困难。我国管理信息系统开发的专业人士虽然有很多, 但是许多人士都没有认识到向先进主体学习的重要性, 对于一个软件的开发, 总是倾向于一个人且从头开始进行, 不去学习他人的优秀开发方法, 也不总结相关的开发经验, 如此一来, 就大大的延长了管理信息系统开发的时间, 使得开发的周期过长。

3 软件工程思想在管理信息系统开发中的应用措施

由上述可知, 软件工程思想对于管理信息系统开发具有十分重要的作用。然而, 在当下的管理信息系统开发中, 软件工程思想的应用却在技术、管理等多个方面存在着严重的问题, 且这些问题的存在阻碍了管理信息系统的开发进度。笔者在此对软件工程思想在管理信息系统开发中应用的措施进行了一定的研究, 希望能够为解决上述中存在的问题而做出一些贡献。

3.1 将软件工程方法引入到管理信息系统开发中

通过上述分析, 可以很明显的看出, 运用软件工程思想来进行开发管理信息系统是一件十分复杂的研究。在开发的每一个过程, 都需要开发人员进行认真、仔细的思考和研究。因此, 将软件工程方法运用到该系统的开发过程中, 可以使得软件的开发更有效率。

3.2 面向对象分析法的应用

面向对象分析法在软件开发中得到了广泛的应用, 并且已经处于了一个相对成熟的阶段, 因此在管理信息系统开发中完全可以大胆的对其进行使用, 使面向对象技术能够在管理信息系统开发中发挥其作用。例如, 将对象概念进行引入, 对实体进行描述, 结合类图、数据传递图等分析非结构信息, 从而建立合理的非结构模型。如果情况需要, 我们也可以将形式化方法引入到系统开发之中, 用严谨的语言对客户的需求进行定义。这样系统开发人员可以依据语言和图, 对用户的需求进行详细、合理的分析, 最终开发出让用户满意的系统。

3.3 加强项目管理工作

要想加强软件工程思想在管理信息系统中的应用, 还要加强系统开发的项目管理。系统开发是一个十分复杂的过程, 同时每一个阶段, 阶段与阶段的衔接都很重要。所以, 如果项目的管理工作能够很好的展开, 那么管理信息系统在开发的过程中就能够有序的、顺利的进行, 不会形成糟烂无章的局面。所以, 加强项目的管理工作十分重要。与此同时, 可以利用一些软件开发的理论, 通过对软件进行评估, 来加强软件开发的管理, 使得软件开发的成功率大幅度提高。

3.4 对原有软件原型进行利用

软件原型一般来讲都是建立在成功经验基础之上的, 基本上都能够取得客户的满意。所以, 对于管理信息系统来说, 消除软件原型是一项比较好的技术。与此同时, 原型的建立还有一个好处就是能够纠正系统开发过程中一些不正确、不合理的地方, 如此一来, 可以使得系统开发过程中所承担的风险变小、同时变得更加透彻, 促进管理信息系统的顺利开发。所以, 对原有软件原型进行利用意义重大。

3.5 利用构件技术避免重复开发

要想加强软件工程思想在管理信息系统开发中的应用, 除了要做到以上几个方面外, 利用构件技术来达到避免重复开发的目的也是十分重要的一个方法和措施。所谓的构件技术听起来特别复杂, 而实际上构件指的就是一个模子, 其目的是用来生产预制板。使用构件可以很有效的通过实例, 来对应用的软件进行组装并且加以控制。与此同时, 使用构件技术还有一个比较好的好处, 即一旦一些条件发生变化时, 相关人员可以对系统进行进一步的调控, 同时, 相关人员可以通过研究, 制定出一套可行的方案, 促使系统的开发成功。

事实上, 在管理信息系统开发的过程中, 软件工程思想的应用涉及到多个方面。然而, 以上仅仅只是其应用的几个方面, 并且每一个方面的探索都还比较浅显。因而仅仅凭借这些研究来促进软件工程思想在管理信息系统开发中的应用水平还是远远不够的。因此, 对于软件工程思想应用的研究还需要系统开发领域的专业人士进行进一步的研究和探索。

4 结语

软件工程思想在管理信息系统的开发中的应用对于管理信息系统的开发有着不可忽视的重要作用。然而, 软件工程思想的应用涉及的方面很多, 同时每一方面都比较复杂, 再加之我国管理信息开发领域对于软件工程思想的应用研究还没有达到一定的深度, 因而不利于该领域的发展。所以, 在今后的管理信息系统开发中, 要加强对软件工程思想应用的重视和研究, 并且要从软件工程思想的多个方面, 从管理信息系统开发的多个角度进行研究, 从而研究出更好、更有效的适应于当下管理信息系统开发的软件工程思想的应用方法和措施, 从而促进我国在系统开发领域的进一步发展。

参考文献

[1]涂海丽, 陆玲.软件工程思想在管理系统开发中的应用探讨[J].电脑知识与技术, 2011, 10 (13) :17-18.

[2]韩生利, 狄明.软件工程思想在有线电视管理信息系统开发中的应用[J].有线电视技术, 2013, 12 (3) :21-22.

[3]王建良.面向对象方法在管理系统开发中的深入应用研究[J].南京航空航天大学, 2012, 11 (11) :27-28.

软件思想 第10篇

关键词：软件工程思想,微课资源,微课生命周期

一、引言

可汗学院利用微课进行教学获得成功的案例引起了国内外学者对微课的极大兴趣,进而许多的学者都开始对微课进行不同方面以及不同方式的研究。对微课的研究涵盖了微课概念、内涵、制作以及使用评价等,甚至除了教育行业,相关企业也在不同的领域来推动微课资源的建设和发展,正是微课这种新的学习资源形式的出现,让人们希望借助这种新的形式来提高数字化学习资源的利用率[1]。“微课”是指以视频为主要的载体,记录教师在课堂内外教育教学过程中围绕某个重点知识点或是难点知识点亦或是重要的教学环节而开展的精彩教与学活动全过程[2]。其核心组成内容为教学视频,包括课堂教学、教学反思、习题点评等辅助性教学资源,它们以一定的组织关系和呈现方式共同打造了一个独特的资源单元应用“小环境”[3]。

虽然,微课发展很快,但诸多教师只是为了完成学校任务而去制作微课,很少考虑到学生的需求,也没有慎重思考过用系统的理论思想进行微课设计与制作,造成了现实中微课实践先行而理论滞后的现状,进而出现了学生利用微课进行学习的效率低下的现象。为了使微课在实际教学中发挥更大的作用,笔者用全新的视角——软件工程的思想来进行微课资源建设,改进微课发展中的不足之处。

二、微课资源开发现状与出现的问题

国内对微课的主要研究是介绍微课的背景、含义、特征、制作流程、意义及影响等内容,但是这些微课资源的形式不一,并未有统一的设计开发标准;此外,对微课的实际应用效果涉及也不多。虽然在国内,“微课”是一个人人口中的热搜词,但是,在微课资源建设过程中,很少有人想过用系统的理论去支持微课资源的建设与应用,所以,不可避免的就会出现以下问题。

(一)设计环节缺失

很多教师在制作微课时,就是简单地架起摄像机,把上课的过程拍了下来。这仅仅是微课制作的一个环节。笔者认为,要把微课看成是软件,用软件生命周期的思想来思考微课资源的建设。因此,微课制作还包括对学习者的需求分析、知识点可行性分析、制作微课的相关脚本、微课制作、微课后期、微课维护等环节。

(二)目标模糊

在制作微课之前,一定要做需求分析和可行性分析,很多教师缺失了这一环节,导致他们制作微课的目的不明确,目标模糊。对学习者做完需求分析之后,教师才知道学生真正需要哪些内容制作成微课,做完可行性分析之后,教师才知道不同的知识点需要将微课拍摄成不同的形式。

(三)参与人员不专业

参与微课制作的相关人员需要来自不同行业,如教师、美工等等,但是往往在实际操作时,微课开发人员并不是教师或是学习本专业的人员,很多资源建设的思想会隐含在开发人员的头脑中,最后可能导致制作出的微课没有达到预期效果。

针对这三个方面的问题,笔者把软件工程思想引入微课资源建设过程中,使微课资源有系统的理论作指导,使微课发展更具有系统化和规模化。

三、软件工程基本思想

软件工程的基本思想其实就是把软件当成是产品进行对待,一项产品想要合格地出厂,必须有一个完整的流程来制作这个产品。而软件工程思想就是控制产品是否合格的流程,从时间的角度把软件开发的各个阶段分解开来,并确定好各阶段的任务,然后按照时间节点来完成任务,进而进行整个流程,整个软件也就设计制造出来。软件工程思想的另一重要方面就是在各个阶段完成之前都会有严格的审查,审查分为技术方面和任务完成方面,通过比较软件现有阶段与开始阶段的差距来确定是否完成本阶段的任务,进而进行反馈修改。

软件生命周期是软件工程思想的基础,软件生命周期的阶段划分有多种方法。其中,具有代表性的是把软件生命周期化为六个阶段,分别是:问题定义、可行性研究、需求分析、设计阶段、测试阶段、运行与维护阶段,总体分为项目计划、资源开发、运行与维护三个阶段[4]。

四、微课资源的软件生命周期

微课资源开发虽然要利用软件工程思想,但是也不同于一般软件的开发,也不仅仅是传统的教学设计,具有自身内在的质的约定性。软件拥有自己的软件生命周期,而微课也可以当作一种特殊的软件,同样的,微课也拥有微课生命周期。微课的生命周期是指微课从提出、计划、开发、使用到最后淘汰的过程,本文根据微课的特性将微课生命周期划分为项目计划、开发、实现、评价和维护几个阶段(如图1)。

(一)项目计划阶段

微课资源开发和一般的软件开发不同,微课是针对某项课程里面的具体知识点来进行开发的。所以,在项目计划阶段的开始就要考虑,课程里面的哪些知识点适合做成微课?为什么要选这些知识点?这些知识点是不是学生的重难点?这些微课的受众是谁?这些知识点做成微课之后是否满足学生的需求?作为微课开发的前端分析,是由具有特定的教学内容和教学对象而决定的。

(二)资源开发阶段

在资源开发阶段最重要的就是设计,如何设计使微课更好地展示知识点?如何更好地设计能让学习者接受?如何设计能让学习者对微课更加感兴趣?这些问题都是在这个阶段需要思考的。但是设计阶段又与传统的教学设计有很大的区别,传统的教学设计只是其中的一部分,它是针对课程知识点的角度进行设计,而设计阶段另一重要的组成部分就是结构设计,结构设计是针对微课角度的,即根据微课内容编写出合适的脚本。除此之外,结构设计不仅要满足微课的教学性,也要考虑微课的技术性以及艺术性。

(三)实现阶段

实现阶段的任务就是根据设计阶段编写出的脚本,以及已有的多媒体素材,进行后期的剪辑与合成,最后得出完整的微课视频。这些任务主要是依靠媒体制作人员,这些专业人员选择合适的建设微课资源的工具,将资源开发出来之后选择合适的平台进行运行。实现阶段的产物就是最后的微课视频,既包括声音也包括画面,所以,要在保持专业性的同时也要把美观与艺术性兼顾,要考虑到音乐是否合适,色彩是否和谐。

(四)评价与维护阶段

微课资源完成之后,要尽快进行运用,只有投入到实践中,通过学习者的学习目标以及最后的学习效果之差进行衡量,以检验微课资源建设是否达到预期教学效果。让学生进行学习使用,才是真正的检验学习资源的好坏的途径,也是评价微课资源是否成功的指标之一,如果在使用过程中,发现有不足之处,比如:呈现内容存在知识性错误、画面不清晰等,就要尽快进行修改,从而提高微课资源的质量。

虽然,评价与维护阶段是微课资源建设的最后一阶段,但是,通过这个阶段可以提高微课资源的时效性与实用性,也可以让微课资源的质量更高。

五、基于软件工程思想的《微机原理》微课资源建设

基于微课资源的软件生命周期,可以为《微机原理》这门课进行微课资源建设。

(一)《微微机机原原理理》项目计划

1. 问题定义

问题定义就是要明确开发的微课资源的名称以及微课开发必须完成的总任务和必须达到的总目标。《微机原理》就是这门课的微课名称,微课开发的总任务及总目标就是能够根据课本上的知识点制作出符合教学要求的微课视频并应用到教学当中,使学生有较好的学习效果。

2.进行可行性分析

可行性分析包含两部分内容:一是要分析这门课程的内容是否适合制作微课以及学习者需要何种微课形式;二是分析完成微课资源建设的需要的技术环境是否能够达到。在进行《微机原理》这门课的微课资源建设时,首先要明确此课程的教学要求是通过理论与实践相结合的方式,让学生掌握计算机系统结构,以及通过操作性的实验来增加学生的动手能力。授课对象是陕西师范大学2013级创新班以及师范班的教育技术学在校本科生。所以,在微课建设之前就要考虑这门课是否适合做微课以及针对不同的班级微课设计时的针对性不同等问题。可行性分析的另一重要方面就是微课所需要的技术条件和运行环境,《微机原理》微课需要的是拍摄器材、实验器材、后期制作软件。

3.制定微课资源开发计划

首先,熟悉该课程的教材,然后挑出可拍摄成微课的知识点,制作相关PPT以及文字讲稿,然后再确定每个知识点拍摄成微课的方式,比如:课堂实录式、手机加白纸或录屏式等等。拍摄微课后,选择合适的后期编辑软件进行后期加工,最后放到平台上供学生学习使用,在学生使用一段时间后,总结其中出现的问题并进行修改与评价。

(二)《微微机机原原理理》微课资源开发

1. 进行需求分析

需求分析是所有阶段的前提,是软件生存周期中的关键一步,于是需求分析做得好坏直接影响到微课资源建设是否成功。在建设这门课的微课资源之前,就要对这门课的教学对象——陕西师范大学2013级创新班以及师范班的教育技术学,在校本科生用问卷调查的方式来得出他们最需要的拍成微课的知识点有哪些,然后结合该课程的重点难点,制定微课的大体框架,使其符合课程教学大纲。

2.进行微课设计

做好需求分析之后,根据得出的结果进行微课的设计。在进行设计时要注意以下几方面。第一,选取合适的教学内容,根据确定的知识点来选择合适的微课制作的方式,比如:介绍主板的知识点可以利用实拍式,硬盘分区可以利用录屏式。要根据不同的拍摄形式,编写符合该形式的脚本。第二,不仅要考虑单个知识点的逻辑关系,还要考虑知识点与知识点之间的链接关系,使教学内容更具有严谨性。除了知识点的关系之外,还要考虑到不同模块之间的关系,具体到每一个页面,每一个页面的元素,尽可能的考虑全面,设计得当,为后期的制作合成打好基础。

微课设计与传统教学设计的不同点就在于,微课涉及的是一个知识点而不是整节课的内容,整个微课视频只有5到10分钟,所以,要求微课的设计能够快速进入主题并且吸引学习者,而且可以在微课视频中,在一个知识点结束或是视频结束时设置一个有关知识点的问题,以帮助学习者巩固所学知识。

3.进行微课制作

微课制作这部分由三个环节组成。第一,准备相关微课的PPT或是电子讲稿。根据微课制作的形式确定做PPT还是讲稿,比如某个微课是用录屏式,只需制作相关讲稿即可;而有的微课是讲授式,则必须制作相关的PPT。第二,进行微课的拍摄。在这个环节需要注意根据已经确定的拍摄形式,准备好相关的拍摄器材,比如说:在课堂式实录中,只需摄像机即可,而在画中画式拍摄中,需要准备好带有画中画的软件的计算机,该计算机还要有良好的收音功能和摄像头。第三,后期剪辑。这一步很关键,关系到制作出来的微课的质量的好坏,要对微课的声音、视频画面都要仔细编辑,可利用到会声会影、AE、Premier等软件来进行剪辑。

4.进行测试

测试环节很关键,这是关系到微课资源质量的决定性环节。主要是测试以下几方面:测试微课内容是否有知识性错误,或是字幕是否正确,字幕与教师嘴型同步;测试微课中的音频是否能够流程播放,视频是否清新,颜色搭配是否突兀;测试微课是否与脚本内容统一,是否遗漏知识点,知识点前后联系是否符合逻辑性。

(三)《微机原理》运行与维护

《微机原理》这门课的微课视频全部制作好后,放在Blackboard平台上,供学生学习使用,要实时追踪学习者在Blackboard平台上的学习效果以及教师与学生的反馈。可以在此阶段再次进行问卷调查,进行后测,通过搜集学习者的相关意见再对微课资源进行完善。在此阶段,不仅要关注学习者的学习效果,还要关注之前的每一个阶段是否做好,所以,评价与维护阶段是针对微课资源建设全程来说的。只有这样反复评价、反复修改,才能提高微课资源的质量,达到最终的学习目标和学习效果。

六、总结

本文基于软件工程的思想和方法,从软件生命周期的角度构建出微课生命周期,以《微机原理》为例,用微课生命周期重新建设微课资源,对微课资源建设提供了一种新的方法,使微课资源建设有了系统的理论作指导,进而提高微课资源的质量以及推广。

参考文献

[1]李新林,陈晖.微课资源建设的比较研究及启示[J].中国教育信息化,2015,(06):53—56.

[2]桂耀荣.微课及微课的制作和意义[J].化学教与学,2013(05):41-42.

[3]胡铁生.“微课”:区域教育信息资源发展新趋势[J].电化教育研究,2011,(10):61-65.

[4]张海藩.软件工程导论[M].北京:清华大学出版社,1998.