Модели разработки программного обеспечения

Содержание:

1.Введение

В настоящее время вряд ли найдется человек у которого нет компьютера\ ноутбука, планшета или смартфона. Данные технические устройства уже стали неотъемлемой частью жизни человека. Компьютер из всех перечисленных устройств является самым универсальным. Мы сталкиваемся с ним и дома и на работе, т.к он является универсальным устройством по вводу и любой обработки информации. Но на сколько бы компьютер не был бы универсальным устройством он не сможет работать без программного обеспечения. Устанавливая определенные программы можно создать рабочее место для бухгалтера, менеджера, инженера и т. д.

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

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

2.Понятие и жизненный цикл программного обеспечения

2.1 Понятие программное обеспечение

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

Для полного понимания что такое программное обеспечение разберемся в его понятии.

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

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

ПО делится на 3 категории:

1. Прикладные ПО. Являются самыми обширными.К ним относится множество программ которые мы используем в повседневной жизни, например: Аудио проигрыватели и вид видеофайлы, браузеры, текстовые редакторы, антивирусы и т. д
2. Системные ПО. Это программы которые отвечают за управление аппаратной часть ПК (памятью, процессами и т. д).Они не носят практичный характер, а только обеспечивают правильную работу других программ.

К ним относятся:

• Драйвера (обеспечивают корректную работу той или иной части сетевого ПО)
• Дополнительные программы (расширенные возможности операционной системы)

1. Инструментальные программные системы. Они упрощают создание новых программ.

По виду использования и распространения ПО делятся на 4 вида:

• Бесплатное. Эти программы можно скачивать в свободном доступе и распространять. Как правило сам распространитель денег за ПО не берет.
• Свободное. Практически ничем не отличается от первого вида, но имеет возможность вносить в программный код изменения и распространять новые версии
• Открытое. Распространяется с открытым кодом, только при условии этого в лицензии
• Закрытое.Распространяется только на определенных условиях т.к является частной собственностью. Плата за распространение такого ПО может быть любой, но в рамках законодательства. Например это может быть фиксированная плата или определенные условия, такие как регистрация на сайте и т.д

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

Разработа и введение в эксплуатацию ПО

Использование ПО

Сопровождение ПО

Концепция развития жизненного цикла ПО связанно с поиском все более усовершенствованной для него модели. В модели для ПО опущены вопросы деталей и она является абстракцией настоящего процесса жизненного цикла.

Существование моделей разнообразно, что и определяет различность применений .

Существуют 3 основных причины которые определяют необходимость изучения вопросов моделирования «жизни» ПО:

1.Модель жизненного цикла ПО дает возможность заказчику понять, что можно ожидать от данного ПО, а что невозможно. Естественно доработка по основной поставленной задачи для ПО будет возможна при сопровождении ПО, но координально иные задачи – это концепция другого ПО.

2.Модель- это база любого ПО. При создании абсолютно любого ПО создается модель того кого как должна работать программа, выстраиваются этапы жизненного цикла.

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

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

2.2 Жизненный цикл программного обеспечения.

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

Существуют 7 фаз жизненного цикла ПО:

1. Стратегия
2. Анализ
3. Проектирование
4. Реализация
5. Тестирование
6. Внедрение
7. Эксплуатация и сопровождение ПО

Рассмотрим каждую фазу отдельно:

1 Фаза - Стратегия .

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

Эта фаза предполагает создание ключевого документа в котором будет прописаны условия,а именно:

• Сроки изготовления ПО
• Финансовые затраты заказчика
• Что в итоге получает заказчик при финансировании проекта
• Сроки окупаемости проекта (при необходимости)
• Возможные риски
• Описание функций ПО
• Возможности ПО в будущем

2 Фаза- Анализ

Если первая фаза прошла успешно, то начинается 2 фаза жизненногоцикла ПО.

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

3 Фаза- Проектирование

Если фаза анализа предоставляет информативную модель ПО ,то фаза проектирования формирует модель данных. Проектирование проекта предоставляет схему базы данных и набор модулей системы. Так же в этой фазе происходит создание плана тестирования ПО.

3 фаза имеет определенные задачи:

• Проверка анализа и его информативность
• Определение ограничений проекта
• Решение критических вопросов с заказчиками
• Создание плана тестирования
• Выявление безопасности проекта
• Определение необходимость привлечения сторонних производителей и определение механики их взаимодействия
• Проектирование схемы базы данных и бета версии проекта

4 Фаза- Реализация

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

Цепочка взаимодействий: Проектировщик –разработчик - тестировщик.

Проектировщик составляет, что нужно сделать, разработчик определяет как ,а тестировщик.

Проектировщик служит «справочником» дающим ответы на возникающие вопросы на этапе разработки ПО, а тестировщики постоянно взаимосвязаны с разработчиками.

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

5 Фаза-Тестирование

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

Само тестирование систем можно разделить на 3 группы:

1. Автономные тесты модулей (позволяют отслеживать ошибки отдельных компонентов)
2. тесты связей компонентов системы (позволяют отслеживать правильность взаимодействия и обмена информацией компонентов системы)
3. системный тест (цель данного теста — внутренняя приемка системы и оценка ее качества).

Так же в этой фазе тестируется система отказов, т.е проверяется как поведет себя система на определенные сбои, т.к:

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

Эта фаза очень важна т.к дает возможность оценить качество подсистемы и системы в общем.

6 Фаза- Внедрение

После завершения тестирование ПО начинается фаза внедрения.

Она как правила проходит в несколько этапов:

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

Эта фаза важна тем ,что предоставляется заказчику для получения одобрения проекта. Тестировщиком в данной фазе выступает заказчик. Как правило в фазе внедрения происходит доработка мелких ошибок.

7 Фаза- Эксплуатация и сопровождение ПО

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

3.Виды моделей разработки программного обеспечения

3.1 Виды моделей разработки программного обеспечения

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

В общепринятой модели проходят развитие два этапа жизненного цикла ПО :

• Разработка ПО
• Сопровождение ПО

Эти два этапа имеют ряд фаз:

Определение требований

Анализ

Пректирование

Реализация

Этап разработки ПО

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

Сопровождение

Этап сопровождения

Развитие

Разработка ПО начинается определения потребностей и заказчивается ввода ПО в эксплуатацию

Модели ПО бывают:

• Каскадная
• V- образная
• Спиральная
• Интеративная
• Инкрементальная

Для понимания области применения той или иной модели разработки ПО рассмотрим каждую модель отдельно, а так же выявим их плюсы и минусы.

1 Модель – Каскадная

Сбор и анализ информации

Проектирование

Реализация

Внедрение

Сопровождение ПО

Каскадная модель имеет вид последовательного потока который проходит фазы :

• Сбора и анализа информации
• Проектирования
• Реальзации
• Тестирования
• Внедрения
• Сопровождения ПО

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

Рассмотрим плюсы и минусы данной модели.

Плюсы:

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

2.Простота самой модели. При полном завершении одной фазы происходит переход к другой без возврата к предыдущей.

3.Логическая последовательность фаз

Минусы:

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

2. Отсутствует возможность возвращения на предыдущую фазу.

3.Отсутствие гибкости модели

4. Пользователю приходится сразу привыкать к ПО из-за отсутствия бета версии.

5.Заказчик участвует только в первой фазе модели и в последней

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

У каскадной модели существует разновидность – Водопадная модель. Она имеет возможность обратной связи с предыдущей фазой, но это несет за собой очень большие затраты.

2.V- образная модель.

Планирование ПО и требований

Реализаци и сопровождение ПО

Анализ необходимых требований

Системное тестирование

Разработка проекта

Внедрение и тестировнаие

Детальная разработка проекта

Модульное тестирование

Кодирование

При работе с каскадной моделью выявлялся ряд недостатков. V-образная модель является усовершенствованным прототипом каскадной модели. Свое название она получила из-за своего графического вида. Больше всего данная модель ориентирована на тестирование, что значительно повышает качество ПО.

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

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

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

Спиральная модель была создана Барри Боэмом в 1980-х г.

Главным ее преимуществом является сочетание проектирования и создание пост прототипирование целью которого является сочетание преимуществ восходящей и нисходящей концепции.

Плюсы модели:

1.Оня является наиболее усовершенствованной моделью разработки ПО с высоким уровнем конкурентноспособности

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

3. Успешна в решениях критических задач, когда ошибка априори невозможна

4.Хорошо подходит для сложных проектов

5.Дает возможность намного раньше увидеть работоспособность ПО

6.Надежность системы

7.Минимизация рисков

Минусы:

1.Не подходит для маленьких проектов

2.Жизнненый цикл может быть бесконечным, а конечный продукт может так и не появиться

3.Отсутствует четкое понимание перехода на следующую фазу.

4.Может оказаться дорогостоящей от продолжительности жизненного цикла ПО.

Спиральная модель хорошо применяется при:

• создании совершенно нового продукта не имеющего прототипов.
• При необходимости минимизации рисков
• При необходимости подстраивоемости к изменениям требований к ПО

4 Модель- Интеративная

В интеративной модели сочетаются преимущества спиральной и каскадной моделей.

Интеративная модель имеет 4 основных фазы «жизни» ПО:

• Начало
• Исследование
• Построение
• Внедрение

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

Плюсы:

1.Возможность применения в больших проектах

2.Детали постоянно могут усовершенствоваться

3.Гибкость к требованиям заказчика

4.Успешно справляется с рисками

5.Ориентирована на выпуск последовательных версий

Минусы:

1.Не подходит для маленьких проектов

2.Задача должна быть поставлена сразу

3.Больше всего подходит для свободного рынка, т.к предполагает дальнейший выпуск версий

5 Модель- Инкрементальная

Разработка требований

Проектирование

Реализация

Ввод в действие

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

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

Данная модель имеет большую схожесть с каскадной моделью ,но не смотря на это инкрементальная модель будет иметь и свои достоинства и недостатки

Плюсы

1.С появлением каждой новой версией затраты снижаются, т.к базовые требования сформированы и реализованы.

2.У клиента появляется возможность постепенно обучится ПО, т.к сначала клиент осваивает базовые навыки работы с ПО, а далее только дополнения

3.Клиент намного раньше получает первую версию

Минусы:

1.Для создания каждой последовательной версии придется подсобрать требования к усовершенствованию ПО, т.к создавать новую версии про появлении каждого нового требования неразумно

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

Данный вид модели разработки ПО хорошо применяется если:

1. Если требования четкие
2. Необходим ранний выход ПО на рынок
3. Изначально предполагается создание последующих версий

3.2 Сравнение моделей программного обеспечения

Чтобы иметь более четкое понимание какую модель необходимо выбрать при создании ПО произведем сравнение по общим критериям

Сравнительная таблица моделей разработки ПО:

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

Для примера сравнения взяли 6 основных критерий моделей.

1.Простота исполнения

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

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

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

2. Гибкость к требованиям (возможность внедрения новых требований)

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

Из таблицы следует, что из 5 моделей только 3 имеют возможность внедрения новых требований на любой фазе. Это обуславливается возможностью тестирования каждой фазы и возможностью взаимодействия между собой тех или иных фаз, а так же предусмотрение создания новых версий программы. Несмотря, что V-образная модель имеет возможность тестирования все же она не приспособлена к изменениям требований к ПО на разных фазах. Так же V-образная и каскадная модели подходят для простых ПО, остальные же подходят больше для больших проектов, что так же влияет на гибкость к ведению требований к ПО.

3.Продолжтельность жизненного цикла ПО

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

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

Но жизненный цикл любой ПО может закончится из-за таких факторов как:

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

2. Вечное тестирование ПО. Жизненный цикл может закончится до выпуска ПО в свободный рынок, т.к она может стать неактуальной

4.Удобство при использовании.

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

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

5.Стоимость проекта.

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

Из таблицы видно, что более простые модели менее финансово затратны, чем более сложные модели.

6. Уменьшение рисков.

Данный критерий основывается на минимизации ошибок после ввода ПО в полную его эксплуатацию.

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

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

4.Заключение

ПО является неотъемлемой частью технического устройства. Не имеет значение какое оно встроенное или установленное, основным критерием характеризующее любое ПО является его правильная работа.

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

5.Список литературы

1.  Б.У. Боэм «Инженерное проектирование программного обеспечения». М.: Радио и связь. 1985

2. Гантер Р. Методы управления проектированием программного обеспечения. — М.: Мир, 1981.

Информатика / под ред. проф. Ю.А. Романовой. ― М.: Эксмо, 2005. ― 322 с.

3. Молчанов, А.Ю. Системное программное обеспечение / А.Ю. Молчанов. ― СПб.: Питер, 2003. ― 400 с.

4. Можаров, Р.В., Можарова, Н.Р. Программное обеспечение персональных компьютеров / Р.В. Можаров, Н.Р. Можарова. ― М.: Финстатинформ, 2003. ― 512 с.