13 программы малого жизненного цикла это программы

Нарыжная, Н. Ю. Сравнительный анализ моделей жизненного цикла программного обеспечения / Н. Ю. Нарыжная, Л. Г. Шарифова. — Текст : непосредственный // Молодой ученый. — 2020. — № 28 (318). — С. 28-32. — URL: https://moluch.ru/archive/318/72498/ (дата обращения: 12.07.2023).

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

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

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

«Модели жизненного цикла программного обеспечения»

Жизненный цикл информационной системы включает в себя такие стадии, как планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию [1].

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

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

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

Рис. 1. Каскадная модель жизненного цикла ПО

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

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

Тестировщик с нуля / Урок 7. Модели разработки ПО. Водопадная, итерационная и V-модель

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

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

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

Рис. 2. Процесс прототипирования

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

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

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

Спиральная модель жизненного цикла программного обеспечения.

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

К недостаткам данной модели следует отнести:

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

Подробная схема данной модели представлена на рис. 3.

Рис. 3. Спиральная модель жизненного цикла ПО

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

Методика выбора на основе анализа критериев.

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

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

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

Характеристика проекта

Модель

Каскадная

Прототипная

Спиральная

Новизна разработки и обеспеченность ресурсами

Источник: moluch.ru

Структура жизненного цикла. Большой жизненный цикл.

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

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

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

Большой жизненный цикл программы характеризуется:

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

Структура жизненного цикла. Малый жизненный цикл.

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

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

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

Малый жизненный цикл программы характеризуется:

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

Классический жизненный цикл пи. Водопадная модель. Классический жизненный цикл

Старейшей парадигмой процесса разработки программного обеспечения является классический жизнен­ный цикл (автор Уинстон Ройс, 1970).

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

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

1. планирование разработки;
2. определение требований к системе; 2.1 выработка требований;
3. анализ требований;
4. проектирование системы; 3.1 проектирование архитектуры системы;
5. детальное проектирование компонент системы, в т.ч. для программного обеспечения;
6. реализация и тестирование системы;
7. создание отдельных компонент системы, в т.ч. для программного обеспечения; 4.1.1 создание отдельных программных модулей; 4.1.2 тестирование отдельных программных модулей;
8. тестирование компонент системы, в т.ч. программного обеспечения как единого компонента системы;
9. интегрирование отдельных компонент в систему;
10. выпуск системы;
11. эксплуатация системы; 7 завершение разработки.

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

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

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

Проектирование состоит в создании представлений:

• архитектуры ПО;
• модульной структуры ПО;
• алгоритмической структуры ПО;
• структуры данных;
• входного и выходного интерфейса (входных и выходных форм данных).

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

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

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

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

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

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

Как и любая инженерная схема, классический жизненный цикл имеет достоин­ства и недостатки.

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

Недостатки классического жизненного цикла:

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

Источник: studfile.net

IX Международная студенческая научная конференция Студенческий научный форум — 2017

СТАНДАРТЫ И МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Алиева А.А. 1
1 Дагестанский Государственный Университет
Работа в формате PDF

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF

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

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

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

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

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

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

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

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

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

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

Рисунок 1. Разработка национальных стандартов в России. [3]

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

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

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

Среди наиболее известных стандартов можно выделить следующие:

• ГОСТ 34.601-90 — распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 — стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.
• CustomDevelopmentMethod(методика Oracle) по разработке прикладных информационных систем — технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.
• RationalUnifiedProcess(RUP)предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP — это создание и сопровождение моделей на базе UML.
• MicrosoftSolutionFramework(MSF)сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес- приложений.
• ExtremeProgramming(XP).Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов. [3, с. 10]

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

Рисунок 2. Стандарты, описывающие структуру жизненного цикла ПО.

Для таких формализованных подходов, как спиральная и каскадная (водопадная) модель, существует определённый путь в виде последовательных этапов жизненного цикла (ЖЦ), по котором осуществляется прохождение программного продукта:

— формирование проектных спецификаций;

— введение в эксплуатацию и сопровождение;

— выведение из эксплуатации.

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

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

В основе сущности предварительного алгоритмического проектирования лежит наличие «монополитности» документации и персонального кода, отсутствие гибкости. Что в совокупности ведёт к отсутствию у разработчиков оперативной реакции на изменяющиеся требования заказчиков.

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

К примеру для стандарта UML 2.0 (Unified Modeling Language) существуют 14 типов диаграмм, предназначенных для применения. Однако на практике использованию подлежат в два раза меньше типов диаграмм.

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

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

Применения моделей полного жизненного цикла

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

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

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

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

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

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

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

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

Гибкие методики разработки ПО

Гибкие методики, такие как Crystal, Scrum, XP, предусматривают быструю поставку начальной версии работающей программы заказчику для тестирования, игнорируя на начальном этапе многие проектные требования и подразумевая последующее расширение функциональности программы. Основная цель – обеспечение непрерывности развития проекта с возможностью оперативного реагирования на изменения требований бизнеса. Тяжеловесные модели полного ЖЦ слишком неуклюжи, чтобы предусмотреть полный пересмотр заказчиком своего «видения» на этапе завершения проекта. Гибкие методики предлагают коллективам разработчиков ПО сконцентрироваться на качестве выпускаемого продукта в ущерб документации и прочим артефактам проектно-процессной деятельности.

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

В связи с этим в практической деятельности целесообразно оперировать понятиями ЖЦ отдельной сборочной версии или итерации, что позволит сконцентрировать видение заказчиков и разработчиков на функциональном, более узком аспекте деятельности ИТ-коллективов, связанных в первую очередь с разработкой ПО. Таким образом, в гибкой разработке этапы проектирования, программирования и сопровождения непрерывны, неотделимы друг от друга и входят в состав отдельной короткой итерации разработки. [5, с. 150]

Список использованной литературы:

1. Добрынин А. С., Р. С. Койнов, С. М. Кулаков. Модель неполного жизненного цикла программного обеспечения // Вестник Астраханского государственного технического университета. Серия: Управление, вычислительная техника и информатика. № 2 / 2015. С 65-70

2. Добрынин А. С. Формирование расписаний в задачах временного планирования / А. С. Добрынин, С. М. Кулаков, Р. С. Койнов, А. В. Грачёв // Вестн. Астрахан. гос. техн. ун-та. Сер.: Управление, вычисли- тельная техника и информатика. 2014. № 4. С. 103–111.

3. Заговор О. В. Учет особенностей ИТ-проектов при определении их жизненного цикла // Восточно-Европейский журнал передовых технологий. 2011г. – С 8-14.

4. Зимин В. В. Основы управления жизненным циклом сервиса систем информатики и автоматизации (лучшие практики ITIL): учеб. пособие / В. В. Зимин, А. А. Ивушкин, С. М. Кулаков, К. А. Ивушкин. Кемерово: Кузбассвузиздат, 2013. 96-100 с

5. Чумакова Т.Я., Цыганенко С.М. Стандартизация в сфере информационных технологий // Математичні машини і системи. – 2009. – № 2. – С. 145 – 150.

Источник: scienceforum.ru