BoatmansHome: АвтоматизированныеСистемы/КакОниЕсть ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Ниже о проблемах, вызванных незнанием, сознательным искажением или игнорированием сути АС. А так же, почему, даже если вы создаете всего лишь программные продукты, все равно придется думать об автоматизированных системах.
Если коротко, то автоматизированная система (АС) – это (согласно ГОСТ 34.003) система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.


Оглавление

Все сложно

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


Перед тем как делать любой ИТ проект неплохо было бы договориться в команде и со всеми заинтересованными лицами вне проекта, какого класса продукт мы поставляем:


А ведь существуют еще:


И, наконец, если порыться в западных стандартах, добавятся:


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

Немного определений

Однако, давайте посмотрим на определения и увидим, как плавают границы понятий.
Источниками определений служат ГОСТ 34, ГОСТ 19, официальные переводы ИСО/МЭК, неофициальные переводы ИСО/МЭК, по крайней мере один ФЗ РФ и словари.


Автоматизированная система (АС) – это (согласно ГОСТ 34.003) система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций (это уже обсуждалось здесь).


Информационная система (ИС) – это (согласно ФЗ № 149-ФЗ от 27 июля 2006 г., Ст 2., п.3.) совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий (трактуемых, как «процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов», там же п.2.) и технических средств. С точки зрения логики это определение логически не корректное, но что есть – то есть.

Тут, правда, есть тонкость: понятие «информационная система» определяют по крайней мере еще два стандарта (ISO/IEC 2382–1 и ГОСТ РВ 51987) и каждый делает это чуть по своему, что несколько размывает границы понятия в реальной практике.
Ну и, конечно, википедия не добавляет четкости, предлагая еще пару толкований.
Если вчитаться в определения, например можно увидеть, что АС (ГОСТ 34)!=ИС (ФЗ), но практически АС (ГОСТ 34)==ИС (ISO/IEC 2382–1)
Вот и представьте себе совещание команды на старте проекта, где у каждого в контексте свое определение. Обычно оно плавно перерастает в ожесточенный спор. Кто-то начинает говорить о бизнес-процессах, изх показателях, оргструктуре и методических решениях. Кто-то другой думает, что надо просто собрать требования с пользователей и написать, что они сказали, приемо-сдав на тестовом сервере. Кто-то считает, что в зоне ответственности команды будет интеграция, миграция и закупка «боевого» железа, а других это приводит в ужас. Не говоря уже о том, что ключевых заказчиков о рамках того, что они ждут на выходе, скорее всего и не спрашивали. Чего там, ИТ – они и в Африке ИТ.
В зависимости от выбранного определения системы и тонкой подстройки рамок бюджет проекта и длительность могут увеличиваться или уменьшаться на порядок.

Программное средство – стандартами не определяется, но есть словарь: Термин П. с. ЭВМ используется для обозначения любой программы, или последовательности логических команд, к-рая предписывает аппаратным средствам выполнить последовательность действий, необходимых для решения определенной задачи.


Программное изделие АС – (согласно ГОСТ 34.003) программное средство, изготовленное, прошедшее испытания установленного вида и поставляемое как продукция производственно-технического назначения для применения в АС;


Программное обеспечение АС – (согласно ГОСТ 34.003) совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС.


(Программный) компонент – (согласно ГОСТ 19.101) программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса.


Программная комплекс – (согласно ГОСТ 19.101) программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса.


Программный продукт – (согласно ГОСТ Р ИСО/МЭК 12207–99) набор машинных программ, процедур и, возможно, связанных с ними документации и данных;


Программно-аппаратный/программно-технический комплекс (такого термина официально тоже нет), но есть Комплекс средств автоматизации АС – (по ГОСТ 34.003) совокупность всех компонентов АС, за исключением людей.


Все виды обеспечения являются компонентами АС наряду с персоналом и определены (кроме инженерного) в ГОСТ 34.003.


Информационный продукт не имеет определения в ГОСТ, но есть словарь: «документированная информация, подготовленная в соответствии с потребностями пользователей и представленная в форме товара».


Зато в ГОСТ 34.003 есть следующее:


Драма со всем программным и информационным кроется в разном понимании итогового качества (а значит, и в разном составе работ и бюджете проекта):

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


Драма с использованием слов система и комплекс кроется в разнице между:

И опять здесь большие отличия в составе работ и бюджете проекта.


И есть еще калька Сервис, которое в Документ PDFглоссарии ITIL переведено, как Услуга. И определено, как «Способ предоставления ценности заказчикам через содействие им в получении конечных результатов, которых Заказчики хотят достичь без владения специфическими затратами и рисками. Термин «услуга» может использоваться для обозначения основной услуги, ИТ-услуги или пакета услуг.»


В итоге, на сегодняшний день, лучше не опираться на «страшные слова» и всегда уточнять состав, рамки и точные свойства «той штуки, о которой мы все сейчас с вами говорим».

Картина в целом

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


Картинка же на самом деле достаточно проста. Вот она:


file:as1.png


Однако, подкрутив приближение, это выглядит уже вот так:


file:as.png


На картинке показаны только самые частые пересечения понятий (абсолютно все возможные связи не влезли) – это компоненты АС (зеленый потемнее) и основные работы, необходимые для создания АС (зеленый посветлее).
Разная обводка контуров показывает качественную разницу между объемами проектов по построению автоматизированной системы (вся картинка), информационной системы (красный контур), программного продукта (голубой контур).


Как получается, что проектные команды вместе с заказчиками до последнего момента путают, что же мы строим на самом деле. Есть разные варианты:

Как прострелить себе ногу, уменьшая рамки ИТ проекта

Еще одна разница, которая заключается в границах ответственности систем и их взаимосвязи.
Главный фокус в картинке ниже:


file:as_vs_pp.png


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

  1. Для автоматизированной системы (верхний уровень на картинке) мы смотрим на цепочку прибавленной стоимости (или просто деятельнсть пользоавателей) в целом. В ней выделяем объект автоматизации – это участки деятельности, показатели которых мы будем повышать автоматизацией. Внутри этой деятельности (человеко-машинная) система будет выполнять свои функции.
    • объект исследования – деятельность пользователей в целом, и более глубоко – объект автоматизации – улучшаемые участки деятельности, с их бизнес-значимыми результатами и всеми остальными деталями.
    • основные объекты концептуального проектирования (но не все):
      • информационная технология – состав обращаемой информации, направления и последовательность информационного оборота;
      • методические и организационные решения – кто участвует в обороте информации, как люди и исполнительные устройства интерпретируют получаемую информацию, когда и как получаемая людьми и устройствами информация запускается в автоматизированные средства.
    • цели и ответственность системы – повышение показателей деятельности, видимых с уровня бмзнеса и менеджмента, что в теории дает подход к ТЭО.
  2. Для информационной системы (средний уровень на картинке) мы смотрим на вводимую и выводимую информацию, а так же на то, что должно происходить между ввводом и выводом. Причем, определение системы из ФЗ говорит об оперировании информацией, но если разобраться, ИС в определении ФЗ может оперировать только данными, так как информация из данных получается лишь при наличии людей с их контекстом. Качество определения из ФЗ создает размытость рамок ИС от широких «информация на входе и выходе» до узких «данные на входе и выходе». Разницу можно увидеть н картинке.
    • объект исследования – информационная технология, как она есть – то есть информационная технология для создания ИС должна быть задана на вход проекту.
    • основные объекты концептуального проектирования – ключевые алгоритмы и концептуальная программно-аппаратная архитектура хранения, ввода/вывода, передачи и обработки данных (не информации).
    • цели и ответственность системы – корректная реализация информационной технологии на территории заказчика.
  3. Для программного продукта (нижний уровень) мы смотрим на требования по вводу/выводу, обработке и хранению данных.
    • объект исследования – данные на входе и выходе, ключевые алгоритмы и сценарии обработки, описание окружения;
    • основные объекты концептуального проектирования – алгоритмы, концептуальная программная архитектура;
    • цели и ответственность – правильная реакция на входные воздействия в оговоренной окружающей среде (например, на тестовом стенде).

Видно, что со снижением уровня от АС к программному продукту ответственность понижается, объем и ширина зоны исследования и принятия решений тоже снижаются. Это часто становится ловушкой для начинающих менеджеров и проектных команд.
Дело в том, что требования и исходные данные к проектированию следующего уровня являются результатами от работ с предыдущего уровня.
Все это бесконечное нытье о том, что входящие требования имеют низкое качество, да еще и меняются, заказчики и пользователи не знают, чего хотят, а написанными программами никто не пользуется, в большом количестве случаев является прямым следствием провисания ответственности за проектные решения предыдущего уровня.
Часто команда делает ставку на то, что можно будет снять все требования с пользователей и аккуратно их выполнить, оперируя на уровне создания программного продукта или информационной системы. Но выходит, что информационная технология и/или алгоритмы и другие ключевые требования для программного продукта должны быть спроектированы – их никто не может рассказать от и до. А на проектирование не заложено ни сроков, ни бюджета, ни соответствующих работ в плане, ни обязательств заказчика по вовлечению специалистов и принятию соответствующих решений.

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

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


 
Много файлов (3).[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]