Использование модели проектирования программного обеспечения "Библиотечный фонд Николаевской библиотеки им. Шуры Кобера и Вити Хоменко"

Размещено на http://www.allbest.ru

3

Лабораторная работа №1

Тема: Использование модели проектирования программного обеспечения «Библиотечный фонд николаевской библиотеки им. Шуры Кобера и Вити Хоменко»

Цель: Использование навыков выбора модели проектирования для конкретного проекта.

Задание:

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

Составить общий календарный план выполнения этапов проекта программного обеспечения.

Разработать и обосновать требования к ПО, которое разрабатывается.

Создать устав проекта согласно теме работы.

Теоретический материал

Место КПЗ в жизненном цикле программной системы.

КПЗ в общем случае включает:

Определение проблемы

Выработка требований

Создание плана конструирования

Разработка архитектуры ПО или высокоуровневое проектирование

Детальное проектирование

Кодирование и отладка

Блочное тестирование

Итнеграционное тестирование

Интеграция

Тестирование системы

Коррекционное сопровождение

При решении конкретной задачи в процессе разработки ПО не обходимо:

Проверить выполнение всех тренований

Определить способы тестирования

Аккуратно подойти к созданию имен переменных и констант

После проведения блочного тестирования и отладки собственного кода призвести осмотр кода всеми членами разработки низкуровневых программных структур

Интегрировать программные компоненты и оптимизировать код для повышения быстродействия и снижения использования ресурсов.

При конструировании программного обеспечения необходимо минимизировать сложность; предусмотреть ожидаемые перемены; конструировать с возможностью проверки; использовать стандарты при конструировании (включают в себя: коммуникационные методы(стандарты форматов документов); языки программирования и стили кодирования; платформы; инструменты).

Модели жизненного цикла

В рамках специфических моделей жизненного цикла, которые предписывают правила организации разработки ПО в рамках данной отрасли или организации, определяются более конкретные процессы разработки. Отличаются они от стандартов, прежде всего, большей детальностью и четким описанием связей между отдельными видами деятельности, определением потоков данных (документов и артефактов) в ходе жизненного цикла. Таких моделей довольно много, ведь фактически каждый раз, когда некоторая организация определяет собственный процесс разработки, в качестве основы этого процесса разрабатывается некоторая модель жизненного цикла ПО. Рассмотрим несколько моделей.

Каскадная модель

Наиболее широко известной и применяемой долгое время осталавась так называемая каскадная или водопадная (waterfall) модель жизненного цикла, которая, как считается, была впервые четко сформулирована в работе и впоследствии запечалена в стандартах министерства обороны США в 70-80-х годах ХХ века. Эта модель предполагает последовательное выполнение различных видов деятельности, начиння с выработки тренований и заканчивая сопровождением, с четким определением границ между етапами, на которых набор документов, созданный на предыдущей стадии, передается в качестве входных даннях для следующей. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла. Последовательность шагов разработки показана на рис. 1. “Классическая” каскадная модель предполагает только движение вперед по этой схеме: все необходимое для проведения очередной деятельности должно быть подготовленно в ходе предшествующих работ.

Рис. 1. Последовательность разработки согласно “классической” каскадной модели.

При реальной работе в соответствии с моделью, допускающей движение только в одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями окружения, в котором разрабатывается ПО (это могуть быть изменения требований, смена подрядчиков, изменения политик, разрабатывающей или эксплуатирующей организации, изменения отраслевых стандартов, появление конкурирующих продуктов и пр.).

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

Рис. 2. Ход разработки по каскадной модели

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

Итеративная модель

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

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

Рис. 3. Возможный ход работ по итеративной модели

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

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

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

Спиральная модель

Развитием идеи итераци является спиральная модель жизненного цикла ПО, предложенная Боэмом (Boehm). Она предлагает кардую итерацию начинать с выделения целей и планирования очередной итерации, определения основних альтернатив и ограничений при ее выполнении, их оценки, а также оценки возникающих рисков и определения способов избавления от них, а заканчивать итерацию оценкой результатов проведеннях в ее рамках работ.

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

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

Рис. 4. Изображение хода работ по спиральной модели согласно Боему.

Рис. 4 показывает возможное развитие проекта по спиральной модели. Количество витков, а также расположение и набор видов деятельности в правом нижнем квадрате могут изменяться в зависимости от результатов планирования и анализа рисков, проводимых на предыдущих этапах.

Достоинства:

- нет фиксированных этапов;

- эта модель может включать в себя любые другие модели на каждом витке спирали:

- прототипирование может использоваться при нечетком определении требований;

- каскадная модель в случае последовательного выполнения некоторых этапов;

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

Недостатки:

- сложная автоматизация процессов разработки;

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

Общий календарный график выполнения этапов проекта

Для своевременного завершения разработки ПО проект был разбит на несколько этапов и для этих этапов был составлен общий календарный график, который представлен в таблице 1.

Таблица 1. Общий календарный график выполнения этапов проекта

Устав проекта

Требования к проекту:

вывод на экран списка авторов;

вывод на экран поля для введения фамилии автора для поиска по ней данных;

вывод на экран поля для введения названия книги и поиска по ней данных;

вывод на экран информации о книге (автор, название, название издательства, место издания, год выпуска издания).

Модель жизненного цикла

Было выбрано итеративную модель жизненного цикла программного обеспечения «Библиотечный фонд николаевской библиотеки им. Шуры Кобера и Вити Хоменко» из-за возможности отображения поэтапной разработки. Модель отображает поочередной переход от одного этапа к следующему; на следующей итерации либо первый кусок переделывается, либо разрабатывается следующий, который может зависеть от первого, либо как-то совмещается доработка первого куска с добавлением новых функций. В результате, на каждой итерации можно анализировать промежуточные результаты работ и реакцию на них всех заинтересованных лиц, включая пользователей, и вность изменения на следующих итерациях.

Финансовые показатели проекта

Затраты на создание и эксплуатацию программы составят около 3000 грн. Конкретные варианты организации программы внедрения могут быть предметом переговоров между Заказчиком и Исполнителем.

Технические требования на продукт

Продукт «Библиотечный фонд николаевской библиотеки им. Шуры Кобера и Вити Хоменко» разработан на языке программирования Java и может эффективно работать на любой UNIX или Windows-платформе.

каскадная модель программный

WBS-структура проекта

Таблица 2. WBS-структура проекта

Вывод:

При выполнении лабораторной работы я рассмотрела разновидности моделей жизненного цикла программного обеспечения, из которых выбрала модель для выполнения проекта, а так же составила график выполнения проекта, устав проекта и разработала требования к ПО и составила WBS-структуру проекта.

Размещено на Allbest.ru