Файл: Инфрам.pdf

92 создание инфраструктуры управления.
3.4.2. Процесс создания инфраструктуры охватывает выбор и под- держку технологий, стандартов и инструментальных средств, исполь- зуемых для разработки, эксплуатации или сопровождения ПС. Инфра- структура должна модифицироваться и сопровождаться в соответствии с изменениями требований к соответствующим процессам. Инфраструк- тура, в свою очередь, является одним из объектов управления конфигу- рацией.
Процесс создания инфраструктуры включает следующие действия: подготовительную работу; создание инфраструктуры; сопровождение инфраструктуры.
3.4.3. Процесс усовершенствования предусматривает оценку, изме- рение, контроль и собственно усовершенствование процессов ЖЦ ПС.
Этот процесс включает три основных действия: создание процесса; оценку процесса; усовершенствование процесса.
Усовершенствование процессов ЖЦ ПС направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии, методов управле- ния, выбора инструментальных средств и обучения персонала. Усовер- шенствование основано на анализе достоинств и недостатков каждого процесса. Такому анализу способствует накопление в организации ис- торической, технической, экономической и иной информации по реали- зованным проектам.
3.4.4. Процесс обучения включает первоначальное обучение и по- следующее постоянное повышение квалификации персонала и состоит из трех действий: подготовительной работы; работки учебных материалов; реализации планов обучения.
3.5. Взаимосвязь между процессами ЖЦ ПС
Процессы ЖЦ ПС, регламентируемые стандартом ISO/IEC 12207 мо- гут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некото- рый базовый набор взаимодействий между процессами с различных точек зрения (либо в различных аспектах), который показан на рис. 3.2.
Такими аспектами являются:
1) договорной аспект, в котором заказчик и поставщик вступают в до- говорные отношения и реализуют процессы приобретения и постав- ки;
2) аспект управления, включающий действия управления лицами, уча- ствующими в ЖЦ ПС (поставщик, заказчик, разработчик, оператор и др.);

93 3) аспект эксплуатации, включающий действия оператора по предос- тавлению услуг пользователям системы;
4) инженерный аспект, содержащий действия разработчика или службы сопровождения по решению технических задач, связанных с разра- боткой или модификацией программных продуктов;
5) аспект поддержки, связанный с реализацией вспомогательных про- цессов, с помощью которых службы поддержки предоставляют не- обходимые услуги всем остальным участникам работ. В этом аспек- те можно выделить аспект управления качеством ПС, включающий процессы обеспечения качества, верификацию, аттестацию, совме- стную оценку и аудит.
Рис. 3.2. Взаимосвязь между процессами ЖЦ ПС
Организационные процессы выполняются на корпоративном уровне, или на уровне всей организации в целом, создавая базу для реализации и постоянного совершенствования процессов ЖЦ ПС.
3.6. Модели и стадии ЖЦ ПС
Под моделью ЖЦ ПС понимается структура, определяющая после- довательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ ПС. Модель ЖЦ зависите от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует. Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПС. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПС. Стан-

94 дарт описывает структуру процессов ЖЦ ПС, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ любой конкретной ПС определяет характер процесса ее создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии (фазы) работ, вы- полнение которых необходимо достаточно для создания ПС, соответст- вующего заданным требованиям.
Под стадией (фазой) создания ПС понимается часть процесса созда- ния ПС, ограниченная некоторыми временными рамками и заканчи- вающаяся выпуском конкретного продукта (моделей ПС, программных компонентов, документации и пр.), определяемого заданными для дан- ной стадии требованиями. Стадии создания ПС выделяются по сообра- жениям рационального планирования и организации работ, заканчи- вающихся заданными результатами. В состав ЖЦ ПС обычно включа- ются следующие стадии:
1) формирование требований к ПС;
2) проектирование (разработка системного проекта);
3) реализация (может быть разбита на подэтапы: детальное проек- тирование, кодирование);
4) тестирование (может быть разбито на автономное и комплекс- ное тестирование и интеграцию);
5) ввод в действие (внедрение);
6) эксплуатация и сопровождение;
7) снятие с эксплуатации.
Некоторые специалисты, например, Б. Боэм [6] вводят дополнитель- но начальную стадию – анализ осуществимости системы, что следует считать оправданным, особенно при создании достаточно сложных сис- тем. Здесь имеется в виду программно-аппаратная система, для которой создается, приобретается или модифицируется ПС.
Стадия формирования требований к ПС является одной из важней- ших и определяет в значительной (даже решающей!) степени успех все- го проекта. Началом этой стадии является получение одобренной и ут- вержденной архитектуры системы с включением основных соглашений о распределении функций между аппаратурой и программами. Этот до- кумент должен также содержать подтверждение общего представления о функционировании ПС с включением основных соглашений о распре- делении функций между человеком и системой.
Стадия формирования требований к ПС включает следующие эта- пы:
1. Планирование работ, предваряющих работы над проектом. Основ- ными задачами этапа являются: а) определение целей разработки; б) предварительная экономическая оценка проекта; в) построение плана-графика выполнения работ; г) создание и обучение совместной рабочей группы.

95 2. Проведение обследования деятельности автоматизируемой орга- низации (объекта), в рамках которого осуществляются: а) предварительное выявление требований к будущей системе; б) определение структуры организации; в) определение перечня целевых функций организации; г) анализ распределения функций по подразделениям и сотрудникам; д) выявление функциональных взаимодействий между подразделения- ми; е) установление информационных потоков внутри подразделений и ме- жду ними; ж) выявление внешних по отношению к организации объектов и внеш- них информационных воздействий; з) анализ существующих средств автоматизации деятельности органи- зации.
3. Построение модели деятельности организации (объекта), преду- сматривающее обработку материалов обследования и построение двух видов моделей: а) модели “AS - IS” (“как есть”), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, ка- ким образом работает данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации; б) модели “TO - BE” (“как должно быть”), отражающей представление о новых технологиях работы организации.
Каждая из моделей должна включать полную функциональную и информационную модель деятельности организации, а также (при необ- ходимости) модель, описывающую динамику поведения организации.
Заметим, что построенные модели имеют самостоятельное практиче- ское значение, независимо от того, будет ли на предприятии разрабаты- ваться и внедряться информационная система, поскольку с их помощью можно обучать сотрудников и совершенствовать бизнес-процессы предприятия.
Результатом завершения стадии формирования требований к ПО яв- ляются: спецификации ПС, функциональные, технические и интерфейс- ные спецификации, для которых подтверждена их полнота, проверяе- мость и осуществимость.
Стадия проектирования включает следующие этапы:
1. Разработку системного проекта ПС. На этом этапе дается ответ на вопрос ”Что должна делать будущая система?”, а именно определяется архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и систе- мой, требования к программным и информационным компонентам, со- став исполнителей и сроки разработки, план отладки ПО и контроль качества.
Основу системного проекта составляют модели проектируемой сис- темы, которые строятся на модели “TO - BE”. Результатом разработки системного проекта должна быть одобренная и подтвержденная специ-
фикация требований к ПС: функциональные, технические и интерфейс-

96 ные спецификации, для которых подтверждена их полнота, проверяе- мость и осуществимость.
2. Разработку детального (технического) проекта. На этом этапе осуще- ствляется собственно проектирование ПС, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, да- ется ответ на вопрос: “Как построить систему, чтобы она удовлетворяла требованиям?”
Результатом детального проектирования является разработка вери-
фицированной спецификации ПС, включающей [6,20]: формирование иерархии программных компонентов, межмодульных интерфейсов по данным и управлению; спецификация каждого компонента ПС, имени, назначения, предпо- ложений, размеров, последовательности вызовов, входных и выход- ных данных, ошибочных выходов, алгоритмов и логических схем; формирование физической и логической структур данных до уровня отдельных полей; разработку плана распределения вычислительных ресурсов (времени центральных процессоров, памяти и др.); верификацию полноты, непротиворечивости, осуществимости и обоснованности требований; предварительный план комплексирования и отладки, план руково- дства для пользователей и приемных испытаний.
Завершением стадии детального проектирования является сквозной контроль проекта или критический поблочный анализ проекта.
Стадия реализации предусматривает выполнение следующих работ:
1. Разработку верифицированной детальной спецификации каждой под- программы (блока не более чем из 100 исходных команд языка высоко- го уровня).
Внешние спецификации должны содержать следующие сведения: имя модуля, указывается имя, применяемое для вызова модуля (для модуля с несколькими входами для каждого входа должны быть от- дельные спецификации); функция – дается определение функции или функций, выполняемых модулем; список параметров (число и порядок следования), передаваемых мо- дулю; выходные параметры – точное описание всех данных, возвращаемых модулем (должно быть определено поведение модуля при любых входных условиях); внешние эффекты (печать сообщения, чтение запроса с терминала и т. п.).
2. Проектирование логики модулей и программирование (кодирование) модулей.
3. Проверку правильности модулей.
4. Тестирование модулей.
5. Описание базы данных до уровня отдельных параметров, символов и битов.

97 6. Разработку план приемных испытаний.
7. Разработку руководства пользователю.
8. Предварительный план комплексирования и отладки.
Содержание последующих стадий в основном совпадает с соответст- вующими процессами ЖЦ ПС. Вообще технологические стадии выде- ляются исходя из соображений разумного и рационального планирова- ния и организации работ. Возможный вариант взаимосвязи и стадий работ с процессами ЖЦ ПО [7,18]показан на рис. 3.3.
Рис. 3.3. Вариант взаимосвязи и стадий работ с процессами ЖЦ ПО