х годов была предложена спиральная модель ЖЦ рис

Работа добавлена на сайт samzan.net:

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

Для преодоления перечисленных проблем в середине 80-х годов была предложена спиральная модель ЖЦ (рис. 5). Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков от необходимости точного и полного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

Как показано на рис. 5, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

Планирование — определение целей, вариантов и ограничений.

Анализ риска — анализ вариантов и распознавание/выбор риска.

Конструирование — разработка продукта следующего уровня.

Оценивание — оценка заказчиком текущих результатов конструирования.

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

Рис. 5. Спиральная модель: 1 - начальный сбор требований и планирование проекта; 2 - та же работа, но на основе рекомендаций заказчика; 3 - анализ риска на основе начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход к комплексной системе; б - начальный макет системы; 7 - следующий уровень макета; 8 - сконструированная система; 9 - оценивание заказчиком.

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

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

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

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

Достоинства спиральной модели:

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

Недостатки спиральной модели:

1.  новизна (отсутствует достаточная статистика эффективности модели);
2.  повышенные требования к заказчику;
3.  трудности контроля и управления временем разработки.

Вопрос 16. Процессы жизненного цикла программных средств и информационных технологий.

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт 180/1ЕС 12207: 1995 “1пйогтайоп ТесЬпо1оду - Зой^аге Ьйе Сус1е Ргосеввев” (180 - 1п1егпа1юпа1 Огдатгайоп йог 81апёагё12а1;юп - Международная организация по стандартизации, 1ЕС - 1п1егпа1юпа1 Е1ес1го1есЬтса1 Сотт188юп - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

В России существуют стандарты:

ГОСТ 34601 - 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

ГОСТ 34601 - 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

ГОСТ 34601 - 92. «Информационная технология. Виды испытаний автоматизированных систем».

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

В соответствии с 180/1ЕС 12207: 1995 все процессы ЖЦ ПО разделены на три группы:

Основные процессы:

1.  приобретение;
2.  поставка;
3.  разработка;
4.  эксплуатация;
5.  сопровождение.

Вспомогательные процессы:

1.  документирование;
2.  управление конфигурацией;
3.  обеспечение качества;
4.  верификация;
5.  аттестация;
6.  совместная оценка;
7.  аудит;
8.  разрешение проблем.

Организационные процессы:

1.  управление;
2.  усовершенствование;
3.  создание инфраструктуры;

обучение.

Вопрос 17. Основные процессы жизненного цикла программного обеспечения.

1.  Основные процессы жизненного цикла ПО

Процесс приобретения состоит из действий и задач заказчика приобретающего программное средство:

Действие - инициирование приобретения - включает задачи:

1.  определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, программных продуктов или услуг;

анализ требований к системе; принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;

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

Действие - подготовка заявочных предложений. Заявочные предложения должны содержать:

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

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

Действие - подготовка и корректировка договора - включает задачи:

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

Действие - надзор за деятельностью поставщика - осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита.

В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.

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

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

Планирование включает задачи:

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

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

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

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

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

Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО:

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

Требования к ПО оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании.

Проектирование архитектуры ПО включает задачи (для каждого компонента ПО):

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

Архитектура компонентов ПО должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.

Детальное проектирование ПО включает следующие задачи:

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

Кодирование и тестирование ПО охватывает задачи:

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

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

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

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

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

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

Процесс эксплуатации охватывает действия и задачи оператора - организации, эксплуатирующей систему и включает действия:

Подготовительная работа включает проведение оператором следующих задач:

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

Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она передается в эксплуатацию.

Эксплуатация системы выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.

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

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

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

Процесс сопровождения охватывает следующие действия:

Подготовительная работа службы сопровождения включает в себя следующие задачи:

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

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

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

Модификация ПО предусматривает определение компонентов ПО, их

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

Проверка и приемка заключается в проверке целостности модифицированной системы и утверждении внесенных изменений.

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

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

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

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

Процесс документирования включает действия:

1.  подготовительную работу;
2.  проектирование и разработку;
3.  выпуск документации;
4.  сопровождение.

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

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

Процесс управления конфигурацией включает действия:

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

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

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

Процесс обеспечения качества включает действия:

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

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

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

Процесс верификации включает следующие действия:

1.  подготовительную работу;
2.  верификацию;

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

1.  непротиворечивость требований к системе и степень учета потребностей пользователей;
2.  возможности поставщика выполнять заданные требования;
3.  соответствие выбранных процессов ЖЦ ПО условиям договора;
4.  адекватность стандартов, процедур и среды разработки процесса ЖЦ ПО;
5.  соответствие проектных спецификаций ПО заданным требованиям;
6.  корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики;
7.  соответствие кода проектным спецификациям и требованиям;
8.  тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
9.  корректность интеграции компонентов ПО в систему;
10.  адекватность, полнота и непротиворечивость документации.

Процесс аттестации предусматривает определение полноты

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

Аттестация, так же как и верификация, может осуществляться с различными степенями независимости. Если процесс аттестации выполняется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой аттестации.

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

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

Процесс совместной оценки включает действия:

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

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

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

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

Вопрос 19.Организационные процессы жизненного цикла программного обеспечения.

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

Процесс управления включает следующие действия:

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

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

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

Процесс обучения охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.

Вопрос 20. Процесс разработки пс

Стадия разработки ПС включает в себя следующие фазы:

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

Вопрос 21.Специфика разработки программных средств.

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

1. Реконструкция подстанции гежская 110-6 кв.html
2. тематичних наук Чернівці2003 Дисертацією є рукопис
3. тема запалювання автомобіляРозділ- Технічні науки Система запалювання автомобіля Робоча суміш у циліндр
4. Лизинг. Актуальность темы обусловлена рядом причин таких как например- лизинг сравнительно недав
5. Тема Методи вивчення будови металів Мета
6. C utoEventWireuptrue CodeFile
7. . Дать определение понятиям- промышленная безопасность авария инцидент промышленная безопасность оп
8. І. Коломия ІваноФранківської обл.
9. духовне виробництв
10. Исследования отечественных психологов В
11. тема сети11 Выбор технических средств15 Системное сетевое ПО16 Категории пользователей17 Сист
12.  Языковая игра и образность 1
13. О государственном регулировании в области добычи и использования угля об особенностях социальной защиты ра
14. тематически сгруппированных философских текстов извлечений из трудов мыслителей разных эпох включая совр2
15. это состояние которое характеризуется только подавленным настроением
16. Gilt of his skin nd cst up golden sheens nd lights through the glimmering blue of his eyes
17. Задание 1 Вопрос- У беременной при профилактическом осмотре в пришеечной области фронтальной группы зубо
18. Ба~ухаус нем
19. Державна регіональна економічна політика її суть мета та основні завдання
20. На тему Содержание обучения Выполнила Уйданова Екатерина Павловна 26 группа Преподаватель Кузн

Материалы собраны группой SamZan и находятся в свободном доступе