630_Poletajkin_A.N._Sotsial'nye_iehkonomicheskie_informatsionnye_sistemy_

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

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

классификация субъектов функционирования (категорий и групп работников);

классификация элементов процесса функционирования (действий, процедур);

классификация направлений (решаемых проблем), целей функционирования;

классификация элементов информационных потоков;

проведение обследования деятельности персонала организации;

исследование распределения (по времени и частоте) организационных характеристик: процедур, контактов персонала, направлений деятельности, элементов информационных потоков – по отдельности и в комбинациях друг с другом по категориям работников, видам процедур и их направлениям (согласно результатам и логике исследований);

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

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

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

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

71

альной модели организационной структуры и сравнение ее с декларируемой;

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

Сплошной "фотографией" рабочего времени (рис. 2.3) называется непрерывное наблюдение и регистрация характеристик работников в процессе функционирования в течение всего рабочего дня.

Рис. 2.3. Структура "фотографии" рабочего времени При этом индицируемые параметры последовательно вносятся в заранее

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

номер (по порядку);

агент (должность обследуемого работника);

время, в течение которого выполнялась процедура;

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

содержание (суть процедуры, которая должна быть классифицирована);

информация (направление движения информации между агентом и контрагентом);

инициатива (инициатор начала выполнения данной процедуры);

контрагент (должность работника, который находится с обследуемым в контакте);

отношение (форма взаимодействия, отражающая субординацию агента и контрагента в данной процедуре);

проблема (словесная характеристика решаемой проблемы).

2.2.5 Результаты обследования предметной области

Результатом предпроектного обследования является "Отчет о предпроектном обследовании предприятия" (характеристика объекта информатизации), в состав которого входят такие сведения:

72

1.Краткое схематичное описание бизнес-процессов:

Операции бизнес-процесса

Описание документов бизнес-процесса

2.Основные требования и приоритеты автоматизации.

3.Оценка необходимых для обеспечения проекта ресурсов заказчика.

4.Оценка возможности и целесообразности автоматизации.

5.Предложения по созданию автоматизированной системы с оценкой примерных сроков и стоимости.

Проведение предпроектного обследования позволяет решить следующие

задачи:

предварительное выявление требований к будущей системе;

определение структуры организации;

определение перечня целевых функций организации;

анализ распределения функций по подразделениям и сотрудникам;

выявление функциональных взаимодействий между подразделениями;

выявление информационных потоков внутри подразделений и между ними, внешних информационных воздействий;

анализ существующих средств автоматизации организации.

2.3Особенности жизненного цикла социальных и экономических ИС

2.3.1 Возникновение понятия «Жизненный цикл»

В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования [28]. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры (период времени появления операционных систем), и в настоящее время намного опережает стоимость аппаратуры (рис. 2.4). Тогда и возникла необходимость в разработке технологии программирования, в основу которой было положено понятие о жизненном цикле программного обеспечения.

73

Рис. 2.4. Соотношение между затратами на аппаратную и программную часть

информационной системы

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

Повторное использование кода (модульное программирование).

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

Рост сложности программ (структурное программирование).

Проблема возникла с появлением потребности в сложных программах (системы управления космическими объектами, управления оборонным комплексом, автоматизации крупного финансового учреждения и т.д.). Сложность программ оценивалась следующими показателями:

большой объем кода (миллионы строк);

большое количество связей между элементами кода;

74

большое количество разработчиков (сотни человек);

большое количество пользователей (сотни и тысячи человек);

длительное время использования.

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

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

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

применение специальных языков проектирования и средств автоматизации использования этих языков;

дисциплина проектирования и разработки: планирование и документирование проекта, поддержка соответствия кода проектной документации;

структурное кодирование без использования оператора goto.

Модификация программ (ООП).

Следующая проблема роста стоимости программ была вызвана тем, что изменение требований к программе стали возникать также на стадии проектирования. Это проблема заказчика, который не знает, чего он хочет. Создание программного продукта превратилось в его перманентное перепроектирование. Возник вопрос: как проектировать и писать программы, чтобы обеспечить возможность внесений изменений в программу, не меняя ранее написанного кода?

Решением этой проблемы стало использование объектноориентированного подхода (подробнее об ООП см. подраздел 5.1.3), который стали называть объектно-ориентированным проектированием, а подход к программированию соответственно объектно-ориентированным программированием. Суть данного подхода состоит в том, что вводится понятие класса как развитие понятия модуля с определенными свойствами и поведением, характе-

75

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

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

Таблица 2.1 Основные процессы ЖЦ ПО

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

На сегодняшний день не существует универсального процесса разработки ПО для любых компаний, для команд любой национальности и т.д. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество индивидуальных особенностей. Однако есть и общие моменты. Так, перед началом проекта целесообразно спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), структуру проекта, порядок участия в их разработке членов команды и т.д. В методологии управления ЖЦ это предварительное описание называется конкретным процессом [13]. В системах управления ЖЦ используется шаблон данного процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. Наиболее распространенная подобная система – Microsoft Visual Studio Team System (VSTS) – универсальное решение для управления ЖЦ ПО и командной разработки приложений, позволяет создавать программные системы различного назначения в командах, придерживающихся различных подхо-

дов к управлению процессами разработки ПО. В VSTS существуют заготовки

77

для конкретных процессов на базе различных технологических подходов (CMMI, Scrum и другие подобные подходы будут описаны далее).

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

информацию о средствах разработки (систем версионного контроля, средств контроля ошибок, средств программирования – различных IDE, СУБД и т.д.), в т.ч. правила их использования, документацию и инсталляционные пакеты;

описание практик разработки – проектного менеджмента, правил работы с заказчиком и т.д.;

шаблоны проектных документов – технических заданий, проектных

спецификаций, тестовых планов и пр.

Также возможна стандартизация процедуры разработки конкретного процесса как "вырезки" из стандартного. Основная идея стандартного процесса

– курсирование внутри компании передового опыта, а также унификация средств разработки. Множественность этих средств существенно затрудняет миграцию специалистов из проекта в проект, использование результатов одного проекта в другом и т.д. Однако при организации стандартного процесса необходимо следить, чтобы стандартный процесс не оказался всего лишь формальным, бюрократическим аппаратом. Понятие стандартного процесса введено и подробно описано в подходе CMM/CMMI (Capability Maturity Model – модель зрелости возможностей создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение), CMMI (Integration – обобщающий стандарт).

2.3.2 Модели процесса разработки ПО

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

ства [13]:

происходит быстрая смена технологий разработки ПО, требуется изучение и внедрение новых средств разработки;

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

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

При этом возможны следующие практические решения, улучшающие производственный процесс компании-производителя ПО:

78

1)переход на новые средства разработки, языки программирования и т.д.;

2)улучшение отдельных управленческих и инженерных практик – тес-

тирования, управления требованиями и пр.;

3)полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI);

4)сертификация компании (CMM/CMMI, ISO 9000 и пр.).

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

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

ствования процессов разработки CMMI [18].

В числе прочих средств совершенствования процесса создания ПО цен-

тральное место занимают модели данного процесса. Модель процесса разра-

ботки ПО – это упрощенное описание программного процесса, представленное с некоторой точки зрения [13]. Модель задается в виде практических этапов, необходимых для создания ПО. Выбор модели процесса является первым шагом в создании ПО. Правильный выбор модели очень важен, т.к. во многом определяет успех проекта. Выбор "тяжелых" процессов может "утопить" проект, а слишком легкое отношение к процессам – к потере контроля над ходом выполнения. В соответствии с двумя типами процессов – основных и дополнительных

– можно говорить о двух типах моделей процесса: модели процесса разработки

(модели жизненного цикла) и модели организации работ по выполнению разработки.

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

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

Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением. На первом

79

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

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

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

кода описанным требованиям.

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

Ко второму типу моделей – моделей организации работ – относятся:

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

Модель потоков данных – представляет процесс в виде последовательного преобразования данных. Каждое преобразование может выполняться в одно или несколько действий.

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

2.3.3 Жизненный цикл информационных систем

Применительно к ИС понятие жизненного цикла (ЖЦ ИС) выглядит следующим образом. Это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации [11].

Основным нормативным документом, регламентирующим структуру ЖЦ ИС, является международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация по стандартиза-

ции, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены за период существования

ИС.

80