Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Основные процессы жизненного цикла программного средства
В соответствии с ISO/IEC 12207: 1995 все процессы ЖЦ ПО разделены на три группы: Основные процессы:
Вспомогательные процессы:
Организационные процессы:
Процеcc приобретения (acquisition process) состоит из действий и задач заказчика, приобретающего программное средство (рис. 2.2). Инициирование приобретения включает следующие задачи: · определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, программных продуктов или услуг; · анализ требований к системе; · принятие решения относительно приобретения, разработки или усовершенствования существующего ПС; · проверку наличия необходимой документации, гарантии, сертификатов, лицензий и поддержки в случае приобретения программного продукта; · подготовку и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон и т. д. Заявочные предложения должны содержать: требования к системе; перечень программных продуктов; условия и соглашения; технические ограничения (например, среда функционирования системы). Заявочные предложения направляются выбранному поставщику (или нескольким поставщикам в случае проведения тенде-). Поставщик — это организация, которая заключает договор с заказчиком на поставку системы, ПС или программной услуги наусловиях, оговоренных в договоре. Подготовка и корректировка договора включают следующие задачи: • определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков; • ныбор конкретного поставщика на основе анализа предложений, • подготовку и заключение договора с поставщиком; • внесение изменений (при необходимости) в договор в процессе его выполнения.
Рис. 2.2. Схема процесса приобретения программного средства Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита. В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки. Процесс поставки (supply process) охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой (рис. 2.3). Рис. 2.3. Схема процесса поставки Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения о согласии с выставленными требованиями и условиями или предложение своих. Планирование включает следующие задачи: принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика; разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки и ресурсам, управление субподрядчиками и др. Процесс разработки (development process) предусматривает Действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПС и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т. д. (рис. 2.4).
Рис. 2.4. Схема процесса разработки Подготовительная работа начинается с выбора модели ЖЦ ПС, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ. Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т. д. Требования к системе оцениваются исходя из критериев реализуемости и возможности проверки при тестировании. Проектирование архитектуры системы на высоком уровне заключается в определении компонентов ее оборудования, ПС и операций, выполняемых эксплуатирующим систему персоналом. Архитектура системы должна соответствовать требованиям, предъявляемым к системе, а также принятым проектным стандартам и методам. Анализ требований к ПС предполагает определение следующих характеристик для каждого компонента ПС: • функциональных возможностей, включая характеристики производительности и среды функционирования компонента; • внешних интерфейсов; • спецификаций надежности и безопасности; • эргономических требований; • требований к используемым данным; • требований к установке и приемке; • требований к пользовательской документации; • требований к эксплуатации и сопровождению. Требования к ПС оцениваются исходя из критериев соответствия имя требованиям к системе, реализуемости и возможности проверки при тестировании. Проектирование архитектуры ПС включает следующие задачи (для каждого компонента ПС): · трансформацию требований к ПС в архитектуру, определяющую на высоком уровне структуру ПС и состав его компонентов; · разработку и документирование программных интерфейсов ПС и баз данных; · разработку предварительной версии пользовательской докумен- тации; · разработку и документирование предварительных требований к тестам и плана интеграции ПС. Архитектура компонентов ПС должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам. Детальное проектирование ПС включает следующие задачи: · писание компонентов ПС и интерфейсов между ними на более низком уровне, достаточном для их последующего самостоятельного кодирования и тестирования; · разработку и документирование детального проекта базы данных; · обновление (при необходимости) пользовательской докумен-тации; · разработку и документирование требований к тестам и плана тестирования компонентов ПС; · обновление плана интеграции ПС. Кодирование и тестирование ПС охватывают следующие задачи: • разработку (кодирование) и документирование каждого компонента ПС и базы данных, а также совокупности тестовых процедур и данных для их тестирования; • тестирование каждого компонента ПС и базы данных на соответствие предъявляемым к ним требованиям. Результаты тестирования компонентов должны быть документированы; • обновление (при необходимости) пользовательской документации; • обновление плана интеграции ПС. Интеграция ПС предусматривает сборку разработанных компонентов ПС в соответствии с планом интеграции и тестирование агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование — это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации. Квалификационное тестирование ПС проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПС удовлетворяет своим спецификациям и готово к использованию в условиях эксплуатации. Квалификационное тестирование выполняется для каждого компонента ПС по всем разделам требований при широком варьировании тестов. При этом также проверяются полнота технической и пользовательской документации и ее адекватность самим компонентам ПС. Интеграция системы заключается в сборке всех ее компонентов, включая ПС и оборудование. После интеграции система, в свою очередь, подвергается квалификационному тестированию на соответствие совокупности требований к ней. При этом также производятся оформление и проверка полного комплекта документации на систему. Установка ПС осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПС и баз данных. Если устанавливаемое ПС заменяет существующую систему, разработчик должен обеспечить их параллельное функционирование в соответствии с договором. Приемка ПС предусматривает оценку результатов квалификационного тестирования ПС и системы и документирование результатов оценки, которые проводятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПС заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку. Процесс эксплуатации (operation process) охватывает действия и задачи оператора — организации, эксплуатирующей систему (рис. 2.5). Рис. 2.5. Схема процесса эксплуатации Подготовительная работа включает проведение оператором следующих задач: · планирование действий и работ, выполняемых в процессе эксплуатации, и установку эксплуатационных стандартов; · определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации. Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она передается в эксплуатацию. Эксплуатация системы выполняется в предназначенной для этого среде в соответствии с пользовательской документацией. Поддержка пользователей заключается в оказании помощи и консультации при обнаружении ошибок в процессе эксплуатации ПС. Процесс сопровождения (maintenance process) предусматривает (действия и задачи, выполняемые сопровождающей организацией (службой сопровождения).Данный процесс активизируется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблема ми или потребностями в модернизации либо адаптации ПС. соответствии со стандартом IEEE-90 под сопровождением пони мается внесение изменений в ПС в целях исправления ошибок повышения производительности или адаптации к изменившимся условиям работы или требованиям. Изменения, вносимые в существующее ПС, не должны нарушать его целостность. Процесс сопровождения включает перенос ПС в другую среду (миграцию) и заканчивается снятием ПС эксплуатации (рис. 2.6). Рис. 2.6. Схема процесса сопровождения Подготовительная работа службы сопровождения включает следующие задачи: • планирование действий и работ, выполняемых в процессе сопровождения; • определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения. Анализ проблем и запросов на модификацию ПС, выполняемый службой сопровождения, включает следующие задачи: • анализ сообщения о возникшей проблеме или запроса на модификацию ПС относительно его влияния на организацию, существующую систему и интерфейсы с другими системами. При этом определяются следующие характеристики возможной модификации: тип (корректирующая, улучшающая, профилактическая или адаптирующая к новой среде); масштаб (размеры модификации, стоимость и время ее реализации); критичность (воздействие на производительность, надежность или безопасность); • оценку целесообразности проведения модификации и возможных вариантов ее проведения; • утверждение выбранного варианта модификации. Модификация ПС предусматривает определение компонентов ПС их версий и документации, подлежащих модификации, и вне- сение необходимых изменений в соответствии с правилами про-цесса наработки. Подготовленные изменения тестируются и про-веряются по критериям, определенным в документации. При под-верждении корректности изменений в программах проводится корректировка документации. Проверка и приемка заключаются в проверке целостности мо-дифицированной системы и утверждении внесенных изменений. При переносе ПС в другую среду используются имеющиеся или разрабатываются новые средства переноса, затем выполняется конвертирование программ и данных в новую среду. С целью облегчить переход предусматривается параллельная эксплуатаци ПС в старой и новой среде в течение некоторого периода, когда проводится необходимое обучение пользователей работе в новой среде. Снятитие ПС с эксплуатации осуществляется по решению за-казчика при участии эксплуатирующей организации, службы со-провожения и пользователей. При этом программные продук-ты соответствующая документация подлежат архивированию в соответствии с договором. Аналогично переносу ПС в другую среду с целью облегчить переход к новой системе предусматрива-етсяпараллельная эксплуатация старого и нового ПС в течение некоторогоо периода, когда выполняется необходимое обучение пользователей работе с новой системой.
|