Требования, предъявляемые к информационным системам
Способность к адаптации и дальнейшему развитию подразумевают возможность приспособления информационной системы к новым условиям, новым потребностям предприятия.
Требование надёжности обеспечивается созданием резервных копий хранимой информации, выполнения операций протоколирования, поддержанием качества каналов связи и физических носителей информации, использованием современных программных и аппаратных средств.
Эффективность
Система является эффективной, если с учётом выделенных ей ресурсов она позволяет решать возложенные на неё задачи в минимальные сроки. Эффективность системы обеспечивается оптимизацией данных и методов их обработки, применением оригинальных разработок, идей, методов проектирования.
Безопасность
Под безопасностью, прежде всего, подразумевается свойство системы, в силу которого посторонние лица не имеют доступа к информационным ресурсам организации, кроме тех, которые для них предназначены. Требование безопасности обеспечивается современными средствами разработки информационных систем, современной аппаратурой, методами защиты информации, применением паролей и протоколированием, постоянным мониторингом состояния безопасности операционных систем и средств их защиты.
Понятие проекта
Проект это ограниченное по времени целенаправленное изменение отдельной системы с изначально чётко определёнными целями, достижение которых означает завершение проекта, а также с установленными требованиями к срокам, результатам, риску, рамкам расходования средств и ресурсов, организационной структуре.
Можно выделить следующие основные отличительные признаки проекта как объекта управления: ограниченность конечной цели; ограниченность продолжительности; ограниченность бюджета; ограниченность требуемых ресурсов; новизна для предприятия, для которого реализуется проект; комплексность; правовое и организационное обеспечение.
Рассматривая планирование проектов и управление ими, необходимо чётко осознавать, что речь идёт об управлении неким динамическим объектом. Поэтому система управления проектом должна быть достаточно гибкой, чтобы допускать возможность модификации без глобальных изменений в рабочей программе. Выполнение работ обеспечивается наличием необходимых ресурсов: материалов; оборудования; человеческих ресурсов. С точки зрения теории систем управления проект как объект управления должен быть наблюдаемым и управляемым, то есть выделяются некоторые характеристики, по которым можно постоянно контролировать ход выполнения проекта. Кроме того, необходимы механизмы своевременного воздействия на ход выполнения проекта.
Для обоснования целесообразности и осуществляемости проекта, анализа хода его реализации, а также для заключительной оценки степени достижения поставленных целей проекта и сравнения фактических результатов с запланированными проектами существует ряд характеристик проекта:
— экономическая эффективность, обеспечиваемая реализацией проекта
Проекты классифицируются по самым различным признакам.
Класс проекта определяется по составу и структуре проекта. Обычно различают два класса:
Монопроект — отдельный проект, который может быть любого типа, вида и масштаба.
Мультипроект — комплексный проект, состоящий из ряда монопроектов и требующий мультипроектного управления.
Тип проекта определяется по основным видам деятельности, в которых осуществляется проект:
Масштаб проекта определяется размером бюджета и количеством участников:
Какие требования предъявляются к информационным системам
Статья 13. Информационные системы
1. Информационные системы включают в себя:
1) государственные информационные системы — федеральные информационные системы и региональные информационные системы, созданные на основании соответственно федеральных законов, законов субъектов Российской Федерации, на основании правовых актов государственных органов;
2) муниципальные информационные системы, созданные на основании решения органа местного самоуправления;
3) иные информационные системы.
2. Если иное не установлено федеральными законами, оператором информационной системы является собственник используемых для обработки содержащейся в базах данных информации технических средств, который правомерно пользуется такими базами данных, или лицо, с которым этот собственник заключил договор об эксплуатации информационной системы. В случаях и в порядке, установленных федеральными законами, оператор информационной системы должен обеспечить возможность размещения информации в сети «Интернет» в форме открытых данных.
(в ред. Федерального закона от 07.06.2013 N 112-ФЗ)
(см. текст в предыдущей редакции)
2.1. Технические средства информационных систем, используемых государственными органами, органами местного самоуправления, государственными и муниципальными унитарными предприятиями или государственными и муниципальными учреждениями, должны размещаться на территории Российской Федерации. Операторы государственных информационных систем, муниципальных информационных систем, информационных систем юридических лиц, осуществляющих закупки в соответствии с Федеральным законом от 18 июля 2011 года N 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц», не должны допускать при эксплуатации информационных систем использования размещенных за пределами территории Российской Федерации баз данных и технических средств, не входящих в состав таких информационных систем.
(часть 2.1 введена Федеральным законом от 31.12.2014 N 531-ФЗ; в ред. Федерального закона от 01.05.2019 N 90-ФЗ)
(см. текст в предыдущей редакции)
С 01.09.2024 ст. 13 дополняется ч. 2.1-1 и 2.1-2 (ФЗ от 31.07.2023 N 406-ФЗ).
2.2. В случае создания или модернизации информационной системы на основании концессионного соглашения, соглашения о государственно-частном партнерстве или соглашения о муниципально-частном партнерстве функции оператора информационной системы в пределах, в объемах и в сроки, которые предусмотрены соответствующим соглашением, осуществляются концессионером или частным партнером соответственно.
(часть 2.2 введена Федеральным законом от 29.06.2018 N 173-ФЗ; в ред. Федерального закона от 29.12.2022 N 604-ФЗ)
(см. текст в предыдущей редакции)
2.3. Государственные органы, органы местного самоуправления, государственные и муниципальные унитарные предприятия, государственные и муниципальные учреждения при осуществлении взаимодействия в электронной форме, в том числе с гражданами (физическими лицами) и организациями, обязаны обеспечивать возможность осуществления такого взаимодействия в соответствии с правилами и принципами, установленными национальными стандартами Российской Федерации в области криптографической защиты информации, утвержденными в соответствии с Федеральным законом от 29 июня 2015 года N 162-ФЗ «О стандартизации в Российской Федерации».
(часть 2.3 введена Федеральным законом от 01.05.2019 N 90-ФЗ)
С 01.09.2024 ст. 13 дополняется ч. 2.4 (ФЗ от 31.07.2023 N 406-ФЗ).
3. Права обладателя информации, содержащейся в базах данных информационной системы, подлежат охране независимо от авторских и иных прав на такие базы данных.
4. Установленные настоящим Федеральным законом требования к государственным информационным системам распространяются на муниципальные информационные системы, если иное не предусмотрено законодательством Российской Федерации о местном самоуправлении.
5. Особенности эксплуатации государственных информационных систем и муниципальных информационных систем могут устанавливаться в соответствии с техническими регламентами, нормативными правовыми актами государственных органов, нормативными правовыми актами органов местного самоуправления, принимающих решения о создании таких информационных систем.
6. Порядок создания и эксплуатации информационных систем, не являющихся государственными информационными системами или муниципальными информационными системами, определяется операторами таких информационных систем в соответствии с требованиями, установленными настоящим Федеральным законом или другими федеральными законами.
7. Порядок осуществления контроля за соблюдением требований, предусмотренных частью 2.1 настоящей статьи и частью 6 статьи 14 настоящего Федерального закона, устанавливается Правительством Российской Федерации.
Как правильно сформировать требования к ИТ-системе
На примере рассказываем, каким образом можно формулировать требования, и показываем примеры документов, которые можно использовать при составлении требований. Статья будет полезна людям, которые пытаются разобраться в способах построения IT-инфраструктуры предприятия.
За 7 лет разработки и внедрения индивидуальных IT-систем на нашей платформе Бипиум мы столкнулись с множеством крупных и не очень крупных предприятий. Каждое находилось на определенном этапе развития цифровой грамотности. Кто-то формулирует требования профессионально, у кого-то получается не очень профессионально. Мы хотим помочь вторым разобраться в теме и научить их понимать цель внедрения IT-системы.
Статья большая, поэтому держите оглавление:
В понятие «требования к информационной системе» можно вложить несколько смыслов. Первое определение требований — комплексное описание того, как информационная система повлияет на работу компании. Второе определение требований — описание желаемого поведения системы при ее использовании участниками деятельности. Требования нужны, чтобы и вы, и разработчик системы понимали, что должно получиться в итоге.
Оба тезиса применимы к цифровизации уже существующей деятельности и цифровизации планируемой.
Бывают случаи, когда заказчик приходит на встречу с разработчиком не подготовив требования и начинает импровизировать. В таком случае получается хаотичный набор информации, из которого нельзя собрать что-то конкретное. Из-за этого, либо стоимость разработки увеличивается в разы, либо система не решает глобальную проблему.
Рассмотрим на примере процесса заключения договора с клиентом.
Опишите контекст, в котором находится компания и автоматизируемую деятельность. Например, нужно описать, что в заключении договора несколько сотрудников выполняют определенные операции, что эти операции несут следующий бизнес смысл, который объединяется в определенный результат.
Используя наш пример с заключением договора, можно описать следующее:
«Наша компания занимается производством молочной продукции. Для реализации продукции мы заключаем договоры с оптовыми покупателями. У нас большое количество потенциальных покупателей, отдел продаж слишком долго формирует и подписывает договоры.
Автоматизируемая деятельность выглядит следующим образом: менеджер формирует и подписывает с заказчиком договор, передает договор в бухгалтерию для выставления счета».
Осмыслите проблемы, которые заставили вас думать об автоматизации. Это могут быть как конкретные кейсы, так и описание того, что затрудняет работу.
«Первая проблема — менеджеры не используют актуальный шаблон договора, потому что нет единого места, где хранится такой шаблон. Из-за этого наша компания может понести финансовые убытки.
Вторая проблема — менеджеры долго формируют данный договор, подставляя данные во все нужные поля.
Третья проблема — договоры долго доходят до бухгалтерии, из-за этого процесс получения денег сильно затягивается.
Четвертая проблема — менеджеры приходят/звонят в бухгалтерию, чтобы уточнить статус договора и денег, а это отвлекает бухгалтеров и сильно замедляет работу».
Сформулируйте цель создания системы. Система может регламентировать деятельность, сократить время на подготовку документов или что-то иное.
«Мы хотим организовать учет всех договоров, чтобы они не терялись.
Мы хотим ускорить процесс формирования договора, в идеале — формировать его автоматически.
Мы хотим прогнозировать загруженность рабочего времени сотрудников».
В итоге у вас получится формализованный документ, с которого можно начинать думать над изменениями.
После выяснения причин и целей автоматизации вам нужно понять кто будет участником деятельности.
Выделите всех участников процесса и определите, что они делают в бизнес-деятельности и что они будут делать в информационной системе. Бизнес-деяетельность — это фактические рабочие действия человека, «отправить документ», «подписать документ» и т.д.
Чтобы описать бизнес-деятельность участников, надо общаться с каждым. Это поможет понять проблемы каждого человека и детаельнее описать сценарии использования системы.
В нашем примере мы можем выделить трех участников — покупатель, менеджер и бухгалтер. Описание деятельности данных ролей может выглядеть следующим образом:
Покупатель. Оставляет запрос на предоставление некоторого количества товара, подписывает договор, оплачивает счет.
В системе: не выполняет никаких операций
Менеджер. Общается с покупателем, заключает договор с покупателем, предоставляет информацию в бухгалтерию, контролирует статус сделки.
В системе: формирует договор, загружает подписанный скан для бухгалтерии.
Бухгалтер. Ведет учет обязательств покупателей и перед покупателями.
В системе: меняет статус, отображающий состояние сделки, прикладывает к сделке документы — счета и акты.
С деятельностью и информационной системой связаны не только люди. С ней могут быть связаны еще и другие системы и сервисы.
Вам требуется понять, что задействовано в автоматизируемой деятельности. Например, это может быть телефония, 1С и электронная почта.
После того, как выяснили, что вы используете, надо подумать над тем, хотите ли вы интегрировать эти системы между собой, и если да, то какой результат должен быть. Это может помочь отказаться от использования продукта, который будет дублировать функции.
Продолжая рассматривать наш пример, давайте опишем взаимодействия систем:
Телефония. Необходимо настроить возможность принимать и осуществлять звонки из информационной системы, данная возможность должна быть только у менеджеров. Так же необходимо хранить записи разговоров, чтобы руководитель мог их прослушивать для оценки качества.
Почта. Необходимо, чтобы при формировании договора, система автоматически отправляла сгенерированный договор покупателю для ознакомления.
1С. С данной системой нет необходимости интегрироваться на данном этапе. В будущем возможно информационная система будет выступать источником сигналов, о полученных платежах по контрактам.
Если сформулируете требования некорректно или не полностью, то полученный вами продукт не будет соответствовать ожиданиям и вместо упрощения деятельности усложнит её.
Например, выше мы указали, что доступ к звонкам в системе имеет только менеджер. Если бы мы не указали этого, то звонки поступали бы не только им, а еще и в бухгалтерию, что сильно отвлекало бы бухгалтеров от работы и замедляло бы темп отдела.
Другим примером может быть следующее: вы можете запланировать, что будете работать по определенному алгоритму, который вы придумали, но в ходе реализации системы, решили поменять деятельность сотрудников, не проинформировав разработчиков. В данной ситуации вы попадаете на деньги и время, ведь вероятно придется переделывать функционал полностью.
Частая проблема при формулировании требований — погружение на уровень отдельных действий, внешнего вида или цвета кнопок в системе. Уделяя слишком много времени тому, как будет выглядеть та или иная кнопка, вы отдаляетесь от цели создания системы.
Всегда помните, что вы формулируете требования, а не пишите техническое задание по ГОСТу. Не надо писать слишком формальным языком, поскольку с требованиями будет знакомится такой же живой человек как и вы.
Важно формулировать мысли понятно и стараться избегать слишком поверхностного описания. В таком случае придется потратить время на разъяснение пунктов разработчикам.
Другой проблемой может быть, когда вы совмещаете уровень «кнопочек» и максимально широкое описание функционала. Например, заказчик говорит, что хочет нажать на кнопку и «увидеть всё». Но он сам не понимает, что имеет в виду под этим «всё».
Требования, предъявляемые к информационным системам
Информационная система должна соответствовать требованиям гибкости, надежности, эффективности и безопасности.
Гибкость
Гибкость, способность к адаптации и дальнейшему развитию подразумевает возможность приспособления информационной системы к новым условиям, новым потребностям предприятия. Выполнение этих условий возможно, если на этапе разработки информационной системы использовались общепринятые средства и методы документирования, так что по прошествии определенного времени сохранится возможность разобраться в структуре системы и внести в нее соответствующие изменения, даже если все разработчики или их часть по каким-либо причинам не смогут продолжить работу.
Любая информационная система рано или поздно морально устареет, и станет вопрос о ее модернизации или полной замене. Разработчики информационных систем, как правило, не являются специалистами в прикладной области, для которой разрабатывается система. Участие в модернизации или создании новой системы той же группы проектировщиков существенно сократит сроки модернизации. Вместе с тем возникает риск применения устаревших решений при модернизации системы. Рекомендация в таком случае одна — внимательнее относиться к подбору разработчиков информационных систем.
Надежность
Надежность информационной системы подразумевает ее функционирование без искажения информации, потери данных по «техническим причинам». Требование надежности обеспечивается созданием резервных копий хранимой информации, выполнения операций протоколирования, поддержанием качества каналов связи и физических носителей информации, использованием современных программных и аппаратных средств. Сюда же следует отнести защиту от случайных потерь информации в силу недостаточной квалификации персонала.
Эффективность
Система является эффективной, если с учетом выделенных ей ресурсов она позволяет решать возложенные на нее задачи в минимальные сроки. В любом случае оценка эффективности будет производиться заказчиком, исходя из вложенных в разработку средств и соответствия представленной информационной системы его ожиданиям.
Негативной оценки эффективности информационной системы со стороны заказчика можно избежать, если представители заказчика будут привлекаться к проектированию системы на всех его стадиях. Такой подход позволяет многим конечным пользователям уже на этапе проектирования адаптироваться к изменениям условий работы, которые иначе были бы приняты враждебно.
Активное сотрудничество с заказчиком с ранних этапов проектирования позволяет уточнить потребности заказчика. Часто встречается ситуация, когда заказчик чего-то хочет, но сам не знает чего именно. Чем раньше будут учтены дополнения заказчика, тем с меньшими затратами и в более короткие сроки система будет создана.
Кроме того, заказчик, не являясь специалистом в области разработки информационных систем, может не знать о новых информационных технологиях. Контакты с заказчиком во время разработки для него информационной системы могут подтолкнуть заказчика к модернизации его аппаратных средств, применению новых методов ведения бизнеса, что отвечает потребностям, как заказчика, так и проектировщика. Заказчик получает рост эффективности своего предприятия, проектировщик — расширение возможностей, применяемых при проектировании информационной системы.
Эффективность системы обеспечивается оптимизацией данных и методов их обработки, применением оригинальных разработок, идей, методов проектирования.
Не следует забывать и о том, что работать с системой придется обычным людям, являющимся специалистами в своей предметной области, но зачастую обладающим весьма средними навыками в работе с компьютерами. Интерфейс информационных систем должен быть им интуитивно понятен. В свою очередь, разработчик-программист должен понимать характер выполняемых конечным пользователем операций. Рекомендациями в этом случае могут служить повышение эффективности управления разработкой информационных систем, улучшение информированности разработчиков о предметной области.