22
Стоит отметить, что именно появление процесса прототипирования
приводит к тому, что весь процесс модификации ПО перестал
восприниматься так, как «необходимое зло», а начал восприниматься как
отдельный процесс создания ПО.
Прототипом ПО называют действующую программы (модуль
программы или весь программный продукт), что реализует отдельные
функции разрабатываемого программного обеспечения.
Заметим, что на первой итерации проектируют, специфицируют,
реализуют или тестируют пользовательский интерфейс. На второй –
добавляют ограниченный набор функционала.
Далее, на последующих этапах указанный набор расширяют,
наращивая все возможности для данного продукта (рисунок 5).
Рисунок 5 – Спиральная схема разработки ПО
Самым главным достоинством рассматриваемой схемы является тот
факт, что, начиная с определенной итерации, на которой обеспечивается
23
определенная функциональная полнота, программный продукт можно
предоставлять клиенту, что позволяет:
– сокращать время до появления самых первых версий
программного средства;
– заинтересовать множество пользователей, обеспечивая
стремительное продвижение следующих версий программы на рынке;
– выполнить ускорение формирования и уточнения спецификаций
за счет реализации практики использования ПО;
– уменьшить вероятность устаревания системы во время
разработки.
Самой главной проблемой использования спиральной структуры
является определение моментов для перехода на последующие стадии
разработки.
Главной особенностью спиральной модели является концентрация на
всевозможных рисках. Для оценки их даже выделена определенная стадия.
Основные типы рисков, возникающие в процессе разработки по данной
модели:
– нереалистичный бюджет;
– дефицит разработчиков;
– частые корректировки требований;
– чрезмерная оптимизация ПО;
– низкая производительность ИС;
– несоответствие уровня квалификации разработчиков разных
отделов.
Для ее решения ограничиваются обычно сроки прохождения для всех
стадий, основываясь на разного рода экспертных оценках.
CASE-технологии имеют возможности представлять собой
совокупность разных методологий проектирования, анализа, разработки и
сопровождения программных систем, что основаны на структурной и на
объектной методологии, которые поддерживаются комплексом средств
24
автоматизации, что являются взаимосвязанными. В основе всех CASE-
технологий лежат парадигмы (нотация).
Методология проектирования ПО строится на основании некоторого
подхода, а также определяет шаги для работы, их непосредственную
последовательность, а также и правила назначения и распределения методов.
Метод же определяет способ достижения цели, а именно выполнение шага
работы.
Нотация – это система обозначений, что применяется для описания
некоторого типа моделей. Нотации являются:
– графические;
– текстовые.
В CASE-технологиях такие нотации используют для
непосредственного описания структуры системы, что проектируется, а также
элементов данных, стадий их обработки и т.д.
Средствами является инструментарий для поддержки методов
разработки: средства редактирования и создания графического проекта,
организации программного проекта в качестве иерархии уровней абстракции,
проверки соответствия компонентов.
Автоматизируя трудоемкие операции, все современные CASE-средства
значительно повышают производительность труда разработчиков и
улучшают качество ПО, что создается.
В первом разделе работы рассматриваются главные определения
понятия типов программного обеспечения, также приводится расширенная
классификация программного обеспечения, технологии по разработке
разного рода программных продуктов:
– дана характеристика определению «жизненный цикл»;
– выполнено описание основных компонентов ЖЦ ПО;
– рассмотрены классические модели ЖЦ.
25
Стоит заметить, что от правильного выбора модели разработки ПО
зависит корректность работы программы, быстрота ее создания и ее
поддержки.
26
ГЛАВА 2. ПРИНЦИПЫ ПРОТОТИПИРОВАНИЯ ПО
2.1. Понятие прототипов ПО, классификация
Процесс создание прототипа (прототипирование) для ПО позволяет
проектировать разные макеты интерфейса, БД и моделей для программных
средств самого разного уровня достоверности: от набросков до макетов
созданных с помощью специальных программ.
Создание самых разных прототипов позволяет разработчикам
проверять свои идеи, а также адаптировать программный продукт по
требованиям клиента, что, как правило, часто меняются.
Стоит заметить тот факт, что прототипы используют и по причине
того, что их проектирование стоит дешевле, чем непосредственное создание
оригинального программного продукта.
Рассмотрим самые основные характеристики и классификацию
прототипов ПО. [3]
С точки зрения масштаба разработки все прототипы подразделяются на
такие категории (рисунок 6):
Рисунок 6 – Категории прототипов по масштабу проектирования
Глобальные прототипы предназначаются для моделирования системы в
целом.
Прототипы
программного
обеспечения
Глобальные
прототипы
Локальные прототипы
27
Такое их применение дает возможность выявить проблемы, что
связаны с полнотой пользовательского интерфейса, а также всего
разрабатываемого ПО.
Локальными прототипами при этом выполняются моделирование
только для некоторой небольшой части системы. Они часто используются
для устранения всяческих нестыковок мнений клиентов и разработчиков
через сопоставление многих примеров дизайна интерфейса,
функционирования программ.
Стоит также заметить, что практически все локальные прототипы
разделяются на такие виды (рисунок 7):[6]
Рисунок 7 – Типы локальных прототипов
Рассмотренные на рисунке 7 типы прототипов направляются также на
полноту функциональности и диапазон различных возможностей для
процесса прототипирования.
Для еще лучшего понимания рассмотрим описание двух диаграмм, что
иллюстрируют отличия между приведенными выше горизонтальным и
вертикальным типом прототипирования.
Также, заметим, что горизонтальные прототипы используют в своей
деятельности небольшую функциональную глубину, а при этом они
считаются широкими в своих возможностях (рисунок 8).[9]
Локальные прототипы
Горизонтальные
прототипы
Вертикальные
прототипы
28
Рисунок 8 – Схема горизонтального прототипирования
Вертикальные категории прототипов являются глубокими в
функциональной плоскости, но они являются сильно ограниченными в своих
непосредственных возможностях (рисунок 9).[18]
Рисунок 9 – Описание вертикального прототипирования
Все рассмотренные классы прототипов по уровню их достоверности
можно разделить на такие категории (рисунок 10):[21]
Рисунок 10 – Классификация прототипов по уровню достоверности
Прототипы
программного
обеспечения
Прототипы с низкой
достоверностью
Прототипы с высокой
достоверностью
29
Первые данные прототипы, как правило, не являются очень похожими
на свой эталонный вариант ПО. Поскольку делаются они не с такого же
«строительного материала», как и ПО на заключительной стадии.
Для проектирования прототипов с низким уровнем достоверности
может симулироваться специальная интерактивность, хотя она не будет
отражать все тонкости их взаимодействия.[27]
Вторая категория выглядит, напротив, очень похожими на
окончательное программное приложение. Конечный утвержденный проект
или вся его функциональность является примером типичного прототипа с
достаточно высокой степенью достоверности.
Прототип может также использовать некоторые с основных функций,
которые присущи полностью оконченному продукту и дает возможность
протестировать разные «узкие места» в непосредственном взаимодействии с
пользователями.
При этом, для них используется больше времени на непосредственную
разработку или создание. Зачастую, после использования действующего
прототипа, что может иметь высокий уровень достоверности разработчики
неохотно от него отказываются и пытаются как-тот развить законченное ПО.
[33]
При реализации прототипирования процесс разработки полностью
аналогичен: чтобы протестировать некоторую идею в создании ПО нужно
создавать прототип с его оценкой.
Рассмотрим далее основные подходы к реализации прототипа.
Традиционный подход для создания макетов пользовательских
интерфейсов или ПО в целом основан на выполнении переходов с прототипа
малого уровня достоверности к прототипам более высокого уровня (рисунок
11). [39]
30
Рисунок 11 – Классическая схема создания прототипа
Стоит также заметить, что непосредственно на практике, такая
логичная схема может выльется также в намного более совершенную
методологию применения эволюционного прототипирования.
Непосредственно эволюционное прототипирование дает все
возможности выполнить последовательное увеличение уровня достоверности
для образца, пока он не станет полностью законченным ПО (рисунок 12).
Рисунок 12 – Принцип выполнения эволюционного прототипирования
Под эволюционным прототипированием понимают очень широко
распространенный подход к разработке интерфейсов, ПО. Стоит отметить,
что в этом есть некоторая опасность: когда изначально создается прототип с
высоким уровнем достоверности, то его практически невозможно расширить
для проверки.
Но, несмотря на всю полезность эволюционного прототипирования при
выявлении разных тонкостей и аспектов, к примеру, пользовательского
интерфейса, усовершенствования его многими методами.
Быстрое прототипирование подразумевает часто под собой, что сразу
создается некоторое количество прототипов, а потом, в результате оценки об
неадекватности будут постепенно отбрасываться.
Стоит заметить тот факт, что описываемый метод быстрого
прототипирования может являться очень сложным для разработки даже с
помощью команды программистов, а именно для непосредственной приемки
менеджерами.
Анализ Прототип
Конструи-
рование
Тестиро-
вание
Релиз
31
Инкрементное прототипирование базируется на сборке
заключительного релиза продукта с нескольких самыми разными
прототипами. Все его составные части также могут разрабатываться
параллельно (рисунок 13).
Рисунок 13 – Схема для инкрементной модели
Под экстремальным прототипированием, схема которого указана на
рисунке 14, используется, в основном, в проектировании web-приложений
самой разной сложности.
Полностью процесс разбит на несколько фаз. [2]
При выполнении первой фазы будет спроектирован первый прототип
самой низкой достоверности.
На втором этапе разрабатывают работоспособный код ПО, а
статические страницы будут переписаны под используемый фреймворк и
нужный уровень функциональности.
На третьей фазе реализуется интеграция проектируемого веб-
интерфейса во все ресурсы.
Рисунок 14 – Структура экстремального прототипирования