Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
внедрение. На этой стадии система устанавливается, подготавливается к началу эксплуатации. Происходит подготовка персонала; 6) эксплуатация. Поддержка системы, планирование будущих дополнений и изменений. Интересно отметить, что Oracle не рассматривает такую стадию суще- ствования ИС, как снятие с эксплуатации. То есть разработчик, применяющий методику и ПО Oracle, автоматически «подсаживается» на него. Другое дело, что удобство средств разработки во многом оправдывает такую зависимость. Особенности методики Oracle CDM: 1) по степени адаптивности методика CDM предлагает три модели жизнен- ного цикла: классическая – предусматривает все этапы, быстрая разра- ботка – с использованием инструментов моделирования и программиро- вания Oracle, облегченный подход – для малых проектов; 2) методикой не предусмотрено включение дополнительных задач, которые не оговорены в CDM, не предусмотрена тем более привязка их к осталь- ным. Кроме того, невозможно удаление задачи и порождаемых ею доку- ментов, которое не было предусмотрено ни в одной из трёх моделей жиз- ненного цикла ИС, невозможно изменение последовательности выполне- ния задач относительно предложенной; 3) модель жизненного цикла ИС в Oracle CDM является, по сути, каскадной; 4) методика не является обязательной, хотя и является фирменным стандар- том, однако в случае использования ПО Oracle иной подход маловероя- тен; 5) методика опирается на использование ПО разработчика от Oracle, при- способление её к другим средствам затруднительно. 66 Спиральная модель ЖЦ Поскольку программные проекты отличаются от других, например, стро- ительных проектов, то и управлять ими тоже нужно по-другому. Наглядным подтверждением этого является тот факт, что к концу 1980-х гг. Министерство обороны США начало испытывать серьезные трудности с разработкой ПО в соответствии с жесткой, основанной на директивных документах и предусмат- ривающей один проход модели, как это требовалось стандартом DoD-Std- 2167A. Проведенная позже в 1999 проверка по выборке ранее утвержденных в Министерстве обороны проектов дала удручающие результаты. Из общего чис- ла входящих в выборку проектов, на реализацию которых было выделено 37 млрд долл., 75% проектов закончились неудачей или выделенные на них сред- ства не были использованы, и только 2% выделенных средств были использо- ваны без значительной модификации проектов. В результате в конце 1987 г. Министерство отступило от стандартов на базе каскадной модели и допустило применение итерационного подхода. Истоки концепции итерационной разработки прослеживаются в относя- щихся к 1930-м годам работах эксперта по проблемам качества продукции Уол- тера Шеварта из компании Bell Labs, который предложил ориентированную на повышение качества методику, состоящую из серии коротких циклов шагов по планированию, реализации, изучению и действию (plan-do-study-act, PDSA). С 1940- х годов энергичным поборником PDSA стал известный авторитет в обла- сти качества Эдварде Деминг. В более поздних работах PDSA была исследова- на применительно к разработке ПО. В середине 1980-х годов Барри Боэм предложил свой вариант итерацион- ной модели под названием «спиральная модель» (spiral model). Принципиальные особенности спиральной модели: • отказ от фиксации требований и назначение приоритетов пользователь- ским требованиям; 67 • разработка последовательности прототипов, начиная с требований наивысшего приоритета; • идентификация и анализ риска на каждой итерации; • использование каскадной модели для реализации окончательного прото- типа; • оценка результатов по завершении каждой итерации и планирование сле- дующей итерации. При использовании спиральной модели прикладное ПО создается в не- сколько итераций (витков спирали) методом прототи-пирования. Под прото- типом понимается действующий программный компонент, реализующий от- дельные функции и внешние интерфейсы разрабатываемого ПО. Создание про- тотипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производит- ся тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность пре- кращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким обра- зом, углубляются и последовательно конкретизируются детали проекта, и в ре- зультате выбирается обоснованный вариант, который доводится до реализации. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 1.8.), делающая упор на начальные этапы ЖЦ: анализ и про- ектирование. 68 Рис. 1.8. Спиральная модель ЖЦ На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фраг- мента или версии ПО, на нем уточняются цели и характеристики проекта, опре- деляется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализа- ции. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограниче- ния на каждый из этапов жизненного цикла. Переход осуществляется в соот- ветствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. 69 В рамках спиральной модели была разработана методология RAD(Rapid Application Development, 1980 – разработка подхода, James Martin в IBM, 1991 – публикация), использующая инструментальные средства быстрой разработки ПО. Методология быстрой разработки приложений RAD Методология быстрой разработки приложений RAD(Rapid Application Development) основана на использовании средств быстрой разработки при- ложений и ориентирована на использование спиральной моделиЖЦ. При про- ектировании использует объектно-ориентированные методы описания пред- метной области. Специфика RAD: 1) небольшая команда программистов (от 2 до 10 человек). При этом коман- да разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестирова- нии ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения ко- нечных пользователей; 2) короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); 3) повторяющийся цикл, при котором разработчики, по мере того, как при- ложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком; Основные принципы методологии RAD: • разработка приложений итерациями; • необязательность полного завершения работ на каждом из этапов жиз- ненного цикла; • обязательное вовлечение пользователей в процесс разработки ИС; • обязательное применение CASE-средств, обеспечивающих целостность проекта; 70 • применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы; • необходимое использование генераторов кода; • использование прототипирования, позволяющее полнее выяснить и удо- влетворить потребности конечного пользователя; • тестирование и развитие проекта, осуществляемые одновременно с раз- работкой; • ведение разработки немногочисленной хорошо управляемой командой профессионалов (обычно от 2 до 10 человек); • грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: 1) анализа и планирования требований; 2) проектирования; 3) построения; 4) внедрения. 1. На фазе анализа и планирования требований определяются функции системы, выделяются наиболее приоритетные из них, требующие проработки в первую очередь, описываются информационные потребности. Определение требований выполняется в основном пользователями системы при помощи спе- циалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финан- сирования, на данных аппаратных средствах и т.п. Результат данной фазы: 1) список и приоритетность функций будущей ИС; 2) предварительные функциональные и информационные модели ИС. 2. На фазе проектирования пользователи принимает участие в техниче- ском проектировании системы под руководством специалистов-разработчиков при помощи CASE-средств. Уточняются и дополняются требования к системе, которые не были выявлены на предыдущей фазе, а именно: 71 • более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого эле- ментарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности; • определяются требования разграничения доступа к данным; • определяется набор необходимой документации; • оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, под- дающиеся реализации одной командой разработчиков за приемлемое для RAD- проектов время (порядка 60 – 90 дней); • с использованием CASE-средств проект распределяется между различ- ными командами (делится функциональная модель). Результат фазы проектирования: 1) общая информационная модель системы; 2) функциональные модели системы в целом и подсистем, реализуемых от- дельными командами разработчиков; 3) точно определенные с помощью CASE-средства интерфейсы между авто- номно разрабатываемыми подсистемами; 4) построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE- средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при пе- редаче информации о проекте с этапа на этап может произойти фактически не- контролируемое искажение данных. Применение единой среды хранения ин- формации о проекте позволяет избежать этой опасности. В отличие от традиционного подхода, при котором использовались спе- цифические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип раз- 72 вивается в часть будущей системы. Таким образом, на следующую фазу пере- дается более полная и полезная информация. 3. На фазе построения выполняется непосредственно сама быстрая раз- работка приложения. На данной фазе разработчики производят итеративное по- строение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информа- цию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в про- цессе разработки. После окончания работ каждой отдельной команды разработ- чиков производится постепенная интеграция данной части системы с осталь- ными, формируется полный программный код, выполняется тестирование сов- местной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершение физического проектирования системы может вы- глядеть следующим образом: 1) определяется необходимость распределения данных; 2) производится анализ использования данных; 3) производится физическое проектирование базы данных; 4) определяются требования к аппаратным ресурсам; 5) определяются способы увеличения производительности; 6) завершается разработка документации проекта. Результат фазы построения – готовая система, удовлетворяющая всем согласованным требованиям. 4. На фазе внедрения производится обучение пользователей, организацион- ные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. 73 Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, таких как: • разрабатывается совершенно новая система; • уже было проведено обследование предприятия и существует модель его деятельности; • на предприятии уже существует некоторая ИС, которая а)может быть ис- пользована в качестве начального прототипа или б)должна быть интегри- рована с разрабатываемой. Ограничения методологии RAD. Как и любая методология, RAD, не- смотря на все достоинства, не может претендовать на универсальность. Ее при- менение наиболее эффективно при выполнении сравнительно небольших си- стем, разрабатываемых для вполне определенного предприятия. Методология RAD неприменима: 1) для создания типовых ИС, которые не являются законченным программ- ным продуктом, а представляют собой совокупность типовых элементов ИС, и где большое значение имеют такие показатели проекта, как управ- ляемость и качество, что может войти в противоречие с простотой и ско- ростью разработки. Для типовых проектов, которые обычно централизо- ванно сопровождаются и могут быть адаптированы к различным про- граммно-аппаратным платформам, СУБД, коммуникационным средствам, а также интегрироваться с существующими разработками, необходим вы- сокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки; 2) для построения программ, требующих написания большого объема уни- кального кода, например: сложных расчетных программ, операционных систем, программ управления сложными инженерно-техническими объ- ектами; 3) для разработки приложений, в которых интерфейс пользователя является вторичным, т.е. отсутствует наглядное определение логики работы си- 74 стемы, например для создания приложений реального времени, драйверов и служб; 4) для разработки систем, от которых зависит безопасность людей, напри- мер, систем управления транспортом или АЭС. Это обусловлено тем, что итеративный подход, являющийся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособны. Итерационный подход Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который по существу представляет собой рациональное сочетание этих моделей (рис. 1.9). Рис. 1.9. Итеративная модель ЖЦ Различные варианты итерационного подхода реализованы в большинстве современных методов: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), XR и др. 1. RUP (Rational Unified Process, компания Rational Software – подразделе- ние IBM, 2003) – использует итеративную модель разработки, включаю- 75 щую четыре фазы (начало, исследование, построение, внедрение), разби- тых на итерации, каждая из которых завершается получением промежу- точной, но функциональной версии конечного продукта. RUP опирается на интегрированный комплекс инструментальных средств Rational Suite, в состав которого, кроме самой технологии RUP как продукта, входят та- кие компоненты, как: • Rational Rose – средство визуального моделирования (анализа и проек- тирования), использующее язык UML; • Rational XDE – средство анализа и проектирования, интегрируемое с платформами MS Visual Studio .NET и IBM WebSphere Studio Application Developer и др.; 2. MSF (Microsoft Solution Framework, 1993 – v.1.0, 2002 – v.1.0, 2005 – v .4.0) сходна с RUP, так же включает четыре фазы: анализ, проектирова- ние, разработка, стабилизация, является итерационной и предполагает использование объектно-ориентированного моделирования. MSF в срав- нении с RUP в большей степени ориентирована на разработку бизнес- приложений. 3. Методология XP (Extreme Programming, Экстремальное программирова- ние, разработана в 1996, опубликована в 1999 г.). Разработка представля- ет собой итеративный процесс, где фазы разбиваются на «экстремально» малые шаги. В основе методологии – командная работа и эффективная коммуникация между заказчиком и исполнителем. 1.6. Парадигмы проектирования ИС В настоящее время известны две парадигмы проектирования, использу- ющие два различных подхода к описанию систем: • структурная (процессно-ориентированная), основанная на каскадной (водопадной) модели жизненного цикла ИС (см. рис. 1.7); |