Тема 1. Программные продукты и их основные характеристики

1.1 Основные понятия программного обеспечения

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

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

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

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

Задача (problem, task) - проблема, подлежащая решению.

Приложение (application) - программная реализация на компьютере решения задачи.

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

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

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

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

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

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

-цель или назначение задачи, ее место и связи с другими задачами;

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

-содержание функций обработки входной информации при решении задачи;

-требования к периодичности решения задачи;

-ограничения по срокам и точности выходной информации;

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

-источники входной информации для решения задачи;

-пользователи задачи (кто осуществляет ее решение и пользуется результатами решение и пользуется результатами решения).

Процесс создания программ можно представить как последовательность действий.

Постановка задачи (problem definition) - это точная формулировка решения задачи на компьютере с описанием входной и выходной информации.

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

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

?? Задача 1: Анализ и классификация задач ??

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

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

Технология программирования – это совершенствование профессиональной культуры программирования, организация и упорядочение труда самого программиста, независимо от конкретного языка программирования, решаемой задачи и ЭВМ

Программотехника (software engineering) - технология разработки, отладки, верификации и внедрения программного обеспечения.

Все программы по характеру использования и категориям пользователей можно разделить на два класса - утилитарные программы и программные продукты (изделия).

Утилитарные программы ("программы для себя") предназначены для удовлетворения нужд их разработчиков. Чаще всего утилитарные программы выполняют роль сервиса в технологии обработки данных либо являются программами решения функциональных задач, не предназначенных для широкого распространения.

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

?? Задача 2: Определение типа программы ??

?? Задача 3. «Классификация программных решений в IT-компании» ??

Как правило, программные продукты требуют сопровождения, которое осуществляется специализированными фирмами - распространителями программ (дистрибьюторами), реже - фирмами-разработчиками.

Сопровождение программного продукта - поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.

Программы не имеют заранее строго регламентированного набора качественных характеристик.

Основными характеристиками программ являются:

‒         алгоритмическая сложность (логика алгоритмов обработки информации);

‒         состав и глубина проработки, полнота и системность реализованных функций обработки  программы;

‒         требования к операционной системе и техническим средствам со стороны программы;

‒         объем файлов программ;

‒         удобство освоения и эксплуатации программы;

‒         объем дисковой памяти;

‒         размер оперативной памяти для запуска программ;

‒         тип процессора;

‒         версия операционной системы;

‒         наличие вычислительной сети и др.

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

Инструментарии технологии программирования - программные продукты поддержки (обеспечения) технологии программирования.

В рамках этих направлений сформировались следующие группы программных продуктов:

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

 Включают:

+ локальные средства, обеспечивающие выполнение отдельных работ по созданию программ;

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

Язык программирования - формализованный язык для описания алгоритма решения задачи на компьютере.

2. СASE-технология (Computer-Aided System Engineering) – программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных систем.

Средства CASE-технологий делятся на две группы:

- встроенные в систему реализации - все решения по проектированию и реализации привязаны к выбранной системе управления базами данных (СУБД);

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

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

Другой класс CASE-технологий поддерживает только разработку программ, включая:

- автоматическую генерацию кодов программ на основании их спецификаций;

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

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

- тестирование и отладку программ.

Кодогенерация программ выполняется двумя способами; создание каркаса программ и создание полного продукта.

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

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

Большинство CASE-технологий использует также метод "прототипов" для быстрого создания программ на ранних этапах разработки.

?? Задача 4. «Выбор инструментария технологии программирования» ??

Контрольные вопросы:

1. Дайте определение термину «программа».
2. Что такое «программное обеспечение» (software) и что оно в себя включает, помимо программ?
3. В чем заключается ключевое различие между понятиями «задача» (problem) и «приложение» (application) в контексте информатики?
4. Какое альтернативное значение может иметь термин «задача» в среде мультипрограммирования?
5. На какие два основных класса делятся задачи с позиций специфики разработки ПО? Дайте их краткую характеристику.
6. Что является предметной областью и как она формируется?
7. Перечислите не менее пяти основных характеристик функциональной задачи, которые уточняются при её формализованной постановке.
8. Что понимается под «постановкой задачи» в процессе создания программ?
9. Какие формы может принимать выходная информация программы?
10. Что может служить входной информацией для решения задачи на компьютере?
11. Дайте определение «технологии программирования». От чего она не зависит?
12. Что такое «программотехника» (software engineering)?
13. На какие два класса делятся все программы по характеру использования? Чем они принципиально отличаются?
14. Что такое «программный продукт» и каковы его ключевые признаки?
15. Что включает в себя «сопровождение программного продукта»?
16. Перечислите не менее пяти основных характеристик (свойств) программ.
17. Что относится к «средствам для создания приложений»?
18. Что такое CASE-технология и какую главную цель она преследует?
19. На какие две группы делятся средства CASE-технологий по критерию привязки к системе реализации? В чем их различие?
20. Каковы основные достоинства CASE-технологий при коллективной работе над проектом?

1.2. Основные характеристики программных продуктов

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

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

Качество ПО (Software Quality) –  это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

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

Процесс обеспечения качества состоит из следующих работ:

‒         подготовка процесса;

‒         обеспечение качества продукта;

‒         обеспечение процесса;

‒         обеспечение систем качества.

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

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

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

Обеспечение систем качества означает проведение дополнительных работ по управлению качеством в соответствии с разделами стандарта, указанными в договоре.

Эволюция понятия качества

•      1970-е: Фокус на отсутствии дефектов

•      1980-е: Соответствие требованиям

•      1990-е: Соответствие использования

•      2000-е: Удовлетворенность пользователя и ценность

Программные продукты имеют многообразие показателей качества, которые отражают следующие аспекты:

- функциональные аспекты программного обеспечения

- как был создан программный продукт

- как работает программный продукт

- насколько хорошо (просто, надежно, эффективно) можно использовать программный продукт;

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

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

Дерево характеристик качества программных продуктов представлено на рисунке.

Критериями (характеристиками) качества программы являются:

‒      мобильность — независимость программы от программных и технических средств обработки данных (операционной среды, сетевой технологии обработки данных, специфики предметной области и т.п.). Мобильный (многоплатформный) программный продукт может быть установлен на различных моделях компьютеров и операционных систем, без ограничений на его эксплуатацию в условиях вычислительной сети. Функции обработки такого программного продукта пригодны для массового использования без каких-либо изменений.

‒      надежность — устойчивость в работе программы, точность выполнения функций обработки;

‒      эффективность — оценка расходов вычислительных ресурсов (объемов памяти для эксплуатации программы и т. п.);

‒      дружественность — обеспечение дружественного интерфейса для работы пользователя (наличие контекстно-зависимой подсказки или обучающей системы в составе программного средства, хорошей документации для освоения и использования заложенных в программном средстве функциональных возможностей, анализ и диагностику возникших ошибок и др.);

‒      модифицируемость — способность к внесению изменений и расширений функций обработки;

‒      коммуникативность — возможность интеграции с другими программами, обеспечении обмена данными в общих форматах представления (экспорт/импорт баз данных, внедрение  или связывание объектов обработки и др.).

Модели качества ПО.

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

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

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

Все модели качества могут быть разделены на три категории в соответствии с методами, на основе которых они были созданы.

К первому виду можно отнести теоретические (эмпирические)модели, основанные на гипотезе отношений между переменными качества.

Ко второму виду относятся модели «управления данными», основанные на статистическом анализе больших наборов эмпирических данных. Модель выводится "снизу вверх" из данных, а не навязывается сверху экспертом.

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

На основе этого, сформулируем определение модели качества:

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

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

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

Существуют  множество подходов к обеспечению качества ПО, которые имеют свои преимущества и недостатки.

??  Задание 5. Модели качества ПО. Найти и записать определения характеристик и атрибутов Модели качества ISO 9126  ??

Модель ISO 9126 определяет иерархическую структуру качества, состоящую из шести основных характеристик, каждая из которых детализируется через набор подхарактеристик (атрибутов).

На верхнем уровне выделено 6 основных характеристик (показателей) качества ПО.

Каждую характеристику (показатель) определяют набором (подхарактеристик) атрибутов.

?? Задание 6. Модели качества ПО. Найти и записать определения характеристик и атрибутов Модели качества ISO 25010 ??

На верхнем уровне выделено 8 основных характеристик (показателей) качества ПО.

ISO 25010 определяет модель качества при использовании системы или продукта и модель качества продукта.

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

Из схем видно, что стандарт ISO 25010 переосмысливает идеи, которые лежали в основе ISO 9126, и расширяет область применения на системы, состоящие не только из ПО.

На качество программы влияют следующие факторы:

‒         маркетинг рынка и спецификация требований к программе,

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

‒         проектирование структурной схемы программы — алгоритмизация процессов обработки данных, разработка структуры программы и базы данных, выбор метода и средств создания программы — технологии программирования;

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

‒         эксплуатация и сопровождение программы — важный этап, связанный с устранением обнаруженных ошибок;

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

Перечислим основные свойства алгоритмов:

‒         определенность (детерминированность) — точность и понятность, обеспечивающие однозначность результата;

‒         результативность — получение искомого результата через конечное число этапов (шагов);

‒         дискретность — расчлененность алгоритма на отдельные этапы (шаги);

‒         массовость — пригодность алгоритма для решения всех задач данного типа.

?? Задание 7 ??

- Выбрать приложение/программный модуль

- Выбрать модель качества ИСО 9126 или ИСО 25010

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

- При проведении оценки дать расшифровку характеристики (показателей качества) и каждого атрибута всех  характеристик качества.

?? Задача 8. Выбор CMS для образовательного портала  ??

Контрольные вопросы:

1. Дайте определение «качеству программного обеспечения» (Software Quality) согласно представленным материалам.
2. На какие четыре основные работы подразделяется процесс обеспечения качества ПО?
3. Что подразумевается под работой «обеспечение качества продукта» в рамках процесса обеспечения качества?
4. Как изменился фокус в понимании качества ПО с 1970-х по 2000-е годы? Кратко охарактеризуйте каждый этап.
5. Какие аспекты программного продукта отражают многообразные показатели качества (например, «как был создан», «как работает»)?
6. Дайте развернутое определение критерия «мобильность» программного продукта.
7. Что включает в себя критерий «дружественность» (usability) программы?
8. Какой критерий качества описывает возможность интеграции программы с другими программами и обмена данными? Раскройте его содержание.
9. Для чего пользователям и разработчикам необходимы модели качества ПО?
10. На какие три категории делятся все модели качества в зависимости от методов их создания? Дайте краткую характеристику каждой.
11. Сформулируйте определение «модели качества программного обеспечения».
12. В чем заключается основное преимущество использования иерархических моделей качества?
13. Какой стандарт определяет модель качества, состоящую из шести основных характеристик (функциональность, надежность и т.д.)?
14. Какая модель качества, помимо качества продукта, дополнительно определяет «качество при использовании»?
15. Чем модель ISO 25010 принципиально расширяет область применения по сравнению с ISO 9126?
16. Перечислите основные факторы, влияющие на качество программы, начиная с этапа маркетинга.
17. Какой этап жизненного цикла программы связан с устранением обнаруженных ошибок после её выпуска?
18. Какое основное свойство алгоритма обеспечивает получение искомого результата за конечное число шагов?
19. Какое свойство алгоритма подразумевает его пригодность для решения всех задач определённого типа, а не одной конкретной?
20. Какие два подхода сочетает в себе комбинированная модель качества (третий вид)?

1.3. Понятие жизненного цикла программы

Жизненный цикл программного обеспечения (ЖЦ ПО) — это совокупность взаимосвязанных процессов от момента появления идеи создания программного обеспечения до окончания его эксплуатации.

1.3.1  стандарт ISO/IEC 12207: 1995

Описание структуры ЖЦ ПО и состав его процессов регламентируется международным стандартом ISO/IEC 12207: 1995 «Information Technology — Software Life Cycle Processes» («Информационные технологии — Процессы жизненного цикла программного обеспечения»). Отечественный вариант стандарта называется ГОСТ Р ИСО/МЭК 12207—2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

- Международная организация по стандартизации (International Standards Organization, ISO) - основная м/н организация, которая занимается стандартизацией.

- Международная электротехническая комиссия МЭК (International Electrotechnical Commission, IEC) - область электротехники, электроники, радиосвязи и приборостроения

Организации ISO и IEC объединили свою деятельность в сфере стандартизации информационных технологий, создав в 1987 году Объединенный технический комитет (JTC1).

Стандарты, которые разрабатываются JTC1 получают аббревиатуру ISO/IEC (ИСО/МЭК).

Международный стандарт ISO/IEC 12207: 1995-08-01. – Базовый стандарт, который определяет процессы ЖЦ ПО, действия и задачи, которые необходимо выполнить во время разработки ПО.

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

Стандарт равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь);

Может быть в равной степени применен, когда обе стороны - из одной организации.

В стандарте  не предусмотрены этапы (фазы, стадим) ЖЦ ИС.

Общая структура стандарта - набор процессов ЖЦ.

Каждый процесс разделен на набор действий, каждое действие - на набор задач.

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

Согласно этому стандарту, архитектура ЖЦ ПО состоит из трех компонентов:

— 5 основных процессов: Приобретение, Поставка, Разработка, Эксплуатация, Сопровождение;

—    8 вспомогательных процессов -  обеспечивающие выполнение основных процессов:

1) процесс решения проблем;

2) процесс документирования;

3) процесс управления конфигурацией;

4) процесс обеспечения качества;

5) процесс верификации;

6) процесс аттестации;

7) процесс совместной оценки;

8) процесс аудита.

— 4 организационных процесса:

 1) процесс управления;

2) процесс создания инфраструктуры;

3) процесс усовершенствования;

4) процесс обучения.

Стандарт состоит из семи разделов и четырех приложений. Разделы 1—4 являются вводными. Разделы 5, 6, 7 состоят из подразделов, в которых раскрывается содержание работ и даются комментарии к ним.

В стандарте описаны 5 основных, крупных обобщенных процессов ЖЦ ПО:

1) процесс приобретения - определяет действия предприятия - покупателя ИС, ПП или службы ПО;

2) процесс поставки определяет действия предприятия-поставщика по снабжению покупателя информ. системой, программ. продуктом или службы ПО;

3) процесс разработки определяет действия предприятия-разработчика, который разрабатывает принципы построения программного продукта и сам ПП.

4) процесс функционирования определяет действия предприятия-оператора, обслуживающего систему в целом. Сюда входят консультация пользователей, получение обратной связи и т.д.;

5) процесс сопровождения определяет действия персонала, обеспечивающего сопровождение ПП, ( управление модификацией программного продукта, поддержку текущего состояния и функциональной пригодности, установку и удаление)

Процесс Разработка программного обеспечения (раздел 5.3) содержит 13 подразделов:

— подготовка процесса — выбор модели жизненного цикла, стандартов, составление плана работ;

— анализ требований к системе — определение функциональных, эксплуатационных, пользовательских требований;

— проектирование архитектуры системы — определение состава оборудования, ПО и операций, выполняемых персоналом;

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

— проектирование архитектуры программного обеспечения — определение структуры программного обеспечения, документирование интерфейсов его компонентов;

— детальное проектирование программного обеспечения — описание компонентов ПО и интерфейсов между ними, разработка требований к тестам;

— кодирование и тестирование компонентов программного обеспечения — разработка и тестирование компонентов;

— интеграция компонентов программного обеспечения — сборка программных компонентов в соответствии с планом интеграции, тестирование ПО на соответствие требованиям, соответствующим своим спецификациям;

— квалификационное тестирование программного обеспечения — тестирование в присутствии заказчика, проверка документации;

— интеграция системы — сборка всех компонентов системы, ПО и оборудования;

— квалификационное (аттестационное) тестирование системы — тестирование системы на соответствие требованиям, проверка оформления и полноты документации;

— инсталляция программного обеспечения — установка программного обеспечения на оборудовании заказчика и проверка его работоспособности;

— приемка программного обеспечения — оценка результатов квалификационного тестирования и передача программного обеспечения заказчику.

Контрольные вопросы:

1. Как расшифровываются аббревиатуры ISO и IEC, и какой объединенный комитет они создали для стандартизации в области информационных технологий?
2. Каков основной фокус и назначение международного стандарта ISO/IEC 12207:1995?
3. Какие две основные стороны (роли) в процессе жизненного цикла ПО рассматривает стандарт, и как он регулирует их взаимодействие?
4. На какие три группы подразделяются все процессы жизненного цикла программного обеспечения согласно архитектуре стандарта ISO/IEC 12207?
5. Перечислите пять основных процессов жизненного цикла ПО, определенных в стандарте.
6. Перечислите 8 вспомогательных процессов  жизненного цикла ПО, определенных в стандарте.
7. Перечислите 4 организационных процесса жизненного цикла ПО, определенных в стандарте.
8. В чем заключается ключевое отличие в подходе стандарта ISO/IEC 12207 к последовательности выполнения процессов и задач по сравнению с жесткими пошаговыми моделями?
9. Назовите три первых подраздела (действия) в рамках процесса «Разработка программного обеспечения» согласно стандарту.
10. Какие два заключительных действия процесса разработки связаны с передачей готового продукта заказчику (пользователю)?

1.3.2  Этапы (стадии)  разработки ПО

Можно выделить следующие укрупненные этапы разработки ПО с учетом соответствующих стадий разработки по ГОСТ 19.102—77 «Стадии разработки»:

— постановка задачи (стадия «Техническое задание»);

— определение спецификаций (стадия «Эскизный проект»);

— проектирование (стадия «Технический проект»);

— реализация (стадия «Рабочий проект»).

— внедрение

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

Неверно предполагать, что жизненный цикл разработки ПО согласно ГОСТ 19.102- 77 есть последовательное выполнение стадий и этапов, определенных в таблице.

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

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

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

1. На стадии Техническое задание выполняются следующие работы, входящие в состав соответствующих этапов.

1.1. Обоснование необходимости разработки программ:

- постановка задачи;

-- сбор исходных материалов;

- выбор и обоснование критериев эффективности и качества;

- обоснование необходимости проведения НИР.

1.2. Выполнение научно-исследовательских работ:

- определение структуры входных и выходных данных;

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

- обоснование целесообразности применения ранее разработанных программ;

- определение требований к техническим средствам;

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

1.3. Разработка и утверждение технического задания:

- определение требований к программе;

- разработка технико-экономического обоснования разработки программы;

 -определение стадий, этапов и сроков разработки программы и документации на нее;

- выбор языков программирования;

- определение необходимости проведения НИР на последующих стадиях;

 -согласование и утверждение ТЗ.

Постановка задачи — это процесс формулировки назначения программного обеспечения и основных требований к нему.

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

Этап постановки задачи заканчивается разработкой технического задания с принятием основных проектных решений.

Техническое задание в соответствии со стандартом ГОСТ 19.201—78 «Техническое задание. Требования к содержанию и оформлению» имеет следующие основные разделы:

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

Технологические требования определяют выбор следующих принципиальных решений, влияющих на процесс проектирования программного обеспечения:

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

Архитектурой программного обеспечения называют описание создаваемого программного обеспечения на уровне его компонентов и связей между ними.

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

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

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

Распространенными являются следующие архитектурные паттерны:

·            модель-представление-контроллер (Model-View-Controller, MVC) применяется в системах, ориентированных на обслуживание клиентов;

·            паттерн хранилища данных применяется в системах, функционирование которых связано с обработкой большого объема данных (информационные системы, системы управления); архитектура таких систем должна содержать компоненты, генерирующие данные, и компоненты, их обрабатывающие;

·            паттерн «клиент-сервер» предусматривает распределение задач между поставщиками и заказчиками услуг. Поставщики (серверы) предоставляют заказчикам (клиентам) определенный набор услуг (сервисов), доступ к которым осуществляется с помощью удаленного вызова соответствующих процедур;

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

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

При процедурном программировании модель построения программы — иерархия множества подпрограмм, при объектно-ориентированном программировании — иерархия множества классов, совокупность обменивающихся сообщениями объектов классов.

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

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

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

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

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

Различают следующие типы пользовательских интерфейсов:

• примитивные интерфейсы;
• интерфейсы-меню;
• интерфейсы со свободной навигацией;
• интерфейсы прямого манипулирования.

К технологическим требованиям к программному обеспечению относятся:

• выбор метода программирования: процедурный или объектно-ориентированный;
• выбор языка программирования: C++, Java, Python и др.;
• выбор среды программирования: Visual Studio фирмы Microsoft, Embarcadero RAD Studio (включающая Delphi и C++ Builder), Eclipse и др.

2. Эскизный проект

Основные этапы и содержание работ на стадии Эскизный проект приведены в таблице.

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

Требование полноты означает строгое соответствие техническому заданию, а требование точности — однозначное толкование спецификаций разработчиком и заказчиком.

Спецификации содержат:

• декомпозицию и содержательную постановку задач;
• эксплуатационные ограничения;
• математические методы решения;
• модели программного обеспечения.

2.1. Графическое представление спецификаций

Модели программного обеспечения зависят от технологии программирования (процедурная или объектно-ориентированная).

При процедурном программировании используются следующие модели разрабатываемого программного обеспечения:

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

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

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

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

В настоящее время стандартным средством описания разрабатываемого программного обеспечения с использованием объектно-ориентированного подхода является фактически графический язык UML (Unified Modeling Language, универсальный язык моделирования), разработанный авторами Г. Буч, Д. Рамбо и И. Якобсоном в 1995 г.

Язык UML описывает модель сложной системы в виде специальных графических конструкций (диаграмм).

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

Все диаграммы используют единую графическую нотацию.

В диаграммах используется 3 типа графических элементов, имеющих различное назначение:

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

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

Нотация языка UML определяет использование следующих основных видов диаграмм:

• вариантов использования (прецедентов) — описывают основные функции системы;
• классов — описывают классы, их характеристики (поля и операции) и связи между ними;
• кооперации — показывают взаимодействие объектов в процессе реализации варианта использования;
• пакетов — показывают связи наборов классов, объединенных в пакеты;

• состояний — демонстрируют состояния объекта и переходы из одного состояния в другое;
• деятельности — представляют собой схему потоков управления для решения некоторой задачи;
• компонентов — описывают компоненты программного обеспечения и их связи между собой;
• развертывания — позволяют связывать программные и аппаратные компоненты системы.

Пример 1

Пример 2

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

Любая модель должна содержать только те элементы, которые определены в нотации языка UML. Каждый элемент может быть использован только в соответствии с назначением и по правилам, определенным в языке.

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

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

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

Каждая модель конкретной программной системы может содержать все или только некоторые типы диаграмм.

3. Технический проект

Основные этапы и содержание работ на стадии Технический проект приведены в таблице.

Содержанием работ на этой стадии является проектирование структуры ПО.

Проектирование — это процесс разработки структурной схемы программного обеспечения с проектированием компонентов и их взаимосвязей.

Методологической основой проектирования программного обеспечения является системный подход.

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

При этом исследование объектов нацелено:

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

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

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

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

Методы структурного анализа основываются на соблюдении следующих правил:

·       разбиение системы на уровни абстракции с ограничением числа элементов на уровне;

·       включение на каждом уровне только существенных для этого уровня деталей;

·       использование строгих формальных правил записи и условных обозначений — нотаций;

·       последовательное приближение к конечному результату.

Основными средствами структурного анализа являются:

·       DFD (Data Flow Diagrams) — диаграммы потоков данных в нотациях Гейна — Сарсона, Йордона — Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;

·       STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда — Меллора для проектирования систем реального времени;

·       ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера; структурные карты Джексона и (или) Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;

·       FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;

·       SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;

·       семейство IDEF (Integration Definition for Function Modeling).

Тип модели программного обеспечения определяется выбранной технологией — методом программирования (процедурный, объектно-ориентированный, компонентный).

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

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

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

При объектно-ориентированном подходе модель построения программы — это иерархия классов, объектная декомпозиция. В результате декомпозиции получается структурная схема программы, представляющая собой многоуровневую, иерархическую схему взаимодействия экземпляров (объектов) классов. Следующий этап проектирования программного обеспечения заключается в разработке классов и их интерфейсов с описанием элементов-данных и элементов-функций каждого класса. Для проектирования пользовательских интерфейсов используются сложные интерфейсы: меню с иерархической структурой команд, свободная навигация, не привязанная к уровням иерархии (используется в Windows-приложениях).

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

4. Рабочий проект

Основные этапы и содержание работ на стадии Рабочий проект приведены в таблице.

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

Реализация — это процесс создания кода компонентов программного обеспечения на выбранном языке программирования, его тестирования и отладки.

При процедурном подходе реализация заключается в программировании функций и файлов (модулей) с использованием методов структурного программирования функций и программирования «сверху-вниз» (top-down).

Этап программирования задачи выполняется в следующей последовательности:

• программирование функций верхнего уровня схемы;
• программирование функций нижнего уровня схемы и т. д.

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

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

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

Тестирование и отладка являются завершающими этапами процесса реализации программного обеспечения.

Тестирование позволяет обнаружить ошибки, а отладка — их исправить.

В соответствии с этапами обработки программы (компиляция, компоновка, выполнение) различают следующие группы ошибок:

• синтаксические ошибки, обнаруживаемые компилятором при синтаксическом и семантическом анализе программы;
• ошибки компоновки, фиксируемые компоновщиком (редактором связей) при объединении модулей программы;
• ошибки выполнения, обнаруживаемые операционной системой или пользователем при выполнении программы.

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

Согласно рекомендациям Microsoft, различают следующие стадии тестирования:

·  модульное тестирование, проверяющее небольшие отдельные части программы (циклы, блоки, подпрограммы);

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

·  системное тестирование, проверяющее полную версию программы, взаимодействие с операционной системой;

·  стресс-тестирование, изучающее работу программы при ограниченных системных ресурсах;

·  бета-тестирование, позволяющее узнать мнение специалистов-пользователей;

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

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

Существуют и другие виды тестирования, направленные на проверку различных аспектов корректности кода программы и его соответствия техническому заданию. Отдельной разновидностью можно считать методологию разработки через тестирование (TDD, Test-Driven Development), согласно которой тесты для различных функций программы разрабатываются до создания кода этих функций. Такая методика позволяет сократить объем программного кода и повысить его надежность, но увеличивает затраты на разработку.

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

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

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

Но, безусловно, наиболее эффективными методами являются интегрированные средства отладки, имеющиеся в современных средах программирования. Например, отладчик Visual C++ встроен в среду Visual Studio, имеет свои меню и панели инструментов, которые позволяют выполнять следующие действия:

• установка различных точек прерывания, связанных с кодом, с данными, с сообщением, условных точек прерывания;
• выполнение программы до точки прерывания;
• просмотр в шести окнах отладчика информации о текущем состоянии программы при остановке программы в точке прерывания и при пошаговом выполнении;
• пошаговое выполнение программы с заходом в функции и без захода;
• выполнение программы до строки с курсором.

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

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

8. Внедрение

На стадии Внедрения осуществляется подготовка и передача ПО и программной

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

?? Задача 9. по разделу 1.3.1 «Стандарт ISO/IEC 12207:1995» ??

Контрольные вопросы:

1.3.3 Этапы ЖЦ ПО

Полный жизненный цикл информационной системы состоит из следующих основных этапов:

1.        анализ и формирование требований к будущей системе (Предпроектное обследование);

2.        проектирование;

3.        реализация проекта создания ИС;

4.        тестирование ИС;

5.        ввод ИС в эксплуатацию;

6.        эксплуатация и сопровождение ИС;

7.        вывод ИС из эксплуатации.

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

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

Ключевые цели:

·       Установить общее видение и границы проекта.

·       Выявить и согласовать потребности всех заинтересованных сторон (стейкхолдеров).

·       Сформулировать непротиворечивый, полный, проверяемый набор требований.

·       Оценить техническую и экономическую осуществимость проекта.

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

Основные активности:

·       Интервью, анкетирование, наблюдение за работой пользователей.

·       Анализ документов и существующих процессов («как есть»).

·       Моделирование бизнес-процессов (BPMN, диаграммы потоков данных).

·       Выявление и классификация требований: функциональные, нефункциональные (атрибуты качества), бизнес-требования, ограничения.

·       Разработка прототипов интерфейсов для уточнения потребностей.

·       Оценка рисков и составление предварительного плана проекта.

Выходные артефакты (результаты):

·       Устав проекта (Project Charter).

·       Отчет об обследовании.

·       Модели «As-Is» и «To-Be».

·       Спецификация требований к программному обеспечению (SRS) или бэклог продукта (в Agile).

·       Бизнес-кейс с предварительной оценкой затрат и выгод.

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

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

Данная стадия включает в себя этапы:

a.    Планирование работ предшествует работам над проектом. На этом этапе производится предварительная экономическая оценка проекта (Расчет ROI (Return on Investment), TCO (Total Cost of Ownership), анализ рисков и альтернатив (build vs. buy)), определяются цели разработки, строится план выполнения работ, создается и обучается рабочая группа.

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

c.    Моделирование. Построение двух моделей деятельности организации на основании результатов обследования:

·       Модель «Как есть» — отражает существующее на момент обследования положение дел в организации. Позволяет выявить «узкие» места в функционировании и сформулировать предложение по улучшению ситуации.

·       Модель «Как должно быть» — представляет наиболее оптимальную работу предприятия. Проектируется целевое состояние процессов. На этом этапе уже закладываются контуры будущей системы:

- Выделение ключевых сущностей и их атрибутов (предметная область → будущие классы/модули).

- Определение точек автоматизации → будущие функциональные модули.

- Анализ информационных потоков → будущие интерфейсы (API) между модулями.

Каждая из моделей представляет собой совокупность функциональной и информационной моделей деятельности предприятия. Необходимо определить способы перехода от модели «Как есть» к модели «Как должно быть».

Переход может осуществляться двумя путями:

a.    совершенствование существующих жизненных процессов;

b.    радикальное перепроектирование бизнес – процессов и внедрение новых технологий обработки.

Для сбора информации используются следующие способы:

• сравнительный анализ: выполняется сравнение целей и задач проекта с аналогичными или похожими проектами для установления взаимосвязей и выявления потенциальных проблем;

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

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

Логическим завершением каждой из этой процедур является пересмотр существующих планов.

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

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

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

• Совместимость требований. Функции разрабатываемого программного обеспечения могут оказаться несовместимыми по логическим (противоречивость функций) или психологическим (концептуальные различия) компонентам.

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

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

• Подверженность тестированию. Позволяет определить соответствие документации и требований.

2. Проектирование ИС осуществляется на основе моделей «Как должно быть».

Это творческо-техническая фаза, на которой требования трансформируются в детальные планы и спецификации, описывающие КАК система будет удовлетворять этим требованиям. Фокус смещается с «что» на «как».

Ключевые цели:

·       Разработать архитектурное решение, удовлетворяющее функциональным и нефункциональным требованиям.

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

·       Создать техническую документацию, достаточную для начала разработки.

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

Основные активности:

·       Архитектурное проектирование: Выбор стиля (микросервисы, монолит), определение ключевых подсистем и технологического стека.

·       Проектирование данных: Создание логической и физической модели базы данных.

·       Проектирование компонентов: Детальная спецификация программных модулей, их интерфейсов (API), алгоритмов и структур данных.

·       Проектирование пользовательского интерфейса (UI/UX): Создание макетов, сценариев взаимодействия, дизайн-системы.

·       Проектирование интеграций: Описание протоколов взаимодействия с внешними системами.

Выходные артефакты:

·       Архитектурная схема (диаграмма компонентов, развертывания).

·       Техническое задание (ТЗ) или детальные спецификации.

·       Диаграммы UML (Sequence, Class, State).

·       Прототипы/макеты интерфейсов.

·       Спецификация API (например, в OpenAPI).

Риски при некорректном выполнении: Создание неоптимальной, нерасширяемой или неустойчивой архитектуры, что ведет к проблемам с производительностью, сложностям в разработке и высоким затратам на поддержку.

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

-  Концептуальное проектирование (Архитектура высокого уровня):

• Выбор технологического стека (языки, фреймворки, СУБД).
• Определение архитектурного стиля (монолит, микросервисы, сервис-ориентированная архитектура). Это ключевое решение, определяющее границы и принципы взаимодействия модулей.
• Проектирование компонентной архитектуры: Выделение основных подсистем и модулей, определение их ответственности.
• Проектирование данных: Концептуальная и логическая модель данных (ER-диаграммы).

-  Детальное проектирование (Низкоуровневое):

• Спецификация модулей: Детальное описание интерфейсов (вход/выход), алгоритмов, структур данных для каждого программного модуля.
• Проектирование базы данных: Физическая модель данных, индексы, процедуры.
• Проектирование пользовательского интерфейса (UI/UX): Макеты, сценарии взаимодействия, прототипы.
• Спецификация интеграций: API-контракты (например, с использованием OpenAPI/Swagger), форматы обмена сообщениями.
• Выходные артефакты: Техническое задание (ТЗ), спецификации, диаграммы UML (Sequence, Class, Component), прототипы.

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

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

Ключевые цели:

·       Создать качественный, соответствующий проекту и стандартам код.

·       Обеспечить модульность, тестируемость и сопровождаемость кода.

·       Организовать эффективную совместную работу команды разработчиков.

·       Интегрировать отдельные компоненты в единую систему.

Основные активности:

·       Написание исходного кода в соответствии с техническим заданием и стандартами кодирования.

·       Модульное (юнит) тестирование (часто по методологии TDD).

·       Обзоры кода (Code Review) для обеспечения качества и передачи знаний.

·       Статический анализ кода.

·       Сборка (Build) компонентов и системы в целом.

·       Непрерывная интеграция (CI) — частое слияние кода в общий репозиторий с автоматической сборкой и тестированием.

·       Версионный контроль кода (Git).

Выходные артефакты:

·       Исходный код системы в репозитории.

·       Исполняемые файлы / артефакты сборки.

·       Наборы модульных тестов.

·       Техническая документация к коду (комментарии, README).

Риски при некорректном выполнении: Низкое качество кода, несоблюдение архитектуры, рост «технического долга», что делает систему нестабильной и крайне дорогой в изменении.

Стадия включает фазы:

-  Подготовительная фаза:

·  Настройка среды разработки (IDE, инструменты сборки).

·  Создание репозитория кода (Git) и стратегии ветвления (Gitflow, Trunk-based).

·  Настройка CI/CD-конвейера для автоматической сборки и базового тестирования.

-   Непосредственная разработка модулей:

·  Кодирование в соответствии со спецификациями и стандартами кодирования (code style, naming conventions).

·  Применение принципов «чистого кода» (Clean Code) и паттернов проектирования (SOLID, GRASP) на уровне модулей.

·  Параллельная разработка модульных (юнит) тестов (TDD — Test-Driven Development — как возможный подход).

·  Проведение регулярного обзора кода (Code Review) для обеспечения качества и обмена знаниями в команде.

·  Непрерывная интеграция (Continuous Integration): Частая сборка и слияние кода с главной веткой, автоматический прогон тестов.

4. Тестирование - это фаза проверки качества, направленная на систематическое выявление дефектов в созданном программном обеспечении, а также на подтверждение того, что система соответствует заявленным требованиям и готова к эксплуатации.

Ключевые цели:

·       Обнаружить и зафиксировать как можно больше дефектов до передачи системы пользователям.

·       Оценить соответствие системы функциональным и нефункциональным требованиям.

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

·       Минимизировать риски сбоев при эксплуатации.

Основные активности:

• Планирование тестирования, разработка тестовых сценариев и чек-листов.
• Модульное, интеграционное, системное и приемочное тестирование.
• Нефункциональное тестирование: нагрузочное, стрессовое, тестирование безопасности и удобства использования.
• Регрессионное тестирование — проверка, что новые изменения не сломали существующий функционал.
• Автоматизация тестирования (где это целесообразно).
• Анализ и классификация обнаруженных дефектов, их передача на исправление.

Выходные артефакты:

• План тестирования.
• Тестовые сценарии и данные.
• Отчеты о дефектах (баг-репорты).
• Итоговый отчет о тестировании с рекомендацией о готовности к выпуску.

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

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

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

Ключевые цели:

·       Обеспечить плавный, контролируемый и безопасный переход пользователей от старых процессов/систем к новой ИС.

·       Минимизировать простои и негативное влияние на бизнес-процессы.

·       Добиться того, чтобы пользователи могли эффективно работать с новой системой.

Основные активности:

·       Подготовка производственной среды: установка и настройка серверов, СУБД, сетевого оборудования.

·       Развертывание (деплой) установочных пакетов системы и перенос данных.

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

·       Осуществление стратегии перехода: прямой замены, параллельного запуска, пилотного внедрения или поэтапного ввода.

·       Формальная приемка-передача системы заказчику (подписание акта).

Выходные артефакты:

·       Развернутая и работающая система в продуктивной среде.

·       Акт о вводе в эксплуатацию.

·       Пользовательская и административная документация.

·       Обученные пользователи и команда поддержки.

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

Стадия включает этапы:

- Пилотное внедрение (Pilot Launch): Запуск системы для ограниченной группы пользователей или в одном подразделении.

- Фазированный ввод (Phased Rollout): Поэтапный запуск функциональности.

- Полномасштабный запуск (Big Bang): Полный переход на новую систему в назначенную дату.

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

6. Эксплуатация и сопровождение ИС

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

Ключевые цели:

·       Обеспечить стабильную, надежную и безопасную работу системы.

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

·       Реализовывать необходимые доработки для увеличения ценности системы.

Основные активности:

·       Техническая поддержка и устранение инцидентов.

·       Мониторинг производительности, доступности и безопасности системы.

·       Внесение изменений:

- Корректирующие — исправление ошибок.

- Адаптивные — приспособление к новой среде (ОС, законы).

- Совершенствующие — добавление новой функциональности или улучшение существующей.

·       Резервное копирование и восстановление.

·       Оптимизация производительности.

Выходные артефакты:

·       Стабильно работающая, актуальная система.

·       Журналы инцидентов и изменений.

·       Обновленные версии документации и кода.

·       Отчеты о работе системы.

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

Наиболее длительная и ресурсоемкая фаза, которая включает:

- Техническая поддержка: Устранение инцидентов и ошибок (корректирующее сопровождение).

- Адаптивное сопровождение: Дообучение пользователей, настройка под изменяющиеся условия работы, адаптация к новым версиям ОС или платформ.

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

- Управление инцидентами и проблемами (ITSM/ITIL).

 - Мониторинг и аналитика: Отслеживание доступности, производительности, анализ логов для предупреждения проблем.

7. Вывод из эксплуатации

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

Ключевые цели:

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

Основные активности:

• Планирование вывода (уведомление пользователей, определение даты).
• Миграция данных в новую систему или архивные хранилища.
• Резервное копирование финального состояния для юридических целей.
• Отключение сервисов, остановка серверов.
• Утилизация или перепрофилирование оборудования.
• Анализ извлеченных уроков для будущих проектов.

Выходные артефакты:

• Акт о выводе системы из эксплуатации.
• Архивные копии данных и кода.
• Отчет о завершении проекта/жизненного цикла.

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

Стадия включает этапы:

- Анализ и планирование: Определение даты вывода, оценка рисков.

- Миграция данных: Перенос исторических данных в новую систему или в архивный формат.

- Отключение сервисов: Поэтапное прекращение работы компонентов системы.

- Архивация: Сохранение кода, документации и данных для юридических и исторических целей.

 - Вывод оборудования из эксплуатации или его перепрофилирование.

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

?? Задача 10.  «Проект внедрения складской системы для сети розничных магазинов» ??

Контрольные вопросы:

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

1.3.4 Модели ЖЦ ПО

?? Задание 11.  Используя информацию из опорного конспекта и пользуясь дополнительными источниками опишите: ??

- Схема (Рисунок)

- Описание модели

- Описание каждого этапа (стадии), что на нем происходит

- Результаты каждой стадии

- На каком этапе начинается тестирование

- Размер команды разработчиков

- Особенности

- Для каких по масштабу и направленности проектов разработки подходит

- Преимущества

- Недостатки

В основе любого жизненного цикла лежат модели и методологии разработанные на их основе.

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

Модель ЖЦ зависит от характерных особенностей информационной системы и условий, в которых она создается.

Модель жизненного цикла информационной системы может включать:

1.    Стадии.

2.    Основные результаты выполнения работ на каждой стадии.

3.    Ключевые события (точки завершения работ и принятия решений)

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

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

Можно выделить  модели жизненного цикла программного обеспечения:

•      Каскадная (Waterfall)

•      Итерационная с промежуточным контролем

•      Спиральная (Spiral Model)

•      Итерационная, Инкрементальная

•      RAD (Rapid Application Development)

•       v-образная V-Model

•      Rational Unified Process (RUP)

•      Microsoft Solutions Framework (MSF)

•      Гибкие методологии Agile:

o      scrum,

o      Kanban

o       extreme Programming (XP)

Моделей разработки ПО много, но, в общем случае, классическими можно считать каскадную, v-образную, итерационную, инкрементальную, спиральную и гибкую.

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

Достоинства модели заключаются в следующем:

·                     получение после этапа законченного набора проектной документации без возврата на предыдущие этапы;

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

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

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

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

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

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

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

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

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

Необходимость возвратов на предыдущие этапы бывает обусловлена следующими причинами:

·                     неточные спецификации, уточнение которых требует пересмотра предыдущих решений;

·                     изменения требований заказчика;

·                     моральное устаревание технических и программных средств.

К достоинствам модели относятся:

•   устойчивость к изменению кадрового состава;

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

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

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

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

Недостатки модели:

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

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

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

Таким образом, каскадная методология — хорошее решение, с точки зрения сроков и отчетности, но очень слабое в плане качества, поэтому сегодня ее рекомендуется использовать только в трех случаях:

·           при ориентации ИС на заказчика, требующего прозрачность работ и исполнение в назначенные сроки;

·           при наличии в штате руководителей соответствующей квалификации;

·           при исполнении проекта, не имеющего конкуренции на рынке.

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

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

 (а) в неправильном тесте,

(б) в ошибке кодирования (реализации),

(в) в неверной архитектуре системы,

(г) некорректности требований к программному обеспечению и т.д.

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

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

Разработка ИС ведется итерациями

Каждый этап имеет с циклы обратной связи между итерациями

Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах

Время жизни каждого из этапов растягивается на весь период разработки

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

Некоторые свойства модели:

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

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

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

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

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

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

При этом обосновывается и проверяется возможность реализации спроектированных технических решений.

В спиральной модели разработка системы происходит повторяющимися этапами – витками спирали. Каждый виток спирали – один каскадный или V-образный жизненный цикл.

На каждом витке создается прототип проектируемой информационной системы  (законченная версия системы, реализующая некоторый набор функций), который на следующих витках спирали ЖЦ ИС совершенствуется, дополняется и доводится до полного внедрения.

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

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

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

Новый виток спирали соответствует поэтапной модели создания фрагмента информационной системы.

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

При использовании спиральной модели ЖЦ:

-       происходит ориентация на модернизацию информационной системы;

- осуществляется аккумулирование всех решений в процессе проектирования и создания моделей и прототипов информационной системы;

-       проводится анализ издержек и всех рисков в процессе проектирования ИС.

Этот многократный цикл, завершающийся созданием новой версии информационной системы.

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

•  проработка целей, альтернатив и ограничений;

•  анализ рисков и прототипирование;

•  разработка (промежуточной версии) продукта;

•  планирование следующего цикла.

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

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

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

Например, на первой итерации создается и поставляется пользователю первая версия программного продукта с реализацией внешних интерфейсов и главных функций, на следующих итерациях — следующие версии программного продукта с реализацией дополнительных функций.

Достоинства модели:

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

•     допускает изменение требований при разработке системы;

•     обеспечивает большую гибкость в управлении проектом;

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

•     позволяет совершенствовать процесс разработки — анализ, проводимый в каждой итерации, позволяет провести оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации;

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

Недостатки модели:

•     увеличивается неопределенность в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

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

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

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

Как следует из названия модели, ей свойственна определённая двойственность (а ISTQB-глоссарий даже не приводит единого определения, разбивая его на отдельные части):

•  с точки зрения жизненного цикла модель является итерационной, т.к. подразумевает многократное повторение одних и тех же стадий;

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

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

Для каждого инкремента выполняется:

·          Анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;

·          Проектирование, на котором происходит проектирование архитектуры, допроектирование тех вещей, которые не были сделаны на предыдущем инкременте;

·          Разработка;

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

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

Сам подход является однократным, т.е. мы весь наш проект делаем за один большой этап, имея в виду требования, но весь проект делится на инкременты, это небольшие версии продуктов, для которых заранее определена функциональность. Т.е. мы говорим, что у нас вся длительная разработка состоит, например, из 5 фаз. На первом этапе получим однопользовательскую версию, на втором инкременте (фазе) мы получим версию, которая поддерживает много пользователей, на третьем инкременте у нас появится поддержка веб-интерфейсов, а на четвертом какое-нибудь протоколирование и т.д. (рис. 6). Т.е. хоть требования у нас все равно задаются только один раз, но на выходе у нас появляется несколько инкрементов.

Длина итераций может меняться в зависимости от множества факторов, однако сам принцип многократного повторения позволяет гарантировать, что и тестирование, и демонстрация продукта конечному заказчику (с получением обратной связи) будет активно применяться с самого начала и на протяжении всего времени разработки проекта.

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

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

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

•    отсутствия у заказчика возможности сразу профинансировать весь проект;

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

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

Преимущества инкрементной модели:

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

·          не требуется заранее тратить средства, необходимые для разработки всего проекта, поскольку сначала выполняется разработка и реализация основной функции или функции из группы высокого риска;

·          в результате выполнения каждого инкремента получается функциональный продукт;

·          ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);

·          риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);

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

Недостатки инкрементной модели:

·          в модели не предусмотрены итерации в рамках каждого инкремента;

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

·          формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом;

·          поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах;

·          для модели необходимо хорошее планирование и проектирование;

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

5. RAD (Rapid Application Development)

RAD (Rapid Application Development) - модель жизненного цикла программного обеспечения, которая акцентирует внимание на быстрой разработке прототипов и итеративном подходе к разработке приложений. RAD-модель может использоваться для разработки различных типов приложений, включая веб-приложения, мобильные приложения и десктопные приложения.

RAD-модель включает в себя следующие этапы:

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

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

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

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

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

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

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

Преимущества:

Модель RAD (Rapid Application Development) – это методология разработки программного обеспечения, основанная на быстром создании прототипов и итеративном подходе. Её главными преимуществами являются:

Быстрота разработки: RAD-модель позволяет быстро создавать рабочие прототипы, которые можно демонстрировать клиентам и пользователям. Это ускоряет процесс разработки и позволяет быстрее получать обратную связь на ранних стадиях проекта.

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

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

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

Большая прозрачность: RAD-модель обеспечивает большую прозрачность процесса разработки, так как клиенты и пользователи активно участвуют в тестировании итеративных прототипов. Это позволяет улучшить коммуникацию и снизить риски непонимания требований.

Улучшенная коммуникация: RAD-модель способствует улучшению коммуникации между командами разработчиков, тестировщиков, менеджеров и клиентов. Более частые встречи и общение улучшают понимание требований и уменьшают риск непонимания.

Недостатки:

Несмотря на ряд преимуществ, у модели RAD есть и недостатки, включая:

Ограниченность масштабируемости: RAD-модель может быть ограничена по масштабу проекта. Более крупные проекты могут потребовать больше времени на создание прототипов и итераций, что может снизить эффективность модели.

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

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

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

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

Когда использовать:

Модель RAD (Rapid Application Development) подходит для проектов, где сроки и время разработки критичны, а клиенты и пользователи требуют быстрой реакции на изменения и быстрое внедрение новых функциональных возможностей. Она также хорошо подходит для проектов, где требуется демонстрация прототипов клиентам и пользователям на ранних стадиях разработки, чтобы получать обратную связь и улучшать продукт.

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

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

6. «V-Model»

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

Модель имеет специфику проектов для государственных органов: фиксированные требования, стоимость и время. Унаследовала структуру «шаг за шагом» от каскадной модели.

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

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

В V-модели каждому этапу проектирования и разработки системы соответствует отдельный уровень тестирования. Здесь процесс разработки представлен нисходящей последовательностью в левой части условной буквы V, а стадии тестирования — на ее правом ребре (рис. 4). Соответствие этапов разработки и тестирования показано горизонтальными линиями.

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

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

Когда использовать V-модель?

·                Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.

·                Для малых и средних проектов, где требования четко определены и фиксированы.

·                В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

Достоинства V-модели:

• строгая последовательность этапов;

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

• улучшенный, по сравнению с каскадной моделью, тайм- менеджмент;

• промежуточное тестирование. Недостатки V-модели:

• недостаточная гибкость модели;

• создание программы происходит на этапе написания кода, т. е. уже в середине процесса разработки;

•       недостаточный анализ рисков;

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

Когда рекомендуется использовать V-модель:

1)            в проектах, в которых существуют временные и финансовые ограничения;

2)            для задач, которые предполагают более широкое, по сравнению с каскадной моделью, тестовое покрытие.

7. Rational Unified Process (RUP)

Rational Unified Process – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработаниподдерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования, процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.

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

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

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

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

использования передового опыта в:

  итерационной разработке ПО,

  управлении требованиями,

  использовании компонентной архитектуры,

  визуальном моделировании,

  тестировании качества ПО,

  контроле за изменениями в ПО.

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

8. Microsoft Solutions Framework (MSF)

Microsoft Solutions Framework (MSF) - это методология ведения проектов и разработки решений, базирующаяся на принципах работы над продуктами самой фирмы Microsoft, и предназначенная для использования в организациях, нуждающихся в концептуальной схеме для построения современных решений.

Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.

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

В момент подготовки данного учебного курса последней версией MSF была 3.1, при этом существовали документы, относящиеся к версии 4.0 beta.

MSF состоит из двух моделей:

  модель проектной группы;

  модель процессов;

и трех дисциплин:

  управление проектами;

  управление рисками;

  управление подготовкой.

В MSF нет роли «менеджер проекта» и иерархии руководства, управление разработкой распределено между руководителями отдельных проектных групп внутри коллектива, выполняющих следующие задачи:

  Управление программой

  Разработка

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

  Управление выпуском

  Удовлетворение потребителя

  Управление продуктом

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

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

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

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

9. Гибкие методологии Agile:

Гибкая модель(agile model) представляет собой совокупность различных подходов к разработке ПО и базируется на т. н. «agile-манифесте»:

•  Люди и взаимодействие важнее процессов и инструментов.

•  Работающий продукт важнее исчерпывающей документации.

•  Сотрудничество с заказчиком важнее согласования условий контракта.

•  Готовность к изменениям важнее следования первоначальному плану.

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

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

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

Тем не менее можно утверждать, что всё больше и больше проектов начинают использовать гибкую модель разработки.

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

9.1 scrum

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

В конце каждого этапа (в терминологии Scrum — спринта) готовый продукт предоставляется заказчику. Полученный от заказчика отзыв позволяет выявить возможные проблемы или пересмотреть некоторые аспекты первоначального плана. Прежде чем приступить к описанию жизненного цикла Scrum-проекта, стоит рассказать об основных ролях, принятых в Scrum-методологии: Владелец продукта (Product owner) представляет интересы конечного пользователя. Скрам-мастер (Scrum master) следит за соблюдением принципов Scrum-разработки, координирует процесс, проводит ежедневные собрания (Scrum Meetings). Скрам-команда (Scrum team) участвует в разработке продукта. В скрам-команду входят программисты, тестировщики, аналитики и прочие специалисты. (5-9 чел.) Стейкхолдеры (бизнес-заказчик) и пользователи.

Шаг 1. Создание бэклога продукта Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story (описание функциональной возможности ПО простыми словами, составленное с точки зрения пользователя)). Каждой истории соответствует уникальный ID. Описание каждой истории должно включать в себя набор обязательных полей, необходимых для дальнейшей работы над проектом: Важность (Importance). Степень важности задачи, по мнению владельца продукта. Описывается произвольным числом. Предварительная оценка (Initial estimate). Предварительная оценка объема работ. Измеряется в story point’ах. Как продемонстрировать (How to demo). Описание способа демонстрации завершенной задачи. 9

Шаг 2. Планирование спринта и создание Бэклога спринта На этапе планирования определяется длительность спринта. Короткий спринт позволяет чаще выпускать работающие версии продукта, а, следовательно, чаще получать отзывы от клиента и вовремя выявлять возможные ошибки. С другой стороны, длинные спринты позволяют посвятить решению проблемы больше времени. Оптимальная длина спринта выбирается как нечто среднее между этими двумя решениями и составляет обычно около 2-ух недель. На этом этапе важно взаимодействие владельца продукта и скрамкоманды. Владелец продукта определяет приоритет той или иной задачи, а задача скрамкоманды состоит в определении необходимых трудозатрат. Во время планирования спринта команда выбирает самые приоритетные пользовательские истории из бэклога продукта и решает, каким образом будут решаться поставленные задачи. Истории, выбранные для реализации в течение данного спринта, составляют Бэклог спринта (Sprint backlog). Количество историй, попадающих в бэклог спринта зависит от их длительности в story point’ах, присвоенных каждой истории на этапе предварительной оценки. Это количество выбирается так, чтобы каждая история была успешно реализована к концу спринта.

Шаг 3. Работа над спринтом. Scrum meetings После того, как определены актуальные для данного спринта пользовательские истории, начинается процесс разработки. Для визуализации процесса разработки удобно использовать учетные карточки. Они могут иметь вид больших карточек с названием конкретной истории и маленьких стикеров, описывающих отдельные задачи, необходимые для реализации истории. После начала работы над определенной задачей, ее стикер перемещается из поля «Запланировано» в область «В работе». По завершении работы над задачей, стикер перемещается в поле «Тестирование» и затем, при успешном выполнении тестирования, в поле «Готово». Расположив истории согласно их важности, можно получить представление о текущем состоянии проекта: Также может быть использовано программное обеспечение, предназначенное для такого рода задач. Примером такого ПО может служить, например, Atlassian JIRA. Важной отличительной особенностью Scrum являются ежедневные совещания (Scrum meetings), целью которых является дать команде полную и достоверную информацию о том, на каком этапе находится процесс разработки. Во время совещания каждый участник скрам-команды сообщает о том, какая задача им выполнена, какая будет выполняться и какие у него возникли трудности во время работы.

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

Финал каждого спринта — демонстрация готового продукта. Скрам-команда составляет ревью, в котором описывает цели спринта, поставленные задачи и то, как они были решены. Владелец продукта, заказчики и пользователи на основе ревью и демонстрации принимают решение о том, что должно быть изменено в дальнейшем процессе разработки.

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

9.2 .Kanban

«KANBAN» стал символом визуализации рабочего процесса (карточки на стенде) и сейчас обозначает стратегию оптимизации потока поставки ценности посредством 10 процесса, использующую систему вытягивания и имеющую ограничение незавершённой работы. Этот метод, демонстрирующий, что происходит в процессе работы, увеличивает предсказуемость процедур, благодаря чему рабочий процесс становится прозрачным и равномерным. Kanban также можно использовать, чтобы достичь большей согласованности действий, а это означает более быстрое достижение стратегических целей

Kanban — метод управления разработкой, который реализует принцип «точно в срок» и способствует равномерному распределению нагрузки между работниками.  

Некоторые особенности Kanban-модели жизненного цикла разработки ПО:

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

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

·  Поиск слабых мест. Визуализация всех фаз процесса разработки помогает быстро понять, на каком этапе возникают проблемы и выявить, где находится «бутылочное горлышко».

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

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

9.3 extreme Programming (XP)

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

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

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

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

XP ориентирована на:

  командную работу с тесными связями внутри команды и с заказчиком,

  разработку наиболее простых работающих решений,

  гибкое адаптивное планирование

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

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

Основными практиками XP являются

  Планирование процесса

  Частые релизы

  Метафора системы

  Простая архитектура

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

  Рефакторинг

  Парное программирование

  Коллективное владение кодом

  Частая интеграция

  40-часовая рабочая неделя

  Стандарты кодирования

  Тесное взаимодействие с заказчиком

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

 На самом деле в любой модели жизненного цикла можно увидеть четыре вида процессов:

1. Основной процесс разработки

2. Процесс верификации

3. Процесс управления разработкой

4. Вспомогательные (поддерживающие) процессы

?? Задача 12. Выбор модели жизненного цикла разработки ПО ??

?? Задача 13. «Создай свой ЖЦ!»

Контрольные вопросы:

1.      Дайте определение «модели жизненного цикла программного обеспечения» и назовите её основные структурные элементы.

2.      Каков главный принцип каскадной (водопадной) модели? Перечислите её основные фазы в правильной последовательности-2.

3.      Почему в каскадной модели этап тестирования считается критически важным и в то же время проблемным? На каком этапе он обычно проводится?-2

4.      В чем заключаются ключевые достоинства каскадной модели, делающие её применимой для определённых проектов?-4-9

5.      Какие проектные условия являются идеальными для выбора каскадной модели? Приведите пример такого проекта-2.

6.      Опишите основную идею спиральной модели жизненного цикла. Что происходит на каждом витке «спирали»?

7.      В чем заключается принципиальное различие между итерационной и инкрементальной моделью? Можно ли их использовать вместе?-3-10

8.      Какой подход к разработке — итерационный или инкрементальный — лучше подходит для проекта с постоянно меняющимися или плохо определёнными требованиями? Обоснуйте свой выбор-10.

9.      Спиральная модель часто считается комбинацией двух других подходов. Каких именно и за счёт чего это достигается?-4

10.  Назовите главный риск, связанный с использованием спиральной модели, и как его можно минимизировать?

11.  Что такое прототип в контексте моделей ЖЦ и какова его основная цель в таких моделях, как RAD или спиральная?-4

12.  Перечислите четыре ценности Манифеста гибкой (Agile) разработки. Как они влияют на процесс разработки ПО?

13.  В чем заключается ключевое отличие подхода Agile от каскадной модели с точки зрения структуры процесса и работы с требованиями?-1

14.  Опишите базовый рабочий цикл в Scrum. Что такое «спринт», и какие ключевые события в него входят?-1

15.  Каковы основные практики Экстремального программирования (XP), направленные на обеспечение высокого качества кода? Назовите не менее трёх-5-6.

16.  Какой принцип лежит в основе методологии Kanban и как он визуализируется в работе команды?

17.  Методология RUP также использует итерационный подход. Чем её фазы (Inception, Elaboration, Construction, Transition) отличаются от простых циклов разработки?-3

18.  V-образная модель делает особый акцент на тестировании. Как в ней организована связь между этапами разработки и этапами тестирования?

19.  Для каких типов проектов и условий наиболее подходит модель быстрой разработки приложений (RAD)?

20.  Microsoft Solutions Framework (MSF) объединяет идеи разных моделей. Какой известный инструмент управления используется в MSF для балансировки ключевых ограничений проекта (сроки, ресурсы, содержание)?

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

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

1.4. Основные этапы разработки программного обеспечения

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

Анализ осуществимости.

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

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

Анализ осуществимости часто используется для принятия организацией решения "создать или приобрести": стоит ли разрабатывать продукт самим или экономически выгоднее купить похожий?

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

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

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

Результатом является документ, в котором должны содержаться, по крайней мере, следующие пункты:

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

2 Альтернативные решения и ожидаемые от них преимущества.

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

Выявление, понимание и спецификация требований

Между разработчиками и заказчиками существует соглашение о том, что процедуры

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

Спецификация ПО – формализованное представление сервисов, которыми будет

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

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

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

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

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

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

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

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

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

Ниже приведен возможный перечень пунктов документа спецификации требований, который может быть руководством специалиста по программному обеспечению:

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

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

3.Нефункциональные требования. Их можно классифицировать по следующим категориям:

- надежность (работоспособность, целостность, безопасность, защищенность и т.д.);

- точность результатов;

- производительность;

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

- эксплуатационные ограничения; физические ограничения; переносимость и др.

4.Требования к процессу разработки и сопровождения. Сюда входят процедуры управления качеством (в частности процедуры тестирования системы), приоритеты необходимых функций, возможные изменения процедур обслуживания системы и прочие требования.

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

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

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

Кодирование и тестирование модулей

Написание кода и тестирование модулей — операции, посредством которых пишутся

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

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

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

Фактически пошаговые разработки могут постепенно интегрировать и тестировать компоненты по мере их разработки. Несмотря на то, что два этих этапа можно объединить, они принципиально различаются по масштабу проблем, которые призваны решать: первая относится к локальному программированию, тогда как вторая — к программированию системы в целом.

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

Поставка, развертывание и сопровождение ПО

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

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

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

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

Другой тип классификации затрат на сопровождение был описан в работе Линца (Lienz) и Свонсона (Swanson) в 1980 г. Их анализ показал, что порядка 42 % затрат относятся на внесение изменений в требования пользователей, 17 % — на изменение формата данных, 12 % — на устранение аварийных неполадок, 9 % — на отладку процедур, 6 % — на модификацию аппаратных средств, 5 % — на исправление документации, 4 % — на повышение производительности и остальное — на прочие причины.

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

- Как уже рассматривалось раньше, требования являются основным источником

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

- Довольно много ошибок не исправляется до поставки системы заказчику. Это —

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

- Подверженность изменениям — это характерное свойство любого программного

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

Контрольные вопросы:

1.      Какова цель этапа анализа осуществимости (feasibility study) и какой ключевой вопрос (например, "создать или купить?") он помогает решить?

2.      Какие три основных пункта должен содержать итоговый документ по анализу осуществимости?

3.      Дайте определение спецификации программного обеспечения (Software Specification). Что она должна описывать, а что — нет?

4.      На какие две основные категории делятся требования к программному обеспечению? Приведите примеры каждой категории.

5.      Почему деятельность по определению требований считается одной из самых критичных в процессе разработки ПО?

6.      Что является результатом (выходным артефактом) деятельности по проектированию и как этот документ называется?

7.      Чем принципиально отличается системное тестирование от тестирования отдельных модулей?

8.      Что такое бета-тестирование и какова его основная цель в процессе поставки ПО?

9.      Назовите три основных вида технического сопровождения (maintenance) ПО и дайте им краткую характеристику.

10.  Согласно приведённой статистике, на какие цели чаще всего тратятся ресурсы в процессе сопровождения ПО и какой вывод из этого следует?

1.5. Документирование программ

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

Эти документы сопровождают процессы:

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

Вся документация делится на две основные группы:

• документы управления разработкой программного обеспечения;
• документы, входящие в состав программного обеспечения.

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

К ней относятся документы, связанные с разработкой и сопровождением программного обеспечения).

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

Сюда включаются различные стандарты планы, отчёты, рабочие материалы (документы) и переписка между разработчиками и управляющими разработкой.

Эти документы регламентируют процессы, отвечая на вопросы «КТО?», «КОГДА?» и «КАК организовать?».

1.1. Документы управления разработкой (на этапе создания ПО)

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

1.2. Документы управления сопровождением

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

Группа 2. Документы, входящие в состав программного обеспечения

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

Эти документы являются частью продукта и передаются заказчику/пользователю. Они делятся на два типа, отвечающие на вопросы «ЧТО?» и «КАК это устроено/использовать?»

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

• документация по сопровождению;
• пользовательская документация.

2.1 Документация по сопровождению - описывает внутреннее устройство ПО для его понимания, модификации, исправления и сборки.

2.2. Пользовательская документация (входит в состав ПО)

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

К пользовательской документации относятся документы:

-    описывающие процессы установки и настройки ПО

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

Для иллюстрации разделения и взаимосвязи между группами можно представить следующую схему:

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

 В связи с этим для обеспечения её качества разработан ряд международных и национальных стандартов (таких как ГОСТ, ISO/IEC, IEEE).

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

Задания:

Вариант 1: Определение типа документа по описанию ситуации

Задание: Определите, к какой категории документации относится описанный документ (управление разработкой, управление сопровождением, документация по сопровождению, пользовательская документация).

Вариант 2: Подбор документа под задачу

Задание: Выберите из списка документ, который необходимо создать или использовать в описанной ситуации.

Вариант 3: Анализ соответствия стандартам

Задание: Определите, какой стандарт (ГОСТ, ISO/IEC, IEEE и др.) наиболее подходит для разработки описанного документа.

Вариант 4: Анализ жизненного цикла документации

Задание: Определите, на каком этапе жизненного цикла ПО (планирование, разработка, тестирование, сопровождение) создаётся или актуализируется указанный документ.

Вариант 5: Ситуации с ошибками в документации

Задание: Определите, какая ошибка допущена в процессе документирования в описанной ситуации, и предложите, как её исправить.

Вариант 6: Выбор документации для разных методологий разработки

Задание: Определите, какие документы являются наиболее критичными для указанной методологии разработки (Waterfall, Agile, DevOps).

Скачано с www.znanio.ru