为什么要去医院呢？
为什么不呢 这是一个很好的例子。 该项目无处不在一个项目：加或减相同的阶段，相同的管理方案，文档管理，风险管理，质量控制等。 到处都有对设备，房屋和软件的需求。 您问，信息系统对房地的要求是什么？ 非常简单：操作员的工作站，服务器的位置-都需要空调。 这是该场所的要求。 现在几乎没有人怀疑医院是否需要软件。 如果要保持最新状态，您将面临创建具有电子病历的自动化医疗机构的任务，在该机构中，医生用平板电脑进行检查，例如，护士在洗手间上标记的不是洗手间，而是在电话上。 在这种情况下，将会有大量的软件需求。 一旦需要软件，就需要安装服务器，将管理员和操作员放在某个地方。 一切都是相互联系的。
我们选择一个建设项目是因为它最容易演示如何设计IP。 信息系统隐藏在内部某个地方，我们看不到它，而墙壁在我们眼前：弯曲和倾斜，有死胡同的走廊，因为该项目是在膝盖上完成的，甚至客户在游戏过程中都改变了一百次要求。
内部的程序代码（但没人能看到）如果我们开发软件，医院与它有什么关系？
亲爱的开发人员，执行人员，分析师，测试人员就在这里。
不是您正在开发的软件...以Android为例，这是软件。 例如，如果您有一个会计系统，那么您已经不仅在处理软件，还在处理信息系统。
区别是显而易见的。 如果您购买了电话，那么一切都很简单：将其打开，一个绿色的人（Android）启动，然后使用它。 而且，如果您购买的是装有会计软件的包装盒，那么很明显，现在需要服务器，需要配置网络，配置工作站，培训员工，将系统与其他企业IP集成并以测试模式运行系统。 是的，需要说服会计师改用新软件，但并不是所有人都准备好进行创新。 通常，在任何IT项目中，有10％到20％是IT，其他所有东西都是组织和管理措施，而且非常密集，需要与员工一起工作。
信息系统（仅仅是软件？）最后，我们回想起遥远的90年代对系统的定义，没有人取消过：
自动化系统：由人员和一套用于其活动的自动化工具组成的系统，该工具实施信息技术以执行已建立的功能。
GOST 34.003-90。 信息技术。 一套自动化系统的标准。 自动化系统。 术语和定义。
也就是说，知识产权首先是人，再加上有助于自动化其活动的技术，反之亦然。
如何设计医院
想象您是一个建筑组织，有客户来找您，并要求在这样的地方建医院。 您立即跑来打砖还是...？ 如果您查看信息系统的创建频率，那就是：表演者立即开始“干涉混凝土并购买玻璃包装”。 就像那样，它无法解决问题-我们将重建！ 我们将重建直到达到期望的结果。
但是，如果您是一个认真的组织，请首先为客户提供施工设计。 你同意吗 信息系统为什么错了？ 也许建设与软件开发之间没有区别，但是在同一家医院中，他们会先想一想，先计划然后再建设，然后先开发然后再考虑软件？ 这不是为什么您会听到很多关于krivoruky程序员的信息，却听不到关于建筑工地的同一个移民工人的信息吗？ 与开发人员不同，建设者在项目上工作。
即使没有可见项目也总是这样现在，我们将更详细地考虑设计过程。 它分为几个阶段。 为什么我们需要经历几个阶段，为什么不一次执行呢？ 为了清楚起见，我将举一个学校的例子...在学校里研究乘法的运算已有多少年了？ 您说一两个月，从根本上说是错误的。 是的，如何将5乘以6，需要一周时间。 在一定的时间教授乘法表。 分数，带阶数的数字，对数，方括号中的表达式，复数的乘法运算，在一定程度上提高了学习人数？ 几乎所有学年！ 事实证明，我们每年从不同的角度研究相同的乘法。
为何不对此进行一年级学习？因此，学习和设计的任何过程都是周期性的。 首先，我们获得了有关数字的一般概念，然后学习了如何对它们执行简单的操作，然后了解了分数并学习了如何使用它们，依此类推。
首先，我们意识到应该借助信息系统解决什么问题。 然后，我们确定了要解决的任务范围，了解了系统应执行的操作，人员应执行的操作。 然后，他们考虑了系统应如何完成之前定义的任务。 您可以跳过这些步骤，仅需返回并重做所有操作：测量七次，并且一次剪切的速度比反之快得多，并且将剩下的材料更少。
我们再举一个例子。 您在山顶上，用强壮的双筒望远镜向下看，试图做出详细的下降路线。 在目镜中，您可以看到路径上的每个卵石，每个水坑。 但是，这是一条道路，是否能用双筒望远镜直通顶端尚无形：没有总体规划。 合理的登山者将首先用肉眼勾勒出下降路径，然后在放大倍数下对其进行检查。 深入细节后，您将失去对项目的总体了解。 立即拿起望远镜，理想情况下，您需要描述10个功能，而忽略其他40个功能，并且通常不要提及它们。
可以很好地看到，但只有一小部分分阶段设计的复杂性在于，在流程开始时，您必须使用抽象概念进行操作。 所以我想“感觉”准备就绪，而不是谈论某些需求，功能，任务，过程。 立即绘制用户界面较为简单，但至少会错过一半的要求也更容易。 如果首先我们列出了用户在使用一个或另一个屏幕窗体时必须执行的详细操作列表，那么设计人员将只需要绘图即可，而不必幻想大小。
现在终于进入设计阶段。
1.拟定一般要求
因此，假设您是一名设计师。 一位负责任的建筑商“送出”一个客户来找您。 客户自然会要求您开发医院项目。 您跑到Kuhlmann，然后……好吧，这是上古-启动ArchiCAD并绘制。
但是，当然，这与您无关。 您是专业人士，开始询问一堆“愚蠢”的问题。 其中最重要的-您为什么需要建医院？ 建设的目的是什么？ 如果目标不明确，那么无论是大型医院还是小型医院，您都无法回答这个问题。 不幸的是，客户经常说很多有趣的事情，除了主要的事情-他们的目的是什么。 在这里，有必要首先将它们“拉出”。 你应该问一个问题。 客户本人不是专家，他有一个主意，在此基础上，他看到了自己的角色。 他不了解实现他的想法需要走什么路。 通常，客户希望有一个很好的旧奇迹-来到海边，扔网（付钱），钓一条鱼，她就会实现自己的愿望。但这就像一个有钱人在开玩笑说的那样，他抓了一条金鱼，要求实现一个愿望：我希望一切都与我同在！” 鱼回答：“没问题，你拥有了一切……”
要了解项目的目标，仅用一组标准的短语组成几个句子是不够的。 一个项目的目标通常是在反对的基础上确定的：他们描述了现有的信息模型（例如，人们坐在档案中并通过文件进行排序），然后是它的缺点（由于缺乏自动化，有10人参与了档案，这显然是多余的，其他部门数周无法收到从档案中获取他们需要的信息等），并提供解决方案（要引入允许以自动化模式执行许多操作的软件，必须列出这些操作）。 如果将一种全新的服务引入市场，则有必要研究现有市场并“批判”那里的可用工具，然后提出解决方案。
此外，在此阶段必须确定必须考虑哪些法律要求，如何合法执行某些操作，如何通过新服务获利，如何计划进入市场，如何使新系统的外部参与者感兴趣。
换句话说，应该制定业务模型。 一方面，这不是开发人员的任务，但另一方面，如果没有明确定义目标以及如何实现目标，则不清楚系统应该解决什么任务。 而且，如果客户本人尚未明确提出自己的需求，那么他至少不会对某些结果感到满意。
2.选择系统概念
在此阶段，必须选择可以满足前一阶段要求的通用技术解决方案。 无论是Web应用程序，还是本机胖客户端，还是瘦集中式数据库，还是分布式，关系型DBMS或noSQL，整体或微服务，Java或Python。 通常忘记及时讨论这些问题，然后事实证明，其中一名程序员独立选择了某个工具，最终，该解决方案无法实现目标。
3.制定职权范围
为医院提出了一般要求，选择了概念。 客户会说：“好吧，现在一切都清楚了，您可以进行绘制了。” 有可能吗 要求是一般性的，需要详细说明。 例如，在第一步中，您确定应该有一个血液测试实验室。 但是会有什么样的设备，它会消耗多少电能，压缩空气（如果是的话）？是否需要石英灯进行消毒，实验室工作台和通风？ 没有这个，将很难设计。 这是第一。 其次，有必要制定建造医院，准备和投入运营的计划。
对于信息系统，TOR（职责范围）的开发是该项目的核心部分。
职权范围描述：
- 系统应该做什么。
- 系统的整体结构应该是什么。
- 如何创建系统。
也就是说，TOR包含功能性和非功能性需求，以及对开发阶段，交付，验收和文档的需求。 此外，在ToR中还应简要描述我们实际自动化的过程。
在描述系统功能时（这是TOR的核心部分），应该理解-我们给出了系统应该做什么而不是如何做的要求。 对您来说，覆盖范围应比深度更重要。 例如，在第一阶段（准备一般要求），我们确定了对用户登录阻止功能的需求。 工作说明表明，如果该帐户已使用90天或6次未成功登录，则该帐户将被阻止，管理员可以在一段时间内限制访问，在尝试输入被阻止的用户时，必须显示一条消息，等等。 在技术项目中（让我们超越自己），我们将绘制一个带有锁定标志和解锁日期的用户卡样机，编写一个用于登录检查了锁定的系统的脚本，在设定的时间段后自动解锁，并在登录尝试失败时锁定； 让我们确定在客户端完成什么，在服务器端完成什么。
我想揭穿与
技术规范制定有关的几个神话。
误解一：传统知识只包含承包商的要求。不，传统知识是创建系统的方式，在职权范围中有几节可以描述责任的分配。
误区二：在职权范围中通常有很多“水”。确实，TK通常包含有关系统的一般信息，但是它们是必需的。 例如，我们讨论并讨论了对系统的要求，结果，一个团队意识到有必要为Windows开发一个应用程序，而另一个为浏览器开发应用程序。 一个以为系统被称为那，另一个以不同的名字命名。 这似乎是显而易见的事情，但所有团队成员和所有相关专家都应平等地理解它们。
误区三：对员工，服务器，通信渠道，管理员的操作模式的要求是多余的，因为它们属于客户责任范围。首先，正如我们已经考虑的那样，TK是一次为每个人编写的，其次，TK描述了如何使系统正常工作，而不仅仅是编写了软件。 否则，将有另一个盒子放在架子上，上面有磁盘和厚厚的说明书。 因此，传统知识的组织部分，即非功能性需求，与功能性需求同样重要。
我们在另一篇文章中更详细地考虑了传统知识的准备，
按照GOST 34制定职责范围很容易 。
4.开发技术项目
所以，继续前进。 这里就在您面前（我们承认您是设计师）构建具有大量要求的医院的职权范围。 您坐下，可悲地看着100页的TK，而且不知道从哪里开始。 然后图像逐渐开始清晰。 您认为：是的，我们在病房下需要这么多米，在厨房下需要那么多米，在休息区，实验室，护理室等等上等等。 然后诞生了许多草图，草图，选项，您重新制作，交换房间，总之，寻找最佳比例。 然后转到详细信息-图纸，图纸，蓝图：墙壁，门，窗户，电缆通道，电线，管道，通风设备，地板，墙壁材料，饰面……等等等等。 通常，尽可能详细地概述完工后医院的外观和功能。
在开发信息系统的技术项目时，需要包含以下内容的文件：描述已开发系统，用户和相关系统的操作和交互的详细方案； 用户界面的详细布局，其中包含每个接口元素的数据类型和行为的描述（默认值，可以更改字段值的条件，可见性，元素更改时系统执行的操作等）； 与相关系统和设备集成的协议的描述，报告表以及其形成算法的描述，服务器和数据库的结构（如果有）。
通常，这足以将文档提供给开发人员并获得理智的结果。 详细的模型和脚本提供了有关系统和接口的行为以及数据结构的足够信息。 开发人员将被置于一个紧凑的框架中，您可以在其中幻想，但是却步步为营。
我希望在以下文章中，我们将更详细地研究如何以高质量的方式执行技术设计，如何开发模型，方案以及需要编写哪些文档。
5.编制工作文件
逻辑上的问题是医院的工作文件是什么？ 真的是清洁走廊的指示吗？ 开个玩笑，您需要维持消防系统吗？ 这是必要的。 还有电梯？ 那计算机网络呢？ 和水供应？ “嗯，这不适用于医院项目！” -你说。 是的，这部分是正确的。 但是，医院是整体交付给客户的，所有系统都必须具有适当的操作文档。 为了快速，成功地进行更改，您将草拟一份要求清单，在清单的对面可以检查是否一切井井有条。
IP的用户和管理员指南的存在是一个标准，所有这些都一目了然。 但是客户经常在最后时刻考虑系统的接受过程。 并且徒劳。 为此，有一个出色的文档“程序和测试方法”，通常也与工作文档相关。 这是一种清单，其中包含验证程序的描述。 如果该文档是事先准备好的（并且脚本可以作为基础，可以从技术项目中借用），那么开发人员将有一个明确的标准来接受他们的工作。 您不需要自己的或外包的程序员来证明自己的情况-在某种情况下，必须加以解决。 客户不会有任何问题-幻想已经受到文档的限制。
敏捷的地方在哪里？
有些人双手捧着敏捷（或其他“灵活”的开发方法），另一些人则强烈反对。 本文的作者有自己的见解：敏捷非常好，但是要点。 他们通常将其用于其他目的。
敏捷爱好者，请告诉我，是否有可能使用这项技术来确定在开发，成本和条款结束时获得的结果？ 不行吗
那么，您会发现多少傻瓜客户参与了这项工作，但结果，预算和持续时间不清楚？您会使用敏捷命令公寓维修团队吗？因此，除了内部项目之外，敏捷还有一个地方。您可以根据自己的意愿进行维修，并复查几次。对于外部客户而言，这是一个巧妙的称呼骗局（您当然不会同意这种表述，但要说服客户也是如此）。客户认为：他们还会带我多少鼻子？其次，敏捷擅长创新，尚不清楚要获得什么样的结果，或者实现方式尚不清楚。这称为OCD，实验开发。甚至研发-研究与开发。在任何工厂，都有一个实验车间，通过文件获取原型，并进行多次重塑。想象一下，您需要重新开发触摸屏，所有手势和行为。在这里，您确实应该尝试一下，您无法提前描述其行为。但是，您经常面临此类任务吗？工程和研究之间应加以区分。基本上，我们是信息系统设计工程师。第三，在一个大型项目中，可能存在需要OCD的阶段，然后需要敏捷来提供帮助。没有人会在运营计划级别上使用冲刺。相反，这是一种非常方便的技术：计划一两个星期并不断监控结果。在策略级别，级联计划在战术级别上是迭代的。并没有矛盾！不幸的是，很多时候，开发人员在“涉足”敏捷时，试图掩盖他们无法开发系统项目的能力（或者甚至不知道这是可能的）。他们以最方便的方式行事：我们将以客户的钱来完成交易。尽管没有人控制成本，但这是完全可以避免的。但是，随后，外部观察者（老板）可能会觉得该过程已经存在，但是没有终点和边缘，并且看不到任何结果。尝试不仅从钟楼看。在哪里可以找到有关信息系统设计的更多信息？
关于这个主题有很多书。厚而不是。但是，一本书始终是外星人的经历。您将拥有不同的性格，良好的处境和项目。有这样的TRIZ系统-解决发明问题的理论。它的作者Altshuller试图解释发明某些东西所需采取的步骤。原来呢？通常不会。所述原理被认为是有趣的，有用的，但是没有出现根据本发明的单个模板。每个人都以自己的方式思考和创造，这是不可能的，您只能学习。有必要使用别人的经验，不要使用它是愚蠢的，但是您必须经历（处理）经验，然后转变为自己的想法。复制奇迹不会成功。如果您想学习设计，我建议以第34系列的国家标准规格为基础。这是真正的杰作，是整个研究机构工作的结果。在这些标准的开发过程中，研究了数十个（如果不是数百个）最复杂的项目，这些项目用于各种系统的自动化。巨大的经验正在积累。这些标准很难掌握，您也不会马上学会如何使用它们。因此，我们将在后续文章中尝试揭示它们的本质。阅读续篇：有关信息系统设计的一些说明。阅读作者的其他文章：