Программная инженерия

Лекция 7. Планирование жизненного цикла программных средств

—описание методов идентификации компонентов, на которые ока­ зывает воздействие модификация ПС, и измененные части исполняемого объектного кода.

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

—описание процессов управления конфигурацией в жизненном цик­ ле ПС, которые обеспечат выполнение задач сопровождения;

—описание среды управления конфигурацией, которую следует ис­ пользовать, включая процедуры, инструментальные средства, методы, стан­ дарты, организационные соглашения и интерфейсы;

—идентификацию отчетов о дефектах и ошибках программного про­ дукта и процессов жизненного цикла; метод закрытия отчетов об ошибках

ивзаимодействия с контролем изменений;

—архивацию версий; применение методов и средств формирования версий и обеспечения их сохранности.

Цель планирования технологической среды жизненного цикла ПС

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

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

—плана подготовки и обучения пользователей для квалифицирован­ ной эксплуатации версий ПС;

—плана обслуживания пользователей в процессе эксплуатации ПС;

190

7.2.Задачи планов для обеспечения жизненного цикла сложных программных средств

—плана организации переноса и установки версий ПС на различные аппаратные и операционные платформы пользователей.

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

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

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

Впроверку проекта могут входить: анализ выходных проектных дан­ ных; демонстрации прототипов и моделей, а также результатов их тести-

191

Лекция 7. Планирование жизненного цикла программных средств

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

7.3. Планирование процессов управления качеством сложных программных средств

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

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

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

192

7.3. Планирование процессов управления качеством сложных программных средств

ISO 10005, ISO 10006, ISO 10013, поддерживающие базовые стандарты менеджмента качества серии ISO 9000 (см. лекцию 3).

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

Организационной основой управления качеством ПС на базе стандар­ тов ЖЦ является план обеспечения заданных характеристик качества

на всех этапах жизненного цикла комплекса программ (см. лекцию 11). Для этого до начала разработки в процессе формирования требований технического задания следует сформулировать основные положения ме­ тодики обеспечения качества, поэтапных испытаний компонентов и опре­ деления достигнутых значений характеристик, допустимых для продолже­ ния работ на следующих этапах. Такой план целесообразно создавать для сложных проектов ПС на этапах системного анализа, разработки требова­ ний технического задания и проектирования. На этих этапах оформляются первичные требования к характеристикам и качеству ПС и, соответствен­ но, должна планироваться совокупность мероприятий, обеспечивающих их достижение в процессе последующего проектирования. В плане управ­ ления качеством /7С должны быть отражены:

— цели управления качеством, номенклатура и требования к значе­ ниям характеристик качества, область действия требований и условия их применения;

193

Лекция 7. Планирование жизненного цикла программных средств

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

—организация разработчиков и технология создания ПС; утвержден­ ные обязанности специалистов по обеспечению качества, их ответствен­ ность и полномочия на утверждение программных компонентов и доку­ ментов;

—ресурсы, базовые документы и стандарты, используемые для обес­ печения качества на всех этапах разработки;

—средства автоматизации разработки, обеспечивающие достижение

иизмерение заданных свойств и значений характеристик качества;

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

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

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

194

7.3. Планирование процессов управления качеством сложных программных средств

требования к характеристикам качества сложных ПС последователь­

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

понимания задач проекта как заказчиком, так и разработчиком.

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

—анализ контракта и спецификаций требований заказчика к ПС, выделение и ранжирование приоритетов характеристик и атрибутов каче­ ства конечного продукта;

—декомпозицию требований к характеристикам качества по контро­ лируемым этапам и компонентам разработки и создание разделов по де­ тальным требованиям к атрибутам качества в спецификациях на программ­ ные компоненты и ПС в целом;

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

—разработку методик контроля соблюдения стандартов, правил тех­ нологии проектирования и системы обеспечения качества жизненного цикла программных средств;

—создание методов, методик и средств объективного измерения свойств и/или значений атрибутов характеристик качества программных компонентов на этапах их создания и всего ЖЦ ПС для испытаний заказ­ чиком и эксплуатации пользователями;

—организацию, обучение и стимулирование коллектива специалис­ тов на создание компонентов и ПС в целом, в максимальной степени

195

Лекция 7. Планирование жизненного цикла программных средств

удовлетворяющих требования заказчиков и пользователей к характерис­ тикам качества.

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

В стандарте ISO 15504 (раздел MAN.3) процесс планирования и управления качеством 77С концентрируется на мониторинге качества про­ дуктов и процессов как проекта, так и предприятия в целом. В результате успешной реализации процессов в проекте должно быть обеспечено:

—на основе явных и неявных требований потребителя необходимо определить цели по качеству продукта и процессов, которые следует оце­ нивать, предпочтительно количественным образом, для различных конт­ рольных точек в жизненном цикле ПС;

—определить общую стратегию на уровне проекта ПС и предприя­ тия, помогающие аттестовать достижение соответствующих целей по ка­ честву, определяя количественную меру результатов деятельности по про­ екту и критерии их приемки;

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

—проводить идентифицированные виды деятельности по контролю

иобеспечению качества и подтверждать их выполнение;

—по ходу реализации проекта в контрольных точках жизненного цикла ПС применять заданные метрики качества для аттестации достиже­ ния соответствующих целей по качеству;

—в случаях, когда заданные цели по качеству не достигаются, при­ менять корректирующие или предотвращающие мероприятия, которые мо-

196

Л Е К Ц И Я 8

ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ

8.1. Задачи и особенности объектно-ориентированного проектирования программных средств

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

ты внутри деталей описаний объекта.

Объектно-ориентированное проектирование представляет собой стра­ тегию, в рамках которой программная система состоит из взаимодейству­ ющих объектов, имеющих собственное локальное состояние и способных

198

8.1. Задачи и особенности объектно-ориентированного проектирования...

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

Общий процесс объектно-ориентированного проектирования состоит из нескольких крупных этапов:

—определение рабочего окружения системы и разработка моделей

ееиспользования;

—проектирование архитектуры программной системы;

—определение и идентификация основных объектов системы;

—разработка модели архитектуры комплекса программ;

—определение и документирование интерфейсов объектов.

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

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

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

Основные понятия ООП включают:

— при объектно-ориентированном проектировании основные компо­ ненты программной системы представляются как объекты со своими со­ стояниями и операциями;

199