практические работы. Методические указания к лабораторной работе (1). Федерации федеральное агентство по образованию государственное
 Скачать 0.67 Mb.
|
Спиральная модель ЖЦСпиральнаямодельЖЦ(рисунок 5), делает упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются де- тали проекта и в результате выбирается обоснованный вариант, который дово- дится до реализации.  Рисунок 5 – Спиральная модель ЖЦ Методология разработки ПО RADОдним из возможных подходов к разработке ПО в рамках спиральной мо- дели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять из себя группу профессио- налов, имеющих опыт в анализе, проектировании, генерации кода и тестирова- нии ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользо- вателей. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: фаза анализа и планирования требований; фаза проектирования; фаза построения; фаза внедрения. На фазе анализаипланированиятребованийпользователи системы опре- деляют функции, которые она должна выполнять, выделяют наиболее приори- тетные из них,требующие проработки в первую очередь,описывают информа- ционные потребности. Определение требований выполняется в основном сила- ми пользователей под руководством специалистов-разработчиков. Ограничива- ется масштаб проекта,определяются временные рамки для каждой из последу- ющих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных сред- ствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ПО, предварительные функциональные и информационные модели ПО. На фазе проектированиячасть пользователей принимает участие в техни- ческом проектировании системы под руководством специалистов-разработчи- ков. CASE-средства используются для быстрого получения работающих прото- типов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе,которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анали- зируется и, при необходимости, корректируется функциональная модель. Каж- дый процесс рассматривается детально. При необходимости для каждого эле- ментарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования раз- граничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ПО на подсистемы,поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время – порядка 60 – 90 дней. С использованием CASE-средств проект распределяется между различными ко- мандами (делится функциональная модель). Результатом данной фазы должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные с помощью CASE-средства интерфейсы между ав- тономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов. На фазе построения разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично форми- руется при помощи автоматических генераторов, получающих информацию не- посредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды разработчиков произ- водится постепенная интеграция данной части системы с остальными, форми- руется полный программный код, выполняется тестирование совместной рабо- ты данной части приложения с остальными, а затем тестирование системы в це- лом. Завершается физическое проектирование системы: определяется необходимость распределения данных; производится анализ использования данных; производится физическое проектирование базы данных; определяются требования к аппаратным ресурсам; определяются способы увеличения производительности; завершается разработка документации проекта. Результатом фазы является готовая система, удовлетворяющая всем со- гласованным требованиям. На фазевнедренияпроизводится обучение пользователей,организацион- ные изменения и параллельно с внедрением новой системы осуществляется ра- бота с существующей системой (до полного внедрения новой). Приведенная схема разработки ПО не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было про- ведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ПО, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабаты- ваемой. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подоб- ная метрика не зависит от языка программирования, на котором ведется разра- ботка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ПО с максимальным повтор- ным использованием программных компонентов, определяется следующим об- разом:
Проблемы межу пользователем и программистом и способы их преодоленияВ заключении отметим, что разработка ПО носит творческийхарактер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регла- ментированных действий. Тем самым эта разработка ближе к процессу проек- тирования каких-либо сложных устройств,но никак не к их массовому произ- водству. Этот творческий характер разработки ПО сохраняется до самого ее конца. Как же преодолеет разногласии между пользователем и разработчиком, которые несомненно возникнут в процессе работе? Как обеспечить, чтобы ПО выполняло то, что пользователю разумно ожидать от него? Для этого разработ- чикам необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых,его уровень подготовки и окружающую его обстановку.Ясное опи- сание соответствующей сферы деятельности пользователя или интересующей его проблемной области во многом облегчает достижение разработчиками этой цели. При разработке ПО следует привлекать пользователя для участия в про- цессах принятия решений, а также тщательно освоить особенности его работы. С учетом этого при разработки ПО необходимо применять везде, где это воз- можно смежный контроль и сочетание как статических, так и динамических ме- тодов контроля. Смежный контроль означает, проверку полученного документа лицами, не участвующими в его разработке, с двух сторон: во-первых, со стороны авто- ра исходного для контролируемого процесса документа,и,во-вторых,лицами, которые будут использовать полученный документ в качестве исходного в по- следующих технологических процессах. Такой контроль позволяет обеспечи- вать однозначность интерпретации полученного документа. Сочетание статических и динамических методов контроля означает, что нужно не только контролировать документ как таковой, но и проверять, какой процесс обработки данных он описывает. Реальное применение любой технологии проектирования, разработки и сопровождения ПО в конкретной организации и конкретном проекте невозмож- но без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта.К таким стандартам относятся следу- ющие: стандарт проектирования; стандарт оформления проектной документации; стандарт пользовательского интерфейса. Стандартпроектированиядолженустанавливать: набор необходимых моделей (диаграмм) на каждой стадии проектиро- вания и степень их детализации; правила фиксации проектных решений на диаграммах,в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их за- полнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т.д.; требования к конфигурации рабочих мест разработчиков, включая на- стройки операционной системы, настройки CASE-средств, общие на- стройки проекта и т.д.; механизм обеспечения совместной работы над проектом,в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т.д. вать: Стандартоформленияпроектнойдокументациидолженустанавли- комплектность, состав и структуру документации на каждой стадии проектирования; требования к ее оформлению (включая требования к содержанию раз- делов, подразделов, пунктов, таблиц и т.д.), правила подготовки, рассмотрения, согласования и утверждения доку- ментации с указанием предельных сроков для каждой стадии; требования к настройке издательской системы, используемой в каче- стве встроенного средства подготовки документации; требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; правила использования клавиатуры и мыши; правила оформления текстов помощи; перечень стандартных сообщений; правила обработки реакции пользователя. |