Национальный исследовательский университет "Высшая Школа Экономики"
Опубликован: 19.11.2012 | Доступ: свободный | Студентов: 1991 / 429 | Длительность: 30:21:00
Специальности: Менеджер, Преподаватель
Лекция 5:

Жизненный цикл программных систем

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >

5.5. Взаимосвязь между процессами ЖЦ ПО

Процессы ЖЦ ПО, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом [2]. Тем не менее, стандарт предлагает некоторый базовый набор взаимодействий между процессами с различных точек зрения (либо в различных аспектах), который показан на рис.5.2.

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

Рис. 5.2. Взаимосвязь между процессами жизненного цикла программного обеспечения

Такими аспектами являются:

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

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

5.6. Модели и стадии ЖЦ ПО

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

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

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

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

  1. формирование требований к ПО;
  2. проектирование (разработка системного проекта);
  3. реализация (может быть разбита на подэтапы: детальное проектирование, кодирование);
  4. тестирование (может быть разбито на автономное и комплексное тестирование и интеграцию);
  5. ввод в действие (внедрение);
  6. эксплуатация и сопровождение;
  7. снятие с эксплуатации.

Некоторые специалисты [1] вводят дополнительно начальную стадию – анализ осуществимости системы. Здесь имеется в виду программно-аппаратная система, для которой создается, приобретается или модифицируется ПО.

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

Стадия формирования требований к ПО включает следующие этапы.

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

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

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

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

Стадия проектирования включает следующие этапы.

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

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

  2. Разработка детального (технического) проекта. На этом этапе осуществляется собственно проектирование ПО, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла требованиям?"

Результатом детального проектирования является разработка верифицированной спецификации ПО, включающей:

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

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

Стадия реализации – выполнение следующих работ.

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

    Внешние спецификации должны содержать следующие сведения:

    • имя модуля — указывается имя, применяемое для вызова модуля (для модуля с несколькими входами для каждого входа должны быть отдельные спецификации);
    • функция – дается определение функции или функций, выполняемых модулем;
    • список параметров (число и порядок следования), передаваемых модулю;
    • входные параметры – точное описание всех данных, возвращаемых модулем (должно быть определено поведение модуля при любых входных условиях);
    • внешние эффекты (печать сообщения, чтение запроса с терминала и т. п.).
  2. Проектирование логики модулей и программирование (кодирование) модулей.
  3. Проверка правильности модулей.
  4. Тестирование модулей.
  5. Описание базы данных до уровня отдельных параметров, символов и битов.
  6. План приемных испытаний.
  7. Руководство пользователю.
  8. Предварительный план комплексирования и отладки. Содержание последующих стадий в основном совпадает с соответствующими процессами ЖЦ ПО [9]. Вообще технологические стадии выделяются исходя из соображений разумного и рационального планирования и организации работ. Возможный вариант взаимосвязи и стадий работ с процессами ЖЦ ПО показан на рис.5.3.
Взаимосвязь между процессами и стадиями разработки в жизненном цикле программного обеспечения

Рис. 5.3. Взаимосвязь между процессами и стадиями разработки в жизненном цикле программного обеспечения
< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Аннна Миллер
Аннна Миллер
Екатерина Дмитриева
Екатерина Дмитриева