Данное учебно-методическое пособие содержит материал для изучения дисциплины «Управление качеством разработки программного обеспечения». В нем освещены вопросы, связанные с обеспечением и контролем качества программного обеспечения в рамках процесса его разработки. Особое внимание уделено процессу тестирования программных продуктов. В курсе «Управление качеством разработки программного обеспечения» тестирование программного обеспечения рассматривается в аспекте жизненного цикла программного обеспечения. Отображены специфика в подходах к организации, базовым принципам и выполнению тестирования в зависимости от применяемой модели жизненного цикла программного обеспечения и методологии разработки.
В настоящее время существуют различные значения термина “качество”. Фил Кросби (Phil Crosby) в 1979 году дал определение качеству как “соответствие пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор концепции модели оценки зрелости CMM, а также PSP и TSP – People Software Process и Team Software Process, описывает качество как “достижение отличного уровня пригодности к использованию”.
«Модели жизненного цикла программного обеспечения»
Существуют корпоративные стандарты управления качеством. Так, например, компания IBM ввела в оборот “качество, управляемое рыночными потребностями”. Критерий Бэлдриджа (Baldrige) для организационного качества (National Institute of Standards and Technology, “Baldrige National Quality Program”, https://www.quality.nist.gov) использует похожую фразу — “качество, задаваемое потребителем” (“customer-driven quality”), определяя удовлетворение потребителя основным принципом в отношении качества.
Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ISO 9001 как “ степень соответствия присущих характеристик требованиям” как это сформулировано в официальном переводе ИСО 9000-2000 «Системы менеджмента качества. Основные положения и словарь”. Интересно, что и сама “ степень соответствия ” также выступает в роли ограничения проекта, а в приложении к индустрии программного обеспечения представлена практически во всех областях проектной деятельности – от управления требованиями (“атрибуты качества” как категория нефункциональных требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF — Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п.).
В какой-то степени, “приемлемое качество” можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement, давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, приемлемое качество может рассматриваться как количественно выраженный компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах решения задач заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как “cost of quality” – “стоимость качества”). Можно сказать, что такой взгляд может в какой-то степени рассматриваться как расширение определения в ISO 9001 с учетом достигнутого компромисса между заказчиком и исполнителем (поставщиком) в отношении характеристик качества.
Жизненный цикл IT проекта
Рассматриваются вопросы качества программного обеспечения, выходящие за рамки отдельных процессов жизненного цикла. Так например, качество программного обеспечения является постоянным объектом внимания программной инженерии и обсуждается во многих областях знаний в сфере информационных технологий, что вполне обосновано, если учесть поистине катастрофический уровень «проваленных» проектов и неудовлетворенность пользователей программных продуктов, ставшая притчей во языцех для программной индустрии. В общем случае, описывается ряд путей достижения качества программного обеспечения. В частности, эта область знаний касается «статических техник», не требующих выполнения (создания) оцениваемых программных систем, в отличие от «динамических техник», рассмотренных в области знаний “Тестирование”.
Другой важный стандарт – CMMI, предоставляет рекомендации по совершенствованию процесса. Требуется упомянуть и ISO 15504 “Information Technology — Software Process Assessment”, известный как SPICE — Software Process Improvement and Capability dEtermination.
Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”), проверка (verification, категория “Engineering”) и аттестация (validation, категория “Engineering”). При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы, в отличие, например, от стандарта 12207.
Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества программного обеспечения – CMMI или ISO 9001, продолжаются с самого создания этих стандартов. Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и, что сертификация по ISO 9001 помогает в достижении старших уровней зрелости по CMMI.
SQA (Software Quality Assurance) концентрируется на процессах. Роль SQA состоит в том, чтобы обеспечить соответствующее планирование процессов, дальнейшее исполнение процессов на основе заданного плана и проведение необходимых измерений процессов с передачей результатов измерений заинтересованным сторонам (организационными структурам и лицам).
Тестирование, в общем случае, представляет собой деятельность, выполняемую для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.
Техники управления качеством разделены на статические (без выполнения кода) и динамические (с выполнением кода). Тестирование входит в состав динамических техник.
Тестирование программных систем состоит из динамической верификации поведения программ на конечном (ограниченном) наборе тестов, выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия требуемому поведению системы.
Как уже отмечалось ранее, тестирование программного обеспечения тесно связано с программированием (ГОСТ 12207). Более того, модульное (unit-) и интеграционное тестирование все чаще рассматривают как неотъемлемый элемент деятельности по конструированию программного обеспечения в SWEBOK.
2. Основные определения
Программа – последовательность формализованных инструкций, предназначенная для исполнения устройством управления вычислительной машины. Инструкции программы записываются при помощи машинного кода или специальных языков программирования.
Программное обеспечение (ПО) — это совокупность всей информации, данных и программ, которые обрабатываются компьютерными системами. На компьютерном жаргоне – часто используется слово «софт» от английского «software»
Системное ПО (system software) — это набор программ, которые управляют компонентами вычислительной системы (ОС, драйвера устройств и т.п.).
Инструментальное ПО (programming software) — программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ (среда разработки, компиляторы, СУБД, текстовые редакторы и т.п.).
Прикладное (специальное) ПО (application software) – программы, предназначенные для выполнения определенных пользовательских задач и расчитанные на непосредственное взаимодействие с пользователем (офисные приложения, бухгалтерские программы, ERP, электронная почта и т.п.).
Программный продукт (ПП) — это программное обеспечение, предназначенное для удовлетворения потребностей пользователей широкого распространения и продажи (записанное на носителях данных; снабженное программной документацией).
Коробочный программный продукт — это программный продукт, предназначенный для неопределенного круга покупателей и поставляемое на условиях «как есть», со стандартными для всех покупателей функциями.
Заказной программный продукт – программный продукт, появление которого обусловлено требованием конкретного заказчика и продажа которого может, по требованию заказчика, сопровождаться проектной доработкой или разработкой функций, дополняющих стандартные (базовые) возможности.
Процесс разработки программного продукта – это структура, согласно которой построена разработка программного обеспечения.
Жизненный цикл программного обеспечения (ПО) — это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации (ISO 12207).
Модель жизненного цикла ПП — описание набора фаз (этапов, стадий) проекта по созданию ПО, в которых выполняются отдельные процессы, разбитые на операции и задачи.
Проект – это уникальный процесс, в ходе выполнения которого получают уникальный продукт. Проект представляет собой уникальную (в отличие от операций) деятельность, имеющую начало и конец во времени, направленную на достижение определённого результата (цели ), создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.
Требование – задокументированная уникальная потребность (необходимость) того, что должен делать конкретный продукт или каким он должен быть.
Отладка (Debugging) – деятельность, направленная на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Результаты тестирования являются исходными данными для отладки.
Контроль (Verification) – попытка найти ошибки, выполняя программу в тестовой, или смоделированной, среде.
Испытание (Validation) – попытка найти ошибки, выполняя программу в заданной реальной среде.
3. Процесс разработки программного обеспечения.
Промышленное применение компьютеров и растущий спрос на программы поставили актуальные задачи существенного повышения производительности разработки программного обеспечения, разработки индустриальных методов планирования и проектирования программ, переноса организационно-технических, технико-экономических и социально-психологических приемов, закономерностей и методов из сферы материального производства в сферу применения информационных технологий.
Комплексный подход к процессам разработки, эксплуатации и сопровождения программного обеспечения выдвинул ряд насущных проблем, решение которых исключит «узкие места» в процессе разработки программного обеспечения, уменьшит сроки завершения работ.
Поскольку компьютерная программа практически любого типа становится изделием — продуктом, подход к ее изготовлению во многом должен быть аналогичен подходу к производству промышленной продукции.
Процесс разработки программного продукта – это «организационная структура», согласно которой построена разработка программного обеспечения. Эта структура определяется моделью жизненного цикла ПП.
Основные этапы процесса разработки программного обеспечения:
· Сбор и анализ требований
Жизненный цикл программного обеспечения.
Концепция проекта в области информационных технологий описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ), представляя его как последовательность стадий и выполняемых процессов. Для каждого этапа жизненного цикла определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Жизненный цикл программного обеспечения — это непрерывный процесс, который начинается с момента принятия решения о необходимости создания программного обеспечения и заканчивается в момент его полного изъятия из эксплуатации.
Существует несколько подходов при определении фаз и работ жизненного цикла программного обеспечения, но все они содержат общие основополагающие этапы:
· постановка задачи = сбор и анализ требований
· проектирование решения = разработка архитектуры
· реализация = кодирование, тестирование и документирование
Определение требований включает описание общего контекста задачи, ожидаемых функций системы и ее ограничений. На данном этапе основную роль играет аналитик, который обладает навыками описания требований в различной форме.
В процессе согласования требований со стороны будущей команды разработчиков в обсуждении участвует менеджер проекта, а также, возможно, архитектор, как действующее лицо, способное оценить технические возможности реализации идеи заказчика.
Принципиально то, что на данном этапе самого проекта еще нет и можно говорить только о предпроектных работах, в которых участвуют представители будущей команды разработки или специалисты, занимающиеся предпроектной подготовкой. Определение требований в фактических проектах не может ограничиваться лишь предпроектными работами. Для большинства прикладных задач требования поступают в течение всего развития проекта.
Постановка задачи является одним из наиболее важных этапов. Она выполняет функции контракта между пользователем и исполнителем. Как и юридически плохо составленный контракт, плохая постановка задачи бесполезна.
При хорошей постановке задачи как пользователь, так и команда разработки ясно и недвусмысленно представляют задачу, которую необходимо выполнить, т.е. в этом случае учитываются интересы как пользователя, так и исполнителей. Пользователь может планировать использование еще не созданного программного обеспечения, опираясь на знание того, что оно может. Хорошая постановка задачи служит основой для формирования ее решения.
Постановка задачи (спецификация программы), по существу, означает точное, полное и понятное описание того, что происходит при выполнении конкретной программы. Пользователь обычно смотрит на компьютер, как на черный ящик: для него неважно, как работает компьютер, а важно, что может компьютер из того, что интересует пользователя. При этом основное внимание фокусируется на взаимодействии человека с машиной.
Характеристики Хорошей Постановки Задачи:
Точность, т.е. исключение любой неоднозначности. Не должно возникать вопросов относительно того, каким будет вывод программы при каждом конкретном вводе.
Полнота, т.е. рассмотрение всех вариантов для заданного ввода, включая ошибочный или непредусмотренный ввод, и определение соответствующего вывода.
Ясность, т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи — это единственный контракт между ними.
Часто требование точности, полноты и ясности находятся в противоречии. Так, многие юридические документы трудно понять, потому что они написаны на формальном языке, который позволяет предельно точно сформулировать те или иные положения, исключая любые самые незначительные разночтения.
Например, некоторые вопросы в экзаменационных билетах иногда сформулированы настолько точно, что студент тратит больше времени на то, чтобы понять вопрос, чем на то чтобы на него ответить. Более того, студент вообще может не уловить основной смысл вопроса из-за большого количества деталей. Наилучшая постановка задачи та, при которой достигается баланс всех трех требований.
Разработка проектных решений, отвечающих на вопрос о том, как должна быть реализована система, чтобы она могла удовлетворять специфицированным требованиям, выполняется на этапе проектирования. Поскольку сложность системы в целом может быть очень высока, главной задачей этого этапа является последовательная декомпозиция системы до уровня очевидно реализуемых модулей или процедур. Наиболее активная роль на данном этапе — архитектор, для которого декомпозиция системы есть главная задача в проекте.
На следующем этапе – этапе реализации — кодируется каждый из модулей, выявленных при декомпозиции, программируется на наиболее подходящем для данного приложения языке. Основные действующие лица этапа — руководитель команды и разработчики. Традиционно именно данный этап считали основой проекта в целом, что, не отражает современного взгляда на проект.
Интеграция построенных и используемых модулей в систему является одним из видов работ этапа реализации. Фаза разработки заканчивается этапом тестирования, главными лицами которой являются инженеры по тестированию и этапом документирования, главными лицами которого являются технические писатели.
Фаза эксплуатации и сопровождения включает в себя всю деятельность по обеспечению нормального функционирования программных систем, в том числе фиксирование в скрытых во время исполнения программ ошибок, поиск их причин и исправление, повышение эксплуатационных характеристик системы, адаптацию системы к окружающей среде, а также, при необходимости, и более существенные работы по совершенствованию системы. Все это дает право говорить об эволюции системы.
В связи с этим фаза эксплуатации и сопровождения разбивается на два этапа: собственно сопровождение и развитие. В ряде случаев на данную фазу приходится большая часть средств, расходуемых в процессе жизненного цикла программного обеспечения.
Источник: poisk-ru.ru
Жизненный цикл программных систем
В общем случае программная система помимо собственно программ содержит еще и аппаратное обеспечение, а также обычно рассматривается в окружении других программно-аппаратных систем.
Под жизненным циклом программной системы обычно понимают весь период времени существования программной системы, начинающийся с момента выработки первоначальной концепции системы и кончающийся тогда, когда система морально устаревает. Понятие «жизненного цикла»используется, когда предполагается, что программная система будет иметь достаточно большой срок действия, в отличие от экспериментального программирования, при котором программы прогоняются несколько раз и больше не используются.
Жизненный цикл традиционно моделируется в виде некоторого числа последовательных этапов (или стадий, фаз). В настоящее время не выработано общепринятого разбиения жизненного цикла программной системы на этапы. Иногда этап выделяется как отдельный пункт, иногда — входит в качестве составной части в более крупный этап.
Могут варьироваться действия, производимые на том или ином этапе. Нет единообразия и в названиях этих этапов. Поэтому попытаемся вначале описать некоторый обобщенный жизненный цикл программной системы, а затем продемонстрируем несколько примеров различных жизненных циклов с указанием аналогий из этого обобщенного цикла.
Этапы жизненного цикла ПО
Жизненный цикл программного обеспечения — период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: -1- возникновение и исследование идеи; -2- анализ требований и проектирование; -3- программирование; -4- тестирование и отладка; -5- ввод программы в действие; -6- эксплуатация и сопровождение; -7- завершение эксплуатации.
Следует обратить внимание, что разбиение жизненного цикла на этапы иногда способствует затушевыванию некоторых важных аспектов создания программного обеспечения; особенно это проявляется по отношению к такому необходимому процессу, как итерационная реализация различных этапов жизненного цикла с целью исправления ошибок, изменения решений, которые оказались неправильными, или учета изменений в общих требованиях, предъявляемых к системе.
Примеры описания жизненного цикла
Рассмотрим несколько описаний жизненного цикла программного обеспечения, которые послужат своеобразным комментарием этапам обобщенного жизненного цикла.
В отечественных нормативных документах (например, ГОСТ ЕСПД) принято следующее разграничение на этапы, которое приводится с указанием аналогий из списка, данного в начале раздела:
- разработка технического задания (этапы 1 и 2);
- технический проект (третий этап до 3.2.1 включительно);
- рабочий проект (3.2.2, 4.2.1 и, частично, 4.2, 4.3);
- экспериментальное внедрение (4.2 и 4.3);
- сдача в промышленную эксплуатацию (этап 5);
- промышленная эксплуатация (этап 6).
Подобное описание имеет своим прообразом технологию разработки аппаратных средств и поэтому не вполне учитывает все отличительные особенности проектирования программ. Более подходящим выглядит описание жизненного цикла программного обеспечения, состоящее из 12 этапов, которые очень близки этапам обобщенного жизненного цикла (см. рис. 1.1). В скобках после имени фазы указывается аналог из обобщенного цикла. Практически все этапы заканчиваются проверкой результатов, полученных на соответствующем этапе. 
Рис. 1.1 Пример жизненного цикла программных систем
- Начало проекта и планирование (этап 1). Определяются необходимые действия, планы и организация управления проектом. Определяются меры по обеспечению непрерывного выполнения фаз жизненного цикла.
- Анализ целевых требований (2.1). Определяются, без учета средств реализации, общие характеристики системы, которым она должна удовлетворять. Устанавливается, что и как должна делать система.
- Анализ системных требований (2.2). Описывается, как должны удовлетворятся запросы пользователя, в терминах конкретных функциональных понятий описываются действия предполагаемой системы, хранимые данные, используемый интерфейс — все это без учета физической реализации. Проверяется пригодность этих конкретных понятий.
- Проектирование системы (3.1). Устанавливается структура системы или, иначе говоря, ее архитектура в терминах основных компонентов этой системы и их предполагаемой реализации (аппаратной, программной, с помощью окружения и т.д.). Устанавливаются требования для каждого компонента, а также стратегию тестирования и интеграции.
- Предварительное проектирование программного обеспечения (3.2.1). Определение конкретных программных компонент, которые будут разрабатываться и внедряться в конечную систему. Проверка этого множества компонент на непротиворечивость общим требованиям к программному обеспечению. Определение функциональных, эксплуатационных и тестовых требований к каждому конкретному компоненту.
- Детальное проектирование программного обеспечения (3.2.2). В терминах используемых программных конструкций производится описание того, как каждый конкретный компонент будет разрабатываться. Описываются режимы использования каждого компонента в системе.
- Кодирование и тестирование программного обеспечения (4.1.1 и 4.1.2). Создание, тестирование отдельных модулей, документирование и приемка программных компонентов, которые составляют программную систему.
- Интеграция программного обеспечения (частично 4.2). Тестирование работоспособности и функциональной законченности программных частей системы в предсказуемом окружении (аппаратуре и окружающей среде).
- Интеграция системы (4.3). Тестирование работоспособности и функциональной законченности частей общей системы в целом.
- Приемка и поставка системы (5). Производится приемка системы заказчиком, и поставка ему системы.
- Эксплуатация и сопровождение системы (6). Выпуск последующих вариантов или версий системы, необходимость в которых возникает из-за устранений дефектов, отработки измененных требований и т.д.
- Завершение проекта (7). Формирование посториорной модели проектных действий с анализом достоинств, недостатков и т.д., и использование их в качестве основания для улучшения процесса разработки.
В качестве следующего примера рассмотрим неполный жизненный цикл программного обеспечения, без этапов эксплуатации и сопровождения (см. рис. 1.2). В этом варианте не фиксируется последовательность фаз или этапов, а предлагается перечень действий, которые должны быть выполнены на протяжении жизненного цикла программного обеспечения. Эти действия могут быть разбиты или, наоборот, сгруппированы в различные этапы, в зависимости от конкретных условий. Можно выделить следующие этапы жизненного цикла программных систем (в скобках, как и ранее, — аналоги из модели обобщенного цикла):
- этап планирования, который определяет и координирует действия по разработке программной системы (этап 1);
- этап разработки, на котором создается программная система:
- постановку задачи (этап 2),
- проектирование (3),
- кодирование (4.1.1),
- получение исполняемого кода (4.1.1, 4.3);
Рис. 1.2 Вариант упрощенного жизненного цикла программной системы. Отсутствие интегрированного этапа в обобщенном жизненном цикле не означает, что проверка производится только там, где это явно указано в названии этапа (например 4.2.1 и 4.2). Каждый этап может считаться завершенным только тогда, когда результаты, полученные на данном этапе, были признаны удовлетворительными, а для этого необходимо производить проверку результатов на каждом этапе. В обобщенном жизненном цикле некоторые проверки были вынесены отдельными пунктами для демонстрации повышенных объемов, сложности и важности этих проверок. Последовательность этапов жизненного цикла для разных программных систем определяется такими характеристиками как функциональные возможности, сложность, размер, устойчивость, использование ранее полученных результатов, разрабатываемая стратегия и аппаратное обеспечение. На рис. 1.3. показана последовательность этапов разработки программного обеспечения для отдельных компонентов единой программной системы с различными жизненными циклами. 
Рис. 1.3 Последовательность этапов разработки компонент программного обеспечения Для компонента W из множества системных требований к единому продукту формируется подмножество требований, относящихся к данному компоненту, используются эти требования при формировании проекта программного компонента, реализовывают этот проект в исходном коде и тогда интегрирует компонент с аппаратурой. Компонент X показывает использование ранее разработанного программного обеспечения. Компонент Y показывает использование простой отдельной функции, которая может быть закодирована прямо на основе требований к программному обеспечению. Компонент Z показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к программному обеспечению и уменьшение технических рисков и рисков разработки при создании конечного продукта. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в окружение, типичное для конкретного использования системы при разработке. Результатом преобразований является уточненные данные, которые используются для создания конечного программного продукта. Практически все этапы жизненного цикла объединяются с верификацией.Источник: studfile.net
Жизненный цикл разработки программного обеспечения. Модели жизненного цикла разработки программного обеспечения
Таршхоева, Ж. Т. Жизненный цикл разработки программного обеспечения. Модели жизненного цикла разработки программного обеспечения / Ж. Т. Таршхоева. — Текст : непосредственный // Молодой ученый. — 2021. — № 5 (347). — С. 16-18. — URL: https://moluch.ru/archive/347/78099/ (дата обращения: 03.07.2023).
Созданию программного продукта обычно рассматривается как «жизненный цикл разработки программного обеспечения» или (software development life cycle (SDLC), также известный как «жизненный цикл разработки приложений» или просто «процесс разработки программного обеспечения». Поскольку построение программного обеспечения по своей сути является сложным и требует от команды разработчиков много навыков, существует множество различных SDLC для решения проектов различного масштаба и сложности. [2]
Ключевые слова: жизненный цикл разработки программного обеспечения, SDLC, модель.
По сути, жизненный цикл разработки программного обеспечения — это дорожная карта для работы над цифровым решением. Другими словами, SDLC — это схема, предназначенная для команды по созданию, обслуживанию и исправлению цифровых продуктов. Этапы жизненного цикла разработки программного обеспечения зависят от размера проекта и его целей. Каждый шаг также предоставляет общую карту того, как он должен быть завершен. В большинстве случаев каждая команда разработчиков создает свой собственный цикл разработки программного обеспечения или принимает одну из моделей, которые мы рассмотрим далее. [4]
Хотя циклы SDLC предоставляют обзор задач для проекта, они не являются готовым к использованию руководством. SDLC не высечен на камне: существуют различные модели и примеры жизненного цикла разработки программного обеспечения. Последние зависят от сложности проекта, как и многие методологии жизненного цикла разработки программного обеспечения. Тем не менее, основная идея жизненного цикла разработки программного обеспечения остается — это последовательность задач, направленных на создание цифрового решения. [1]
Ключевой причиной принятия SDLC является контроль над процессом разработки. Рабочий план, управление конфликтами между участниками и управление бюджетом — это еще одно большое преимущество жизненного цикла разработки программного обеспечения.
Таким образом, жизненный цикл разработки программного обеспечения позволяет:
– Обладание всеобъемлющим контролем над процессом разработки программного обеспечения
– Повышение эффективности управления ресурсами и затрат
– Дает командам четкий план действий
– Улучшает сотрудничество между участниками
Важно помнить, что все преимущества жизненного цикла разработки программного обеспечения не будут работать для команд самостоятельно. Если менеджерам проекта не хватает опыта или некоторые участники отказываются следовать этому процессу, цикл распадается, что влияет на качество конечного продукта. [1]
Модели Жизненного Цикла Разработки Программного Обеспечения
Жизненный цикл можно представить в виде моделей. Существует множество различных моделей SDLC, которые помогают в различных типах проектов разработки программного обеспечения, даже в тех случаях, когда клиент не имеет четкого представления о том, что ему нужно. [3]
Каскадная модель
Каскадная модель — модель процесса разработки программного обеспечения, жизненный цикл которой выглядит как поток, последовательно проходящий фазы анализа требований, проектирования. реализации, тестирования, интеграции и поддержки. В каскадной моделиSDLC все шаги должны быть завершены до начала разработки. Одним из основных предварительных условий каскадной модели является получение одобрения на каждом этапе, прежде чем команда сможет перейти к следующему. Этот подход может быть эффективным в снижении рисков в жизненном цикле разработки программного обеспечения. Здесь каскадная модель использует спецификацию бизнес-требований (BRS), которая помогает командам оценивать каждый шаг. В то время как некоторые компании — разработчики программного обеспечения все еще предлагают эту модель сотрудничества, этот тип жизненного цикла разработки программного обеспечения она менее популярна, чем другие, более гибкие модели в нашем списке. [6]
Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования. V-образная модель похожа на каскадную модель и может рассматриваться как его продолжение. Поэтому методологической основой V-образной модели является гарантия выполнения задач на одном этапе перед переходом к следующему. Эта модель также делит процесс разработки на различные задачи. Еще одной особенностью V-образной модели SDLC является постоянное тестирование, что выделяет ее среди некоторых других моделей жизненного цикла разработки. [5]
Итеративная модель имеет много циклов разработки программного обеспечения, которые сегментированы на более мелкие циклы. Кроме того, эта модель обеспечивает надежный старт для программного продукта с помощью опробования. Среди конкретных примеров моделей жизненного цикла разработки программного обеспечения здесь рациональный унифицированный процесс позволяет избежать ограничений некоторых других моделей жизненного цикла разработки программного обеспечения. Поскольку метод разработки динамических систем, используемый в этой модели, делит цикл на несколько более мелких, что позволяет осуществлять микроменеджмент, итеративная модель SDLC это один из самых надежных подходов к процессу разработки. [3]
Спиральная модель является универсальной моделью жизненного цикла разработки программного обеспечения. Подобно итерационной модели, она подчеркивает значение меньших циклов в рамках больших циклов SDLC. Как же так? спиральная модель SDLC тесно объединяет все ключевые этапы процесса разработки.
Эта модель жизненного цикла разработки программного обеспечения исключает сложности любого традиционного жизненного цикла разработки программного обеспечения. Жизненный цикл — на каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки — анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов.
Модель Большого Взрыва
Модель Большого Взрыва не имеет никаких руководящих принципов вообще. Эта модель жизненного цикла разработки программного обеспечения была задумана для того, чтобы помочь ориентироваться в проектах, где клиент не знает, как будет выглядеть конечный программный продукт. Более конкретно, модель Большого Взрыва строится для проектов, если исходная информация настолько расплывчата, что сама модель не включает в себя конкретный процесс, выходящий за рамки ее концепций или какого-либо планирования: команда должна понять проект по ходу его реализации. Где бы его применить? Модель Большого Взрыва SDLC подходит для небольших усилий по разработке, небольших команд разработчиков, а также может быть пригоден для краткосрочных экспериментов. [2]
Гибкая методология разработки — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Гибкие подходы к разработке гибкой модели помогают обеспечить оптимизированный процесс разработки программного обеспечения, позволяющий быстро вносить коррективы. Гибкая модель SDLC включает в себя подходы XP и Scrum, которые охватывают циклы SDLC с двухнедельными спринтами разработки. Команда показывает результаты клиенту после каждого спринта, так как клиент также оставляет комментарии о том, что было создано за две недели. [6]
Одна из самых популярных моделей жизненного цикла разработки программного обеспечения Agile нацелена на более частые релизы и видимые результаты. В Agile программный продукт появляется постепенно, и клиент дает обратную связь на каждом этапе пути. Модели также помогают собирать обратную связь и измерять различные аспекты процесса разработки [1].
- Б. У. Боэм «Инженерное проектирование программного обеспечения». М.: Радио и связь. 2015.
- Ю. В. Иванов «Программы и их жизненные циклы». 2008.
- Гагарина Л. Г. «Основы технологии и разработки программных продуктов».
- Соммервилл И. «Инженерия программного обеспечения».
- Буч Г. Объектно-ориентированное проектирование с примерами применения. — М.: Конкорд, 2010.
- Электронный ресурс: https://qaevolution.ru/
Основные термины (генерируются автоматически): SDLC, программное обеспечение, жизненный цикл разработки, модель, каскадная модель, процесс разработки, гибкая модель, жизненный цикл, итеративная модель, программный продукт.
Источник: moluch.ru