Следует начать с определения,
Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.Модели Жизненного цикла программного обеспечения
Жизненный цикл можно представить в виде моделей. В настоящее время наиболее распространенными являются:
каскадная , инкрементная (поэтапная модель с промежуточным контролем ) и спиральная модели жизненного цикла.Каскадная модель
Каскадная модель (англ . waterfall model ) — модель процесса разработки программного обеспечения, жизненный цикл которой выглядит как поток, последовательно проходящий фазы анализа требований, проектирования. реализации, тестирования, интеграции и поддержки.
Процесс разработки реализуется с помощью упорядоченной последовательности независимых шагов. Модель предусматривает, что каждый последующий шаг начинается после полного завершения выполнения предыдущего шага. На всех шагах модели выполняются вспомогательные и организационные процессы и работы, включающие управление проектом, оценку и управление качеством, верификацию и аттестацию, менеджмент конфигурации, разработку документации. В результате завершения шагов формируются промежуточные продукты, которые не могут изменяться на последующих шагах.
Жизненный цикл традиционно разделяют на следующие основные
этапы :- Анализ требований,
- Проектирование,
- Кодирование (программирование),
- Тестирование и отладка,
- Эксплуатация и сопровождение.
Достоинства модели:
- стабильность требований в течение всего жизненного цикла разработки;
- на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
- определенность и понятность шагов модели и простота её применения;
- выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие ресурсы (денежные. материальные и людские).
Недостатки модели:
- сложность чёткого формулирования требований и невозможность их динамического изменения на протяжении пока идет полный жизненный цикл;
- низкая гибкость в управлении проектом;
- последовательность линейной структуры процесса разработки, в результате возврат к предыдущим шагам для решения возникающих проблем приводит к увеличению затрат и нарушению графика работ;
- непригодность промежуточного продукта для использования;
- невозможность гибкого моделирования уникальных систем;
- позднее обнаружение проблем, связанных со сборкой, в связи с одновременной интеграцией всех результатов в конце разработки;
- недостаточное участие пользователя в создании системы — в самом начале (при разработке требований) и в конце (во время приёмочных испытаний);
- пользователи не могут убедиться в качестве разрабатываемого продукта до окончания всего процесса разработки. Они не имеют возможности оценить качество, т.к.нельзя увидеть готовый продукт разработки;
- у пользователя нет возможности постепенно привыкнуть к системе. Процесс обучения происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию;
- каждая фаза является предпосылкой для выполнения последующих действий, что превращает такой метод в рискованный выбор для систем, не имеющих аналогов, т.к. он не поддается гибкому моделированию.
Реализовать Каскадную модель жизненного цикла затруднительно ввиду сложности разработки ПС без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем.
Область применения Каскадной модели
Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:
- при разработке проектов с четкими, неизменяемыми в течение жизненного цикла требованиями, понятными реализацией и техническими методиками;
- при разработке проекта, ориентированного на построение системы или продукта такого же типа, как уже разрабатывались разработчиками ранее;
- при разработке проекта, связанного с созданием и выпуском новой версии уже существующего продукта или системы;
- при разработке проекта, связанного с переносом уже существующего продукта или системы на новую платформу;
- при выполнении больших проектов, в которых задействовано несколько больших команд разработчиков.
Инкрементная модель
(поэтапная модель с промежуточным контролем)
Инкрементная модель (англ . increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.
Разработка программного обеспечения ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах, время жизни каждого из этапов растягивается на весь период разработки.
В начале работы над проектом определяются все основные требования к системе, подразделяются на более и менее важные. После чего выполняется разработка системы по принципу приращений, так, чтобы разработчик мог использовать данные, полученные в ходе разработки ПО. Каждый инкремент должен добавлять системе определенную функциональность. При этом выпуск начинают с компонентов с наивысшим приоритетом. Когда части системы определены, берут первую часть и начинают её детализировать, используя для этого наиболее подходящий процесс. В то же время можно уточнять требования и для других частей, которые в текущей совокупности требований данной работы были заморожены. Если есть необходимость, можно вернуться позже к этой части. Если часть готова, она поставляется клиенту, который может использовать её в работе. Это позволит клиенту уточнить требования для следующих компонентов. Затем занимаются разработкой следующей части системы. Ключевые этапы этого процесса — простая реализация подмножества требований к программе и совершенствование модели в серии последовательных релизов до тех пор, пока не будет реализовано ПО во всей полноте.
Жизненный цикл данной модели характерен при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат. Разработка версиями ведется в силу разного рода причин:
- отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;
- отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;
- требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у её пользователей неприятие и только “затормозить” процесс перехода на новые технологии. Образно говоря, они могут просто “не переварить большой кусок, поэтому его надо измельчить и давать по частям”.
Достоинства и недостатки этой модели (стратегии) такие же, как и у каскадной (классической модели жизненного цикла). Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора.
Достоинства:
- затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с каскадной моделью;
- легче получить отзывы от клиента о проделанной работе — клиенты могут озвучить свои комментарии в отношении готовых частей и могут видеть, что уже сделано. Т.к. первые части системы являются прототипом системы в целом.
- у клиента есть возможность быстро получить и освоить программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с каскадной моделью.
Недостатки модели:
- менеджеры должны постоянно измерять прогресс процесса. в случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии;
- структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям.
Схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к ПО. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ПО зафиксированы в виде технического задания на всё время её создания. Таким образом, пользователи зачастую получаю ПП, не удовлетворяющий их реальным потребностям.
Спиральная модель
Спиральная модель: Жизненный цикл — на каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки — анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов.
Данная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипировнаие с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.
На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.
Жизненный цикл на каждом витке спирали — могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели . Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Достоинства модели:
- позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;
- допускает изменение требований при разработке программного обеспечения, что характерно для большинства разработок, в том числе и типовых;
- в модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества каскадной модели, и в то же время разрешены итерации по всем фазам этой же модели;
- позволяет получить более надежную и устойчивую систему. По мере развития программного обеспечения ошибки и слабые места обнаруживаются и исправляются на каждой итерации;
- эта модель разрешает пользователям активно принимать участие при планировании, анализе рисков, разработке, а также при выполнении оценочных действий;
- уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта;
- обратная связь по направлению от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества.
Недостатки модели:
- если проект имеет низкую степень риска или небольшие размеры, модель может оказаться дорогостоящей. Оценка рисков после прохождения каждой спирали связана с большими затратами;
- Жизненный цикл модели имеет усложненную структуру, поэтому может быть затруднено её применение разработчиками, менеджерами и заказчиками;
- спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл, что отдаляет окончание работы над проектом;
- большое количество промежуточных циклов может привести к необходимости в обработке дополнительной документации;
- использование модели может оказаться дорогостоящим и даже недопустимым по средствам, т.к. время. затраченное на планирование, повторное определение целей, выполнение анализа рисков и прототипирование, может быть чрезмерным;
- могут возникнуть затруднения при определении целей и стадий, указывающих на готовность продолжать процесс разработки на следующей и
Основная проблема спирального цикла — определение момента перехода на следующий этап. Для её решения вводятся временные ограничения на каждый из этапов жизненного цикла и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.
Область применения спиральной модели
Применение спиральной модели целесообразно в следующих случаях:
- при разработке проектов, использующих новые технологии;
- при разработке новой серии продуктов или систем;
- при разработке проектов с ожидаемыми существенными изменениями или дополнениями требований;
- для выполнения долгосрочных проектов;
- при разработке проектов, требующих демонстрации качества и версий системы или продукта через короткий период времени;
- при разработке проектов. для которых необходим подсчет затрат, связанных с оценкой и разрешением рисков.
Стандарты жизненного цикла ПО
- ГОСТ 34.601-90
- ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)
Стандарт ГОСТ 34 .601-90
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID ), получившей также от Т. Гилба в 70-е гг. название эволюционной модели . Также эту модель называют итеративной моделью и инкрементальной моделью .
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение - инкремент - к его возможностям, которые, следовательно, развиваются эволюционно . Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения .
По выражению Т. Гилба, «эволюция - прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте» .
Подход IID имеет и свои отрицательные стороны, которые, по сути, - обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже» .
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP , MSF , ).
Спиральная модель
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
- риск превышения сроков и стоимости проекта;
- необходимость выполнения ещё одной итерации;
- степень полноты и точности понимания требований к системе;
- целесообразность прекращения проекта.
Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID .
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
- Дефицит специалистов.
- Нереалистичные сроки и бюджет.
- Реализация несоответствующей функциональности.
- Разработка неправильного пользовательского интерфейса.
- Перфекционизм, ненужная оптимизация и оттачивание деталей.
- Непрекращающийся поток изменений.
- Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
- Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
- Недостаточная производительность получаемой системы.
- Разрыв в квалификации специалистов разных областей.
В сегодняшней спиральной модели определён следующий общий набор контрольных точек :
- Concept of Operations (COO) - концепция (использования) системы;
- Life Cycle Objectives (LCO) - цели и содержание жизненного цикла;
- Life Cycle Architecture (LCA) - архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
- Initial Operational Capability (IOC) - первая версия создаваемого продукта, пригодная для опытной эксплуатации;
- Final Operational Capability (FOC) –- готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
Методологии разработки ПО
- Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
- Экстремальное программирование (англ. Extreme Programming, XP ). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.
- ЕСПД - комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.
Литература
- Братищенко В.В. Проектирование информационных систем. - Иркутск: Изд-во БГУЭП, 2004. - 84 с.
- Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М .: Финансы и статистика, 2000.
- Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. - М .: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
- Мишенин А.И. Теория экономических информационных систем. - М .: Финансы и статистика, 2000. - 240 с.
Примечания
Wikimedia Foundation . 2010 .
Рис.
5.2.
Такими аспектами являются:
- договорный аспект, в котором заказчик и поставщик вступают в договорные отношения и реализуют процессы приобретения и поставки;
- аспект управления, который включает действия управления лицами, участвующими в ЖЦ ПО (поставщик, заказчик, разработчик, оператор и др.);
- аспект эксплуатации, включающий действия оператора по предоставлению услуг пользователям системы;
- инженерный аспект, который содержит действия разработчика или службы сопровождения по решению технических задач, связанных с разработкой или модификацией программных продуктов;
- аспект поддержки, связанный с реализацией вспомогательных процессов, с помощью которых службы поддержки предоставляют необходимые услуги всем остальным участникам работ. В этом аспекте можно выделить аспект управления качеством ПО, включающий процессы обеспечения качества, верификацию, аттестацию, совместную оценку и аудит.
Организационные процессы выполняются на корпоративном уровне или на уровне всей организации в целом, создавая базу для реализации и постоянного совершенствования процессов ЖЦ ПО .
5.6. Модели и стадии ЖЦ ПО
Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ ПО . Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ISO / IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО . Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО . Стандарт описывает структуру процессов ЖЦ ПО , но не конкретизирует, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ любого конкретного ПО определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии (фазы) работ , выполнение которых необходимо и достаточно для создания ПО , соответствующего заданным требованиям.
Под стадией (фазой) создания ПО понимается часть процесса создания ПО , ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО , программных компонентов, документации и пр.), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по соображениям рационального планирования и организации работ , заканчивающихся заданными результатами. В состав ЖЦ ПО обычно включаются следующие стадии:
- формирование требований к ПО;
- проектирование (разработка системного проекта);
- реализация (может быть разбита на подэтапы: детальное проектирование, кодирование);
- тестирование (может быть разбито на автономное и комплексное тестирование и интеграцию);
- ввод в действие (внедрение);
- эксплуатация и сопровождение;
- снятие с эксплуатации.
Некоторые специалисты вводят дополнительно начальную стадию – анализ осуществимости системы. Здесь имеется в виду программно-аппаратная система, для которой создается, приобретается или модифицируется ПО .
Стадия формирования требований к ПО является одной из важнейших и определяет в значительной (даже решающей!) степени успех всего проекта. Началом этой стадии является получение одобренной и утвержденной архитектуры системы с включением основных соглашений о распределении функций между аппаратурой и программами. Этот документ должен также содержать подтверждение общего представления о функционировании ПО с включением основных соглашений о распределении функций между человеком и системой.
Стадия формирования требований к ПО включает следующие этапы.
- Планирование работ, предваряющее работы над проектом. Основными задачами этапа являются определение целей разработки, предварительная экономическая оценка проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы.
- Проведение обследования деятельности автоматизируемой организации (объекта), в рамках которого осуществляются предварительное выявление требований к будущей системе определение структуры организации, определение перечня целевых функций организации, анализ распределения функций по подразделениям и сотрудникам, выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных воздействий, анализ существующих средств автоматизации деятельности организации.
- модели "AS-IS" ("как есть"), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом работает данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;
- модели "TO-BE" ("как должно быть"), отражающей представление о новых технологиях работы организации.
Построение модели деятельности организации (объекта), предусматривающее обработку материалов обследования и построение двух видов моделей:
Каждая из моделей должна включать полную функциональную и информационную модель деятельности организации, а также (при необходимости) модель, описывающую динамику поведения организации. Заметим, что построенные модели имеют самостоятельное практическое значение , независимо от того, будет ли на предприятии разрабатываться и внедряться информационная система, поскольку с их помощью можно обучать сотрудников и совершенствовать бизнес-процессы предприятия.
Результатом завершения стадии формирования требований к ПО являются спецификации ПО , функциональные, технические и интерфейсные спецификации, для которых подтверждена их полнота , проверяемость и осуществимость.
Стадия проектирования включает следующие этапы.
Разработка системного проекта ПО. На этом этапе дается ответ на вопрос "Что должна делать будущая система?", а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки, план отладки ПО и контроль качества.
Основу системного проекта составляют модели проектируемой системы, которые строятся на модели "TO-BE". Результатом разработки системного проекта должна быть одобренная и подтвержденная спецификация требований к ПО: функциональные, технические и интерфейсные спецификации, для которых подтверждена их полнота, проверяемость и осуществимость.
- Разработка детального (технического) проекта. На этом этапе осуществляется собственно проектирование ПО, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла требованиям?"
Результатом детального проектирования является разработка верифицированной спецификации ПО , включающей:
- формирование иерархии программных компонентов, межмодульных интерфейсов по данным и управлению;
- спецификация каждого компонента ПО, имени, назначения, предположений, размеров, последовательности вызовов, входных и выходных данных, ошибочных выходов, алгоритмов и логических схем;
- формирование физической и логической структур данных до уровня отдельных полей;
- разработку плана распределения вычислительных ресурсов (времени центральных процессоров, памяти и др.);
- верификацию полноты, непротиворечивости, осуществимости и обоснованности требований;
- предварительный план комплексирования и отладки, план руководства для пользователей и приемных испытаний.
Завершением стадии детального проектирования является сквозной
Развитие ВТ постоянно расширяет классы решаемых задач связанных с обработкой информации различного характера.
Это в основном три вида информации и соответственно три класса задач, для решения которых используются компьютеры:
1) Вычислительные задачи, связанные с обработкой числовой информации. К ним относится, например, задача решения системы линейных уравнений большой размерности. Раньше была основной, доминирующей областью использования ЭВМ.
2) Задачи по обработке символьной информации, связанные с созданием, редактированием и преобразованием текстовых данных. С решением таких задач связан труд, например, секретаря-машинистки.
3) Задачи по обработке графической информации т.е. схем, чертежей, графиков, эскизов и т.д. К таким задачам относится, например, задача разработки конструктором чертежей новых изделий.
4) Задачи по обработке алфавитно-цивровой информации – ИС. В настоящее время стало одной из основных областей применеия ЭВМ и задачи все усложняются.
Решение на ЭВМ задач каждого класса имеет свою специфику, но его можно разбить на несколько этапов, характерных для большинства задач.
Технология программирования изучает технологические процессы и порядок их прохождения (стадии) с использованием знаний, методов и средств.
Технологии удобно характеризовать в двух измерениях – вертикальном (представляющем процессы) и горизонтальном (представляющем стадии).
Рисунок
Процесс- совокупность взаимосвязанных действий (технологических операций), преобразующих некоторые входные данные в выходные. Процессы состоят из набора действий (технологических операций), а каждое действие из набора задач и методов их решения. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как рабочие процессы, действия, задачи, результаты деятельности, исполнители.
Стадия – часть действий по созданию ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта, определяемого заданными для данной стадии требованиями. Иногда стадии объединяют в более крупные временные рамки, называемые фазами или этапами. Итак, горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как фазы, стадии, этапы, итерации и контрольные точки.
Разработка ПО подчиняется определенному жизненному циклу.
Жизненный цикл ПО – это непрерывный и упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке и эксплуатации ПО, начинающийся с момента появления идеи(замысла) создания некоторого программного обеспечения и принятия решения о необходимости его создания и заканчивающийся в момент его полного изъятия из эксплуатации по причинам:
а) морального старения;
б) потери необходимости решения соответствующих задач.
Технологические подходы – это механизмы реализации жизненного цикла.
Технологический подход определяется спецификой комбинации стадий и процессов, ориентированной на разные классы ПО и на особенности коллектива разработчиков.
ЖЦ определяет стадии(фазы, этапы), так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сворачивания.
ЖЦ разработки ПО может быть представлен с различной степенью детализации этапов. Простейшее представление жизненного цикла, включает стадии:
Проектирование
Реализация
Тестирование и отладка
Внедрение, эксплуатация и сопровождение.
Простейшее представление ЖЦ программы (каскадный технологический подход к ведению жизненного цикла):
Процессы
Проектирование
Программирование
Тестирование
Сопровождение
Анализ Проектирование Реализация ТестированиеВнедрениеэксплуатация
и отладка и сопровождение
Фактически здесь на каждой стадии выполняется единственный процесс. Очевидно, что при разработке и создании больших программ такая схема недостаточно корректна (неприменима), но ее можно взять за основу.
Этап аализа концентрируется на системных требованиях. Требования определяются и специфицируются (описываются). Осуществляется разработка и интеграция функциональных моделей и моделей данных для системы. Кроме того, фиксируются нефункциональные и другие системные требования.
Этап проектирования разделяется на два основных подэтапа: архитектурное и детализированное проектирование. В частности, проводится уточнение конструкции программы, пользовательского интерфейса и структур данных. Поднимаются и фиксируются вопросы проектирования, которые влияют на понятность, приспособленность к сопровождению и масштабируемость системы.
Этап реализации включает написание программы.
Отличия в вппаратном обеспечении и программном обеспечении особенно видны на этапе эксплуатации . Если товары широкого потребления проходят этапы выведения на рынок, роста, зрелости и упадка, то жизнь ПО больше походит на историю недостроенного, но постоянно достраиваемого и подновляемого здания(самолета) (Абонент).
ЖЦ ПО регламентируется многими стандартами в том числе и международными.
Цель стандартизации ЖЦ сложных ПС:
Обобщение опыта и результатов исследований множества специалистов;
Отработка технологических процессов и приемов разработки, а также методической базы для их автоматизации.
Стандарты включают:
Правила описания исходной информации, способов и методов выполнения операций;
Устанавливают правила контроля технологических процессов;
Устанавливают требования к оформлению результатов;
Регламентируют содержание технологических и эксплуатационных документов;
Определяют организационную структуру коллектива разработчиков;
Обеспечивают распределение и планирование заданий;
Обеспечивают контроль за ходом создания ПС.
В России действуют стандарты, регламентирующие ЖЦ:
Стадии разработки ПО– ГОСТ 19.102-77
Стадии создания АС - ГОСТ 34.601 –90;
ТЗ на создание АС - ГОСТ 34.602-89;
Виды испытания АС - ГОСТ 34.603-92;
Однако создание, сопровождение и развитие прикладных ПС для ИС в этих стандартах отражены недостаточно, а отдельные их положения устарели с точки зрения построения современных распределенных комплексов прикладных программ высокого качества в системах управления и обработки данных с различной архитектурой.
В связи с этим следует отметить международный стандарт ISO/IEC 12207-1999 – «Информационные технологии – Процессы жизненного цикла программного обеспечения».
ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.
Он определяет структуру ЖЦ ПО и его процессы.
Т.е. создание ПО это не такая простая задача, поэтому и существуют стандарты, в которых все расписано: что нужно делать, когда и как.
Структура ЖЦ ПО по международному стандарту ISO/IEC 12207-95 базируется на трех группах процессов:
1) основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение ). Мы основное внимание уделим последним.
2) вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование , управление конфигурацией, обеспечение качества, верификация, аттестация, совместный анализ (оценка), аудит, решение проблем).
1. Управление конфигурацией это процесс, поддерживающий основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения. При разработке проектов сложных ПО, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной (т.е. единой) структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в различные компоненты ПО на всех стадиях его ЖЦ.
2. Верификация -это процесс определения того, отвечает ли текущее состояние ПО, достигнутое на данном этапе, требованиям этого этапа.
3. Аттестация – подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования к конкретным объектам полностью реализованы.
4. Совместный анализ(оценка) – систематическое определение степени соответствия объекта установленным критериям.
5. Аудит – проверка, выполняемая компетентным органом (лицом) с целью обеспечения независимой оценки степени соответствия программных продуктов или процессов установленным требованиям. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, которое проводится для определения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
3) организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний созданного ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов ПО.
Мы будем рассматривать ЖЦ ПО с точки зрения разработчика.
Процесс разработки в соответсвии со стандартом предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, а также подготовку материалов, необходимых для проверки работоспособности и соответствия качества пограммных продуктов, материалов, необходимых для обучения персонала и т.д.
По стандарту жизненный цикл ПО ИС включает в себя следующие действия:
1) возникновение и исследование идеи(замысла);
2) подготовительный этап - выбор модели жизненного цикла, стандартов, методов и средств разработки, а также составление плана работ.
3) анализ требований к информационной системе - определение ее
функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т.д.
4) проектирование архитектуры информациронной системы - определение состава необходимого оборудования, программного обеспечения и операций, выполняемых обслуживающим персоналом .
5) анализ требований к программному обеспечению - определение функциональных возможностей, включая характеристики производительности, среды функционирования компонентов, внешних интерфейсов, спецификаций надежности и безопасности, эргономических требований, требований к используемым данным, установке, приемке, пользовательской документации, эксплуатации и сопровождению.
6) проектирование архитектуры программного обеспечения - определение структуры ПО, документирование интерфейсов его компонентов, разработку предварительной версии пользовательской документации, а также требований к тестам и плана интеграции.
7) детальное проектирование программного обеспечения - подробное
описание компонентов ПО и интерфейсов между ними, обновление пользовательской документации, разработка и документирование требований к тестам и плана тестирования, компонентов ПО, обновление плана интеграции компонентов.
8) кодирование ПО - – разработка и документирование
каждого программного компонента;
9)тестирование ПО – разработка совокупности тестовых процедур и данных для их тестирования, тестирование компонентов, обновление пользовательской документации, обновление плана интеграции ПО;
10) интеграция ПО – сборка программных компонентов в соответсвие с
планом интеграции и тестрование ПО на соответсвие квалификационным требованиям, представляющих собой набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт, как соответсвующий своим спецификациям и готовый к использованию в заданых условиях эксплуатации;
11) квалификационное тестирование ПО – тестирование ПО в
присутствии заказчика для демонстрации его соответствия
требованиям и готовности к эксплуатации; при этом проверяется также готовность и полнота технической и пользовательской документации ;
12) интеграция системы – сборка всех компонетов информационной системы, включая ПО и оборудование;
13) квалификационное тестирование ИС – тестирование системы на
соответсвие требованиям к ней и проверка оформления и полноты документации;
14) установка ПО – установка ПО на обородование заказчика и проверка его работоспособюности; ;
15) приемка ПО – оценка результатов квалифицированного
тестирования ПО и информционной системы в целом и
документирование результатов оценки совместно с заказчиком, аттестация и окончательная передача ПО заказчику.
16)Управление и разработка документации;
17)эксплуатация
18)сопровождение – процесс создания и внедрения новых версий
программного продукта. ;
19)завершение эксплуатации.
Указанные действия можно сгруппировать, условно выделив следующие основные этапы разработки ПО:
· постановка задачи(ТЗ) (по ГОСТ 19.102-77 стадия «Техническое задание»)
Развитие ВТ постоянно расширяет классы решаемых задач связанных с обработкой информации различного характера.
Это в основном три вида информации и соответственно три класса задач, для решения которых используются компьютеры:
1) Вычислительные задачи, связанные с обработкой числовой информации. К ним относится, к примеру, задача решения системы линейных уравнений большой размерности. Раньше была основной, доминирующей областью использования ЭВМ.
2) Задачи по обработке символьной информации, связанные с созданием, редактированием и преобразованием текстовых данных. С решением таких задач связан труд, к примеру, секретаря-машинистки.
3) Задачи по обработке графической информации ᴛ.ᴇ. схем, чертежей, графиков, эскизов и т.д. К таким задачам относится, к примеру, задача разработки конструктором чертежей новых изделий.
4) Задачи по обработке алфавитно-цивровой информации – ИС. Сегодня стало одной из базовых областей применеия ЭВМ и задачи все усложняются.
Решение на ЭВМ задач каждого класса имеет свою специфику, но его можно разбить на несколько этапов, характерных для большинства задач.
Технология программирования изучает технологические процессы и порядок их прохождения (стадии) с использованием знаний, методов и средств.
Технологии удобно характеризовать в двух измерениях – вертикальном (представляющем процессы) и горизонтальном (представляющем стадии).
Рисунок
Процесс- совокупность взаимосвязанных действий (технологических операций), преобразующих некоторые входные данные в выходные. Процессы состоят из набора действий (технологических операций), а каждое действие из набора задач и методов их решения. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как рабочие процессы, действия, задачи, результаты деятельности, исполнители.
Стадия – часть действий по созданию ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта͵ определяемого заданными для данной стадии требованиями. Иногда стадии объединяют в более крупные временные рамки, называемые фазами или этапами. Итак, горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как фазы, стадии, этапы, итерации и контрольные точки.
Разработка ПО подчиняется определенному жизненному циклу.
Жизненный цикл ПО - ϶ᴛᴏ непрерывный и упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке и эксплуатации ПО, начинающийся с момента появления идеи(замысла) создания некоторого программного обеспечения и принятия решения о крайне важно сти его создания и заканчивающийся в момент его полного изъятия из эксплуатации по причинам:
а) морального старения;
б) потери крайне важно сти решения соответствующих задач.
Технологические подходы - ϶ᴛᴏ механизмы реализации жизненного цикла.
Технологический подход определяется спецификой комбинации стадий и процессов, ориентированной на разные классы ПО и на особенности коллектива разработчиков.
ЖЦ определяет стадии(фазы, этапы), так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сворачивания.
ЖЦ разработки ПО должна быть представлен с различной степенью детализации этапов. Простейшее представление жизненного цикла, включает стадии:
Проектирование
Реализация
Тестирование и отладка
Внедрение, эксплуатация и сопровождение.
Простейшее представление ЖЦ программы (каскадный технологический подход к ведению жизненного цикла):
Процессы
Проектирование
Программирование
Тестирование
Сопровождение
Анализ Проектирование Реализация ТестированиеВнедрениеэксплуатация
и отладка и сопровождение
Фактически здесь на каждой стадии выполняется единственный процесс. Очевидно, что при разработке и создании больших программ такая схема недостаточно корректна (неприменима), но ее можно взять за основу.
Этап аализа концентрируется на системных требованиях. Требования определяются и специфицируются (описываются). Осуществляется выработка и интеграция функциональных моделей и моделей данных для системы. Вместе с тем, фиксируются нефункциональные и другие системные требования.
Этап проектирования разделяется на два базовых подэтапа: архитектурное и детализированное проектирование. В частности, проводится уточнение конструкции программы, пользовательского интерфейса и структур данных. Поднимаются и фиксируются вопросы проектирования, которые влияют на понятность, приспособленность к сопровождению и масштабируемость системы.
Этап реализации включает написание программы.
Отличия в вппаратном обеспечении и программном обеспечении особенно видны на этапе эксплуатации . В случае если товары широкого потребления проходят этапы выведения на рынок, роста͵ зрелости и упадка, то жизнь ПО больше походит на историю недостроенного, но постоянно достраиваемого и подновляемого здания(самолета) (Абонент).
ЖЦ ПО регламентируется многими стандартами в т.ч. и международными.
Цель стандартизации ЖЦ сложных ПС:
Обобщение опыта и результатов исследований множества специалистов;
Отработка технологических процессов и приемов разработки, а также методической базы для их автоматизации.
Стандарты включают:
Правила описания исходной информации, способов и методов выполнения операций;
Устанавливают правила контроля технологических процессов;
Устанавливают требования к оформлению результатов;
Регламентируют содержание технологических и эксплуатационных документов;
Определяют организационную структуру коллектива разработчиков;
Обеспечивают распределение и планирование заданий;
Обеспечивают контроль за ходом создания ПС.
В России действуют стандарты, регламентирующие ЖЦ:
Стадии разработки ПО– ГОСТ 19.102-77
Стадии создания АС - ГОСТ 34.601 –90;
ТЗ на создание АС - ГОСТ 34.602-89;
Виды испытания АС - ГОСТ 34.603-92;
При этом создание, сопровождение и развитие прикладных ПС для ИС в этих стандартах отражены недостаточно, а отдельные их положения устарели с точки зрения построения современных распределенных комплексов прикладных программ высокого качества в системах управления и обработки данных с различной архитектурой.
В связи с этим следует отметить международный стандарт ISO/IEC 12207-1999 – ʼʼИнформационные технологии – Процессы жизненного цикла программного обеспеченияʼʼ.
ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.
Он определяет структуру ЖЦ ПО и его процессы.
Т.е. создание ПО это не такая простая задача, в связи с этим и существуют стандарты, в которых все расписано: что нужно делать, когда и как.
Структура ЖЦ ПО по международному стандарту ISO/IEC 12207-95 базируется на трех группах процессов:
1) основные процессы ЖЦ ПО (приобретение, поставка, выработка, эксплуатация, сопровождение ). Мы основное внимание уделим последним.
2) вспомогательные процессы, обеспечивающие выполнение базовых процессов (документирование , управление конфигурацией, обеспечение качества, верификация, аттестация, совместный анализ (оценка), аудит, решение проблем).
1. Управление конфигурацией это процесс, поддерживающий основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения. При разработке проектов сложных ПО, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной (ᴛ.ᴇ. единой) структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в различные компоненты ПО на всех стадиях его ЖЦ.
2. Верификация -это процесс определения того, отвечает ли текущее состояние ПО, достигнутое на данном этапе, требованиям этого этапа.
3. Аттестация – подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования к конкретным объектам полностью реализованы.
4. Совместный анализ(оценка) – систематическое определение степени соответствия объекта установленным критериям.
5. Аудит – проверка, выполняемая компетентным органом (лицом) с целью обеспечения независимой оценки степени соответствия программных продуктов или процессов установленным требованиям. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, ĸᴏᴛᴏᴩᴏᴇ проводится для определения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
3) организационные процессы (управление проектами, создание инфраструктуры проекта͵ определение, оценка и улучшение самого ЖЦ, обучение).
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта͵ определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний созданного ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов ПО.
Мы будем рассматривать ЖЦ ПО с точки зрения разработчика.
Процесс разработки в соответсвии со стандартом предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, а также подготовку материалов, необходимых для проверки работоспособности и соответствия качества пограммных продуктов, материалов, необходимых для обучения персонала и т.д.
По стандарту жизненный цикл ПО ИС включает в себя следующие действия:
1) возникновение и исследование идеи(замысла);
2) подготовительный этап - выбор модели жизненного цикла, стандартов, методов и средств разработки, а также составление плана работ.
3) анализ требований к информационной системе - определение ее
функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т.д.
4) проектирование архитектуры информациронной системы - определение состава крайне важно го оборудования, программного обеспечения и операций, выполняемых обслуживающим персоналом .
5) анализ требований к программному обеспечению - определение функциональных возможностей, включая характеристики производительности, среды функционирования компонентов, внешних интерфейсов, спецификаций надежности и безопасности, эргономических требований, требований к используемым данным, установке, приемке, пользовательской документации, эксплуатации и сопровождению.
6) проектирование архитектуры программного обеспечения - определение структуры ПО, документирование интерфейсов его компонентов, разработку предварительной версии пользовательской документации, а также требований к тестам и плана интеграции.
7) детальное проектирование программного обеспечения - подробное
описание компонентов ПО и интерфейсов между ними, обновление пользовательской документации, выработка и документирование требований к тестам и плана тестирования, компонентов ПО, обновление плана интеграции компонентов.
8) кодирование ПО - – выработка и документирование
каждого программного компонента;
9)тестирование ПО – выработка совокупности тестовых процедур и данных для их тестирования, тестирование компонентов, обновление пользовательской документации, обновление плана интеграции ПО;
10) интеграция ПО – сборка программных компонентов в соответсвие с
планом интеграции и тестрование ПО на соответсвие квалификационным требованиям, представляющих собой набор критериев или условий, которые крайне важно выполнить, чтобы квалифицировать программный продукт, как соответсвующий своим спецификациям и готовый к использованию в заданых условиях эксплуатации;
11) квалификационное тестирование ПО – тестирование ПО в
присутствии заказчика для демонстрации его соответствия
требованиям и готовности к эксплуатации; при этом проверяется также готовность и полнота технической и пользовательской документации ;
12) интеграция системы – сборка всех компонетов информационной системы, включая ПО и оборудование;
13) квалификационное тестирование ИС – тестирование системы на
соответсвие требованиям к ней и проверка оформления и полноты документации;
14) установка ПО – установка ПО на обородование заказчика и проверка его работоспособюности; ;
15) приемка ПО – оценка результатов квалифицированного
тестирования ПО и информционной системы в целом и
документирование результатов оценки совместно с заказчиком, аттестация и окончательная передача ПО заказчику.
16)Управление и выработка документации;
17)эксплуатация
18)сопровождение – процесс создания и внедрения новых версий
программного продукта. ;
19)завершение эксплуатации.
Указанные действия можно сгруппировать, условно выделив следующие основные этапы разработки ПО:
· постановка задачи(ТЗ) (по ГОСТ 19.102-77 стадия ʼʼТехническое заданиеʼʼ)
· анализ требований и выработка спецификаций (по ГОСТ 19.102-77 стадия ʼʼЭскизный проектʼʼ)
· проектирование (по ГОСТ 19.102-77 стадия ʼʼТехнический проектʼʼ)
· реализация (кодирование, тестирование и отладка) (по ГОСТ 19.102-77 стадия ʼʼРабочий проектʼʼ).
· эксплуатация и сопровождение.
Жизненный цикл и этапы разработки ПО - понятие и виды. Классификация и особенности категории "Жизненный цикл и этапы разработки ПО" 2017, 2018.