Раздел: Документация
0 ... 74 75 76 77 78 79 80 ... 96 существующие технологии и поддерживающие их инструментальные средства имеют свою область применения, свои недостатки и ограничения. Как известно, когда у мастера основной инструмент молоток, то каждая проблема становится похожей на гвоздь. Подобная ситуация возникает и в случае освоения новой информационной технологии или приобретения дорогостоящей CASE-системы. Хочется все проблемы решать только теми методами, которые присущи этим средствам. Часто результатом такой деятельности становится разочарование в CASE-системах в целом. Внедрение информационных технологий откладываются до лучших времен, дорогие инструменты не используются. Однако избежать внедрения новых информационных технологий иа практике не удастся. Чем крупнее и сложнее должна быть создана автоматизированная система, тем выше риск ее неудачного построения. Одним из способов снижения риска, повышения гарантии выполнения в срок и при заданном финансировании построения АС является формализация процесса анализа и проектирования последнего. Такой подход помогает добиться повторяемости успеха и качества при информатизации того или иного вида деятельности. Излишне говорить о важности такого результата для предприятий, деятельность которых существенно зависит от функционирования автоматизированных систем, обеспечивающих проектирование и изготовление наукоемкой продукции. А чтобы освоение новых информационных технологий проходило эффективно, необходимо четко видеть их преимущества и недостатки. 3.4.3. Причины появления искажения требований к АС Далее до конца главы использованы материалы из «Computer Week» и Интернет. Почти в каждом проекте возникают ситуации следующего типа. Заказчик что-то считает для себя очевидным и поэтому даже пе упоминает об этом. Разработчик так же молча «обходит» часть требований как абсурдные или же «неудобные». В ходе проектирования сплошь и рядом одни защищают какие-то требования, другие говорят о них как о невыполнимых или безграмотных. Что и как надо сделать, чтобы противоречивые точки зрения, упущения и умолчания не исказили создаваемую АС? Как организовать выполнение работы по созданию АС, чтобы в результате последняя не была отторгнута потребителем или бесконечно долго не «доводилась до ума» под встречные упреки заказчика и исполнителя? Одни говорят, что все проблемы решаются через создание прототипа автоматизированной системы, реализуемой непосредственно исполнителями с привлечением конечных пользователей заказчика. Другие уверены, что дело «компьютерщиков» (включая программистов, сетевиков, проектировщиков баз данных и других специалистов) - сразу предоставить работающую автоматизированную систему в ответ на задание, которое выскажет заказчик. Первая точка зрения очень распространена среди исполнителей. Вторая свойственна заказчикам, относящимся к разработчику, как капризный клиент к портному: «Я плачу деньги, а ты сделай, чтобы мне было хорошо. И без лишних вопросов и примерок». Но и то и другое ведет к искажениям требований. Вот почему в последнее время при создании больших автоматизированных систем появилась новая группа специалистов-аналитиков и их многочисленных «разновидностей». Ответу на вопросы ПОЧЕМУ и КАК они должны сегодня выполнять ключевую роль в построении АС и посвящена настоящая часть работы. Корни проблемы в том, что каждый отдельный человек, связанный с разработкой или использованием больших автоматизированных систем, обычно имеет ие полное, а подчас и искаженное представление о всей картине создания и жизни последней. Чисто по человечески это нормально и неизбежно. Попробуем разобраться в этом вопросе, представив взаимодействие пары «заказчик - исполнитель» с помощью модели Тыугу. Источники искажений, возникающих при создании больших автоматизированных систем, показал Э.Х.Тыугу на предельно простой, но очень полезной модели. В идеальном варианте модели показаны ситуации, в которых возникают искажения восприятия основных участников проекта создания АС: «заказчика» и «исполнителя» (рис.3.19). На взгляд каждого из них проблемы другой стороны видны «издалека». При этом чужое становится мелким, а отчетливо видны детали только своих проблем. Типичная ситуация искажений с точки зрения исполнителя изображена на рис.3.20. В этом варианте сознательно или несознательно исполнитель так ограничивает угол своего «наружного» взгляда, что из всех ситуаций заказчика видит только ту часть, которую легко воспринимает и для чего самому хочется написать программу. Немудрено, что получающееся в результате «изделие» или отвергается заказчиком, или заставляет испытывать долгие мучения в ходе своего внедрения. Из приведенных моделей видно, что задача выработки общего подхода к созданию АС по разному стоит перед заказчиком и исполнителем. Особенно остро она проявляется в подходах к организации корпоративной разработки и управления изменениями АС при реализации проекта совместными усилиями.  Рис.3.19. Взгляды заказчика и исполнителя па «свои и чужие» проблемы Такой взгляд на разработку АС во многом определяется различием корпоративных культур заказчика и исполнителя. Обычно организация разработки АС исполнителем технологически и бизнес ориентирована, что фиксируется в виде: •договора с заказчиком и технического задания; •условий поставки АС и четко обозначенного набора услуг. С этой точки зрения исполнителя практически мало интересует достижение конечного результата, ожидаемого заказчиком после внедрения АС на своем предприятии. Связанный с этим типичный пример работы исполнителя можно продемонстрировать на отношении к программному инструментарию, с помощью которого осуществляется автоматизация деятельности предприятия и его обслуживание. Исполнителя обычно мало интересует сколь эффективно будет работать этот инструмент в руках заказчика. В этом кроется одно из главных расхождений интересов заказчика и исполнителя при заказном  Рис.3.20. Асимметричный вариант модели Тыугу 0 ... 74 75 76 77 78 79 80 ... 96
|
