离开blog的岁月已久，其间经历了喜事多多，晒出来众人分享，也帮我脱掉虎头蛇尾的blog高帽。

 

离开2年，所得有三：

 

一者公司抬头，不必多讲，路漫漫其修远，干到老，才能活到老！

二者收藏了不少好东西，梧州的老茶、巴西的水晶、砗磲的大珠子、良渚的玉器，人生在世几十年，能尽享如此繁华却也该知足了。

三者家里又添新丁，虽然还在老婆的肚子里，但也指日可待了不是？我打算给两个孩子起一样的名字，将来小的学习不好大的可以替她去考试，哈哈，天下难得这样的父母心吧。

 

 

这一年没写过什么东西，但的确经历了一些东西，看了些人的颠倒，看了些事的万变，在这碌碌的一年最后一天，总应该留下点回忆，以念我的曾经。

时下，我过着看起来逍遥的日子，也颠覆着自己曾经的梦想，伴着冷，伴着醉，有怨无悔……

又是爆竹声啪啪作响，又是人面桃花相映红时，故友今非，难忘往日。

 

带着无比乱而无比顺的思绪，把自己拉向新的清晨，但身首异处，总有没舔干净的要去收拾。血也罢、泪也罢，已化作尘。

 

暖茶一盅，浮尘一味，万事乌有，无欲无求；心将无界，志在八方，不识得失，方见真知；

人无善恶，事无良莠，败于执着，失于求索；事行术道，理在四空，人生真意，永无终期。

 

纵使在这一年的最后我失去了所有，但曾经又有过什么？

新的一年即便要面对所有的开始，但我又曾经有何完结？

没有出生的鸡蛋或许不被当个生命，即便他们要结束了它，也不必执着，即便有一天大家叹息它或许是只多么美丽的鸡。所谓路遥知马力，日久见人心，朗朗之词谁人不晓，能言善辩未必稀少，言语之力汝辈尚用，况我乎！但见人心不如昨日残月，况求十五之圆。

 

解脱之人本没必要罗嗦，但毕竟芸芸众生又有几人放下，纵使兄弟姐妹们有些许怨，报些许恨，望能早日得其道，识其术，不必执着，天日自现。造化轮回，不知又见他方，又在何时。

 

 

现在人们越来越认识到软件工程在软件开发中的重要作用。目前国内软件在开发中还没有对软件开发的过程进行明确规定，文档不完整，也不规范，软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础，只有通过建立全过程的改善，采用严格的软件工程方法和管理，并且坚持不懈地付诸实践，才能取得全组织的软件过程能力的不断提高，使软件开发更规范合理。

　　我们马上就要进入WTO，因此软件开发也要与国际接轨，只有这样才能提高我们在项目管理水平，最终开发出高质量的软件。

　综述
　
　　软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，本文以医院管理系统为例详细介绍了需求工程的构成和进行方法。

　一、需求开发

　需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤

　1． 需求获取

　确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。

　2． 需求分析

　绘制关联图、创建开发原型、分析可行性、确定需求优先级、为需求建立模型、编写数据字典、应用质量功能调配。

　3． 编写规格说明书

　项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求

　4． 需求验证

　审查需求文档、依据需求编写测试用例、编写用户手册、确定合格的标准

　二、需求管理

　需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。

　一、综述

　软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，本文以医院管理系统为例详细介绍了需求工程的构成和进行方法。

　首先我们必须了解需求工程和其他项目过程的关系：

软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

图2 软件需求各组成部分关系

　需求工程分为了需求开发和需求管理两个阶段:下面就以这两个阶段说明:

　一,需求开发

　需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。

　1． 需求获取：

　 1）确定需求开发过程：确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。

　 2）编写项目视图和范围文档：项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。

　　

　　a.1 背景 在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。

　a.2 业务机遇 描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。

　a.3 业务目标 用一个定量和可测量的合理方法总结产品所带来的重要商业利润,把重点放在给业务的价值上。

　a.4 客户或市场需求 描述一些典型客户的需求，包括不满足现有市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。

　a.5 提供给客户的价值 确定产品给客户带来的价值，并指明产品怎样满足客户的需要。

　a.6 业务风险 总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。

　b.1 项目视图陈述 编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。

　b.2 主要特性 包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。

　b.3 假设和依赖环境 在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。通常一方所持的假设应与另一方不同。

　c.1 首次发行的范围 总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。

　c.2 随后发行的范围 如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。

　c.3 局限性和专用性 明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。

　d.1 客户概貌 客户概述明确了这一产品的不同类型客户的一些本质的特点，以及目标市场部门和在这些部门中的不同客户的特征。

　d.2 项目的优先级 一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员。

　e. 产品成功的因素 明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括外部因素。如果可能，可建立测量的标准用于评价是否达到业务目标.

　3）用户群分类：产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异，你可以把这些不同的用户分成小组。用户类不一定都指人，你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口，可以帮助你确定产品中那些与外部应用程序或组件有关的需求。将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况，要将可能使都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。

　4）选择产品代表：择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的，因为此时，用户就是身边的职员。而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。每一个产品代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口。

　5）建立核心队伍：建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于，核心队伍成员通常没有决定权。

　6）确定使用实例：让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述-使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。

　一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个使用实例是相关的用法说明的集合，并且一个说明是使用实例的例子。在描述时列出执行者和系统之间相互交互或对话的顺序。当这种对话结束时，执行者也达到了预期的目的。

　对于一些复杂的使用实例，画出图形分析模型是有益的，这些模型包括数据流程图、实体关系图、状态转化图、对象类和联系图。

　使用实例的描述并不向开发者提供他们所要开发的功能的细节。为了减少这种不确定性，你需要把每一个使用实例叙述成详细的功能需求。每一个使用实例可引伸出多个功能需求，这将使执行者可以执行相关的任务；并且多个使用实例可能需要相同的功能需求。使用实例方法给需求获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。比起使用以功能为中心的方法，使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。

　每一个使用实例都描述了一个方法，用户可以利用这个方法与系统进行交互，从而达到特定的目标。使用实例可有效地捕捉大多数所期望的系统行为，但是你可能有一些需求，这些需求与用户任务或其他执行者之间的交互没有特定的关系。这时你就需要一个独立的需求规格说明。

　7）召开应用程序开发联系会议：召开应用程序开发联系会议应用程序开发联系会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。

　8）分析用户工作流程：分析用户工作流程观察用户执行业务任务的过程。画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过程流程文档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标。

　9）确定质量属性：确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性，这是一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义。

　10）检查问题报告：通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。

　11）需求重用：跨项目重用需求如果客户要求的功能与已有的产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。

 

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 8.1

mQGiBENz+WARBADMsAm7MycamL4G1lj9YTmKhv3DJErmsp2Ke6JtBQQp2bgKT7Ab
gq4r591wVsP8+4OI5SKtuR3BGgLNoIIf8kSFUAAqN/xRfY9aG8vbwcDFzm7mrwGr
W1WR1O2pZ8VCCpF2X8SWtsWYU7A2jxt/geSpSShCGhb4/wT+051rdu5tiwCg/1Te
TIC5m2jn35+/rnpAE3uu4CMD/1ZJ61qcsovXNTlbclEjWP5MsFzsjsmXh1txCQjJ
f4H1WRHAXC8pyQYbZiPvMCm6+agaqM+fcs0HcCtJpT7CMWZVvkk8q0Ms17dSrQO7
JKFHWD27AQ+8RCUAnn6vgRFdi76qLFTH3b/PhScyd7TS8tWrPnT7kPrgOvhsvb3O
T9wpA/9h6D+rNYkB6bXe2QGOFsODoujqv1peuETutnksU+BUFVSWfpN6XcjYdiZQ
CdP3kFRsTKT9Iwc1kCNb+V2LU2uQMPvNgFaP4AUofjK1DSSiDaxCB1FVinvQqxrB
76dEYmZCLSknuMoPbs9Gw0k8ody/YjUXEZbCbS5DX8RMAbAXLrQYa2FrYXJ1IDxr
YWthcnVAbmV3eC5vcmc+iQBdBBARAgAdBQJDc/lgBwsJCAcDAgoCGQEFGwMAAAAF
HgEAAAAACgkQ+X75BI2N2sNXHgCgrLsf5XMAl0aqC6m7+eVdknYmqk0An1mYinXS
SdMJUba5qwgT6M8Jqv8MuQINBENz+WAQCAD2Qle3CH8IF3KiutapQvMF6PlTETlP
tvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ+PVZX9x2
Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56NoKVy
OtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPw
pVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnI
Byl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7AAICB/4o
GbG6LzazD4FrMKyOvyhQ2+rGgjefW1+nZR2bGDl5J8DHnHw98ugwQ/xe6GncsvDs
kCy8AyB6ApVQsZAI181m/Fv8FeezXR7RzwsRX9lHWETmIaUxG+3vWWYTuqV6SyVv
ru2ZljltyLRvuj/FuavW9Qb4lqo9Gt/kpHGZgPKh/yWoxDuswA0HBMGsHQf+u14M
DmUq5ulLrmA5u/K2G/0TvRHK/gyE/fHgrwwn7M4DFZy65QAB+3HmwPDOX9ap8ji2
Op43iZNPhFDgbRrUiDiqSx06IHOmkvAVMzHJhRXECyKb+xTAhD5FWKfwY7Pu0mlf
7zYnUYXTqrKcOADBkpQkiQBMBBgRAgAMBQJDc/lgBRsMAAAAAAoJEPl++QSNjdrD
3t4AoOSx4KH5l63WZPYYwaUQAU4iZp+mAKCaUYcM5OOMMtgMeYcnzcl+Tt9WDQ==
=JRxT
-----END PGP PUBLIC KEY BLOCK-----

太多的人做了类似的东西——防火墙，到底有多少用处？

太多的人以为它无所不能——防黑客，买了拐还得意呢！

太多的人赞美它如此强大——能赚钱，蒙一个是一个阿。

太多的人正对它憧憬无限——有市场，丧失道德的商家！

太多的人认为它饱含科技——安全嘛，又一个没有脑的！

太多的人深知它狗屁不是——开源嘛，我抄一个不行啊。

太多的人抛弃它另立山头——没前途，总要找条生路吧？

太多的人撞了南墙也要做——不死心，不蒙出钱来难受。

 

有些人不承认防火墙没用——有人买啊，那都他妈的被商家忽悠的！

有些人不承认防火墙没用——很多人在做啊，那你看被黑了的哪家没装防火墙！

有些人认死了防火墙能赚钱——每年市场占有率如何如何，臭鱼烂虾一年卖的也不比防火墙少，你咋不去卖？

有些人坚信防火墙是无可替代的——的确，很难再找这么糟糕的一个东西出来了。

 

商场里的人做垃圾产品作出了感觉；

死也不会明白除了蒙人还有什么能干的；

骗钱骗顺了手再也无心经营正道；

总想投机骗客户心理才觉得爽；

 

不用讨论任何技术，随便一个用过Linux的人都会很容易的明白什么是防火墙，

防火墙的确不会瞬间从市场消失，那是因为无数靠它骗钱吃饭的商家必须想方设法保住自己的饭碗，

能做的当然不是改善自己的产品，先要“教育”民众，相信防火墙仍旧是最先进的安全防护手段！

我日他奶奶的，不多挨几次黑那些可怜的民众永远也不会明白这个骗局；

可是哪有那么多好心人去一个个的告诉民众那是个谎言？

试问MS不出一个安全补丁，你防火墙又奈我何？从他妈的ida,idq, .printer,到sql injection, arp spoof,你能搞定哪一个？肯定有无耻的厂家号称自己什么都能防，如果是市场人员可以理解，如果是研发人员简直是败类！

 

在民众用得最多的计算机中，如果没有MS的安全工作，至今仍旧会是一片狼藉；

没有人感谢MS，她挨得骂最多，但是她没有计较过，甚至不计较那些拿着盗版骂她的人的无耻；

回想，干得最多的人被骂得也最多，为安全作出最大贡献的人也被骂得最多。

 

真正的安全如果不从OS做起，永远是南辕北辙的徒劳。

愿意听信防火墙厂家忽悠的人，请多看几遍赵本山的《卖拐》！谢谢！