ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения. Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.

Стандарты РФ (ГОСТ Р) на документирование ПС

Помимо действующих стандартов ЕСПД и СОИ (Системы обработки информации) в РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО.

ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990 и устанавпивает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.

ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается «набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается». Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС.

ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. Стандарт полностью соответствует международному стандарту ИСО 9127:1989. В контексте настоящего стандарта под потребитепьским программным пакетом (ПП) понимается «программная продукция, спроектированная и продаваемая для выпопнения опредепенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое». Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП.

ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления. Описывает представление процедурных алгоритмов.

техническое задание.

критерии

Отладка.

Исполнение.

54. Объектно - ориентированное проектирование программного обеспечения на предпроектной стадии (с применением диаграмм использования и классов).

Предпроектное обследование [predesign inspection ]- Сбор и обработка сведений об организации и особенностях функционирования объекта автоматизации, включая данных о его взаимодействии с внешней средой и другими объектами, а также выполнение системного анализа, разработка технико-экономического обоснования целесообразности автоматизации и выработка общих требований на разработку автоматизированной системы. Содержание работ при предпроектном обследовании объекта автоматизации соответствует стадии “Формирование требований к АС” ГОСТ 34.601-90, этапы: “ Обследование объекта и обоснование необходимости создания АС”, “Формирование требований пользователя к АС”, “Оформление отчёта о выполненной работе и заявки на разработку АС - тактико-технического задания”

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

Рис.1 Диаграмма Вариантов Использования для ATM

Ha диаграмме представлено взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Диаграммы показывают, какие действую­щие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. В сущности, диаграмма Вариантов Использования может иллюстрировать требования к системе. В нашем примере клиент банка инициирует различ­ные варианты использования: Снять деньги со счета, Перевести деньги, Положить деньги на счет, Показать баланс, Изменить идентификационный номер, Произвести оплату. Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Произвести оплату" идет стрелка к Кредитной системе. Действующими лицами могут быть и внешние системы, в данном случае Кредитная система показана именно как действующее лицо — она является внешней для системы ATM. Стрелка, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке.

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

Диаграммы Классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов . Например, счет клиента — это объект. Типом такого объекта можно считать счет вообще, т.е. "Счет" (Account) — это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Так, класс Account содержит идентификационный номер клиента и проверяющие его действия. На диаграмме Классов класс создается для каждого типа объектов из диаграмм Последовательности или Кооперативных диаграмм. Диаграмма Классов для варианта использования "Снять деньги" показана на рис.

Рис.4 Диаграмма Классов для варианта использования "Снять деньги" системы ATM

На диаграмме показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM.Screen (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диа­грамме Классов изображается в виде прямоугольника, разделенного на три части. В первой части ука­зывается имя класса, во второй — его атрибуты. Атрибут — это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). Для класса Account определены четыре операции: Open (открыть), Withdraw Funds (снять деньги), Deduct Funds (вычесть сумму денег из счета) и Verify Funds (проверить наличие денег).