niblog重新开张

拿windows server03架的服务器,自从开机那一天起,就不停的遇到各种攻击,虽说在攻击的过程中,我学会了几招并且成功运用于攻击另一台烂透了的windows server 03,但时间长了还是受不了换了个Linux。折腾了若干天之后,才又把这个没人访问的wordpress架了起来。

其实折腾了这么长时间,倒是也想明白了,菜鸟管理Linux,并不能提高安全性,唯一的好处就是,不知道怎么看日志的情况下,有了攻击我也不知道……

 

工作流程描述方法

有人说过,软件工程领域,不严格的说,需求调研过程还不属于“工程”而属于“艺术”,即没有工程化的手段和方法完成此项工作,需要工作人员的创造力,概率性的进行此项工作。本文的目的在于,总结需求向设计转化的思路和方法,力求为将此过程达到标准化提供帮助。

需求调研的直接结果,一般为当场的会议记录,收集到的资料、报表等。对于这些调研成果,归纳的第一步应为整理备忘录,基本要求为涵盖所有细节。而备忘录书写完成后,就要据此进行系统性的整理,将条目分类整合,剔除不必要的细节,对工作进行建模,为后续的设计提供帮助。

报表类的工作,本身的重点在于报表数据的逻辑,归根结底是数学问题,容易处理。而由报表引申出其他工作的方法,可以参考这篇的描述。

流程性的工作掺杂的实际因素较多,不能像报表逻辑能直接转化为数学公式,因此需要一定的建模方法对其进行描述。以下,是实践中对一项工作过程建模的讨论过程。

原始工作描述

考虑如下的工作流程(只考虑正常流程),群众甲办理某证件。经过调研,需求提供放的工作手册一般都为如下的形式:

  1. 群众甲携带相关材料,到某部门作办理某证明1
  2. 工作人员A审核相关材料通过
  3. 工作人员B审核相关材料通过
  4. A开具某证明1
  5. B开具某证明2
  6. 甲携带证明1、证明2,到另一部门办理证件
  7. 工作人员C审核证明1、证明2通过
  8. 工作人员C办理证件
  9. 甲签名
  10. 甲携带证件离开,办理过程结束

这种形式是在工作角度进行描述,同时具有群众办事指南和工作人员办事指南的性质,并且面相的工作人员也是不同部门的人员。因此,这种描述并不能直接反应为功能模块的设计。

划清系统边界,从工作人员或称工作系统的角度描述

为了便于区分,先增加两个假设条件:

本系统为内部办公系统,不提供办事群众直接使用的功能。

该项工作,工作人员A、B所在部门并不属于此次开发最终成品系统的用户。

则系统的唯一用户为C。

从C的角度描述该工作,则1~5步与C并无关系。工作流程变为:

  1. C处于等待状态中
  2. 甲到该部门,办理证件
  3. C查验甲是否携带了真实有效的证明1、证明2
  4. C为甲办理证件
  5. 甲签字
  6. 甲携带证件离开,办理过程结束

这样的描述,可以直接对应设计过程中,系统的一个功能点。涉及到C的每一步,都可以视作系统中的一个表单,通过点击“下一步”按钮,达到下一步骤。

发现问题:遗漏信息

由于当前项目的开发目标除覆盖工作外,还包括力求创新,因此需求调研人员指出,按照以上方法总结的文档,丢掉了步骤1~5,如果以后需要对业务流程进行再造,或扩大系统用户范围,则这种方法则会损失有效信息。

经讨论,对该问题的暂时解决方案确定为:

同时以工作的角度和工作角色的角度总结两份工作流程说明文档。

发现问题:挂起恢复和过于琐碎

去掉以下假设:

该项工作,工作人员A、B所在部门并不属于此次开发最终成品系统的用户。

则系统需要整理A、B、C三个人的工作流程。C见上文描述。A、B二人的工作为穿插进行,有两种整理思路:

  1. 涉及到A、B二人审核材料、开具证明的4个步骤总结为一项工作的4步流程
  2. 4步流程总结为4项工作流程,每项工作流程都类似于:等待;A/B通知B/A作审核/开具证明工作

采用思路1较为简单。但在实际中,A、B二人的工作并不总是单线程的,在A等待B的过程中,可能会去做其他工作。所以据此设计的功能模块中,就无法体现将前一个流程挂起,进入新的工作的思维,会造成在实际中无法使用。

采用思路2,与实际接近,但划分过于琐碎,缺乏概念的完整性。并且,对应的设计方案也会导致功能点膨胀,系统复杂的情况出现。

解决方案:回到多角色描述,增加每个角色的状态描述

参考操作系统中的进程状态模型,将每个参与工作的角色的状态定义如下:

image

此时,工作描述变为:

序号 工作描述 A B C
1 群众甲携带相关材料,到某部门作办理某证明1 进行 未开始 未开始 未开始
2 工作人员A审核相关材料通过 挂起 进行 未开始 未开始
3 工作人员B审核相关材料通过 挂起 挂起 进行 未开始
4 A开具某证明1 挂起 进行 挂起 未开始
5 B开具某证明2 挂起 结束 进行 未开始
6 甲携带证明1、证明2,到另一部门办理证件 进行 结束 结束 未开始
7 工作人员C审核证明1、证明2通过 挂起 结束 结束 进行
8 工作人员C办理证件 挂起 结束 结束 进行
9 甲签名,C审核签名 进行 结束 结束 进行
10 甲携带证件离开,办理过程结束 结束 结束 结束 结束

按照这种方法总结,针对每个角色的一列,都可以设计关于此角色的功能模块,并做到直接对应。

另:这10步工作流程应予细化,一般情况下,每行应只有一个“进行”。如果出现了多个“进行”,则表明出现了并行处理的情况,应与实际工作对应,是否有明确的并行概念和并行关系。如果没有,则尽量简化为单线程工作。

报表调研要点

在需求调研过程中,由于被调研对象一般来说并不具备信息系统实施经验和程序设计基础知识,并不能提供完全符合开发逻辑的工作描述。一个较为常见的情形就是,某工作人员拿出成堆的报表,表示这就是我的日常全部工作。因此,从报表入手进行需求调研,是实际工作中的一个较为无奈的选择。

从另一个角度讲,在需求调研人员的个人能力和场面控制能力没有远高于被调研对象的情况下,很容易在天南海北的聊天中被带离既定的思路。如果能先得到相关报表,再从报表出发逐项进行调研,也不失为一个效果良好的调研工作方式。

就经验来看,报表是衡量工作成效的重要指标。由于政府部门的特点,很难做到岗位职责分明,也很少见有正规有效的工作日志制度,因此对日常工作没有很好的记录,也很难再现。在这种情况下,报表几乎成为了考察工作是否完成、完成得怎么样的唯一指标。更进一步,工作完成情况的体现形式也大多为报表。所以对于报表的调研,应作为需求调研工作的难点和重点看待。

由于当前对一般工作制度的了解还不够深入,不能完全概括报表在工作中的作用。应在需求调研工作中逐步加深对报表的理解。

对于报表的调研,不能只局限于报表数据本身,否则据此设计的系统将会沦为“数据库系统”。应当在调研中获取足够的关于报表所体现的业务流程的信息。在针对报表的提问模板中,为了达到提供足够信息的目的,将要点初步归纳如下:

  • 报表名称
  • 填写人(或填写人所属岗位)
  • 上报去向
  • 原始数据来源
  • 报表数据从原始数据的计算方法
  • 填写频率
  • 触发条件(每n个月填写一次,有xxxx情况发生时填写一次等)
  • 表内、表间逻辑关系
  • 最终存放地点
  • 被引用情况
  • 政策依据

对于以上要点的调研结束后,每张报表都可以归纳出相应的工作流程,大部分情况应为多个流程,如填报工作、上报工作、计算审核工作等。对于每项工作流程,都可以按照工作流程相关的模板进行整理。

采用这种调研方法后,既有了调研起点,又能充分的了解工作,最终有利于信息化方案的提出。

niblogs.com

折腾了好几天,终于把服务器给搞定了,尽管还经常出现各种各样的诡异问题,比方说偶尔跳转到某业务系统中,但总归是圆了自己多年来的一个夙愿。

早年间曾经很想当个运维工程师,或者说叫System Administrator。后来事情一多,这个想法也就淡了。到今天,离着这个想法越来越远,技术也越来越差,陪个Apache都得让我着急上火好多回了,还真是逆水行舟不进则退。不过还好,趁着有点闲工夫,算是把自己的空间开通了,以后随时能自己折腾点什么东西。总要有个东西提醒自己,不要忘了年轻时的当个技术强人的梦。

申请域名的时候,一冲动就申了这个。后来想想,不大妥当。应该申个ni.name,用二级域名blogs.ni.name访问。这样后面就可以陆续开很多其他的东西。不过既然已经交钱了,就只好这样吧。有了blog,后面可以再玩点bbs.niblogs.com,ftp.niblogs.com,mail.niblogs.com之类的。

在没有打招呼的情况下,借用了某客户的服务器,严格来说是个不太地道的行为,在此表示深深的歉意和谢意。等我资金充足的时候,一定尽快搞台自己的服务器,这东西还是蛮好玩的。

Windows live套件中居然有支持Wordpress发布的工具,看来多年不上网,我真out了。直接粘图片的功能真是太犀利了,以后发个技术文章,截图神马的不在话下。

image