ПЗ (1218798), страница 4
Текст из файла (страница 4)
Связность информации в различных документах. В процессе проектирования локальные изменения в отдельных чертежах производятся постоянно, они должны оперативно учитываться и в необходимых случаях отражаться во всех прочих чертежах проекта. В идеале такой перенос информации должен производиться автоматически. Это достижимо при правильной организации работы, как над каждым отдельным чертежом, так и глобально, в рамках всей рабочей группы. Различные чертежные документы формируются на основе общей исходной графической информации. Как правило, это основные чертежи: планы, фасады, разрезы. Формирование остальных чертежей состоит исключительно в фильтрации исходной графической информации (оставить стены и проемы, исключить заполнение проемов) и добавлении к ней информации специальной, но отнюдь не базовой геометрии. Исключить многократное дублирование основных данных можно, обеспечив к ним доступ из различных чертежей по внешним ссылкам.
Этот метод позволяет использовать во всех документах проекта обновленные основные графические данные сразу после внесения в них изменений.
Этой же цели служит рациональная организация набора слоев, позволяющая при необходимости формировать в одном файле множество различных чертежных документов, немедленно отражающих изменения, выполняемые в любом из них.
Параллельная работа группы исполнителей над общим документом. Иногда требуется обеспечить совместную работу нескольких исполнителей над одним документом. Это может понадобиться в том случае, например, если параллельно с началом работ проводятся уточняющие натурные обмеры.
В стандартном случае после создания уточненной строительной подосновы, наработанные чертежи придется корректировать, механически дублируя камеральную часть обмеров. Если строительная подоснова существует в качестве отдельного чертежа-источника, на который делаются внешние ссылки из параллельно нарабатываемых чертежей проекта, их актуализация может производиться автоматически и немедленно по мере внесения изменений в такую подоснову.
Аналогичным образом посредством ссылок на выполняемые различными исполнителями модели отдельных этажей здания можно собирать полную его модель и на ее основе формировать остальные проекции и сечения.
Частый вывод промежуточных чертежей. В процессе работы над проектом выводить промежуточные чертежи приходится очень часто, в том числе для выдачи заданий, согласования с заказчиком и смежниками. Это делает актуальной печать чертежных документов из предварительно сформированных в пространстве листа макетов. Такая настройка требует не больше времени, чем разовая подготовка печати из пространства модели, однако избавляет от необходимости выполнять ее повторно. Таких макетов в любом файле может быть создано множество для различных условий печати. Отправка настроенного макета на внешнее устройство производится мгновенно и не требует при печати дополнительного контроля, что обеспечивает при выполнении рутинных вспомогательных операций экономию времени, которое может быть использовано для решения творческих задач.
В ряде случаев полезной может оказаться возможность замены вывода чертежей на твердые носители формированием компактных файлов специального формата, которые позволяют без запуска AutoCAD просматривать их содержимое и делать распечатки. Поскольку эти файлы не допускают редактирования, вы, передавая чертежи заказчику в такой форме, будете уверены, что ваши проектные материалы не будут использованы конкурентами.
Презентационная визуализация. Презентационная визуализация - чрезвычайно важная часть строительного проектирования. Она выполняется как на ранних стадиях для привлечения заказчика, так и в конце работы над проектом с целью его согласования. Чаще всего, для такого рода работ применяют специальные визуализационные программы. Тем не менее, AutoCAD содержит достаточно мощный модуль для подготовки фотореалистичных изображений, позволяющий гибко настраивать точку зрения и освещение, назначать частям моделей визуальные свойства реальных материалов, применять специальные эффекты, имитирующие естественные условия наблюдения, вписывать создаваемые модели в фотографический фон, воспроизводящий реальное окружение. В большинстве случаев этих возможностей оказывается достаточно для работы с создаваемыми объектами.
2.2 Модели жизненного цикла ПО
Жизненный цикл ПО (ЖЦ ПО) – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации [32].
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
– каскадная модель;
– спиральная модель.
2.2.1 Каскадная модель
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Схематически, каскадный способ разработки представлен на рисунке 3.
Рисунок 3 – Каскадная схема разработки ПО
Положительные стороны применения каскадного подхода заключаются в следующем:
– на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
– выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате, реальный процесс создания ПО принимает вид, изображенный на рисунке 4.
Рисунок 4 – Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания.
Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
2.2.2 Спиральная модель
Для преодоления вышеперечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. Этапы жизненного цикла при использовании спиральной модели представлены на рисунке 5.
Рисунок 5 – Спиральная модель жизненного цикла
На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали.
Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла ̶ определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
После рассмотрения наиболее распространенных моделей жизненного цикла, за основу при разработке модуля для автоматизации проектирования оконных и витражных конструкций принята спиральная модель, как наиболее точно отражающая поставленные к разработке проекта задачи.
При разработке модуля в рамках спиральной модели воспользуемся элементами методологии быстрой разработки приложений RAD (Rapid Application Development), под которой понимают процесс разработки, содержащий три основных элемента: небольшая команда разработчиков, короткий и тщательно проработанный производственный график длинной в два-четыре месяца, повторяющийся цикл разработки, при котором, по мере того, как приложение начинает обретать форму, разработчики запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
По методологии RAD жизненный цикл ПО состоит из четырёх фаз: фаза определения требований и анализа, фаза проектирования, фаза реализации, фаза внедрения.
Целесообразность применения технологии RAD обусловлена приоритетными направлениями разработки проекта:
̶ необходимость выполнения работы в сжатых временных рамках, то есть создание системы для сегодняшних производственных реалий предприятия-заказчика;
̶ нечетко поставленные требования к разрабатываемому модулю, меняющиеся по ходу разработки;
̶ ограниченность бюджета и отсутствие крупной команды разработчиков;
̶ интерфейс пользователя является главным фактором, его простота и понятность, быстрое согласование с заказчиком;
̶ разбиение проекта на функциональные модули;
̶ низкая вычислительная сложность ПО.
Технология RAD предусматривает привлечение заказчика к разработке уже на ранних стадиях. Это подразумевает полное выполнение функциональных требований заказчика с учетом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения разработанного модуля. Это значит, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.
Основными принципами при разработке ПО по методологии RAD являются:
̶ инструментарий при проектировании должен быть нацелен на минимизацию времени разработки;
̶ постоянное создание прототипов для уточнения требований заказчика;
̶ цикличность разработки, при которой каждая новая версия модуля основывается на оценке результата работы предыдущей версии заказчиком;
̶ минимизация времени разработки новых версий уже готового модуля, за счёт переноса уже готовых блоков и добавления функциональности в новую версию.
Модель разработки приложений на основе методологии RAD отображена на схеме, представленной на рисунке 6.
Рисунок 6 – Модель быстрой разработки приложений (RAD)
Разберем фазы поподробнее.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
