1.4Управление жизненным циклом программных средств 1.4.1Понятие жизненного цикла
Жизненный цикл (ЖЦ) программного средства (ПС) определяется как период времени, который начинается с момента принятия решения о необходимости создания ПС и заканчивается в момент его полного изъятия из эксплуатации. Такой подход соответствует закону жизненной кривой теории систем. ПС обычно являются компонентами жизненного цикла технических систем, но по своей природе значительно отличаются от технических изделий, поэтому их жизненный цикл имеет характерные особенности, по сравнению с другими техническими объектами.
Типовая модель процессов жизненного цикла сложной системы начинается с концепции идеи системы или потребности в ней, охватывает проектирование, разработку, применение и сопровождение системы, и заканчивается снятием системы с эксплуатации. Программные средства служат для выполнения определенных функций систем на компьютерах. Модель жизненного цикла системы обычно разделяют на последовательные периоды реализации — стадии или этапы. Каждый подобный период включает основные реализуемые в нем процессы, работы и задачи, при завершении которых может потребоваться переход к следующему периоду реализации. Общую модель жизненного цикла сложной системы обычно разделяют на следующие основные этапы с последующей адаптацией каждого из них в модели жизненного цикла конкретной системы:
определение потребностей;
исследование и описание основных концепций;
проектирование и разработка;
испытания системы;
создание и производство;
распространение и продажа;
эксплуатация;
сопровождение и мониторинг;
снятие с эксплуатации (утилизация).
1.4.2Масштабы программных средств
По особенностям и свойствам жизненного цикла программ их целесообразно делить на ряд классов и категорий, из которых наиболее различающимися являются два крупных класса – малые и большие.
Первый класс составляют относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3–5) специалистов, которые:
создаются преимущественно для получения конкретных результатов автоматизации научных исследований или для анализа относительно простых процессов самими разработчиками программ;
не предназначены для массового тиражирования и распространения как программного продукта на рынке, их оценивают качественно и интуитивно преимущественно как “художественные произведения”;
не имеют конкретного независимого заказчика-потребителя, определяющего требования к программам и их финансирование;
не ограничиваются заказчиком допустимой стоимостью, трудоемкостью и сроками их создания, требованиями заданного качества и документирования;
не подлежат независимому тестированию, гарантированию качества и/или сертификации.
Для таких, а также для многих других видов относительно не сложных программ, нет необходимости в регламентировании их жизненного цикла, в длительном применении и сопровождении множества версий, в формализации и применении профилей стандартов и сертификации качества программ. Их разработчики не знают и не применяют регламентирующих, нормативных документов, вследствие чего жизненный цикл таких изделий имеет не предсказуемый характер по структуре, содержанию, качеству и стоимости основных процессов “творчества”.
Второй класс составляют крупномасштабные комплексы программ для сложных систем управления и обработки информации, оформляемые в виде программных продуктов с гарантированным качеством, и отличаются следующими особенностями и свойствами их жизненного цикла:
большая размерность, высокая трудоемкость и стоимость создания таких комплексов программ определяют необходимость тщательного анализа экономической эффективности всего их жизненного цикла и возможной конкурентоспособности на рынке;
от заказчика, финансирующего проект программного средства и/или базы данных, разработчикам необходимо получать квалифицированные конкретные требования к функциям и характеристикам проекта и продукта, соответствующие выделенному финансированию и квалификации исполнителей проекта;
для организации и координации деятельности специалистов-разработчиков при наличии единой, крупной целевой задачи, создания и совершенствования программного продукта, необходимы квалифицированные менеджеры проектов;
в проектах таких сложных программных средств и баз данных с множеством различных, функциональных компонентов, участвуют специалисты разной квалификации и специализации, от которых требуется высокая ответственность за качество результатов деятельности каждого из них;
от разработчиков проектов требуются гарантии высокого качества, надежности функционирования и безопасности применения компонентов и поставляемых программных продуктов, в которые не допустимо прямое вмешательство заказчика и пользователей для изменений, не предусмотренных эксплуатационной документацией разработчиков;
необходимо применять индустриальные, регламентированные стандартами процессы, этапы и документы, а также методы, методики и комплексы средства автоматизации, технологии обеспечения жизненного цикла комплексов программ.
Такие крупномасштабные комплексы программ являются компонентами систем, реализующими обычно их основные, функциональные свойства, увеличивающими сложность и создающими предпосылки для последующих изменений их жизненного цикла. Реализация ЖЦ, методологии управления и изменения ПС зависит от многих факторов, от персонала, технических, организационных и договорных требований и сложности проекта. Множество текущих состояний и модификаций компонентов сложных ПС менеджерам необходимо упорядочивать, контролировать их развитие и применение участниками проекта. Организованное, контролируемое и методичное отслеживание динамики изменений в жизненном цикле программ и данных, их слаженная разработка при строгом учете и контроле каждого изменения, является основой эффективного, поступательного развития каждой крупной системы методами программной инженерии.
Существует множество моделей процессов жизненного цикла систем и программных средств, но три из них в международных стандартах обычно квалифицируются как фундаментальные: каскадная; инкрементная; эволюционная. Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла конкретного проекта. При этом конкретную модель жизненного цикла системы или ПС следует выбирать так, чтобы процессы и задачи были связаны между собой, и определены их взаимосвязи с предшествующими процессами, видами деятельности и задачами.
1.4.3Классификация процессов жизненного цикла по ИСО/МЭК 12207
Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным).
Согласно ГОСТ Р ИСО/МЭК 12207 выделяют следующие процесса жизненного цикла [ГОСТ Р ИСО/МЭК 12207]:
Основные процессы:
приобретение;
поставка;
разработка;
эксплуатация;
сопровождение.
Вспомогательные процессы:
документирование;
управление конфигурацией;
обеспечение качества;
верификация;
аттестация;
совместная оценка;
аудит;
разрешение проблем.
Организационные процессы:
управление;
усовершенствование;
создание инфраструктуры;
обучение.
1.4.4Стадии разработки программных средств по ЕСПД
Теперь рассмотрим набор типовых стадий создания ПС, изучение которого позволит понимать процесс разработки и более осознанно относиться к созданию качества ПС. Эти стадии предусмотрены ГОСТ 19.102-77 ЕСПД. Стадии разработки.
Стадии – наиболее укрупненные составляющие процесса разработки, для завершения которых характерно получение ПО в определённой стадии готовности.
Рисунок
Выделяют следующие стадии разработки программного обеспечения:
Стадия технического задания (предпроектная стадия) состоит из:
сбора исходных данных;
определения цели разработки – желаемого набора основных свойств и функций разрабатываемого ПС;
обоснования и выбора критерия эффективности и качества разработки;
формирования на верхнем уровне состава входной и выходной документации по решаемой задаче;
выбора принципиальных методов решения задач;
определения требований к комплексу технических средств и операционному окружению;
определения инструментальных средств, используемых для разработки;
планирования, т.е. декомпозиции процесса на стадии и этапы с установлением сроков их выполнения;
разработки документа, называемого «Техническое задание».
Эскизное проектирование
На данной стадии выполняется:
детализация состава и структуры входной и выходной информации;
детализация метода решения задач.
На этапе эскизного проектирования нужно создать предварительную версию программного средства (возможно в виде модели) и выяснить принципиальные вопросы, устраняя возможные разногласия между разработчиком и заказчиком. При этом выполняется:
определение предварительной технологии решения задачи;
прогнозирование эффективности решения задачи на конкретном объекте;
ведется освоение инструментальных средств (апробирование, обучение персонала).
Техническое проектирование (технический проект)
На данном этапе:
окончательно определяется состав и структура информации;
разрабатывается интерфейс во всех его компонентах;
технология решения задачи доводится автоматизма;
полностью определяется конфигурация тех средств, на которых ведется разработка ПС;
определяется структура базы данных, где храниться информация о работе ПС;
разрабатывается тестовый набор для проверки правильности программной реализации;
начинается разработка программной документации;
полностью определяется структура ПС (модули, компоненты).
Технический проект может рассматриваться как постановка задачи, передаваемой специалистом-постановщиком специалисту по программной реализации.
Рабочее проектирование (рабочий проект)
Результат рабочего проектирования – получение ПС в состоянии операционной готовности, в котором устранены синтаксические и семантические ошибки, как в программном коде так и в программной документации.
Основные работы этой стадии:
программная реализация (написание программного кода, привязка его к специфике конкретного объекта, адаптация и настройка программных модулей);
отладка (автономная – в лабораторных условиях и комплексная – на объекте);
разработка эксплуатационной документации;
организация внедрения ПС.
Внедрение
На этапе внедрения осуществляют:
подготовку персонала к эксплуатации;
подготовку базы данных;
проверку работоспособности ПС на реальных данных (опытная эксплуатация);
доводку – окончательное устранение всех ошибок в коде и документации.
По отдельным компонентам может быть откат на предыдущие стадии.
В процессе разработки стадии могут объединяться. Объединяют эскизный и технический или технический и рабочий проекты. Иногда могут сразу объединять эскизный, технический и рабочий проекты. Обычно это производится, если в разрабатываемом ПС можно использовать значительный объём предыдущих разработок.
1.4.5Типичная схема управления процессом создания программного обеспечения
Управление процессами при разработке программного обеспечения в общем случае реализуется по спиральной схеме и состоит из следующих повторяемых действий [SWEBOK]:
создание инфраструктуры процесса (Establish Process Infrastructure). На данном этапе обеспечивается достижение согласия заинтересованных лиц (обычно это руководство организации) в работах по реализации или изменению процесса, определяется потребность в необходимых ресурсах и выполняется распределение обязанностей (ответственности);
планирование (Planning), в ходе которого формулируются текущие бизнес-цели и потребности в процессе, необходимые отдельным специалистам, проекту и/или организации, в целом, определяются и описываются сильные и слабые стороны существующего процесса и планируемых на данной итерации нововведений и/или изменений и разрабатывается план реализации и изменения процесса;
реализация и изменение процесса (Process Implementation and Change), предусматривающая выполнение разработанного плана по внедрению нового (усовершенствованного) процесса, в результате чего он процесс должен быть внедрен в практику организации;
оценка процесса (Process Evaluation), позволяющая выяснить уровень качества реализации процесса, а также степень достижения ожидаемых эффектов от его внедрения, после чего происходит либо выход, либо возвращение к первой итерации.
РИСУНОК
|
