Информационно-вычислительные системы в машиностроении CALS-технологии (Соломенцев, 2003)

Рис.3.17. Компоненты процесса создания программного продукта с помощью ИКС. L1 - язык требований; L2F - язык спецификаций ИКС; L5F - язык взаимодействия пользователя с программой; L6 - язык машинных кодов

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

•деление на объекты обеспечивает модульность системы;

•переменные являются характеристиками объектов предметной области;

•нет жесткого деления переменных на входные и выходные.

2.Исключение из процесса разработки программного обеспече­ ния профессиональных программистов позволяет:

•уменьшить время разработки программного продукта в 10-15 раз;

•уменьшить число ошибок и сократить время отладки;

•упростить сопровождение и модификацию программы.

3.Исходная спецификация является одной из основных состав­ ляющих документации на программу.

3.4.2. Источники формирования требований к ПО

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

Любая разработка, в том числе и программного обеспечения для предприятия в целом, начинается с формирования требований. Соб­ ственно требования к программно-информационной системе

предприятия формируются из целей бизнеса, определяемых руковод­ ством, существующих технических процессов, накопленного опыта, навыков и т.д. (рис.3.18). Использование на рис.3.18 овалов, выхо­ дящих за требования к программно-информационному обеспечению предприятия, может быть интерпретировано следующим образом. В случае 2 это та плата предприятия за покупку стандартного (чаще всего «коробочного») программного обеспечения, которое вряд ли когда-нибудь в полном объеме сможет применяться на конкретном рабочем месте. Случай 3 указывает на то, что абсолютно все техниче­ ские процессы предприятия вряд ли когда-либо будут автоматизиро­ ваны в полном объеме. Как показывает практика, цена каждого по­ следующего процента при приближении к 100 % автоматизации резко возрастает. Случай 4 отражает некоторые психологические факторы, связанные с тем, что с накопле1П1ым программно-информационным багажом возможно частично придется расстаться, т.е. этим отражает­ ся ситуация «когда хранить уже накладно и выбросить жалко».

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

Программное обеспечение предприятия

Базовое программноинформационное обеспечение:

а) операционные системы: Windows, UNIX и т.д.

б) СУБД в) графические пакеты

г) стандарты ППП

д) поддержка ЛВС

Рис.3.18. Источники формирования требований к программному обеспечению предприятия

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

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

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

3.4.3. Причины появления искажения требований к АС

Далее до конца главы использованы материалы из «Computer Week» и Интернет. Почти в каждом проекте возникают ситуации сле­ дующего типа. Заказчик что-то считает для себя очевидным и поэто­ му даже не упоминает об этом. Разработчик так же молча «обходит» часть требований как абсурдные или же «неудобные». В ходе проек­ тирования сплошь и рядом одни защищают какие-то требования, дру­ гие говорят о них как о невыполнимых или безграмотных. Что и как надо сделать, чтобы противоречивые точки зрения, упущения и умол­ чания не исказили создаваемую АС? Как организовать выполнение работы по созданию АС, чтобы в результате последтшя не была оттор­ гнута потребителем или бесконечно долго не «доводилась до ума» под встречные упреки заказчика и исполнителя?

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

Другие уверены, что дело «компьютерщиков» (включая программи­ стов, сетевиков, проектировщиков баз данных и других специали­ стов) - сразу предоставить работающую автоматизированную систе­ му в ответ на задание, которое выскажет заказчик. Первая точка зре­ ния очень распространена среди исполнителей. Вторая свойственна заказчикам, относящимся к разработчику, как капризный клиент к портному: «Я плачу деньги, а ты сделай, чтобы мне было хорошо. И без лишних вопросов и примерок». Но и то и другое ведет к искаже­ ниям требований.

Вот почему в последнее время при создании больших автомати­ зированных систем появилась новая группа специалистов-аналити­ ков и их многочисленных «разновидностей». Ответу на вопросы ПО­ ЧЕМУ и КАК они должны сегодня выполнять ключевую роль в по­ строении АС и посвящена настоящая часть работы.

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

Источники искажений, возникающих при создании больших ав­ томатизированных систем, показал Э.Х.Тыугу на предельно про­ стой, но очень полезной модели. В идеальном варианте модели пока­ заны ситуации, в которых возникают искажения восприятия основ­ ных участников проекта создания АС: «заказчика» и «исполнителя» (рис.3.19). На взгляд каждого из них проблемы другой стороны вид­ ны «издалека». При этом чужое становится мелким, а отчетливо вид­ ны детали только своих проблем.

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

Из приведенных моделей видно, что задача выработки общего подхода к созданию АС по разному стоит перед заказчиком и испол­ нителем. Особенно остро она проявляется в подходах к организации корпоративной разработки и управления изменениями АС при реали­ зации проекта совместными усилиями.

создании АС: заказчику нужна эффективная и сегодня работаю­ щая АСу а исполнителю - реализация АС, не противоречащая усло­ виям договора и технического задания.

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

•технологии разработки программного обеспечения заказчика и исполнителя разные;

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

•заказчик собственными силами осуществляет сопровождение и модификацию АС, созданную исполнителем.

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

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

3.4.4. Аналитик по техническим процессам

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

Обычно перед аналитиком по техническим процессам стоит ди­ лемма участия в двух тесно взаимосвязанных пластах деятельности предприятия: технологическом и социально-руководящем. В

Аналитик по техническим Архитектор

процессам АС

Выделение и представление:

-объектов

-модели деятельности

-среды, в которой протекает эта деятельность

Рис.3.21. Расширенный вид модели Тыугу

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

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

От аналитика не требуется обязательного освоения формальных языков и моделей (таких как модель потоков данных или UML - «унифицированный язык моделирования»). Он может использовать формализмы, но только для более точного описания внешних требо­ ваний к АС, а не для принятия решений в проектировании «компью­ терной» части системы. Аналитик может и часто должен формиро­ вать не только постановки отдельных задач, но и целостную модель автоматизированного предприятия. Однако он строит такую модель на верхних уровнях архитектурного представления автоматизиро­ ванной системы, в то время как CASE-модели лежат ниже.

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

3.4.5. Архитектор АС

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

Архитектор создает целостный «логический» проект АС, в кото­ ром еще не производится выбор конкретных компьютеров, СУБД, инструментов программирования и т.д. Главное здесь то, что он ви­ дит и описывает архитектуру АС в целом, объединяя все ее «слои» -- от людей и целей до данных и функций.

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

Архитектор - сотрудник специализированного «компьютерного» подразделения или фирмы. Он владеет формальными моделями. Он обязан оценивать эффективность своих решений и присущий им риск. Главное здесь то, что он представляет коллектив разработчиков АС перед заказчиком. Он проверяет решения вместе с аналитиками и пользователями, он объясняет возможности АС первым лицам заказ­ чика, защищает ее на совещаниях.

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

238 Глава 3. Опыт применения CALS-технологий

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

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

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

3.4.6. Типовые подходы и типичные проблемы

Методология построения АС содержит три основные составляю­ щие.

•Набор моделей (если строго, то типов моделей) для описания требований к АС, проектных и программных решений. Каж­ дая модель обычно содержит средства для определения конст­ рукций (нотацию) и правила их использования (синтаксис).

•Методика применения набора моделей для построения АС

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

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

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

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

Структурная методика обычно предполагает наличие пяти компонентов.

•Диаграмма потоков данных/модель технических - процессов (Data Flow Diagram/Business Process Model) была предло­ жена в конце 1970-х годов как средство описания процессов об­ работки информации. Основные элементы модели: процесс, поток и хранилище, представляющие соответственно обработ­ ку, передачу и хранение данных (или материальных объек­ тов). Контекст работы автоматизированной системы представ­ лен с помощью внешних сущностей. В настоящее время эту мо­ дель используют в основном для описания технических про­ цессов (производственной деятельности).

•Диаграмма «сущность - связь» (Entity Relationship Diag­ ram) была предложена в середине 1970-х годов как средство описания информационной модели предметной области, не привязанное к инструментам реализации структур хранения данных в автоматизированной системе. Элементы модели: сущность и связь, представляющие типы объектов предметной области и их отношения.

•Диаграмма переходов состояний (State Transition Diagram) в

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

•Структурная карта (Structure Chart) показывает, как про­ граммные модули (функции) вызывают друг друга в процессе выполнения программы. Основные элементы - программный модуль и вызов. Для вызова могут быть указаны передаваемые и возвращаемые параметры. Также существуют обозначения вызова в цикле, условного вызова и лексического включения модулей. Структурная карта служит основной моделью для описания структуры программного кода на универсальных языках программирования третьего поколения.

•Структурные схемы (Flow Chart) содержит вычислительные блоки, используемые дисциплиной структурного программи­ рования. Описывает алгоритмы выполнения процедур.

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