Лобанов Игорь Александрович

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

   Основным результатом этой переоценки является то, что процесс разработки уже не воспринимается как ремесло или искусство, как это было принято ещё со времён появления профессии программиста в середине прошлого века. Для того чтобы «выжить» в нынешних условиях, необходимо видеть в этом, прежде всего, определённый технологический процесс, который можно документировать и, что самое главное, воспроизвести.

   Эта «тихая революция» взглядов идёт повсеместно уже в течение нескольких лет и трудно переоценить её результаты, как трудно переоценить результаты замены кустарных мастерских сборочными цехами с конвейерами. Ещё в 90-ых годах XX века появилось осознание того, что без формального подхода и строгой определённости в организации труда разработчиков разработка любой хоть сколько-нибудь сложной системы становится очень рискованным предприятием, так как никто не может дать гарантий в успешном завершении начинающегося проекта. Тогда же были предприняты первые попытки структурирования деятельности разработчиков, что привело к появлению понятия процесса разработки программного обеспечения. Это формально описанный воспроизводимый способ организации различных видов деятельности в рамках процесса создания программного обеспечения, который существенно снижает риск неудачи проекта.

   За прошедшее время, было создано и опробовано множество таких процессов, каждый из которых в той или иной степени выполнял свои задачи. В течение всего этого времени неоднократно предпринимались попытки обобщить набранный практический опыт и выделить те черты процессов разработки, благодаря которым создавались наиболее успешные проекты. В результате этих попыток в 1998 году компания Rational создала первую редакцию Унифицированного Процесса (Rational Unified Process - RUP). Это был своего рода адаптируемый каркас процесса, настраивая который под свои нужды любая компания могла создать процесс разработки, который наилучшим образом подходил бы под её нужды, но, в то же время, включал в себя только лучшие наработки и практики.

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

   Наиболее важные рекомендации по организации процесса разработки программного обеспечения, реализуемые RUP:
   1. Итеративная разработка. Классический «водопадный» процесс, в котором различные фазы разработки (анализ, реализация, тестирование) выполняются по одному разу в течение времени работы над проектом, имеет ряд существенных недостатков, делающих его негибким. В то время как итеративный подход, в котором эти фазы повторяются циклически определённое количество раз, этих недостатков лишён.
   2. Управление требованиями. Требование – это условие или характеристика, которой должна соответствовать система. Не нужно совершать ошибку, ожидая, что в процессе развития проекта они не будут также изменяться. Управление требованиями проекта предлагает множество решений, устраняющих основные причины проблем в процессе разработки программного обеспечения.
   3. Модульная разработка. Модульная разработка (component-based development) позволяет компаниям повторно использовать свои компоненты и/или найти подходящие на рынке, тем самым, уменьшая сложность разработки и себестоимость системы.
   4. Визуальное моделирование. Модель – это упрощение действительности, которое полностью описывает систему с определённой точки зрения и помогает её лучше понять. Более того, в сложных системах, которые невозможно представить полностью, без модели обойтись вообще невозможно. Средства визуального моделирования облегчают управление моделями и способствуют поддержанию их непротиворечивости, что позволяет эффективно бороться со сложностью программного обеспечения.
   5. Контроль качества. Известно, что поиск и исправление ошибок после распространения программного обеспечения обходится значительно дороже, чем до распространения. По этой причине важно постоянно следить за качеством системы, используя в качестве критериев её функциональные возможности, эффективность и надёжность.
   6. Контроль изменений. Контроль над действиями и результатами работы, как отдельных разработчиков, так и целых команд, требует тщательного управления изменениями, вносимыми в программное обеспечение и друге проектные документы, без которого, процесс разработки быстро станет хаотичным.
   Следование этим советам является важной составляющей успеха любого программного проекта.

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

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

   В связи с вышесказанным, в предлагаемом курсе (Технология программирования) рассматриваются различные фазы (динамическая структура) и технологические процессы (статическая структура), которые необходимо понимать разработчикам, работающим в проектах организованных по правилам RUP. Результатом занятий будут знания по технологии программирования и освоение инструментальных средства пакета Rational Suite (в частности, Rational Rose, Rational SoDA, Rational TestStudio), которые используются в ходе работы над проектом в рамках RUP. Однако, акцент делается не на всеобъемлющем освоении этих пакетов, а на приобретение навыков применять эти инструменты в различных технологических процессах и различных фазах разработки.