Требования ит проекта

Требования ит проекта

Наталья Чернявская, Юрий Чернявский, «Комиздат»

При всем том, что сами понятия общеизвестны, их набор далеко не полон, а предложенная схема далека от совершенства,— статья имеет в себе элемент теоретической разработки. Тем не менее, в «реальных полевых условиях» этот материал может оказаться весьма полезным.

Лирическое вступление

Управление требованиями начинается на самых ранних этапах работы над проектом и не заканчивается даже после его завершения (актом сдачи Заказчику), продолжаясь и далее — на этапе сопровождения.

Еще когда проект существует лишь в виде идеи «а хорошо было бы сделать Нечто», уже подразумевается, что сие Нечто должно удовлетворять целому набору специфических — далеко не очевидных, однако крайне ответственных и от этого не менее расплывчатых — требований.

Далее это зародившееся Нечто развивается, разукрашивается для Заказчика-Инвестора, обрастая все новыми и более четко очерченными (опять-таки) требованиями — и вырастает в Ого-го-что, пока не получит «путевку в жизнь» в виде финансирования и четко определенных сроков.

Но очень скоро наше Ого-го-что на своем тернистом пути сталкивается с суровой реальностью, приносящей все новые и новые открытия из области требований: некорректность формулировки, принципиальная невыполнимость, противоречивость, непредвиденные дополнительные ограничения и т.д., и т.п.

Выскочившее из передряг с требованиями, наше детище имеет вид «изрядно общипанного, но непобежденного» Чего-то — готового и даже работающего.

Теперь ему приходится отдуваться за все неосторожные посулы и обещания в бытность свою Ого-го-чем. И работать, работать, работать — прежде чем заслужить название Кое-что стоящее и действительно полезное, удовлетворяющее набору соответствующих требований (ставших — как-то незаметно — общепринятыми и очевидными).

…И так до тех пор, пока какое-нибудь новое требование своими убийственными ограничениями не превратит наше детище в Ничто.

Но это — лирика эволюции требований. Пора приступить к физике их структуры и свойств.

Относительно свободная форма изложения, принятая авторами, допускает введение новых терминов и соответствующих им понятий, так сказать, по ходу изложения материала, не обременяя читателя отдельно вынесенными определениями или описаниями. Но это только там, где авторы надеются на опыт и интуицию читателя. Например, с самого начала используется термин требования к проекту (или, коротко, требования), обозначающий «то, что под этим понимают компетентные люди».

Но есть термины, с которыми подобные вольности недопустимы. В статье вводится понятие область требований. В российских стандартах существует термин предметная область, а в украинских — предметна сфера, однако область требований обозначает нечто принципиально другое.

Почему именно «область», а не класс, к примеру, или группа? Тут две причины:

  • Часто необходимо учитывать не только актуально существующие требования, но и требования, которых сейчас нет, но которые потенциально могут возникнуть. Кроме того, иногда необходимо принимать во внимание именно факт отсутствия требований, обладающих определенными свойствами. В этих случаях термин пустая область воспринимается гораздо естественнее, чем, скажем, пустой класс или пустая группа.
  • Для визуализации предлагается авторский тип диаграмм, где каждой области требований соответствует графическая область на диаграмме.

Области требований могут частично перекрываться, равно как одна из них может полностью содержать другую, отражая тем самым какое-либо из свойств принадлежащих им требований. Области требований очень похожи на диаграммы Венна из теории множеств. И чем в большей степени каждое отдельное требование будет обладать свойствами атомарности и отличимости (обязательные свойства для элемента множества), тем больше математических результатов из теории множеств можно будет применить.

Предлагаемый метод построения диаграмм областей является инструментом аналитика для процедуры начальной классификации требований. В процессе выделения существенных в данном конкретном случае областей, определения их взаимосвязей относительно включения-пересечения и распределения имеющихся требований по соответствующим областям аналитик приходит ко все более точному и глубокому пониманию сути самих требований.

По ходу изложения материала диаграмма будет эволюционировать от вспомогательного и совсем не обязательного инструмента визуализации простых и очевидных понятий до самостоятельного, мощного механизма, несущего глубокую семантику и, при необходимости, являющегося прочной базой для дальнейшей формализации и применения математических методов.

Диаграмма областей требований

Простейший случай диаграмм

Итак, в простейшем случае на диаграмме имеем область всех мыслимых и «немыслимых» требований — наш аналог универсального множества в математике.

В рамках этого универсального множества всех требований выделяем две большие области: область компетенции и состоятельности Заказчика и область компетенции и состоятельности Разработчика.


Рис. 1. Простейший случай диаграммы (вертикальное измерение — уровень компетенции)

Таким образом, есть Заказчик и Разработчик, у каждого из них — своя область компетенции и состоятельности. Чем дальше в сторону информационных технологий смещаемся, тем шире область компетенции и состоятельности Разработчика. Соответственно, чем дальше в противоположную сторону (сторону технологий из предметной области) — тем меньше специалисты разработчика показывают сообразительности и готовых наработок.

С другой стороны, чем более мощные информационные технологии предлагаются Заказчику, тем меньше у него находится соответствующих задач и тем меньше сотрудников, способных разобраться как в самих задачах, так и в предлагаемых методах автоматизации их решения.

Диалог между представителями Заказчика и Разработчика становится конструктивным только тогда, когда области их компетентности и состоятельности начинают пересекаться.


Рис. 2. Возможность конструктивного диалога

Другими словами, информационное образование экспертов Заказчика должно позволять им формулировать свои требования пусть на ломаном, но все-таки «человеческом» языке, с одной стороны. А с другой — иметь элементарные представления об автоматизации для необходимой оценки и критики предлагаемых Разработчиком методов.

В свою очередь, опыт аналитиков Разработчика должен достичь такого уровня, чтобы они имели возможность разобраться в плохо структурированных лекциях экспертов Заказчика, состоящих на 80% из изложения частных случаев и исключений, каждый из которых просто «вопиит гласом велиим» о высочайшем уровне и исключительности данного эксперта в его области деятельности.

Но серьезное сотрудничество начинается только тогда, когда на пересечении этих двух областей, которое можно назвать областью взаимопонимания, накапливается некая «критическая масса» требований. Именно эти требования и являются основным материалом для переговоров и обоснования целесообразности самых ранних этапов разработки проекта.


Рис. 3. Возможность полноценного сотрудничества

Замечательно, что этими требованиями, как правило, не может пренебречь даже высшее руководство — как с одной, так и с другой стороны. Как правило, эти требования в обязательном порядке попадают в официальные документы и именно на них «высокие договаривающиеся стороны» своими широкими руководящими жестами ставят две черты: порог рациональной автоматизации и порог рациональной формализации предметной области Заказчика.


Рис. 4. «Высокие договаривающиеся стороны» принимают решение и проводят две красные черты

Эти две руководящие директивные черты отрезают две небольшие, но очень интересные области:

  • излишние требования к автоматизации от особо грамотных сотрудников Заказчика;
  • излишняя формализация предметной области от особо рьяных аналитиков Разработчика.

Примером требования из первой области может служить пожелание системного администратора Заказчика: получить систему автоматического архивирования базы данных корпорации на какое-нибудь нестандартное устройство со своим специфическим программным обеспечением по его управлению (какой-нибудь древний стример или новейший CD-RW, оборудованный механическим чейнджером).

Пример для второй области — система автоматического ценообразования для работы дизайнеров или парикмахеров, основанная на эстетических признаках.

Как всегда, сроки — сжаты, бюджет — ограничен. А потому от руководства дается однозначная установка: никаких новшеств, никаких изысканий, реализуем только четко очерченную область требований — просчитать сроки и бюджет.


Рис. 5. Результат встречи «в верхах»

Итак, сроки и бюджет скрупулезно подсчитаны, скорректированы и утверждены на высшем уровне.

Приступаем к воплощению… и с ужасом обнаруживаем: для реализации требования В необходима реализация требований, оставшихся за пределами внимания руководства,— А или C.


Рис. 6. Первые неожиданности: обнаружение новых, не учтенных в документах, но обязательных требований: B или C

В экстренном порядке собирается совещание, на котором руководство Разработчика (наконец-то) хоть немного прислушивается к мнению непосредственных исполнителей и на котором за бурными дебатами прячется основная цель: решить, кто же будет расплачиваться за промах. Руководство ли, вынужденное оплатить реализацию одного из требований A или C, — или же непосредственные исполнители, вынужденные реализовать все те же требования A или C, но (!) без дополнительных финансовых и человеческих ресурсов (в лучшем случае будет дана отсрочка по времени, потому что, как правило, все делается за счет «авралов» и «переработок»).

Итак, приходим к пониманию, что существует еще одна область (рис. 7). Область требований, удовлетворение которых обязательно для реализации проекта в целом и, в частности, для реализации задокументированных и утвержденных требований. Ограничение ресурсов на реализацию этих требований или попытка обойтись вообще без их реализации ведет прямиком к завалу проекта.


Рис. 7. Область контекста реализации

Как только руководство принимает решение — требования из этой области не реализовывать — исполнители встают перед необходимостью делать это за свой счет. В результате наблюдается явление откачки средств и ресурсов из среды исполнителей. Это может выразиться в переработках, задействовании личных наработок или скрытого аутсорсинга исполнителей.

В любом случае результатом будут напряженные отношения между высшим руководством и исполнителями, грозящие перерасти сначала в скрытый, а потом и в явный конфликт. В случае если трудовые отношения построены по принципу «от конечного результата», пострадавшей стороной (то есть стороной, несущей потери) окажется непосредственный исполнитель. В случае же отношений с повременной оплатой все финансовые потери ложатся на плечи руководства Разработчика.

И в том, и в другом случае Заказчику извне ситуация с развитием проекта кажется неопределенной, но, тем не менее, не предвещающей больших тревог — хотя именно в это время закладывается мина замедленного действия под успех проекта в частности и сотрудничество вообще. Тогда как в случае проявления инициативы со стороны Заказчика в сторону переговоров с целью увеличения сметы проекта катастрофические процессы могут быть погашены.

Проще говоря, рассчитывать на конструктивную деятельность со стороны своего руководства исполнителям Разработчика не приходится. Провести переговоры и добиться разумного и обоснованного увеличения бюджета — дело немыслимое, а проявление инициативы в этом направлении со стороны руководства Разработчика вообще принято считать дурным тоном.

С другой стороны, предложение со стороны Заказчика — увеличить бюджет проекта — помимо того что дает возможность решить проблему, еще и работает в сторону повышения имиджа не только Заказчика, но и Разработчика.

Однако на практике мы нередко наблюдаем весьма печальную и уродливую картину. Руководство Разработчика, зажатое реальными и весьма серьезными проблемами по реализации упущенных требований с одной стороны и мнимыми, но весьма болезненными проблемами по преодолению имиджевого стереотипа поведения с другой, все-таки вынуждено действовать. События развиваются по плану, который, может, и кажется счастливой находкой — но на деле лишь оттягивает момент кризиса, приводя к еще более тяжелой ситуации.

На переговорах Руководство разработчика подает сложившуюся ситуацию в очень выгодном (но только при поверхностном взгляде) свете: во время работы над проектом оказалось, что в общем ключе работ, не изменяя идеологии, возможно получить намного более привлекательный для Заказчика продукт, чем предполагалось изначально. Для этого необходимо всего лишь незначительно увеличить бюджет, но (!) прямо на текущей стадии разработки проекта.

Очевидными плодами такого подхода будут:

  • получение дополнительного финансирования, едва достаточного для закрытия образовавшегося прорыва и относительно благополучного завершения проекта в его изначальной редакции;
  • обнародование необходимых, но упущенных пунктов, под видом доработок, составляющих новизну и привлекательность проекта в его новой редакции;
  • целый пакет новых и весьма амбициозных требований, главными свойствами которых будут повышенная туманность формулировок и, как следствие, повышенные риски в реализации;
  • фактические затраты на реализацию этих новых требований окажутся, в лучшем случае, большими не на порядок, а лишь в несколько раз.

Есть простой признак, позволяющий Заказчику распознать такую ситуацию. Предложения об улучшениях поступают от Разработчика в конце временной цепочки его состояний: спад активности — неопределенность — бурная внутренняя деятельность — предложение чего-то лучшего. Вот уж действительно, лучшее — враг хорошего.

Ознакомьтесь так же:  Статья 154 ук рф

Напротив, если предложения об улучшении явились результатом ровной работы аналитиков Разработчика, да еще и при болезненном для Заказчика вскрытии его внутренних проблем,— тогда это может служить поводом к доверительной оценке таких предложений.

Существует еще одна область требований, реализация которых необходима для поддержания естественной и полноценной работы системы в соответствии со взаимно понятными и задокументированными требованиями (рис. 8). Изначально, требования из этой области не были замечены аналитиками Разработчика и считались в равной мере как очевидными, так и обязательными, с точки зрения экспертов Заказчика.

Если проигнорировать реализацию этих Требований, то Заказчик получит Систему, в которой функционирование автоматической части должно поддерживаться большим объемом окружающего ручного труда. Грубо говоря, придется заводить штат сотрудников, специалистов Предметной Области, работающих на Систему.


Рис. 8. Область контекста использования/функционирования

Авторам пришлось внедрять сторонний продукт, в котором был реализован автоматический выбор варианта делопроизводства в зависимости от текущего состояния счета клиента. При этом велся строгий учет самих платежных документов и даты их прихода. Главным упущением аналитиков Разработчика оказалась реализация системы как автомата, реагирующего на наличие определенного платежного документа, а не на общий баланс по счету. Надо было видеть мучения делопроизводителей, вынужденных в угоду системе редактировать пересчитанные вручную суммы по соответствующим документам, а то и вводить дополнительные фиктивные документы…

Да простит меня читатель за случившееся отступление от темы статьи: формальная модель для классификации требований. Прорвались наболевшие наработки по родственному, но все-таки другому направлению — «Как гарантированно завалить проект» (конструктивное название должно быть таким «Риски ошибок в руководстве проектом: какими они бывают и как их избежать»). Возможно, это действительно станет названием следующей статьи, пока же приведенные язвительные примеры послужат лишь подтверждением тому, что за видимой сухостью и формальностью предлагаемой диаграммы кроются болезненные вопросы, сплошь и рядом возникающие в реальных, «живых» проектах. А для обсуждения подобных наболевших вопросов ой как нужна хорошая их визуализация!

Но вернемся к нашей диаграмме и выделенной там области… и зададимся вопросом: «А почему, собственно, область поддерживающих требований должна иметь именно такой вид?» Почему не так, как на рис. 9?

Другой интересный вопрос: а какой смысл в двух различных подобластях данной области? Чем, по сути, отличаются требования A и C? Но об этом чуть далее.


Рис. 9. Та же область контекста реализации — но при более глубоком рассмотрении

А по перовому вопросу очевидно, что диаграмма на приведенном рисунке является просто проявлением более глубокого подхода и дает более интересные результаты, обсуждение которых следовало бы вынести за пределы данной ознакомительной статьи. Мы же ограничимся упрощенным вариантом (рис. 7) и пойдем далее.

Итак, имеем две зеркальные — как по расположению на диаграмме, так и по своим проявлениям в процессе разработки,— области:

  • область контекста реализации — область поддерживающих требований, необходимых для полноценной реализации Разработчиком задокументированной части проекта;
  • область контекста использования — зеркальная предыдущей и включающая требования, которые остались за пределами документов, но обязательны для полноценной работы заказчика.


Рис. 10. Семантика горизонтального измерения — стандартизация или уникальность разработки

Теперь настало время «показать семантику второго измерения». Проще говоря, ответить на поставленный ранее вопрос: а чем, собственно, отличается левая подобласть от симметричной ей правой? Если для полноценной работы Заказчика в соответствии с требованием E необходима реализация одного из поддерживающих требований D или F (рис. 9), то чем они между собой отличаются и что общего у них с зеркальными им требованиями A и C?

Внимательный читатель уже заметил две стрелочки в верхней и нижней части рисунка, подписи которых имеют простой смысл: чем левее на рисунке расположена точка, обозначающая требования, тем больше это требование опирается на широко известные и общепринятые методы решения, стандартное и распространенное оборудование, соответствующее программное обеспечение и т.д. А чем правее — тем больше особенностей в методах решения (вплоть до ноу-хау и патентов), тем больше специального оборудования и\или специального ПО.

И не случайно стрелочка, указывающая стремление использовать стандартные методы, расположена в верхней части, соответствующей стремлениям Разработчика. Именно от него зачастую звучат размашистые предложения в стиле: да, для решения задач такой серьезной и представительной организации, как Заказчик, ну просто необходимы: СУБД — не меньше и не дешевле Oracle 9, CRM-системы — не ниже самого «Сибел-системз», а для решения задач коммуникации без приобретения спутника с антеннами вообще не обойтись.

В ответ на такие предложения со стороны Заказчика активно выдвигаются возражения, что подобная мощь (читай — такие большие расходы) ему абсолютно ни к чему, что вполне достаточно существующей базы и что сотрудники Заказчика успешно справляются со своими задачами чуть ли не с калькулятором и на бумаге …

Существует лишь несколько задач, реально нуждающихся в автоматизации. Именно они являются особенностью деятельности Заказчика, их решение должно дать Заказчику конкурентные преимущества и т.д.

Изюминкой оказывается комплекс из уникальности самих задач, методов их решения и бессмысленности автоматизации всего остального без автоматизации именно этого…

В данном случае особенно к месту оказывается следующий пример из области делопроизводства. Существует обязательное требование E: система должна автоматически реагировать на состояние счета клиента и конфигурацию платежных документов. Существуют особые случаи, в которых необходим перерасчет сумм по платежным документам и реализация требования E нуждается в удовлетворении одного из требований D или F. Пример для требования F — наличие какого-то удобного и логичного механизма для перерасчета. Требование D — ужесточение (стандартизация) требований на платежные документы, исключающие возникновение запутанных ситуаций.

Для зеркальных требований A, B, C можно привести такой пример. B — набор отчетов, генерируемых из БД. Особенность — один или несколько из них не реализуются в виде единственного, пусть и сложного, SQL-запроса. Необходимы хранимые процедуры. Для реализации этого требования следует реализовать либо требование A — использовать Т-SQL с соответствующими механизмами MS-SQL Server (стандартное решение — и никакой головной боли Разработчику) либо требование С — использовать ODBC-интерфейс к файлу MS Access, на чем настаивает Заказчик. Но тогда Разработчику придется засучить рукава — и разрабатывать собственный эмулятор хранимых процедур. Вот вам и уникальность, и специфичность разработки.

Собственно, на этом ознакомительную статью можно и закончить. Заинтересованный читатель уже в состоянии самостоятельно развивать далее предложенный подход, что нас только порадует.

Руководитель ИТ проекта

Руководитель ИТ-проектов – сотрудник, целью которого является сопровождение конкретного проекта от планирования до реализации. Критерием успеха здесь является соответствие результата поставленным задачам.

Суть проекта может заключаться в разработке новой информационной системы или во внедрении уже существующей системы в компании. В один период времени руководитель ИТ-проектов может заниматься одним крупным проектом или несколькими небольшими. В любом случае его труд является разносторонним, ему приходится все время переключаться с одной задачи на другую и одновременно удерживать перед глазами общую картину.

Квалификационные требования

Руководитель проектов в сфере ИТ должен быть знаком с основами системного анализа, разбираться в современном программном обеспечении и информационных системах, знать основы бюджетирования и уметь руководить людьми. Он должен свободно ориентироваться в стандартах и лучших практиках по управлению проектами. Руководитель ИТ-проектов должен понимать суть бизнес-процессов компаний, в которых внедряется информационная система.

Этот сотрудник обычно имеет высшее образование в сфере информационных технологий, а также проходит курсы повышения квалификации в области проектного менеджмента. Дорасти до этой должности можно, постепенно продвигаясь по карьерной лестнице в IT-отделе одной организации.

Чтобы занять этот пост с нуля, обычно требуется опыт работы на аналогичной позиции. Причем нового работодателя будет интересовать не только формальный стаж работы, но и примеры успешно реализованных задач. Свои успехи лучше заранее описать в резюме.

Функциональные обязанности

Руководство проектом в ИТ-сфере включает в себя следующие должностные обязанности:

  • Определение сроков завершения различных этапов работы;
  • Разработка плана действий;
  • Расчет финансовых затрат на закупку оборудования, оплату труда, иные необходимые цели;
  • Ежедневное управление персоналом, участвующим в работе;
  • Контроль качества;
  • Определение возможных рисков и их минимизация;
  • Найм субподрядчиков для исполнения отдельных функций;
  • Своевременное внесение изменений в планы и сроки, если того требует ситуация;
  • Обеспечение связи между всеми участниками реализации проекта, сведение их усилий к единому результату.

Профессиональные навыки

Официальный профессиональный стандарт «Руководитель проектов в области информационных технологий» был утвержден в России в 2014 году. Базовые требования, изложенные в документе, дополняются и конкретизируются в должностных инструкциях организаций. Обычно главные требования указываются в описании вакансии.

Руководитель ИТ-проектов должен быть знаком с современными инструментами управления (такими как сетевые графики и анализ альтернатив) и ориентироваться в ИТ-сфере. IT – динамичная, быстро развивающаяся область. Поэтому сотрудник должен быть готов постоянно повышать квалификацию, узнавать о новых программных продуктах и оборудовании нового поколения. Для изучения технической документации и статей в профессиональных СМИ в большинстве случаев потребуется уверенное знание английского языка.

Чтобы управлять проектами, надо ориентироваться в экономических вопросах, уметь рассчитывать бюджет и контролировать его исполнение. Руководитель ИТ-проектов должен понимать – как минимизировать затраты и в каких случаях снижение затрат нежелательно из-за негативного влияния на сроки и качество работы. Хороший руководитель проектов в сфере ИТ способен исчерпывающе объяснить свою позицию заказчику.

Руководитель ИТ-проектов должен правильно подбирать сотрудников для различных задач и грамотно выстраивать коммуникации между ними. Причем речь идет не только о налаживании связей между людьми, но и о техническом обеспечении этого процесса. Иногда вовремя созданный чат в мессенджере напрямую влияет на успех общего труда.

Важная часть управления ИТ-проектом – оформление документации. Иногда руководителю ИТ-проектов приходится заключать юридически договоры с поставщиками и субподрядчиками, составлять прозрачную отчетность для заказчика и контролирующих органов. При этом ошибки в документах порой заставляют начать всю работу заново и приносят крупные убытки.

Возможность повысить квалификацию для руководителей ИТ-проектов, подтвержденную дипломом Высшей Школы Экономики, реализована в ВШБИ НИУ ВШЭ на программе профессиональной переподготовки «Управление ИТ и ИТ-проектами» или программе МВА-CIO.

Бюджет ИТ-проекта

Деньги являются одним из факторов, ограничивающим развитие бизнеса, в том числе инвестирование в ИТ, поэтому необходимо прежде всего определиться с бюджетом проекта автоматизации. На подготовительном этапе мы не сможем сделать детальный бюджет, да в этом и нет необходимости. Достаточно определиться с готовностью выделять средства и порядком сумм, выделяемых на инвестиции в ИТ, т. е. определить некоторые рамки затрат на ПО, за которые нельзя выходить. Это вызвано тем, что бюджет, выделяемый на ИТ-проект в целом и ПО, зависит от множества факторов:

  • • финансового состояния предприятия;
  • • уровня использования информационных технологий в бизнесе компании, т. е. зависимости результатов бизнеса от использования ИТ;
  • • целей проведения автоматизации;
  • • понимания проблемы со стороны высшего руководства и собственников;
  • • понимания возможного эффекта от реализации ИТ-проекта.

Полезно будет провести распределение суммы бюджета по статьям. Эго можно сделать в процентном выражении, так как точной суммы пока еще нет. Очень часто график платежей не равномерный, а имеет некоторые пики по единовременным выплатам. Это может создавать дополнительные сложности с финансированием работ по проекту. Поэтому необходимо согласовать с руководством организации максимально возможные суммы для единовременных выплат и на переговорах с поставщиками ПО следует их учитывать как одно из требований.

Планирование временных рамок проекта

Заметим, что только при задании четких временных рамок проекта можно будет решать в дальнейшем вопросы исполнительской дисциплины как рядовых сотрудников, так и руководства, поэтому необходимо:

  • • учесть при планировании бюджета времени загрузку текущей работой сотрудников, участвующих в ИТ-проекте;
  • • четко определить сроки выбора, принятия решения и начала внедренческого проекта;
  • • ввести ключевые точки (вехи) по проекту, чтобы в дальнейшем использовать их для контроля соблюдения сроков выполнения работ по проекту;
  • • протоколировать решения всех совещаний и собраний с указанием, кто, что и к какому сроку должен сделать для исполнения решений.
Ознакомьтесь так же:  Льготы пенсионерам по ярославской области

Важно создать соответствующую психологическую атмосферу порядка в команде проекта уже на подготовительном этапе. В противном случае негативный опыт отсутствия дисциплины в команде проекта создаст значительные трудности на этапе внедрения системы. Задержки работ при выполнении ИТ-проекта — это снижение эффективности вложенных средств.

IT-Project Management

IT-PM: Персональный блог об управлении IT-проектами

Tagged with требования

Требования — это главное и основное. Часть 2: Документирование

Продолжаем тему менеджмента требований. После того, как требования собраны (а еще лучше в процессе сбора), они должны быть задокументированы.

Все требования желательно хранить централизовано. Если требования разбросаны по множеству документов, папок, сайтов и т.д., одно из них (или целая группа) будут неучтены. Желательно строго определить формат изложения требований и придерживаться этого формата. Посоветуйтесь со всей командой. Каждый ее участник может привнести в разрабатываемый шаблон требований что-то действительно нужное.

Чтобы не записывать все требования сплошным списком, нужно выделить группы требований. Здесь каждый решает сам, какая таксономия будет удобнее. Можно взять одну из уже существующих систем классификации, можно придумать свою, «заточенную» под конкретные нужды и цели. Лично я, предпочитаю широко известную модель FURPS+. Пару слов об этой модели.

Модель FURPS+ достаточно универсальна, и вместе с тем достаточно удобна. Путаница с распределением требований по группам возникает редко. Выделяются следующие группы требований:

  • Функциональные требования – функциональность, свойства, возможности, безопасность, и т.д.
  • Требования надежности – частота сбоев, возможность восстановления, предсказуемость поведения.
  • Требования производительности – время отклика, точность, доступность, использование ресурсов.
  • Возможность поддержки и конфигурирования – адаптивность, соответствие стандартам, возможность конфигурирования.
  • Требования к реализации – требования к ресурсам, языки и средства разработки, аппаратное обеспечение.
  • Требования к интерфейсам – ограничения, накладываемые необходимостью взаимодействия с внешними системами.
  • Управление системой – требования к инструментам управления системой, к интерфейсам управления и пользовательскому интерфейсу.
  • Требования удобства и эргономики – человеческий фактор, справочная система, документация.
  • Юридические вопросы – авторское право, использование компонентов сторонних разработчиков и пр.

Также полезно снабдить требования некоторыми атрибутами. Например:

  • Уникальный идентификатор, состоящий из первой буквы названия класса требований (Ф — функциональные, Н — надежность) и целого числа. Нумерация списков в Word может сместиться в случае перемещения требования или добавлении нового, а такой идентификатор (записанный простым текстом) никуда не денется. При ссылке на требование из другого документа достаточно указать этот идентификатор.
  • Актуальность («Действительно», «Снято», «Под вопросом») — часть требований в процессе разработки снимается, но не следует сразу удалять их. Возможно, кто-то ссылался на них из других документов.
  • Источник требования — документ, либо лицо, выдвинувшее данное требование. Если требование сформулирован плохо, или непонятно откуда взялось, можно будет уточнить, обратившись к источнику.
  • Дата введения требования.
  • Проектирование — когда и кем требование было учтено при проектировании, и в каком проектном документе можно найти решение, подтверждающее, что требование учтено.
  • Реализация — когда и кем требование было реализовано, и в каком модуле/файле/документе можно найти реализацию этого требования.
  • Тестирование — когда и кем была проверена и подтверждена корректность реализации требования. Также может быть указан использовавшийся при проверке Test-Case.

Требования — это главное и основное. Часть 1: Сбор требований

О том какую роль играют требования в процессе разработки написано очень много. Но раз уж я решил затронуть эту тему, придется и мне присоединится и добавить кое-что от себя.

В любом проекте, если речь не идет о чем-нибудь очень простом, фигурируют такие документы как техническое задание (ТЗ), технические условия (ТУ), требования к изделию и т.д. От названия документа и формата изложения смысл содержимого не меняется — все эти документы содержат требования к разрабатываемому продукту. Невыполнение этих требований может привести к самым разным последствиям. Самый удачный вариант — заказчик просто не заметит отсутствие тех или иных свойств изделия. Самый скверный — откажется платить деньги на основании невыполнения того же пресловутого ТЗ. Это было вступление. Теперь по делу…

В зависимости от масштаба предприятия и состава команды разработки, обязанности по менеджменту требований могут возлагаться на аналитика (насколько я знаю, в некоторых компаниях даже есть такая должность «аналитик по требованиям»), на руководителя или не возлагаться вообще ни на кого. Последний вариант самый печальный и грозит вышеописанными сложностями сдачи продукта заказчику. Задача менеджмента требований состоит в сборе, уточнении и формализации требований, документировании требований, актуализации требований, и самая главная задача – контроль реализации требований.

Источники требований

1. Требования могут быть сформулированы четко и ясно в каком-то документе (те же ТЗ и ТУ). С такими требованиями работать проще всего. Они, как правило, конкретны, четки и исключительно по делу. Иногда такие требования нуждаются в уточнении. К примеру, из требования «Передаваемые по сети данные должны шифроваться» непонятно, шифровать только значимые данные, или и служебные тоже.

2. Требования могут быть высказаны заказчиком в ходе обсуждения проекта. Искусство понять, что конкретно хочет получить заказчик – это тема отдельной статьи. Заказчик в большинстве случаев сам не знает, что конкретно ему нужно. Часто высказывает противоречивые или плохо сформулированные требования. Самое важное, на мой взгляд, стараться говорить с заказчиком на «его языке». Если он не программист не надо пытаться читать ему лекцию на тему «Managed code vs. native code». Может ему вообще неважно, на каком языке будет написан продукт. Углубляться в эту тему здесь я не буду. Замечу лишь, что у заказчика, еще на самых начальных этапах разработки полезно бывает поинтересоваться, насколько критично то, или иное требование. Это поможет спланировать реализацию функций разрабатываемого продукта от важных к менее важным.

3. Требования могут быть обусловлены характером изделия. Например, 24 кадра в секунду минимум для видеоплеера – это достаточно очевидно. Кстати, сомневаюсь насчет необходимости учета наиболее очевидных требований. В дальнейшем это лишь отвлечет разработчиков от действительно важных требований.

В общем случае невозможно определить все требования с самого начала. Перечисленные источники – это лишь то, к чему можно обратиться на начальных стадиях разработки. Источником новых требований может стать любой документ (не говоря уже о переменчивых желаниях заказчика). По завершении некоторых задач, полезно просматривать результаты работ на предмет новых требований. К примеру, в том проекте, на котором я сейчас занят, требования собирались из следующих источников: ТЗ, модель доступа, предполагаемая архитектура, обсуждения проекта с заказчиком, use-case`ы, некоторые стандарты и ГОСТы. Больше чем уверен, что позже, с появлением новых результатов, этот список расширится.

Требования ит проекта

Когда основные потребности пользователей собраны и согласованы со всеми участниками, мы можем приступить к определению ключевых функций разрабатываемой системы, и уже на основании их примерно оценить стоимость и длительность проекта, направленного на создание конечного продукта. В результате этого процесса, как правило выясняется, что не хватает либо времени, либо ресурсов, либо и того и другого для получения качественного результата в предусмотренные сроки. В этом случае, нам очень пригодится умение эффективно определять Границы проекта и управлять ими.

Цель данной группы работ: максимально полно определить набор функций, который должен выполнять целевой продукт, для удовлетворения выявленных потребностей заказчика. Отобрать те из них, которые, могут быть реализованы в рамках текущего проекта.

Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.

Для управления Границами проекта, как на начальных стадиях, так и в течение всего проекта, очень удобно использовать функциональное или процессное моделирование. Модели этого типа позволяют описывать события и последовательности исполнения Бизнес процессов во времени.

Иногда, для определения границ, группа разработчиков пытается использовать не функции, а сущности предметной области. Хочу предостеречь Вас от такого подхода, так как он чреват следующими последствиями:

  • в связи с недостаточной формализацией некоторые процессы могут быть реализованы не полностью, и это будет выявлено только тогда, когда будут выпущены первые версии продукта;
  • некоторые автоматизированные процессы не будут использованы в связи с тем, что связанные с ними процессы в проекте не реализованы;
  • часть объектов системы не будет использоваться, потому что нет процессов, обрабатывающих их.

На рисунке 6.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения функций, которые она должна выполнять.


Рисунок 6.1 — модель процесса определения функций

1. Используем нотацию IDEF0 для определения функций системы и границ проекта

Наиболее удобной методикой функционального моделирования, с точки зрения определения границ проекта, на мой взгляд является “старая добрая” методология проектирования SADT, использующая иерархическую декомпозицию сверху вниз. Применение диаграмм IDEF0 имеет следующие преимущества перед аналогами:

  • Декомпозиция при анализе автоматизируемых процессов производится сверху вниз — от одного самого высокоуровневого к составляющим его подпроцессам. Последовательное разветвление процессов с уточнением их слой за слоем, позволяет с одной стороны, не упустить важные деловые процессы из поля зрения команды, а с другой работать всегда с одним выбранным узлом, содержащим небольшое количество элементов;
  • Способ моделирования, при котором за основу берутся входящие потоки данных и управляющие на них воздействия, позволяет максимально точно и полно выявить все вложенные в процесс подпроцессы, обрабатывающие эти входящие данные и предоставить на выходе процесса результат – исходящий поток;
  • Обязательное для каждого результата процесса (исходящего потока) — сопоставление другого процесса потребляющего его на входе (как входящий поток), позволяет не упустить функции в цепочке обработки и преобразования данных.

При помощи стандарта IDEF0 строится модель, описывающая основные функции, выполняемые системой и их взаимодействие в виде информационных потоков, в том числе с внешней средой. Таким образом на диаграммах IDEF0 легко читаются границы системы и ее окружение. Еще одно достоинство диаграмм этого типа, как было упомянуто выше, заключается в том, что вместо разработки одной большой, громоздкой модели, поэтапно создается несколько небольших, относительно простых моделей, вложенных одна в другую как матрешки.

Таким образом, структура сложного процесса представляется в виде абстракции функций высокого уровня, которая раскладывается на более детальные процессы, увеличивая степень точности, слой за слоем.

Этот вид моделирования позволит нам также определить процессы, которые были выпущены из поля зрения на предыдущих этапах.

Если на этапе процессного моделирования будут обнаружены процессы, которые не описаны на стадии сбора информации, мы должны будем снова вернуться к этапу формирования Пользовательских историй и восполнить пробел. А теперь, чтобы все это нагромождение информации лучше улеглось в сознании, давайте рассмотрим конкретный пример.

2. Пример описания функции “Управление требованиями”

Хочу напомнить основные постулаты стандарта IDEFO. Графическую конструкцию стандарта составляют: понятие «Работа» (Activity) для обозначения действия, представленная в виде блока; четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг. Левая сторона блока предназначена для входов, верхняя — для управления, правая — для выходов, нижняя — для механизмов. Для более подробного изучения этой темы обратитесь к [2].

На первом шаге моделирования необходимо определить все потоки данных, поступающих в систему из вне (входные сигналы). В нашем случае это:

  • Цели проекта;
  • Участники и заинтересованные лица проекта;
  • Потребности участников к функциональности целевого продукта проекта;
  • Методики разработки требований;
Ознакомьтесь так же:  Приказ о выборочной инвентаризации

Далее определяем все “продукты”, генерируемые системой для внешнего использования (выходные сигналы):

  • Артефакты проекта, в том числе Требования, Модели, Планы и т, д.;
  • Целевой продукт проекта.

Описанные выше потоки данных и глобальная абстрактная функция системы, обрабатывающая эти потоки, отображены на Диаграмме см. Рис. 6.2.


Рис.6.2 – Функциональная модель системы Управления требованиями верхнего уровня

Проваливаясь во внутрь функции (блока «Работа») мы попадаем на следующий уровень абстракции функциональности системы. Вначале мы видим только потоки данных, выявленные на предыдущем этапе (уровне), см. рис. 6.3.


Рис.6.3 – Начало работы по детализации функции Управление ИТ проектами

Для каждого такого потока необходимо определить процесс, обрабатывающий (преобразующий) или использующий его, добавляя на диаграмме новые блоки «Работ» (функции), связанные с ним.

Таким образом, при каждом последующем шаге (проваливаясь внутрь процесса) необходимо: каждому потоку данных, выявленному на предшествующем уровне, сопоставить функцию (процесс) для его обработки. В результате такого моделирования, мы получим перечень функций, детализирующих вышестоящий абстрактный процесс см. Рис. 6.3.


Рис.6.4 – Определение подпроцессов для функции Управление ИТ проектами

В нашем проекте, согласно изложенным в главе IV целям и выявленным на первом этапе потокам данных, необходимо автоматизировать следующую группу процессов:

  • Сбор данных о потребностях заказчика, предъявляемых к функциональности продукта;
  • Учет системных требований к целевому продукту;
  • Управление пулом работ, направленных на реализацию системных требований и, как результат — на создание целевого продукта;
  • Учет выполнения работ по реализации системных требований и, как результат — продвижение проекта к цели;

Один процесс «Управление заданиями» у нас не получает данные из вне и не предоставляет ничего во внешнее окружение. Получается — он вспомогательный процесс, обеспечивающий функционирование других. Он пока стоит обособлено см. рис. 6.4.

Поскольку большинство процессов логически связаны между собой, необходимо установить все потоки данных, обеспечивающие эти связи. Таким образом от функции к функции на диаграмме появляются дуги. Позже, каждая такая дуга (связь), входящая в блок «Работы», должна будет, при моделировании следующего вложенного уровня, “получить” свой процесс обработки.

Пример модели этих функций с уже установленными взаимосвязями отображены на Диаграмме см. Рис. 6.5.


Рис.6.5 – Функциональная модель системы Управления требованиями

Если такие диаграммы используют в документе необходимо сопровождать их подробным описанием. Дальше приведен пример описания:

На рисунке видно, что функциональную архитектуру нашего проекта представлена в виде четырех доменов:

  1. Сбор потребностей заказчика. Группа процессов по учету и анализу целей разработки продукта, основных сценариев его использования и действующих лиц — пользователей продукта.
  2. Управление спецификациями требований. Процессы формирования функциональных требований на основании выявленных потребностей заказчика и будущих пользователей целевого продукта.
  3. Управление формированием заданий. Процессы формирования заданий, направленные на удовлетворение выявленных потребностей заказчика, путем реализации функциональных требований. Фиксация результатов, при выполнении заданий исполнителями, путем изменения состояния требований, по которым оно сформировано.
  4. Управление выполнением. Процессы, выполняющие мониторинг и фиксацию приращения функционала, позволяющего реализовывать потребности пользователей в целевом продукте.

В первый функциональный блок “А1”, в качестве входящих параметров, направим данные о целях и пожеланиях заказчика, заинтересованных лицах и т.п. Данные поступают из внешнего окружения системы в виде документов –заявок на разработку или в устной форме. Цель процесса — преобразовать их в информацию, пригодную для передачи в блок “А2” — «Управление спецификациями требований». Результат деятельности первого блока, в виде Пользовательских историй и отчетов, также пригоден и для внешнего использования и доступен внешним системам и пользователям в виде печатных форм или экспорта данных в файлы. Поэтому стрелка из блока разделяется и выходит еще и за границу диаграммы, в вышестоящую функцию.

Из диаграммы видно, что блок “А1” имеет обратную связь от блока “А2”, в виде управляющей информации, доводящей о степени реализации требований, сформированных по Пользовательским историям (дуга «Отчет о реализации требований»). Эта связь позволяет отследить ход и полноту реализации Пользовательской истории в конечном продукте по цепочке, через спецификации требований.

Второй блок, как показано на схеме, получает на вход обработанные пожелания заказчика в виде Пользовательских историй, потребностей пользователей и т.п. уже в формализованном виде. На основании этих данных в нем формируются функциональные требования к разрабатываемому продукту и формализуются в виде спецификаций требований. Дальше эти спецификации передаются в четвертый блок “А4”, отвечающий за выставление задания исполнителям на их реализацию. Из диаграммы видно, что задания могут выставляться и на выполнение работ с требованиями (дуга «Задания», входящая в качестве управления в блок “А2”). Обратите внимание на то, что во второй функциональный блок возвращаются данные об исполнении заданий по спецификациям, что позволяет в этом домене определить приращение функциональности, полученное в ходе разработки.

В третий блок направим из блока “А2”, в качестве управляющих инструкций, ключевые показатели спецификаций. На основании их можно определить степень достижения заданной функциональности, используя отчет о выполнении задний, выставленных по этим спецификациям исполнителям. Отчет поступает в виде входящих параметров из блока “А4”.

Несмотря на все мои старания, этот раздел получился тяжелым и утомительным. Но для понимания концепции важно было разобраться, как это все работает. Далее, будем описывать вложенные функции уже не так подробно.

3. Пример описания функции “Сбор потребностей заказчика”

Продолжаем декомпозицию выявленных функций, раскладывая каждый домен на более мелкие, детальные функции. Для этого используем наши Пользовательские истории (речь о них шла в предыдущей части публикации). При их описании будем определять — насколько полно мы «покрываем» ими потребности заказчика.

Заглянем в блок А1 на рисунке 6.4, представляющий домен «Сбор потребностей заказчика». Его детализация показана на рисунке 6.5. Все потоки данных, которые входили в блок А1 на рисунке 6.4, соответственно попали и в детализирующую его диаграмму см. рис. 6.6.


Рис. 6.6 – Схема домена Сбор потребностей заказчика

Функционально домен мы разделили на четыре процесса:

  1. Интервьюирование заказчиков и пользователей целевого продукта. Процесс фиксации Пользовательской истории, в том числе ее цели. Выполняется проверка наличия подобных историй, зафиксированных ранее. Определяются противоречащие друг другу сценарии. Этот блок должен “покрывать” Пользовательские истории US01, US02
  2. Изменение Пользовательской истории. Процесс управления изменениями в описании потребностей заказчика продукта, включая инициацию процесса изменения связанных с ней системных требований. Этот блок должен “покрывать” Пользовательские истории US02.
  3. Фиксация заинтересованных лиц проекта. Выявляются все лица, так или иначе связанные с проектом. Этот процесс должен “покрывать” Пользовательские истории US04
  4. Определение, уровня реализации Пользовательской истории. Осуществляется мониторинг системных требований, связанных с Пользовательской историей, определяются их текущие состояния и уровень реализации в рамках конечного продукта. Этот блок должен “покрывать” Пользовательские истории US11. Блок, в качеств управляющего интерфейса, получает «Отчет о реализации требования», поступающий из блока “А2” — «Управление спецификациями требований», на основании которого рассчитывается уровень выполнения.

4. Пример описания функции “Управления спецификациями требований”

Следующее уточнение произведем с доменом «Управление спецификациями требований проекта» (А2). На рисунке 6.7 изображена диаграмма этой модели.

Функционально домен делим на четыре процесса:

  1. Определение бизнес-процессов. Выполняется разработка функциональной архитектуры целевого продукта, в том числе, определяется важность и приоритетность автоматизируемых процессов — управление границами проекта. Этот блок должен “покрывать” Пользовательские истории US05, US06. В качестве управляющего интерфейса блок получает «Задания», поступающие из блока “А4” — «Управление заданиями» и инициирующие выполнение работ.
  2. Разработка спецификаций требований. Разрабатываются нотации логической и физической структуры продукта, формируется контент проекта с детальным описанием требований к целевому продукту, на основе которого будет осуществляться взаимодействие всех участников. Этот блок должен “покрывать” Пользовательские истории US07. В качестве управляющего воздействия блок получает описание стандартов, которым должны соответствовать спецификации.
  3. Управление изменениями требований. Фиксируются заявки на изменение ранее утвержденных характеристик целевого продукта. В том числе инициируется процесс формирования заданий на реализацию этих изменений. Этот блок должен “покрывать” Пользовательские истории US10.
  4. Управление состоянием требований. Осуществляется мониторинг процесса продвижения проекта, в части реализации требований. Эта функция должна “покрывать” Пользовательские истории US11. В качестве управляющего интерфейса блок получает отчеты «Выполнение Заданий» поступающие из блока “А4” — «Управление заданиями», для определения текущего состояния и уровня реализации проекта.


Рис. 6.7 – Схема домена Управления спецификациями требований проекта

5. Пример описания функции “Управление заданиями”

На рисунке 6.8 изображена диаграмма, представляющая домен Управления Заданиями проекта (А4). Функционально домен мы разделили на четыре процесса:

  1. Формирований заданий на основании спецификаций требования. Формируются задания на реализацию требования в том числе: на проектирование, разработку, тестирование, развертывание, пилотное внедрение. Этот блок должен “покрывать” Пользовательские истории US08.
  2. Формирование заданий на итерацию. Осуществляется управление выставлением заданий по плану итерации. Эти требования взяты из стандартного процесса управления проектом с использованием итерационного подхода.
  3. Формирование заданий при наступлении риска. Осуществляется управление выставлением заданий по плану устранения последствий риска.
  4. Учет выполнения заданий. Формируется отчет о выполнении задания. Происходит изменение статуса объектов проекта по результатам выполнения заданий. Этот процесс должен “покрывать” Пользовательские истории US09.


Рис. 6.8 – Схема домена Управления Заданиями проекта

При моделировании этого домена, у нас появились процессы, которым мы не можем сопоставить ни одну из Пользовательских историй. Поэтому восполним пробел. Для этого, мы должны вынести проблему на совместное обсуждение команды с заказчиками и сформировать новые Пользовательские истории.

Для процесса 5.2 опишем следующую Пользовательскую историю:

US12. На основании плана итераций проекта отобрать пул задач, которые необходимо реализовать на данном этапе.
Цель: Получить список задач для реализации в текущей итерации проекта.

Процесс 5.3 затрагивает несколько Пользовательских историй:

US13. Подготовить требования, которые необходимо будет реализовать, при наступлении прогнозируемого риска.
Цель: Выработать альтернативные решения для реализации потребности заказчика, при возникновении проблем.

В случае наступления риска, выполняется пользовательская история US8.

6. Пример описания функции “Управление выполнением”

На рисунке 6.9 изображена диаграмма, представляющая домен Управления выполнения проекта. Реализация этого домена немного выходит за рамки нашего проекта, но тесно с ним связана. Поэтому рассмотрим и его.


Рис. 6.9 – Схема домен Управления выполнения проекта

Функционально домен мы разделили на четыре процесса:

  1. Управление продуктом проекта. Фиксируется выпуск продукта. Формируются отчеты о выпуске
  2. Управление качеством. Производится анализ исправления замечаний предыдущей проверки. Определяется соответствие Выпуска требованиям. Оформляется отчет о контроле качества. Выявляются новые проблемы.
  3. Управление проблемами. Реагирование на отклонения в ходе выполнения процессов. Выполняется приоритезация ошибок, формируются запросы на изменение.
  4. Мониторинг и анализ процессов. Выполняется сравнение плановых значений ключевых показателей с реальными. Определяются значения отклонения. Отслеживаются индикаторы — триггеры («признаки рисков», «симптомы риска»), указывающие на то, что события риска произошли или произойдут в ближайшее время. Этот процесс должен “покрывать” Пользовательские истории US11.

7. Подведем итоги процесса определения функций системы и границ проекта

Таким образом, в несколько проходов, слой за слоем уточняется и детализируется функциональная модель разрабатываемого продукта и определяются границы его контуров. В результате этой деятельности мы получаем подробную процессную модель, которую необходимо воплотить в жизнь. Как видно из диаграмм, помимо перечня автоматизируемых функций, также обозначены все информационные потоки, связывающие их.

Теперь если мы хотим вынести какую-либо функцию за рамки проекта или его этапа, мы можем проанализировать зависимости и избежать «провисания» остальных функций в линейке технологического процесса.

В итоге, опираясь на разработанные нами диаграммы, мы можем на первом этапе вынести за рамки проекта функции группы «А3 Управления выполнением», а также функции «А4.2 Формирование заданий на итерацию» и «А4.3 Формирование заданий при наступлении риска». Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.

Теперь, всякий раз, когда заказчик предлагает Вам включить в продукт новую функциональность, Вы должны сначала зафиксировать изменения на диаграмме Процессов (функций), определить степень изменений и их влияний для системы в целом.

В следующей части мы будем детализировать процессы, включенные в рамки системы ссылка
.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *