Раздел: Документация
0 ... 75 76 77 78 79 80 81 ... 96 создании АС: заказчику нужна эффективная и сегодня работающая ACf а исполнителю - реализация АС, ие противоречащая условиям договора и технического задания. Из практики известно, что ошибки в реализации АС обходятся очень дорого. Архитектурные просчеты вообще могут привести к провалу проекта по созданию и внедрению АС на предприятии. Причем ошибки эти чаще всего всплывают только при попытке внесения изменений в созданную АС. Обычно ситуация достигает апогея в следующих случаях: •технологии разработки программного обеспечения заказчика и исполнителя разные; •заказчик обладает оригинальным накопленным функционалом по решению конкретных технических процессов; •заказчик собственными силами осуществляет сопровождение и модификацию АС, созданную исполнителем. Вот почему в качестве аксиомы при создании заказного ПО выступает следующий факт: технология реализации АС должна быть максимально общей и для исполнителя и для заказчика. В этом случае указанные критические ситуации удается если не избежать, то хотя бы предотвратить. Продемонстрировать какие именно специалисты и за счет чего могут помочь в решении проблемы согласования деятельности по разработке АС можно на основе «расширенной модели» (рис.3.21). Для этой модели к паре «заказчик - исполнитель» добавим двух новых участников: аналитика по техническим процессам и архитектора АС. В рамках расширенной модели попробуем показать их функции, профессиональные отличия друг от друга и от остальных участников, наметить связи между ними. 3.4.4. Аналитик по техническим процессам Главные задачи аналитика по техническим процессам - правильно понимать потребности отдельных пользователей и предприятия в целом, ясно и полно их описывать в уместных формах. Аналитик ближе других находится к заказчику и к пониманию его технических процессов. Он «живет» в них. Принципиально, что он умеет обобщать, строить, документировать формальные и неформальные модели их решения. Он должен представлять себе общие возможности современных информационных технологий, в то же время не забивая себе голову вопросами, характерными для специалистов по компьютерным технологиям. Обычно перед аналитиком по техническим процессам стоит дилемма участия в двух тесно взаимосвязанных пластах деятельности предприятия: технологическом и социально-руководящем. В  Выделение и представление: -объектов -модели деятельности -среды, в которой протекает эта деятельность Рис.3.21. Расширенный вид модели Тыугу последнее время эта дилемма резко обозначилась. Далеко не каждому специалисту предприятия приходится моделировать деятельность последнего, а тем более создавать ее действующую технологическую модель. Аналитику по техническим процессам неизбежно приходится сталкиваться и с тем и с другим. Именно с этим связан рост статуса на предприятии аналитика по техническим процессам. Очень часто аналитик не является сотрудником фирмы - разработчика или специализированного подразделения предприятия - заказчика (например, отдела программирования). Современные методики предполагают, что даже консалтинговая фирма, имеющая в своем штате профессиональных аналитиков, ищет таких людей у заказчика, находит с ними общий язык и включает их в свой проектный коллектив. От аналитика не требуется обязательного освоения формальных языков и моделей (таких как модель потоков данных или UML -«унифицированный язык моделирования»). Он может использовать формализмы, но только для более точного описания внешних требований к АС, а не для принятия решений в проектировании «компьютерной» части системы. Аналитик может и часто должен формировать не только постановки отдельных задач, но и целостную модель автоматизированного предприятия. Однако он строит такую модель на верхних уровнях архитектурного представления автоматизированной системы, в то время как CASE-модели лежат ниже. Аналитику нужен очень простой и гибкий компьютерный инструмент для ведения документации: текстов, коллекций рисунков и схем, чертежей, записей алгоритмов и ссылок на нормативные документы с извлечением из них. Значительную часть своих наработок аналитику следует помещать в общую базу проекта, поддерживающую «требования к автоматизированной системе». 3.4.5. Архитектор АС Архитектор рассматривает всю совокупность внешних требований к автоматизированной системе. Вместе с аналитиком он анализирует и выявляет противоречия и неточности в них. Он находится немного дальше от заказчика, чем аналитик, но ближе к компьютерным специалистам. С участием экспертов по компьютерным технологиям он проверяет требования на приемлемость. В случае слишком большой стоимости или невозможности реализации он ищет альтернативные подходы. Архитектор создает целостный «логический» проект АС, в котором еще не производится выбор конкретных компьютеров, СУБД, инструментов программирования и т.д. Главное здесь то, что он видит и описывает архитектуру АС в целом, объединяя все ее «слои» -от людей и целей до данных и функций. Архитектор принимает решения, интегрируя концептуальную модель предприятия с потенциально доступными возможностями компьютерных технологий. Ему нужно рассматривать и чисто технические решения, и часто вместе с проектировщиками автоматизированных систем приходится проверять выполнимость тех или иных требований и логических решений. Но окончательные решения по технической архитектуре он не принимает, это дело «главного программиста» АС, хотя многие такие решения должны согласовываться с архитектором. Архитектор - сотрудник специализированного «компьютерного» подразделения или фирмы. Он владеет формальными моделями. Он обязан оценивать эффективность своих решений и присущий им риск. Главное здесь то, что он представляет коллектив разработчиков АС перед заказчиком. Он проверяет решения вместе с аналитиками и пользователями, он объясняет возможности АС первым лицам заказчика, защищает ее на совещаниях. Иногда архитектор - это «главный архитектор АС», иногда -член «архитектурной мастерской». Но когда его функции выстроены правильно, тогда и заказчик и программист должны считать его не страшилой-начальником, а конструктором совершенно определенного, высокого уровня. Да, он должен проверять то, что реализуют программисты, на соответствие требованиям к автоматизированной 0 ... 75 76 77 78 79 80 81 ... 96
|
