В предыдущей статье автор постарался показать, что в принципе представляет собой автоматизированная система в трактовке ГОСТ 34. Хочется думать, что в основном это удалось. Тем не менее, некоторые важные понятия все-таки оказались за рамками описания. Поэтому вдогонку к первой статье теперь придется написать еще одну, чтобы восполнить образовавшиеся пробелы.
Бизнес-процессы? Нет, информационная модель
Начинающих разработчиков технической документации нередко сбивает с толку отсутствие в ГОСТ 34 упоминания о бизнес-процессах. На первый взгляд может даже показаться, что в этом проявляется оторванность госта от современной практики.
Действительно, автоматизируемую деятельность часто описывают в терминах бизнес-процессов. Это вполне естественно, когда речь идет об управленческой или административной работе. Но человеческая деятельность, а вместе с ней сфера приложения автоматизированных систем не исчерпывается управлением и администрированием.
Понятийный аппарат бизнес-процессов плохо подходит для описания деятельности конструктора или функционирования прокатного стана. В этих предметных областях в ходу другие методы моделирования. Более того, поскольку ГОСТ 34, по-видимому, разрабатывался как бы на все времена и как бы для автоматизированных систем любых типов, никаких конкретных предположений о том, как именно создатели системы будут описывать объект автоматизации, в нем не делается. Вместо этого там вводится обобщенное понятие информационной модели.
Виды и примеры требований. Видеокурс Основы разработки требований в ИТ-проектах. Денис Бесков, 2013
Информационной моделью, согласно ГОСТ 34.003-90, называется «модель объекта, представленная в виде информации, описывающей существенные для данного рассмотрения параметры и переменные величины объекта, связи между ними, входы и выходы объекта и позволяющая путем подачи на модель информации об изменениях входных величин моделировать возможные состояния объекта». Таким образом, ГОСТ 34 позволяет разработчику свободно выбирать способ моделирования объекта. Если вы автоматизируете какие-то бизнес-процессы, вы можете описать их посредством той или иной нотации (например, ARIS), а если управляете прокатным станом, то наверно лучше пользоваться математическими моделями.
Автоматизированные рабочие места
Согласно определению, приведенному в ГОСТ 34.003-90, автоматизированное рабочее место (АРМ) — это «программно-технический комплекс автоматизированной системы, предназначенный для автоматизации деятельности определенного вида». АРМ — это не обязательно компонент автоматизированной системы, и не обязательно одна из ее подсистем, хотя такие варианты не исключены.
Говоря простым языком, АРМ представляет собой рабочее место пользователя определенного типа. Например, в какой-нибудь учетной системе могут быть предусмотрены АРМ бухгалтера и АРМ кладовщика, причем каждое рабочее место будет существовать в нескольких экземплярах.
Поскольку АРМ по определению является программно-техническим комплексом, оно обязательно состоит из оборудования и функционирующих на нем программ. Скажем, АРМ кассира — это кассовый аппарат, сканер штрих-кодов и программное обеспечение, которое позволяет пробить покупку.
Функциональные требования. Это документ или часть ТЗ
Аббревиатура АРМ нередко фигурирует в названиях программных продуктов или их составных частей. Допустим, разработчик программного продукта для автоматизации магазинов может назвать соответствующий модуль словосочетанием «АРМ кассира». Точно также никто не помешает ему назвать свой продукт «Автоматизированная система “Магазин”». Однако в том смысле, который вкладывает в этот термин ГОСТ 34, настоящее АРМ возникнет только после того, как в конкретном магазине будет смонтировано оборудование и установлено программное обеспечение.
Вроде бы АРМ — понятие чисто техническое и не связанное напрямую с такими «высокими материями» как цели деятельности, виды обеспечения, функции автоматизированной системы или ее подсистемы. Тем не менее, номенклатура АРМов становится очень важной, когда мы начинаем описывать развертывание и эксплуатацию автоматизированной системы. Ведь персоналу, который выполняет эту работу, придется непосредственно иметь дело именно с АРМами, а не с подсистемами или видами обеспечения. В частности, от состава и количества АРМов напрямую зависят закупки техники и лицензий на программные продукты.
Организационное обеспечение автоматизированной системы
Автоматизация как организационный проект
Если не брать в расчет всевозможные злоупотребления, цель внедрения любой автоматизированной системы — улучшение (какое именно, вопрос второй) определенной деятельности в рамках организации-заказчика. Следовательно, автоматизация подразумевает не только техническую, но и не менее важную организационную работу.
ГОСТ 34.003-90 гласит: «совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала АС в условиях функционирования, проверки и обеспечения работоспособности АС». По существу, речь в этом определении идет не столько о документах (хотя, конечно, «какая свадьба без баяна»), а об организационных мерах, на которые приходится идти при внедрении автоматизированной системы. К таковым относятся:
— перестройка самой автоматизируемой деятельности, например, изменение состава и последовательности выполнения операций, исключение лишних и дублирующихся операций, перевод документооборота в электронную форму, территориальное перераспределение рабочих мест сотрудников, внесение изменений в должностные инструкции оперативного персонала и т.п.;
— организация эксплуатации автоматизированной системы, например, создание специального отдела или специальной группы в составе какого-то из подразделений, распределение обязанностей по обслуживанию автоматизированной системы между техническими специалистами.
Оперативный и эксплуатационный персонал
Сотрудники, причастные к функционированию автоматизированной системы, делятся на две группы: оперативный персонал и эксплуатационный персонал.
Оперативный персонал непосредственно осуществляет автоматизируемую деятельность. В ГОСТ 34.003-90 эти люди названы пользователями, что в некоторой степени противоречит духу этого же стандарта, поскольку, согласно определению автоматизированной системы, эксплуатационный персонал является частью последней. Если уж на то пошло, пользователем логично было бы назвать саму организацию, владеющую автоматизированной системой.
Эксплуатационный персонал обеспечивает функционирование автоматизированной системы. Как правило, эксплуатационный персонал составляют ИТ-специалисты разного уровня квалификации.
Переведем: в «быту» эксплуатационный персонал часто называет представителей оперативного «бизнес-пользователями», а те называют представителей эксплуатационного персонала «айтишниками».
Функциональные роли
На практике деления персонала автоматизированной системы на оперативный и эксплуатационный оказывается недостаточно ни для целей управления работами по созданию системы, ни для документирования. Внимательное чтение ГОСТ 19 и ГОСТ 34 приводит к предположению, что авторы этих стандартов исходили из определенного представления о том, как именно распределены обязанности между людьми, принимающими участие в создании и эксплуатации программ и автоматизированных систем. Здесь мы коснемся в основном эксплуатации; о разработке пойдет отдельный разговор в другой статье. Следует учесть, что в каждой конкретной ситуации функциональные роли могут быть распределены по-своему (хотя нам сложно представить их себе совсем другими). Также в зависимости от предметной области и типа автоматизированной системы могут сильно различаться требования к квалификации персонала.
Владелец автоматизированной системы. Формально владельцем (и заказчиком) всех автоматизированных систем в организации является сама эта организация. На практике обычно автоматизированная система находится в ведении какого-либо структурного подразделения организации в зависимости от того, какую именно деятельность она обеспечивает.
Например, CRM-система может принадлежать коммерческому департаменту, кадровая система — департаменту “human resources” и т.д. Если автоматизированная система затрагивает деятельность нескольких подразделений, то ее владельцем может считаться то, на долю которого приходится наибольшее количество функций. Можно представить себе и другую ситуацию: автоматизированная система состоит из нескольких подсистем, и у каждой подсистемы есть свой владелец. Фактически от лица подразделения-владельца действует его руководитель, который принимает на себя примерно следующие обязанности:
— Во многих случаях владелец автоматизированной системы инициирует ее создание, а после ввода в эксплуатацию деятельность по ее развитию.
— С владельцем автоматизированной системы обязательно согласовывают требования к ней. Впоследствии владелец участвует в приемке автоматизированной системы.
— Владелец принимает решение о предоставлении доступа к автоматизированной системе конкретным сотрудникам и определяет их функциональные роли.
— Владелец системы оценивает качество обслуживания автоматизированной системы эксплуатационным персоналом и поднимает шум, если что-нибудь начинает идти не так.
Владелец автоматизированной системы может не притрагиваться к клавиатуре. Но по определению ГОСТ 34.003-90 он входит в число ее пользователей, так как «использует результаты ее функционирования».
Квалификация в предметной области: полное (хотя, возможно, не во всех деталях) понимание автоматизируемой деятельности, знание всей необходимой для управления этой деятельностью организационно-распорядительной и нормативно-технической документацией.
Квалификация в области информационных технологий: общие представления о целях, задачах и методах в конкретном случае.
Носитель функциональной роли. Пользователь, непосредственно занятый в автоматизированной деятельности и участвующий в выполнении определенных функций системы на определенных этапах. Набор функций и этапов их выполнения характеризует конкретную функциональную роль.
Носитель функциональной роли не всегда является сотрудником подразделения-владельца или даже организации-владельца. Например, пользователями автоматизированной системы интернет-магазина наряду с сотрудниками последнего являются также покупатели, поставщики, рекламодатели, участники партнерских программ и т.д. Во многих автоматизированных системах для каждой функциональной роли предусматривают отдельное АРМ, хотя жестких правил на это счет не существует. Кроме того, забегая вперед, скажем, что по функциональным ролям удобно профилировать технологические инструкции. Носитель функциональной роли должен уметь выполнять все работы на своем участке.
Квалификация в предметной области: знание собственного участка работы, в том числе, относящейся к нему организационно-распорядительной и нормативно-технической документации. Наличие необходимых для выполнения работ на этом участке прикладных знаний, умений и навыков.
Квалификация в области информационных технологий: пользователь персонального компьютера (в большинстве случаев). Некоторые автоматизированные системы могут предъявлять более жесткие требования к квалификации пользователя. Например, от конструктора можно ожидать владения основами работы в САПР, от дизайнера — умения работать с растровой и векторной графикой и т.п.
Администратор («бизнес-администратор») автоматизированной системы. Особая функциональная роль, подразумевающая выполнение ее носителем ряда вспомогательных функций автоматизированной системы. В зависимости от особенностей последней таковыми могут быть ведение нормативно-справочной информации, предоставление другим пользователям доступа в автоматизированную систему, внесение изменений (непринципиальных с точки зрения системной архитектуры) во входные и выходные формы и т.п.
Квалификация в предметной области: хорошее общее понимание автоматизируемой деятельности и распределение обязанностей между ее участниками. Знание состава нормативно-справочной информации, необходимой для ведения этой деятельности.
Квалификация в области информационных технологий: пользователь персонального компьютера.
Вообще, требования к квалификации администратора очень сильно зависят от предметной области и устройства автоматизированной системы.
Ответственный за эксплуатацию автоматизированной системы. В зависимости от структуры организации, ее штатного расписания и корпоративной культуры у этого человека на визитной карточке может быть написано «ИТ-менеджер», «начальник группы эксплуатации АС» и много чего еще. Суть одна: это технически компетентный менеджер, который обязан обеспечить бесперебойное функционирование вверенной ему автоматизированной системы. Как правило он является сотрудником ИТ-подразделения организации. Отношения между ответственным за системы и владельцем системы паритетные, как между провайдером и потребителем некоторой услуги (во всяком случае, в настоящее время так рекомендуют строить работу).
Квалификация в предметной области: хорошее общее понимание автоматизируемой деятельности и распределение обязанностей между ее участниками.
Квалификация в области информационных технологий: специалист. В зависимости от применяемых в автоматизированной системе компонентов могут требоваться те или иные специальные знания, сертификаты и т.п.
Системный администратор. Технический специалист, обеспечивающий нормальное функционирование технических средств и программного обеспечения. Системному администратору также может быть вменено в обязанность выполнение технически сложных вспомогательных функций автоматизированной системы, например, резервное копирование данных.
Квалификация в предметной области: во многих случаях практически не требуется.
Квалификация в области информационных технологий: специалист. В зависимости от применяемых в автоматизированной системе компонентов могут требоваться те или иные специальные знания, сертификаты и т.п.
Легко заметить, что в приведенный список функциональных ролей не позволяет провести четкую границу между оперативным и эксплуатационным персоналом. В какую категорию мы запишем бизнес-администратора?
Комплекс технических средств автоматизированной системы
Автоматизированная система как объект строительства
Типичная автоматизированная система физически представляет собой совокупность компьютеров, периферийных устройств и других технических средств, соединенных между собой каналами передачи данных. Под каналами передачи данных понимаются локальные или глобальные сети, но только.
Например, в АСУТП для получения информации с датчиков и для передачи информации контроллерам, которые непосредственно управляют промышленным оборудованием, применяются специальные интерфейсы и протоколы. Не забудем и о том, что для функционирования технических средств и сетевого оборудования требуется электричество.
Следовательно, автоматизированная система требует еще наличия силовой проводки. В общем случае (если этого не было сделано ранее для других систем в той же организации) при создании автоматизированной системы необходимо провести силовую проводку, провести слаботочную или оптическую проводку для каналов передачи данных, доставить, смонтировать и подключить технические средства. Разумеется, этой работе будут предшествовать закупки материалов и технических средств. В этой части создание автоматизированной системы представляет собой что-то вроде строительства или ремонта и требует разработки смет, планов расположения оборудования, схем прокладки кабелей и других документов, которыми будут руководствоваться монтажники и техники. В случае сложных автоматизированных систем, в особенности АСУТП, работы по развертыванию комплекса технических средств рассматриваются как строительные и выполняются в соответствии со стандартами серии 21.
Технические средства в рамках автоматизированной системы
Любое устройство (сервер, настольный компьютер, принтер, сканер и т.п.) может рассматриваться нами и как таковое, и как часть определенной автоматизированной системы. Как таковое устройство — это изделие, обладающее определенными техническими характеристиками, определенной конструкцией, определенным набором комплектующих, определенным интерфейсом и т.п.
В этом качестве оно описывается Единой системой конструкторской документации (госты серии 2). Вне зависимости от того, где и с какими целями устройство применяется, его технические характеристики остаются неизменными. Но, если мы включаем устройство в состав конкретной автоматизированной системы, то, с точки зрения эксплуатации, у него появляется ряд дополнительных свойств. Например, скорость печати и емкость картриджа — технические характеристики принтера определенной модели, а необходимость замены картриджа раз в неделю обусловлена количеством выводимых на печать документов и является особенностью его эксплуатации в рамках конкретной автоматизированной системы.
Источник: ru-techwriters.livejournal.com
Зачем улучшать технологии управления требованиями к автоматизированной информационной системе
Требования к автоматизированной информационной системе (АИС), которые позволяют достичь результата при решении какой-либо бизнес-задачи, на практике могут по-разному трактоваться и восприниматься представителями бизнеса и пользователями. О собственном понимании терминологии и наглядной разнице в смыслах рассказал читателям RSpectr функциональный архитектор PROF-IT GROUP Денис Окулов.
ПОЛЬЗОВАТЕЛИ И СТЕЙКХОЛДЕРЫ
Заинтересованных представителей бизнеса, который мы собираемся оцифровывать, автоматизировать, обычно называют стейкхолдерами. Это могут быть, например, шефы производства, финансов, коммерции, логистики и прочих подразделений. Бывает, что в круг стейкхолдеров вносят и акционеров, собственников бизнеса, и клиентов по причине их заинтересованности в конечной автоматизации.
Люди, которые будут использовать информсистему для своей работы или целей, – это пользователи. При этом пользователь может одновременно быть стейкхолдером, если он отвечает за выполнение бизнес-задачи. А если перед ним не стоит такая ответственность, то его основными целями являются удобство и простота цифровых продуктов.
ЧАСТО ПОЛЬЗОВАТЕЛЬСКИЕ ТРЕБОВАНИЯ ТРУДНО ОТДЕЛИТЬ ОТ БИЗНЕС-ТРЕБОВАНИЙ ИМЕННО ПОТОМУ, ЧТО СТЕЙКХОЛДЕРЫ ЯВЛЯЮТСЯ ОДНОВРЕМЕННО И ПОЛЬЗОВАТЕЛЯМИ, И БИЗНЕС-ОТВЕТСТВЕННЫМИ ЗА ЗАДАЧИ
При этом важно понимать, что цели пользователей и стейкхолдеров чаще всего не совпадают.
Пользовательские требования – это то, как себе представляет в идеале работу в АИС пользователь. Обычно эти требования включают в себя не только ответы на вопросы, что и как должна позволять делать система, но и эргономику, и визуальное отображение пользовательского интерфейса.
С другой стороны, есть функциональные требования – это требования к выполнению определенных бизнес-функций в АИС, например, функции казначея или бухгалтера. Обычно описываются очень подробно и детально. Также для большей точности их еще называют функционально-техническими требованиями (ФТТ), но по сути они все равно остаются функциональными требованиями и к чисто техническим их отнести нельзя.
Нефункциональные требования (технические) – это требования к системе как к техническому продукту и его эксплуатации. Например, туда относят доступность системы для пользователя или время отклика на операцию. Чаще это цифры, нежели слова.
ИДЕАЛЬНАЯ МОДЕЛЬ АВТОМАТИЗАЦИИ
Теперь давайте перейдем к модели того, как все это должно работать:
1. Бизнес-вызовы ставят перед стейкхолдерами бизнес-задачи.
2. Бизнес-задачи закрываются реализацией бизнес-требований к новой системе.
3. Бизнес-требования закрываются выполнением функциональных и нефункциональных требований к АИС.
Если все учтено и описано правильно, то мы получаем на выходе положительный результат и выполнение цели автоматизации.
Кто-то из читателей воскликнет: «А где здесь пользовательские требования, забыли про них?!» Все верно, мы про них забыли. Правильно это или нет, тут нужно разобрать поподробнее.
Итак, с точки зрения «оголтелого» бизнеса удобство рядовых пользователей АИС, если это не клиенты, которые приносят жизненно важную выручку, отходит на второй план, потому как за реализацию этих требований платит в конечном счете собственник бизнеса. Более того, реализация такого рода требований зачастую не коррелируется с достижением бизнес-требований и бизнес-задач, а скорее имеет обратное влияние на эффективность.
ДОПОЛНИТЕЛЬНОЕ УДОБСТВО И ЛЕГКОСТЬ ВЫПОЛНЕНИЯ РАБОТЫ НАЕМНЫМИ РАБОТНИКАМИ, КОНЕЧНО, ИМЕЮТ ВАЖНОСТЬ, НО ЦЕННОСТИ БИЗНЕСУ НЕ НЕСУТ САМИ ПО СЕБЕ, А ТОЛЬКО В СВЯЗКЕ С ДРУГИМИ ЭЛЕМЕНТАМИ ЦЕПОЧКИ ДОБАВЛЕНИЯ ЦЕННОСТИ ДЛЯ КЛИЕНТА
Именно поэтому внедренцы на практике стараются не выделять отдельный этап работы по спецификации и реализации пользовательских требований к системе. Однако пользовательские требования не стоит игнорировать как вид вообще, иначе они все равно растворятся в бизнес- или функциональных требованиях, а малоопытные аналитики не смогут их выявить и правильно организовать работу с ними. Далее это приводит к весьма негативным эффектам.
ОЖИДАНИЕ И РЕАЛЬНОСТЬ
На практике вышеописанная модель работает совсем не так, как в теории.
Бизнес-вызовы ставят перед стейкхолдерами бизнес-задачи – с этим все ок.
По мнению заказчика, бизнес-задачи закрываются реализацией бизнес-требований, пользовательских требований, функциональных и нефункциональных требований к системе.
По мнению подрядчика/исполнителя от IТ, бизнес-задачи закрываются реализацией иногда пользовательских требований, чаще функциональных и не всегда нефункциональных требований к системе.
НА ДАННОМ ЭТАПЕ ВОЗНИКАЕТ МНОГО РАЗНОГЛАСИЙ И ПРОТИВОРЕЧИЙ
Бизнес-требования закрываются выполнением функциональных и нефункциональных требований к АИС, но противоречия предыдущего этапа могут не позволить до этого этапа добраться.
Почему же возникает путаница на втором этапе «идеальной» модели работы с требованиями к информационным системам/бизнес-приложениям? Причин, как всегда, сразу несколько.
Во-первых, в стане заказчика будущего решения таким мелочам, как различия между видами требований к будущей информационной системе, не часто придают значение, считая, что это «птичий» айтишный язык.
Во-вторых, нужно понимать, что проектные команды от бизнеса имеют, как правило, «двухголовое» управление – IТ-заказчик и функциональный заказчик. Это накладывает некоторые условности, например, решения по нефункциональным требованиям тяготеют к юрисдикции IТ-заказчика, а по функциональным – функционального заказчика.
В-третьих, команда исполнителя работ по автоматизации также может поставить в один ряд разные виды требований, что сначала дает преимущества по экономии времени и ресурсов, но в конечном счете приводит к неразрешимым противоречиям и путанице.
В-четвертых, зачастую никто не держит в голове, что процесс управления требованиями при внедрении/разработке АИС – это такая постоянная деятельность, которую невозможно ограничить конкретным этапом проекта. У многих складывается впечатление, что достаточно один раз переписать все требования и на этом все закончится. Однако заказчики всегда будут приходить с новыми требованиями, пересмотром старых, и если у вас нет упорядоченности в этом процессе, то управлять изменениями становится трудоемко и конфликтно.
Если на практике возникают аналогичные проектные трудности, то это негативно влияет на цель проекта и снижает удовлетворенность заинтересованных сторон.
С чего можно начать в таких ситуациях? Для начала
НЕОБХОДИМО ЧЕТКО РАЗВЕСТИ ТРЕБОВАНИЯ ПО РАЗНЫМ СЛОЯМ ПРОЕКТНЫХ КОМАНД ЗАКАЗЧИКА
Например, с бизнес-требованиями лучше всего позволят разобраться стейкхолдеры, потому что именно эти люди наиболее заинтересованы в их выполнении.
Функциональные требования лучше фиксировать с фокус-группой из ключевых пользователей будущей АИС, ведь именно они будут потом тестировать будущую систему.
Нефункциональные требования лучше проводить через IТ-заказчика.
Здесь важно не пытаться согласовывать или выспрашивать у функционального заказчика особенности технической стороны реализации тех или иных требований к будущей системе, хотя такие случаи не редкость. И это только один пример инструмента для успешного управления требованиями, а вообще управление требованиями – это целый арсенал, который объединяется в отдельную систему мер в проектной технологии.
Постоянно пересматривать подходы к управлению требованиями в силу причин и обстоятельств, описанных выше, нужно и важно.
Источник: prof-itgroup.ru
Стадия 1. Формирование требований к автоматизированной системе
Главное на этой стадии – провести предпроектное обследование и дать технико-экономическое обоснование целесообразности создания системы. Формируются требования к функциональной части, обеспечивающим подсистемам, методу проектирования.
Обследование – это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для:
· обоснования разработки и поэтапного внедрения систем;
· составления технического задания на разработку систем;
· разработки технического и рабочего проектов систем.
На стадии обследования целесообразно выделить три этапа:
1. определение стратегии внедрения ИС,
2. сбор материалов обследования,
3. анализ материалов обследования.
1. Определение стратегии внедрения ИС. Основная задача первого этапа обследования – оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций.
Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия – получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
По завершении этой стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения).
2. Сбор материалов обследования. Все методы проведения обследования можно объединить в группы по следующим признакам (рис. 2.1):
· метод организации локального проведения обследования, используемый для разработки проекта отдельной задачи или для комплекса задач;
· метод системного обследования объекта, применяемый для изучения всего объекта с целью разработки для него проекта ИС в целом;
- по числу исполнителей, проводящих обследование, применяется:
· индивидуальное обследование, осуществляемое одним проектировщиком;
· бригадное с выделением ряда бригад-исполнителей, изучающих все подразделения предприятия, и одной координирующей бригады;
- по степени охвата предметной области применяют:
· метод сплошного обследования, охватывающего все подразделения экономической системы;
· выборочное обследование, применяемое при наличии типовых по структуре подразделений (например, цехов или складов);
4. по степени одновременности выполнения работ первого и второго этапов предпроектной стадии выделяют:
· метод последовательного проведения работ, при котором проектировщики сначала собирают данные о предметной области, а затем их изучают (часто применяют при отсутствии опыта в выполнении такого рода работ);
· метод параллельного выполнения работ, когда одновременно со сбором происходит изучение полученных материалов обследования, что значительно сокращает время на проведение работ на предпроектной стадии и повышает качество получаемых результатов.
Рисунок 2.1 – Схема классификации методов проведения обследования
Выполнение работ по обследованию предметной области в каком-либо подразделении и сбору материалов можно проводить на основе предварительного проведения выбора методов сбора материалов обследования, которые можно разделить на две группы (рис. 2.2):
· методы сбора, выполняемого силами проектировщиков-исполнителей, включающие методы проведения бесед и опросов, анализа материалов обследования, личных наблюдений, фотографии рабочего дня и хронометража рабочего времени специалиста при выполнении им той или иной работы;
· методы сбора, выполняемого силами специалистов предметной области, которым предлагается либо заполнять тетрадь-дневник на выполняемые ими работы, либо провести документную инвентаризацию рабочего места, либо использовать метод самофотографии рабочего дня, позволяющий выявить состав операций и получаемые при этом документы.
Рисунок 2.2 – Схема классификации методов сбора материалов обследования
Сбор материалов обследования следует проводить с помощью стандартных форм и таблиц, которые удобно читать и обрабатывать (рис. 2.3). Вся получаемая документация разбивается на три группы.
Рисунок 2.3 – Формы документов для формализации материалов обследования
Полученное в результате проведенной формализации описание объекта содержит исходные данные для проектирования ИС и определяет параметры будущей системы.
· инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;
· возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
· функции – информация о событиях и процессах, которые происходят в бизнесе;
· сущности – информация о вещах, имеющих значение для организации и о которых что-то известно.
При изучении каждой функциональной задачи управления определяются:
· сроки и периодичность ее решения;
· степень формализуемости задачи;
· источники информации, необходимые для решения задачи;
· показатели и их количественные характеристики;
· порядок корректировки информации;
· действующие алгоритмы расчета показателей и возможные методы контроля;
· действующие средства сбора, передачи и обработки информации;
· действующие средства связи;
· принятая точность решения задачи;
· трудоемкость решения задачи;
· действующие формы представления исходных данных и результатов их обработки в виде документов;
· потребители результатной информации по задаче.
Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание документооборота организации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить:
· место формирования показателей документа;
· взаимосвязь документов при их формировании;
· маршрут и длительность движения документа;
· место использования и хранения данного документа;
· внутренние и внешние информационные связи;
· объем документа в знаках.
По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки.
На этапе анализа следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации – MuSCoW.
Эта аббревиатура расшифровывается так: Must have – необходимые функции; Should have – желательные функции; Could have – возможные функции; Won’t have – отсутствующие функции.
Функции первой категории обеспечивают критичные для успешной работы системы возможности.
Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками: разрабатывается то, что необходимо, а также максимально возможное в порядке приоритета число функций второй и третьей категорий.
Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.
Модели деятельности организации создаются в двух видах:
· модель «как есть» («as-is») – отражает существующие в организации бизнес-процессы;
· модель «как должно быть» («to-be») – отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.
На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:
· получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;
· разработки плана работ по обеспечению надежности ИС и ее тестирования.
Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в ИС, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.
Результатом стадии «Формирование требований к автоматизированной системе» является документ (технико-экономическое обоснование проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
· ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
· совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;
· сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;
· описание выполняемых системой функций;
· возможности развития системы;
· информационные объекты системы;
· интерфейсы и распределение функций между человеком и системой;
· требования к программным и информационным компонентам ПО, требования к СУБД;
· что не будет реализовано в рамках проекта.
Стадия 2. Разработка концепции автоматизированной системы. Включает научно-исследовательские работы, разработку нескольких вариантов концепции системы и выбор оптимального. Выполняется ориентировочный расчет ожидаемой экономической эффективности и дается оценка научно-технического уровня системы на основании сбора данных об отечественных и зарубежных системах. В заключении оформляется отчет и утверждается концепция.
Стадия 3. Техническое задание. Техническое задание – итог предпроектной работы по созданию ИС. Это документ, обращенный к Исполнителю.
Техническое задание – это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
Главным здесь является состав функциональных задач будущей системы и требования к обеспечивающим подсистемам. Этот документ формируется по материалам первых 2 стадий и составляется в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
При разработке технического задания необходимо решить следующие задачи:
· установить общую цель создания ИС, определить состав подсистем и функциональных задач;
· разработать и обосновать требования, предъявляемые к подсистемам;
· разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);
· установить общие требования к проектируемой системе;
· определить перечень задач создания системы и исполнителей;
· определить этапы создания системы и сроки их выполнения;
· провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
