Тема 15. Принципы стандарта ISO/IEC. Принципы стандарта ГОСТ 34.

⇐ ПредыдущаяСтр 6 из 6

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

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

Согласно ISO 12207, система – это объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для удовлетворения определенных потребностей или целей.

Примечание.

В отличие от CDM фирмы Oracle, стандарт ISO 12207 в равной степени ориентирован на организацию действий каждой из двух сторон: поставщика (разработчика) и покупателя (пользователя); он может быть применен и в том случае, когда обе стороны относятся к одной организации.

Особенности стандарта ISO 12207

Все сказанное выше позволяет сформулировать некоторые особенности стандарта ISO 12207.

• Стандарт ISO 12207 имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и решения задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовать любую модель жизненного цикла.

Примечание.

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

• Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами информационных систем. Адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.

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

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

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

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

Тема 16. Структура средств коллективного проектирования. Методы и средства. Идентификация

Создание крупных ИС требует согласованной работы целой группы программистов.

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

1 Регистрация всех изменений, вносимых в проект;

2 Централизованного хранения файлов проекта.

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

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

· Идентификацию состояния как отдельных компонентов, так и проекта в целом;

· Контроль за вносимыми в компоненты и структуру проекта изменениями;

· Координированное управление всеми составляющими проекта.

Идентификация

Чтобы осуществлять управление объектами, необходимо их идентифицировать. При идентификации объектов в системах PVCS используется понятие версии. Версией проекта называется некий уникальный идентификатор, обозначающий текущий номер разработки. Так как в отдельные составляющие проекта во время разработки могут вноситься изменения, каждому из объектов, помещенных в PVCS-хранилище, присваиваются идентификаторы версий самого объекта и проекта в целом. Это позволяет определить, какие именно файлы должны быть использованы для сборки заданной версии приложения.

Тема 17. Хранение файлов и контроль за изменением файлов. Блокировки. Последовательность работы с PVCS.

Хранение файлов и контроль за их изменением

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

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

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

Блокировки

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

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

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

Последовательность работы

Последовательность операций, выполняемых при использовании системы PVCS:

1. Ввод исходной операции о структуре проекта и его составляющих. Создание первой версии проекта в PVCS-хранилище.

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

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

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

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

Существует множество инструментов, предназначенных для контроля версий проектов. Наиболеепопулярны StarTeam, TeamSourse, Microsoft Visual Sourse Safe QSC Team Conerence.

⇐ Предыдущая 1 2 3 4 56