курсовая. СОДЕРЖАНИЕ. Инструментальное программное обеспечение. История
 Скачать 1.22 Mb.
|
|
ТЕМА: Методологии разработки ПО. Рассмотрим понятия методологии, метода и средства. Определение 1: Метод (от греч. methodos - способ исследования или познания, теория или учение) - прием или система приемов практического осуществления чего-нибудь в какой-либо предметной области, совокупность приемов или операций практического или теоретического освоения действительности, подчиненных решению конкретных задач. Метод включает средства- с помощью чего осуществляется действие и способы- каким образом осуществляется действие. Определение 2: Методология- это система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения. Методология - это реализация стандарта. Сами стандарты лишь говорят о том, что должно быть, оставляя свободу выбора и адаптации. Конкретные вещи реализуются через выбранную методологию. Именно она определяет, как будет выполняться разработка. Существует много успешных методологий создания программного обеспечения. Выбор конкретной методологии зависит от размера команды, от специфики и сложности проекта, от стабильности и зрелости процессов в компании и от личных качеств сотрудников. Методологии представляют собой ядро теории управления разработкой программного обеспечения. В зависимости от используемой модели жизненного цикла методологии делятся на: - водопадные (каскадные); - итерационные (спиральные). Также существует и более общая классификация на: - прогнозируемые; - адаптивные. Прогнозируемые методологии фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок проекта. Команда с трудом реагирует на возможные изменения. План оптимизирован исходя из состава работ и существующих требований. Изменение требований может привести к существенному изменению плана, а также дизайна проекта. Часто создается специальный комитет по «управлению изменениями», чтобы в проекте учитывались только самые важные требования. Адаптивные методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать будущее проекта. Существует точный план лишь на ближайшее время. Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах. Каскадная разработка или модель водопада (англ. waterfall model) - модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. Принципиальной особенностью каскадного подхода является: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии (рис. 1). Рис. 1. Каскадная модель жизненного цикла. Каждая стадия завершается выпуском комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания. Преимущества применения каскадного способа: - на каждой стадии формируется законченный набор проектной документации, отвечающий требованиям полноты и согласованности; - выполняемые в логической последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении электронных информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В то же время этот подход обладает рядом недостатков, вызванных, прежде всего тем, что реальный процесс создания программного обеспечения никогда полностью не укладывается в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на предыдущих стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений (рис. 2). Изображенную схему можно отнести к отдельной модели - модели с промежуточным контролем, в которой межстадийные корректировки обеспечивают большую надежность по сравнению с каскадной моделью, хотя увеличивают весь период разработки. Основным недостатком каскадной модели является существенное запаздывание с получением результатов и, как следствие, высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей. Это объяснятся двумя причинами: - пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; - за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе. Рис. 2. Каскадная модель ЖЦ на практике. В рамках каскадного подхода требования к разрабатываемому продукту фиксируются в виде технического задания на все время его создания, а согласование получаемых результатов с пользователями производится только в точках, планируемых после завершения каждой стадии (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. Пользователи могут получить систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь. Для преодоления перечисленных проблем в середине 80-х годов была предложена спиральная модель жизненного цикла (рис.3). Рис. 3. Спиральная (итерационная) модель ЖЦ. Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков от необходимости точного и полного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. Спиральная модель - классический пример применения эволюционной стратегии конструирования. Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент - анализ риска, отсутствующий ранее. Спиральная модель определяет четыре действия, представляемые отдельными секторами спирали: 1. Планирование - определение целей, вариантов и ограничений. 2. Анализ риска - анализ вариантов и распознавание/выбор риска. 3. Конструирование - разработка продукта следующего уровня. 4. Оценивание - оценка заказчиком текущих результатов конструирования. Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте проектирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации. Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. При итеративном способе недостающую часть работы можно выполнять на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Спиральная модель не исключает каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными. Основная проблема спирального цикла - определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий ЖЦ. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных на предыдущих проектах, и личного опыта разработчиков. Достоинства спиральной модели: - наиболее реально (в виде эволюции) отображает разработку программного обеспечения; - позволяет явно учитывать риск на каждом витке эволюции разработки; - включает шаг системного подхода в итерационную структуру разработки; - использует моделирование для уменьшения риска и совершенствования программного изделия. Недостатки спиральной модели: - новизна (отсутствует достаточная статистика эффективности модели); - повышенные требования к заказчику; - трудности контроля и управления временем разработки. На сегодняшний день можно выделить следующие итеративные методологии разработки программного обеспечения: - Rational Unified Process (RUP) - Гибкие методологии разработки (SCRUM, KANBAN, DSDM, MSF, ALM, XP) Гибкая методология разработки (англ. Agile software development). Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки. Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Одной из наиболее известных и передовых гибких методик является методология SCRUM. SCRUM- методология, предназначенная для небольших команд (до 10 человек). Весь проект делится на итерации (спринты) продолжительностью 30 дней каждый. Выбирается список функций системы, которые планируется реализовать в течение следующего спринта. Самые важные условия - неизменность выбранных функций во время выполнения одной итерации и строгое соблюдение сроков выпуска очередного релиза, даже если к его выпуску не удастся реализовать весь запланированный функционал. Руководитель разработки проводит ежедневные 20 минутные совещания, которые так и называют — scrum, результатом которых является определение функции системы, реализованных за предыдущий день, возникшие сложности и план на следующий день. Такие совещания позволяют постоянно отслеживать ход проекта, быстро выявлять возникшие проблемы и оперативно на них реагировать. KANBAN – гибкая методология разработки программного обеспечения, ориентированная на задачи. Основные правила: - визуализация разработки: o разделение работы на задачи; o использование отметок о положение задачи в разработке; - ограничение работ, выполняющихся одновременно, на каждом этапе разработки; - измерение времени цикла (среднее время на выполнение одной задачи) и оптимизация процесса. Преимущества KANBAN: - уменьшение числа параллельно выполняемых задач значительно уменьшает время выполнения каждой отдельной задачи; - быстрое выявление проблемных задач; - вычисление времени на выполнение усредненной задачи. DYNAMIC SYSTEM DEVELOPMENT METHOD (DSDM) появился в результате работы консорциума из 17 английских компаний. Целая организация занимается разработкой пособий по этой методологии, организацией учебных курсов, программ аккредитации и т.п. Кроме того, ценность DSDM имеет денежный эквивалент. Все начинается с изучения осуществимости программы и области ее применения. В первом случае, вы пытаетесь понять, подходит ли DSDM для данного проекта. Изучать область применения программы предполагается на короткой серии семинаров, где программисты узнают о той сфере бизнеса, для которой им предстоит работать. Здесь же обсуждаются основные положения, касающиеся архитектуры будущей системы и план проекта. Далее процесс делится на три взаимосвязанных цикла: цикл функциональной модели отвечает за создание аналитической документации и прототипов, цикл проектирования и конструирования — за приведение системы в рабочее состояние, и наконец, последний цикл — цикл реализации — обеспечивает развертывание программной системы. Базовые принципы, на которых строится DSDM: - активное взаимодействие с пользователями; - частые выпуски версий; - самостоятельность разработчиков в принятии решений; - тестирование в течение всего цикла работ. Как и большинство других гибких методологий, DSDM использует короткие итерации, продолжительностью от двух до шести недель каждая. Особый упор делается на высоком качестве работы и адаптируемости к изменениям в требованиях. MICROSOFT SOLUTIONS FRAMEWORK (MSF) - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения. Базовые концепции и принципы модели процессов MSF: - единое видение проекта - все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат, всем должна быть понятна цель проекта; - управление компромиссами - поиск компромиссов между ресурсами проекта, календарным графиком и реализуемыми возможностями; - гибкость – готовность к изменяющимся проектным условиям; - концентрация на бизнес-приоритетах - сосредоточенность на той отдаче и выгоде, которую ожидает получить потребитель решения; - поощрение свободного общения внутри проекта; - создание базовых версии — фиксация состояния любого проектного артефакта, в том числе программного кода, плана проекта, руководства пользователя, настройки серверов и последующее эффективное управление изменениями, аналитика проекта. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Application Lifecycle Management (ALM) - разработанная и поддерживаемая компанией Borland. Extreme Programming (XP) -экстремальное программирование, поддерживаемое открытым сообществом независимых разработчиков. Подход RAD Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих: - небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива; - короткого, но тщательного проработанного производственного графика (до 3 месяцев); - повторяющегося цикла, при котором разработчики по мере того, как приложение начинает приобретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в проектировании, программировании и тестировании ПО, способных хорошо взаимодействовать с конечным пользователем и трансформировать их предложения в рабочие прототипы. ЖЦ ПО в соответствии с подходом RAD включает 4 стадии: 1. Анализ и планирование требований предусматривает действия: - определение функций, которые должна выполнять система; - выделение наиболее приоритетных функций, требующих проработки в первую очередь; - описание информационных потребностей. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Кроме того, на данной стадии реализуются следующие задачи: - ограничивается масштаб времени; - устанавливаются временные рамки для каждой из последующих стадий. Определяется сама возможность реализации проекта в заданных рамках финансирования, на имеющихся аппаратных средствах. Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО. 2. Проектирование.На этой стадии часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE - средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии: - более детально рассматриваются процессы системы; - при необходимости для каждого элементарного процесса создается частичный прототип: экранная форма, диалог, отчет, устраняющий неясности и неоднозначности; - устанавливаются требования разграничения доступа к данным; - определяется состав необходимой документации. После детального определения состава процессов оценивается количество так называемых функциональных точек разрабатываемой системы и принимается решение о разделении ЭИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое время (до 3 месяцев). Под функциональной точкой понимается любой из следующих элементов разрабатываемой системы: - входной элемент приложения (входной документ или экранная форма); - выходной элемент приложения (отчет, документ, экранная форма) - запрос (пара «вопрос/ответ»); - логический файл (совокупность записей данных, используемых внутри приложения); - интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него). Далее проект распределяется между различными командами разработчиков. Опыт показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций. Результатом данной стадии должно быть: - общая информационная модель системы; - функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; - точно определенные интерфейсы между автономно разрабатываемыми подсистемами; - построенные прототипы экранных форм, отчетов, диалогов. 3. Реализация.На этой стадиивыполняется непосредственно сама быстрая разработка приложения. Разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требования к надежности, производительности и т.д.). Пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением следующих работ: - осуществляется анализ использования данных и определяется необходимость их распределения; - Производится физическое проектирование базы данных; - формируются требования к аппаратным ресурсам; - устанавливаются способы увеличения производительности; - завершается разработка документации проекта. Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям. 4. Внедрение.На этой стадиипроизводится обучение пользователей, организационные изменения и параллельно с внедрением новой системы продолжается эксплуатация существующей системы (до полного внедрения новой). Так как стадия реализации достаточно продолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на стадии проектирования системы. Приведенная схема разработки ЭИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: - разрабатывается совершенно новая система; - уже было проведено обследование организации и существует модель ее деятельности; - в организации уже существует некоторая ЭИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой системой. Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки. Подход RAD не применим для построения сложных расчетных программ, операционных систем. Не годится этот подход и для приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы и приложений, от которых зависит безопасность людей (например программа управления самолетом или атомной станцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Итак, перечислим основные принципы подхода RAD. - Разработка приложений итерациями. - Необязательность полного завершения работ на каждой стадии ЖЦ ПО. - Обязательность вовлечения пользователей в процесс разработки ЭИС. - Целесообразность применения CASE - средств, обеспечивающих целостность проекта и генерацию кода приложений. - Целесообразность применения средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы. - Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей. - Тестирование и развитие проекта, осуществляемые одновременно с разработкой. - Ведение разработки немногочисленной хорошо управляемой командой профессионалов. - Грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. Таким образом, существует множество различных методологий и подходов при разработке программного обеспечения, они не универсальны и описываются различными принципами. Выбор методологии и подхода при разработке конкретного проекта зависит от предъявляемых требований. |