CC BY
113
УДК 519.2 Н.П. Воробович, О.Н. Лопатеева
АНАЛИЗ МЕТОДОЛОГИЙ РАЗРАБОТКИ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
Проведен анализ наиболее распространенных методологий разработки информационных систем: каскадной, итерационных, быстрой разработки приложений, моделирования, интеграции всей системы. Даны рекомендации по выбору методологии при разработке конкретного приложения.
Ключевые слова: информационная система, разработка, каскадная методология, итерационная методология, система, подсистема, функция, приложение, моделирование, интеграция.
N.P. Vorobovich, O.N. Lopateeva ANALYSIS OF THE METHODOLOGY OF THE AUTOMATED INFORMATION SYSTEMS DEVELOPMENT
The analysis of the most widespread methodologies of the information systems development such as cascade, iterative, fast applications programming, modeling, the whole system integration is made. Recommendations for the methodology choice for the concrete appendix development are given.
Key words: information system, development, cascade methodology, iterative methodology, system, subsystem, function, appendix, modeling, integration.
Опишем наиболее распространенные методологии разработки информационных систем. При этом будем считать, что основным принципом работы разработчика автоматизированных систем есть стремление "выполнить задание".
1. Каскадная методология (waterfall methodology)
Это название указывает на способ, посредством которого результаты одной фазы процесса разработки передаются вниз, на следующую фазу. Эта методология разработана в эпоху языков программирования второго и третьего поколения (COBOL, FORTRAN, PL/1 и т.д.). При таком структурированном подходе разработка начинается с самого верхнего уровня, и установленные требования воплощаются в документированные, детализированные проекты, которые могут быть реализованы.
Каскадная методология может быть реализована различными способами. С одним из наиболее традиционных ее проявлений можно встретиться в американских правительственных контрактах; в них очень подробно определены спецификации, поправки к этим спецификациям сопровождаются уточнением стоимости. Контроль изменений сводится к формальному взаимодействию между заказчиком и подрядчиками. Эта версия предусматривает очень небольшое взаимодействие между разработчиками и конечными пользователями. Спецификации обычно готовят аналитики по материалам совещаний с основными пользователями и персоналом, ответственным за ведение контракта. Иногда для подготовки детализированного набора спецификаций, который может быть предъявлен для проведения конкурса, нанимают отдельную компанию.
Каскадная методология - это очень формальный метод, который использовался в течение ряда лет. При его использовании иногда было нелегко удовлетворить потребности предприятий, которые стремились ввести прикладные программы в действие быстро и за минимальную стоимость.
2. Итерационные методологии
Часто бывает, что при первом внедрении компьютерной системы на каком-то предприятии люди поначалу сопротивляются изменениям. Как только они начинают ее использовать, то приходят с предложениям и о
ее улучшении. Наверное, это - признак того, что сотрудники предприятия начинают видеть пользу от внедрения системы и хотят с ее помощью раскрыть все свои возможности. Однако часто организации не выделяют средств на модернизацию системы, ибо надеются, что все будет сделано идеально с первого раза.
Некоторые разработчики наблюдали такое отношение достаточно часто, что позволило им создать методологию разработки, которая принимает это поведение как естественное, и использует его для улучшения процесса разработки. Основной аргумент здесь - не следует ожидать от пользователей понимания всех потенциальных возможностей, поскольку они раньше не сталкивались с автоматизированными системами обработки деловых операций. К тому же поскольку технология продолжает развиваться, то, что было невозможно годом раньше, теперь может стать вполне осуществимым. Поэтому для некоторых ситуаций итерационный подход, при котором что-то создается, а затем совершенствуется на основе отзывов пользователей и применения новых технологий, может оказаться самым лучшим.
Итерационный подход имеет две основные разновидности: добавление подсистем и добавление функций.
2.1. Добавление подсистем
Многие современные приложения разработаны с целью обеспечения совместной работы нескольких отделов - групп людей, которые, возможно, прежде никогда вместе не работали. В этом случае можно выполнить поставку различных функций в разное время. Этот подход позволяет:
1. Распределить затраты на создание сложной системы на несколько финансовых периодов и постепенно решать кадровые проблемы.
2. Снизить бремя поддержки до приемлемого уровня. При внедрении нового приложения пользователь часто требует значительной помощи, а если это приложение является всеобъемлющим, может возникнуть такой объем работ, который может оказаться не по силам группе сопровождения.
3. Изучить отклики нескольких первых групп, поработавших с системой, и устранить недостатки в интересах не только их, но и тех, кто будет использовать их позднее.
4. Выравнить требования к инвестициям в компьютерные аппаратные средства и сетевые системы, что дает предприятию возможность развиваться в более приемлемом темпе.
5. Создать более комфортную атмосферу для пользователей, поскольку они участвуют в процессе разработки. Некоторые пользователи могут даже начать чувствовать себя причастными к внедренному приложению, будут работать над его совершенствованием.
6. Разработчикам со временем изучить предметную область. Младший персонал разработчиков, поработав на различных итерациях проекта, накапливает знания предметной области, что может повысить его производительность при работе над модулями, которые будут создаваться в дальнейшем.
2.2. Добавление функций
Может оказаться, что никого не устраивает внедрение только части системы, как в предыдущем подходе. Возможно, что пришло время отказаться от существующей системы, которая больше неприемлема, или происходит слияние некоторых систем при объединении ряда предприятий и нужно, чтобы система начала действовать как можно скорее. Существует возможность предложить систему, которая выполняет основные функции и не обеспечивает вывод некоторых отчетов или не располагает некоторыми удобными средствами. Итерационный подход позволяет вначале создать работоспособную систему, а затем добавлять всякие дополнения. Такой подход имеет определенные преимущества:
1. Быстро реализуются основные требования.
2. Не приходится тратить время впустую, разрабатывая менее важные средства, а затем оказаться в цейтноте, потому что сорвана реализация важной функции. Для данной итерации все средства почти равны по своему значению.
3. Если ассигнования в дальнейшем будут сокращены, останутся не реализованными менее важные средства работающего приложения, но не будут потеряны главные его составляющие.
С точки зрения требований каскадную методологию применять намного проще, поскольку в конечном итоге разработчик получает простую модель проекта или документа, в котором указано все, что должно быть в его единственной постановке. Если требуются дальнейшие поставки, то каждая из них обычно рассматривается в отдельном документе. В итерационных методологиях приходится управлять не только тем, что
должно выполнять приложение, но и тем, когда это должно быть выполнено. К счастью, инструментальные средства CASE обычно поддерживают несколько версий системы и позволяют развивать проект.
При использовании итерационных методологий настоятельно рекомендуем применять надежную систему управления версиями. В последнем выпуске приложения может обнаружиться одна трудно исправимая ошибка, которая исключит возможность промышленной эксплуатации приложения. Тогда, вероятно, до ее устранения придется вернуться к предыдущей версии программного изделия. Хорошая система управления версиями может сделать это "отступление" относительно легким. Разумеется, что при планировании этапа внедрения нужно также на всякий случай предусмотреть возможность возврата к предыдущей версии.
3. Быстрая разработка приложения
"Побольше, подешевле и побыстрее". Требования такого типа становятся все более распространенными. Поскольку такие запросы встречаются все чаще, особенно на предприятиях, которые функционируют в условиях быстро изменяющейся среды, были разработаны методы и средства, позволяющие их удовлетворить. Мы будем рассматривать всю массу модных терминов, которые описывают такие средства под общим названием "средства быстрой разработки приложения".
Что это означает? Сознательные программисты и так всегда упорно трудятся и стараются не растрачивать время попусту, т.е. работают так быстро, как только могут. Возможно, так оно и есть, но иногда им просто надо понять, что в некоторых проектах основным требованием является своевременное выполнение. Поэтому они могут скорректировать свои планы, чтобы быть уверенными, что все сроки будут соблюдены. Некоторые примеры изменений, которые они могут внести в свою работу, включают следующее:
1. Рассмотреть итерационный подход, в котором вначале выполняется поставка основных функций, а затем наступает время и для дополнительных средств.
2. Применять тестирование, которое гарантирует правильное функционирование, но игнорирует внешнее оформление.
3. Часто просматривать состояние проекта, что позволяет администраторам обнаруживать отстающие участки и вводить дополнительные ресурсы, обеспечивающие работы строго по графику.
4. Создавать финансовые резервы, что позволяет администраторам привлекать дополнительные ресурсы для решения возникающих проблем.
5. Наладить более тесные рабочие отношения с пользователями, которые смогут ответить на вопросы разработчиков, а также опробовать ранние версии программного обеспечения и подтвердить, что разработчики находятся на правильном пути.
6. В течение всего процесса проектирования постоянно стремиться не усложнять приложение, чтобы его реализация оставалась выполнимой в установленных временных рамках, т.е. проверять, является ли каждое предложенное требование действительно обязательным для реализации.
Некоторые поставщики и консультанты по различным методам хотели бы заставить вас поверить, что только они обладают особой методологией, которая однозначно подходит для быстрой разработки приложений. Не верьте рекламе. Разработчик сам должен оптимизировать существующую методологию с целью создания работающей системы в кратчайшие сроки.
4. Моделирование
Что можно сделать, когда неизвестно, что делать? Возможно, ответ состоит в применении моделирования, которое является хорошим методом, поскольку позволяет ускорить разработку приложения и помогает определиться пользователям, которые не могут точно сформулировать, что они хотят.
Для этого нужно создать незавершенную версию системы и показать ее пользователям. Они дают на нее свои отклики прежде, чем вы впустую потратите время, реализуя функции, которые им в действительности не требуются.
Модель может принимать множество форм. Например, можно показать пользователям рисунки разрабатываемых экранов, описать, какие кнопки они должны будут нажать, и что будет отображено при выполнении той или иной формы. Этот процесс особенно полезен, если есть возможность пройти с пользователем весь деловой процесс, чтобы ничего не было пропущено или ложно истолковано.
В другой форме модель можно относительно легко реализовать с помощью графических инструментальных средств, которые входят в состав инструментальных средств разработки приложений четвертого поколения, где эмулируются фактические экраны, но не реализуются какие-либо стоящие за ними функции.
Можно даже заполнить поля модельными, жестко закодированными данными. Еще один подход состоит в том, что после нажатия кнопки пользователем появляется окно сообщения, которое объясняет, что должно произойти дальше.
Ключевым моментом моделирования является то, что по мере дальнейшего продвижения в процессе разработки изменения будут становиться все более дорогостоящими. Изменение, которое относительно легко можно внести на экране проектирования на бумаге, может перечеркнуть целые дни напряженной работы, если необходимость в нем не была обнаружена до тестирования; для исправления могу потребоваться недели, если проблема выявится после передачи системы на производство. Моделирование ускоряет этот процесс, поскольку пользователи проверяют незавершенные версии приложения и подтверждают, что действительно создается то, что они просили.
Можно также реализовать несколько фаз моделирования, чтобы каждая из них представляла очередную итерацию разработки. Число итераций, материал, представленный на каждой из них, и само использование моделирования зависят от сложности приложения, от того, насколько хорошо оно было продумано пользователем, а также от того, захотят ли пользователи тратить время на проверку моделей. Однако этот метод нужно всегда держать в своем арсенале и применять при благоприятном стечении обстоятельств.
Использование моделирования связано со следующими обстоятельствами.
1. Должны быть выработаны методы определения того, является ли модель адекватной.
2.. Необходимо управлять числом итераций в процессе разработки. Теоретически можно продолжать итерации до бесконечности, поскольку пользователи будут постоянно придумывать новые пути совершенствования. Кроме того, если деловые процессы быстро меняются, может оказаться, что разработчику никогда не удастся сдать заключительный проект, потому что требования изменяются после каждой итерации модели. В большинстве проектов обычно вполне достаточно бывает от одной до трех итераций.
3. Необходимо выяснить критерии успешной реализации модели. Хотя небольшие подробности, наподобие того, какой будет использоваться шрифт, и для чего будет служить та или иная кнопка, остаются открытыми для пожеланий, нужно ясно дать понять, что общие требования к проекту не подлежат дальнейшему расширению.
5. Интеграция всей системы
Одной из самых значительных проблем, с которой приходится сталкиваться в разработке проектов, является отсутствие системного подхода к процессу разработки.
В наше время компьютерные системы продолжают усложняться. Это ведет к специализации, которая сама порождает много проблем. В те дни, когда применялись только большие компьютеры с терминалами, при внедрении нового приложения приходилось иметь дело только с несколькими людьми.
Сегодня, однако, приходится общаться с относительно большим числом разных исполнителей, включая: системных администраторов на серверах; администраторов базы данных; администраторов данных; сетевых администраторов на серверах; сетевых инженеров; персонал, поддерживающий работу персональных компьютеров; администраторов по защите; персонал обеспечения качества; персонал поддержки аппаратных средств сервера; персонал бюро обслуживания.
Здесь необходимо привлечь весь свой опыт. Нужно полностью продумать процесс разработки и реализации. Выясните, кто должен оказать вам помощь, и какую, или кто сопровождает системы (такие, как серверы, сети, персональные компьютеры), которые будут использоваться или с которыми вы будете взаимодействовать. Необходимо уточнить также, кто в процессе реализации и разработки должен предоставлять заключения и с кем выполнять согласования. Нужно найти наилучший способ предоставить этим людям требуемый доступ к вашей системе без значительных потерь времени с их и с вашей стороны.
В завершение этой темы укажем, что системный подход должен быть основой методологии разработки, нельзя вспоминать о нем в последний момент. В большинстве своем разработчики, с которыми доводилось встречаться, были так озабочены уточнением всяких подробностей с пользователями, нарушениями графика и уходом программистов в середине работы над проектом, что им вечно не хватало времени подумать об улучшении процесса разработки. Кроме того, те, кто должен поддерживать разработчика, могут быть слишком заняты преодолением очередных кризисов, чтобы поговорить с ним, когда до сдачи его приложения осталось два месяца. Во многих организациях принято привлекать к процессу проектирования формальные группы поддержки, зачастую для подготовки заключений по проекту. Поддерживающие организации заинтересованы в подготовке заключения к запланированной дате, поскольку они не хотят нести ответственность за срыв других проектов и пе-
рерасход сметы. Поэтому мне представляется, что, не включив в методологию проектирования системный подход, нельзя будет найти время, чтобы подумать о всей системе в целом, а не отдельных ее частях.
6. Выбор методологии
После того, как работа выполнена, часто обнаруживается, что ни одна из методологий, описанных в этой работе, не стала единственно возможной для проекта. По-видимому, все они могли найти свое место в процессе разработки приложения. Проблемы возникают при использовании для проекта неправильной методологии. Например, быстрое моделирование вряд ли будет применимо в среде COBOL при обновлении сопровождения большой существующей системы. Кроме того, каскадную методологию обычно трудно применять в таких обстоятельствах, когда нужно обеспечить быструю поставку приложений, требования, которые плохо понимают пользователи и разработчики.
Ниже перечислены некоторые пункты, которые следует учитывать при выборе методологии для очередного проекта.
1. Методология должна быть совместима с выбранными инструментальными средствами разработки. В ряде случаев нужно либо сменить инструментарий, либо методологию, ибо существуют некоторые комбинации того и другого, которые невозможно использовать.
2. Методология должна быть совместима с процессами, идущими в организации. Может быть, важна быстрая поставка приложения или важнее, например, принять далеко не оптимальные приложения, но удовлетворить требования сметы и плана.
3. Необходимо иметь достаточный опыт и подготовку, чтобы правильно применять методологию.
4. Методология должна позволять решать всевозможные вопросы разработки и реализации, включая координацию работы с соответствующими поддерживающими организациями.
5. Не нужно бояться экспериментировать. Поставщики охотно предоставляют демонстрационное оборудование и рекомендации других компаний, которые реализовали решения поставщика при выполнении требований, аналогичных вашим требованиям. Многие программные средства имеют демонстрационные версии или описания, которые можно получить через Internet. При переходе в совершенно новую среду или при построении особо сложной системы может потребоваться построить в миниатюре прототип аппаратных средств и операционной системы для выявления всех ошибок. Можно обнаружить удивительно много проблем несовместимости программных версий и аппаратных средств, прежде чем процесс разработки начнется всерьез.
Литература
1. CASE-Аналитик для Ш PC. Руководство аналитика. - М.: Эйтэкс, 1993.
2. Калянов, Г.Н. Консалтинг при автоматизации предприятия / Г.Н. Калянов. - М.: СИНТЕГ, 1997.
3. ORACLE 7.3. Пособие разработчика / Л. Сингх [и др.]. - Киев: ДиаСофт, 1998.
4. Воробович, Н.П. Модели, методы и информационно-вычислительные технологии многопроектного управления в иерархических средах САПР и АСУ / Н.П. Воробович; Сиб. гос. технол. ун-т. -М.:ВИНИТИ, 1998. - 273 с. Деп. в ВИИНИТИ 21.08.98, № 2631-В98.
5. Воробович, Н.П. Методология разработки пакетов прикладных программ по управлению строительными проектами / Н.П. Воробович; Сиб. гос. технол. ун-т. - М.:ВИНИТИ, 1999. - 43 с. Деп. в ВИИНИТИ 16.08.99, № 2663-В99.
'--------♦-----------
