ИТ. Жизненный цикл по (проектирование, разработка, сопровождение)
 Скачать 285.41 Kb.
|
|
Информационные технологии Жизненный цикл ПО (проектирование, разработка, сопровождение) + примеры Содержание
ВВЕДЕНИЕ В конце 60-х – начале 70-х годов 20 века в программировании наступил кризис, в связи с которым появилось понятие жизненного цикла программного обеспечения (далее – ПО). Сущность кризиса заключалась в том, что участились выходы из-под контроля программных проектов: нарушение сроков, превышение финансовых затрат, неудовлетворение результатами. Многие проекты так и не были доведены до конца. Кроме этого, оказалось, что разработать программу недостаточно, надо её сопровождать. Этап сопровождения, чаще всего, требует средств гораздо больших, чем сама разработка. Масштабы ситуации, вызванной ростом сложности проектов, нарастали. Пришло время принимать радикальные меры для совершенствования принципов и методов разработки ПО , учитывая его развитие и сопровождение. Было решено обратиться к опыту успешной разработки не менее сложных проектов промышленного проектирования и производства. Понятие жизненного цикла продукта составляет методологическую основу промышленной инженерии, как совокупность всех действий, выполняемых на протяжении всего существования продукта. Взаимосвязанность всех этих действий составляет смысл жизненного цикла [5]. 1. Программное обеспечение Компьютерная программа – это упорядоченный набор команд. Все программы, имеющиеся на компьютере, составляют его программное обеспечение. Различают три вида компьютерных программ: системные программы, прикладные программы и инструментарии программирования (рис. 1).  Рисунок 1. Виды программ Инструментарии программирования иногда относят к системным программам. Системные программы обеспечивают эффективную работу всех частей компьютера, организуют хранение и передачу информацию. В системных программах особое место занимают операционные системы. Операционная система – это комплекс программ, обеспечивающих как единое целое работу всех устройств компьютера и управляющих информацией в компьютере. Другой важной частью системных программ являются служебные программы – утилиты, дополняющие системную программу, увеличивающие её возможности и, помимо этого, самостоятельно решающие некоторые задачи. (антивирусные программы, программы архивирования, проверки работоспособности устройств, управления устройствами (драйверы)). Прикладные программы – самый многочисленный и важный для пользователей класс программ на компьютере. Они предназначены для решения конкретных задач пользователя (создание рисунков, набор текстов, игра). Программы, относящиеся к инструментариям программирования, служат для создания системных и прикладных программ (языки программирования типа Basic, Pascal, C++, LOGO). На рисунке 2 представлена схема, отражающая связь между разными видами программного обеспечения и аппаратной частью компьютера. Из нее видно, что работа устройств (аппаратное обеспечение) напрямую связана с системными программами [].    Рисунок 2. Связь между видами программного обеспечения Генеральной целью создания и применения компьютерных программ всегда является управление устройствами [3]. 2. Жизненный цикл и процессы разработки ПО Жизненным циклом программного обеспечения можно назвать период времени, который начинается с того момента, когда принято решение о необходимости создания программного продукта и заканчивается когда продукт изъят из эксплуатации. Традиционно выделяют следующие основные этапы жизненного цикла программного обеспечения: анализ требований, проектирование, кодирование (программирование), тестирование и отладка, эксплуатация и сопровождение. Особенностью разработки программного продукта является принятие решений на начальных этапах с их реализацией на последующих этапах. Ошибки в требованиях к программному продукту способны привести не только к потерям на этапах разработки и эксплуатации, но и к провалу проекта. Внесение изменений в спецификацию программного продукта чаще всего вызывает необходимость повторить все следующие этапы проектирования и создания программного продукта [7]. Для того, чтобы качественный программный продукт проектировался, создавался и выпускался легче существуют различные модели жизненного цикла ПО. Требования к проекту являются определяющими при выборе подхода к циклу разработки. 2.1. Модели жизненного цикла Обычно обсуждаемые стандарты пытаются описать, как должен выглядеть любой процесс разработки ПО. При этом они вводят очень обобщенные модели жизненного цикла ПО, которые сложно использовать при организации конкретного проекта. В рамках специфических моделей жизненного цикла определяются более точные процессы разработки. От стандартов они отличны, прежде всего, большей детальностью и четким описанием связей между отдельными видами деятельности, определением потоков данных в ходе жизненного цикла. Таких моделей достаточно много. Мы рассмотрим лишь несколько моделей [6]. 2.1.1. Самой популярной и применяемой долгое время оставалась каскадная или водопадная (waterfall) модель жизненного цикла, сформулированная впервые (как считается) в работе1 и зафиксированная впоследствии в стандартах министерства обороны США в 70-80-х годах XX века. В этой модели подразумевается последовательное выполнение различных видов деятельности: от выработки требований до сопровождения, с четким разделением границ между этапами, где набор документов, созданный на предыдущей стадии, передается в качестве входных данных для следующей. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла. Предлагаемая в отмеченной ранее статье последовательность шагов разработки показана на рис. 3. Плюсы: все стадии проекта выполняются в строгой последовательности; строгость этапов позволяет планировать сроки завершения всех работ и соответствующие ресурсы (денежные и человеческие); требования остаются неизменными в течение всего цикла. Минусы: сложности при формулировке четких требований и невозможность их изменения; тестирование начинается только с середины развития проекта; до завершения процесса разработки пользователи не могут убедиться, качествен ли разрабатываемый продукт [2]. 2.1.2. V-образная модель (V-model). Эта модель является последователем каскадной модели, так как благодаря ей можно устранить недостатки, которые были ранее. Суть модели заключается в контролировании процессов на всех этапах, чтобы убедиться в возможности перехода на следующий уровень. Уже при написании требований начинается процесс тестирования (рис. 4).    Рисунок 3. Последовательность разработки согласно "классической" каскадной модели Плюсы: строгая этапизация; минимизация рисков и устранение потенциальных проблем за счет того, что тестирование появляется на самых ранних стадиях; усовершенствованный тайм-менеджмент. Минусы: невозможность адаптироваться к измененным требованиям заказчика; длительное время разработки (иногда длится до нескольких лет) приводит к тому, что продукт может быть уже не нужен заказчику, поскольку его потребности меняются; нет действий, направленных на анализ рисков [2]. 2.1.3. Среди разработчиков и исследователей, работающих со сложным ПО, большую популярность имели модели эволюционных или итеративных процессов2, так как они обладают большей гибкостью и способностью работать в меняющемся окружении. Данные модели подразумевают разбивкусоздаваемой системы на набор частей, которые разрабатываются с помощью нескольких последовательных проходов всех работ или их части.  Рисунок 4. V-образная модель (V-model). На первой итерации (многократное повторение) разрабатывается кусок системы, не зависящий от других. При этом большая часть или даже полный цикл работ проходит через него, затем оцениваются результаты и на следующей итерации либо первый кусок изменяется, либо разрабатывается следующий, который может зависеть от первого, или как-либо совмещается доработка первого куска с добавлением новых функций. В результате на каждой итерации можно анализировать промежуточные результаты работ и реакцию на них всех заинтересованных лиц, включая пользователей, и вносить корректирующие изменения на следующих итерациях. Каждая итерация может содержать полный набор видов деятельности — от анализа требований до ввода в эксплуатацию очередной части ПО (рис.5). Каскадная модель с возможностью возвращения на предшествующий шаг при необходимости пересмотреть его результаты, становится итеративной. Итеративный процесс предусматривает, что разные виды деятельности не привязаны намертво к определенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, до тех пор, пока не будет получен нужный результат [3].         Проектирование Анализ требований требований Проектирование Анализ требований Кодирование Проектирование Кодирование Тестирование Кодирование Тестирование Развертывание Тестирование Развертывание Эксплуатация  1-я итерация 3-я итерация 2-я итерация Рисунок 5. Возможный ход работ по итеративной модели Наряду с гибкостью и возможностью быстро отвечать на изменения, итеративные модели привносят дополнительные сложности в управление проектом и отслеживание его хода. При использовании такого подхода значительно сложнее становится адекватно оценить текущее состояние проекта и спланировать долгосрочное развитие событий, а также предвидеть сроки и ресурсы, необходимые для обеспечения определенного качества результата. 2.1.4. Спиральная модель жизненного цикла ПО, предложенная Боэмом (Boehm) [1], предлагает путь разрабатываемого продукта изображается в виде спирали, которая, начавшись на этапе планирования, раскручивается с прохождением каждого следующего шага. Таким образом, на выходе из очередного витка получаем готовый протестированный прототип, который дополняет существующую сборку. Прототип, удовлетворяющий всем требованиям, готов к выпуску (рис. 5). Плюсы: управлению рисками уделяется особое внимание; дополнительные функции могут быть добавлены на поздних этапах; есть возможность гибкого проектирования. Минусы: оценка рисков на каждом этапе является довольно затратной; постоянные отзывы и реакция заказчика может провоцировать все новые и новые итерации, которые могут приводить к временному затягиванию разработки продукта; более применима для больших проектов. На рисунке 5 показано возможное развитие проекта по спиральной модели. Количество рядов, а также расположение и набор видов деятельности в правом нижнем квадранте могут изменяться в зависимости от результатов планирования и анализа рисков, проводимых на предыдущих этапах.  Рисунок 5. Изображение хода работ по спиральной модели согласно Боэму. ЗАКЛЮЧЕНИЕ В данной были рассмотрены разные подходы к определению жизненного цикла ПО. Все они имеют право на существование, так как отражают практику программирования. Тем более, что выделить общие моменты, встречающиеся в рассмотренных моделях. Исследуя разные модели жизненного цикла ПО, можно отметить, как важно и необходимо знать потребности современного мира при составлении программного продукта (изделия). При составлении программы для автоматизации какой либо системы, нужно учитывать то, что современный мир постоянно меняется, а значит и программа должна быть способной к изменению. Также при составлении программы необходимо придерживаться следующих правил: программа должна быть точной; полной по своему содержанию и пригодной для работы в соответствии со своим предназначением; понятной - для того чтобы пользователь любого уровня мог работать с ней без затруднений; редактируемой – при необходимости в любой момент можно внести коррективы. Следует помнить, что хорошее программирование – это не кодирование быстро найденного решения с помощью любой подходящей методики, а тщательно инструментированная инженерная процедура, позволяющая создать полное, точное и легко понимаемое (ясное) программное обеспечение. Литература Боэм Б.У. «Инженерное проектирование программного обеспечения». М.: Радио и связь, 1985. – с. 312 Иванов Ю.В. «Программы и их жизненные циклы». М., 1998. – с. 12 Махмудзаде Р. «Учебник по предмету Информатика для 7-го класса общеобразовательных школ». Баку, 2018. - с.17-19 Райли Д. «Использование языка Модула-2». М.: Мир, 1993. Симонович С.В./ Общая информатика. Новое издание. – СПб.: Питер, 2008. - с. 315 https://drive.google.com/file/d/0B6696ckkWj_zVmRGbUJncUhEU2c/view https://nsportal.ru/npo-spo/informatika-i-vychislitelnaya-tekhnika/library/2014/12/17/konspekt-uchebnogo-zanyatiya 1 IEEE/EIA 12207.0-1996 Industry Implementation of International Standard ISO/IEC 12207:1995 New York, Mar. 1998. 2 IEEE/EIA 12207.1-1997 Industry Implementation of International Standard ISO/IEC 12207:1995 Software Life Cycle Processes – Life Cycle Data New York, Apr. 1998 |