Новосибирский Государственный Университет
Опубликован: 20.08.2004 | Доступ: свободный | Студентов: 4919 / 487 | Оценка: 4.01 / 3.23 | Длительность: 18:07:00
ISBN: 978-5-9556-0013-0
Лекция 10:

Технологические аспекты развития программных систем в моделях жизненного цикла

< Лекция 9 || Лекция 10: 12345 || Лекция 11 >
Аннотация: Обсуждается возможность отражения в моделях жизненного цикла свойств процесса разработки программного обеспечения, способствующих поддержке эффективности производства. С этой точки зрения рассматривается осуществимость параллельного выполнения итераций и проводится разграничение между иллюстративными и инструментальными моделями. Рассматривается возможность инструментального применения ряда общеупотребительных моделей.
Ключевые слова: жизненный цикл программного обеспечения, очередь, технологичное свойство процесса производства программного обеспечения, итеративность, производственная функция, параллельное выполнение итераций, место, модели жизненного цикла, моделирование жизненного цикла, технологический параллелизм, цикла, итеративное наращивание, словосочетание, ПО, группа, работ, совмещение работ, анализ осуществимости, оценка, информация, определение, рабочий продукт, распределение времени, риск, иллюстративная модель жизненного цикла, инструментальная модель жизненного цикла, точность, графика, CASE-система, RUP, UML, MSF, универсальность, менеджер, деятельность, атрибутивность, расширяемость модели, масштабируемость, интегрированность, мера, модель фазы-функции, отношение, последовательное развитие проекта, каскадная модель, матрица, линия жизненного цикла, контроль, календарный план, участники разработки проекта, подразделения, разбиение, контроль распределения времени, распределение ресурсов, исполнитель, Дополнение, перечисление, таблица, итерация, значимость, спираль развития, спираль охвата предметной области, опыт, модель Боэма, прототип, цикл разработки, доступ, анализ

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

Требуется выяснить:

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

Этим задачам посвящена данная лекция.

Схемы итеративного развития программных систем в большей степени, чем классические схемы, отражают фактический ход многих реальных проектов. Поэтому вполне закономерно, что именно итеративные жизненные циклы привлекают внимание специалистов. С помощью моделей, отражающих итеративность, описываются полезные свойства процессов разработки программных систем. Мы продемонстрировали это при обсуждении контрольных точек и производственных функций модифицированной модели Гантера (см. лекцию 9). Далее будет показано, как при моделировании отражается возможность параллельного выполнения итераций и какое место эта возможность занимает в арсенале средств менеджера программных проектов. Затем мы обратимся к вопросу о том, в какой мере модели жизненного цикла могут способствовать реальному управлению, и с этой точки зрения рассмотрим ряд общеупотребительных моделей.

Параллельное выполнение итераций

Любой программный проект, заслуживающий привлечения менеджера для поддержки разработки, — это процесс, реализуемый коллективно. Следовательно, подчиняя моделирование жизненного цикла задачам менеджмента проекта, уместно ставить вопрос о том, как отражается в модели одновременность деятельности исполнителей.

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

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

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

Одновременность выполнения разных итераций можно представить в виде схем, показанных на рис. 10.1.

Пределы совмещений итераций в проекте. а) Этапы жизненного цикла итерации (привязка к контрольным точкам общей модели указана числами в скобках) б) Три итерации проекта I, II, III, развиваемые одновременно в) Пределы совмещений итераций в проекте

увеличить изображение
Рис. 10.1. Пределы совмещений итераций в проекте. а) Этапы жизненного цикла итерации (привязка к контрольным точкам общей модели указана числами в скобках) б) Три итерации проекта I, II, III, развиваемые одновременно в) Пределы совмещений итераций в проекте

На рис. 10.1а приведена расшифровка этапов итераций. По сравнению с общей моделью (см. рис.9.1 и 9.2) здесь представлено более мелкое дробление этапов: явно выделены планирование, которое для начальной итерации является частью общего этапа анализа осуществимости, и тестирование как перекрывающаяся часть общих этапов программирования и оценки.

Рис. 10.1б демонстрирует три одновременно выполняемые итерации: вторая начинается после завершения программирования первой итерации с таким расчетом, чтобы ее этап программирования начался после окончания тестирования первой итерации. Планирование третьей итерации начинается одновременно с этапом программирования второй итерации.

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

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

< Лекция 9 || Лекция 10: 12345 || Лекция 11 >
Дарья Федотова
Дарья Федотова
Сергей Березовский
Сергей Березовский

В рамках проф. переподготовки по программе "Программирование"

Есть курсы, которые я уже прошел. Но войдя в курс я вижу, что они не зачтены (Язык Ассемблера и архитектура ЭВМ, Программирование на С++ для профессионалов). Это как?

Сергей Прошута
Сергей Прошута
Россия
Sergey Ostr
Sergey Ostr
Россия, Энгельс