Организация процесса проектирования

2019-07-03

232

Обсуждений (0)

0.00 из 5.00 0 оценок

⇐ Предыдущая 1 23

Г. Буч [12] выделяет в процессе проектирования программного приложения микро и макропроцессы.

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

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

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

Макропроцесс обычно включает следующие действия:

- выявление сущности требований к программному продукту (концептуализация);

- разработка модели требуемого поведения системы (анализ);

- создание архитектуры для реализации (проектирование);

- итеративное выполнение реализации (эволюция);

- управление эволюцией продукта в ходе эксплуатации (сопровождение).

У всех нетривиальных программных разработок макропроцесс продолжается и после создания и внедрения системы.

Описание основных этапов разработки приложения дано в таблице 9.

Таблица 9 - Основные этапы разработки приложения

Наименование этапа	Основные действия	Результаты
Выявление сущности требований к программному продукту (концептуализация)	1) определить цели апробации концепции и критерии того, что считать благополучным исходом; 2) собрать подходящую команду для разработки прототипа; 3) оценить готовый прототип и принять ясное решение о проектировании конечного продукта или о дальнейшем исследовании. Решение о начале разработки конечного продукта нужно принимать с разумным учетом потенциального риска, выявленного при апробации концепции.	Первичными продуктами концептуализации являются прототипы системы.
Разработка модели требуемого поведения системы (анализ)	1) идентифицировать основные функциональные точки системы и, если возможно, сгруппировать функционально связанные виды поведения. Рассмотреть возможность создания иерархии функций, в которой высшие функции вытекают из низших. 2) для каждого представляющего интерес набора функциональных точек сделать раскадровку сценария, используя технику анализа поведения. Когда прояснится семантика сценариев, следует документировать их, используя диаграммы объектов, которые иллюстрируют объекты. Приложить описание событий, происходящих при выполнении сценария, и порядок выполняемых в результате действий. Кроме того, необходимо перечислить все предположения, ограничения и показатели эффективности для каждого сценария; 3) если необходимо, сделать описания поведения системы в исключительных ситуациях; 4) для объектов с особо важным жизненным циклом описать диаграммы состояний (построить конечный автомат); 5) найти в сценариях повторяющиеся шаблоны и выразить их в терминах более абстрактных обобщенных сценариев или в терминах диаграмм классов, показывающих связи между ключевыми абстракциями. 6) внести изменения в словарь данных; включить в него новые классы и объекты, выявленные для каждого сценария, вместе с описанием их ролей и обязанностей.	Результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов Побочным результатом анализа будет оценка риска: выявление опасных мест, которые могут повлиять на процесс проектирования.
Создание архитектуры для реализации (проектирование). Архитектурное планирование - охватывает логическую декомпозицию, состоящую в группировании классов, и физическую декомпозицию, состоящую в разбиении на модули и назначении заданий процессорам	1) рассмотреть группирование функциональных точек (найденных в анализе) и распределить их по слоям и разделам архитектуры. Функции, базирующиеся одна на другой должны попасть в разные слои; функции, сотрудничающие между собой для обеспечения требуемого поведения системы на данном уровне абстракции должны попасть в разделы системы, представляющие услуги на этом уровне; 2) проверить архитектуру созданием действующих релизов, которые частично удовлетворяют семантике нескольких важнейших сценариев, предоставленных анализом; 3) оценить достоинства и недостатки архитектуры. Определить риск изменения каждого ключевого архитектурного интерфейса, чтобы можно было заранее распределить ресурсы при эволюции системы.	Диаграммы классов и объектов.
Создание архитектуры для реализации (проектирование). Тактическое проектированиесостоит в принятии решений о множестве общих приемов	1) перечислить все случаи, когда нужно следовать единым общим приемам. Некоторые из них окажутся фундаментальными, независимыми от предметной области, например, управление памятью, обработка ошибок и т.д. Другие будут специфичны для данной области и будут содержать свойственные этой области идиомы и механизмы, такие, как принципы управления системами реального времени или транзакциями и базами данных в информационных системах; 2) для каждого приема составить сценарий, описывающий его семантику. Затем выразить ее в виде исполнимого прототипа, который может быть уточнен и представлен инструментально; 3) документировать каждый принцип и распространить полученные документы, чтобы обеспечить единое архитектурное видение.	Диаграммы классов и объектов Описания семантики. Сценарии
Создание архитектуры для реализации (проектирование). Программные релизы закладывают основы архитектурной эволюции системы.	1) полученные в результате анализа сценарии упорядочить от основных к второстепенным. Приоритетность сценариев лучше выяснить вместе с экспертом в предметной области, аналитиком, архитектором и контролером качества; 2) распределить функциональные точки по релизам так, чтобы последний релиз в серии представлял результирующую систему; 3) определить цели и расписание релизов так, чтобы дать время на разработку и синхронизировать релизы с другими действиями, например, с разработкой документации и полевыми испытаниями; 4) начать планирование задач, учитывая критические места проекта и ресурсы, отведенные на выпуск каждого релиза.	Программные релизы. План, в котором определены расписание работ, задачи коллектива и оценка риска.
Итеративное выполнение реализации (эволюция);	1) определить функциональные точки, которые попадут в новый релиз, и области наивысшего риска, особенно те, которые были выявлены еще при эволюции предыдущего релиза; 2) распределить задачи по релизам среди членов команды и начать новый микропроцесс. Контролировать микропроцесс, просматривая проект, и проверять состояние дел в важных промежуточных этапах с интервалами от нескольких дней до двух недель; 3) когда потребуется понять семантику требуемого поведения системы, поручить разработчикам сделать прототип поведения. Четко установить назначение каждого прототипа и определить критерии готовности. После завершения решить, как включить результаты прототипирования в этот или последующие релизы; 4) завершить микропроцесс интеграцией и очередным действующим релизом.	Серия исполняемых релизов, представляющих итеративные усовершенствования изначальной архитектурной модели. Описание поведения, которое используется для исследования альтернативных подходов и дальнейшего анализа системы
Управление эволюцией продукта в ходе эксплуатации (сопровождение).	1) упорядочить по приоритетам предложения о крупных изменениях и сообщения об ошибках, связанных с системными проблемами, и оценить стоимость переработки; 2) составить список этих изменений и принять их за функциональные точки в дальнейшей эволюции; 3) если позволяют ресурсы, запланировать в следующем релизе менее интенсивные, более локализованные улучшения; 4) приступить к разработке следующего эволюционного релиза программы.	Список новых заданий: обнаруженные дефекты и новые требования.

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

Для анализа рекомендуется использовать технологию CRC – карточек. CRC обозначает Class – Responsibilities - Collaborators (Класс/ Ответственности/ Участники). Это простой и замечательно эффективный способ анализа сценариев. Карты CRC впервые предложили Бек и Каннингхэм для обучения объектно-ориентированному программированию, но такие карточки оказались отличным инструментом для общения разработчиков между собой.

Это обычные библиографические карточки 3х5 или 5х7 дюйма. На карточках записывается (обязательно карандашом) сверху - название класса, снизу в левой половине - за что он отвечает, а в правой половине - с кем он сотрудничает. Заводятся карточки на каждый обнаруженный класс и дописываются в нее новые пункты. При этом каждый раз необходимо анализировать, что из этого получается, и большие классы целесообразно дробить на несколько классов, или передать часть обязанностей другому классу.

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

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

Многие виды деятельности по управлению разработкой программного обеспечения, например, планирование задач и просмотры, предусмотрены не только в объектно-ориентированной технологии.

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

Заключение

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

2019-07-03

232

Обсуждений (0)

0.00 из 5.00 0 оценок

⇐ Предыдущая 1 23

Обсуждение в статье: Организация процесса проектирования

Обсуждений еще не было, будьте первым... ↓↓↓