Стандарты проектирования информационных систем

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Стандарты проектирования информационных систем

2. Международный стандарт ISO/IEC 12207: 1995-08-01. и Стандарты комплекса ГОСТ 34 на создание и развитие АС

3. Основы методологии проектирования ИС и жизненный цикл по ИС

4. Методологии и технологии проектирования ИС

Заключение

Список использованной литературы



Введение

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

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

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



1. Стандарты проектирования информационных систем

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

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

*потребителям информационных систем (ИС) -- для выбора техники, для упорядочения своей деятельности и взаимодействия с поставщиками;

*поставщикам продуктов и услуг - для снижения себестоимости продукции и следования требованиям рынка;

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

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

В качестве примеров рассмотрим следующие стандарты:

1. Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения (ПО).

2. Стандарты комплекса ГОСТ 34 на создание и развитие АС.

3. Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, расчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.

2. Международный стандарт ISO/IEC 12207: 1995-08-01

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

- по предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);

- по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT ), фирменные стандарты (Microsoft ODBC, IBM SNA);

- по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель".

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

- степени обязательности для организаций разного типа;

- конкретности и детализации содержащихся требований;

- открытости и гибкости, адаптируемости к конкретным условиям.

Международный стандарт ISO/IEC 12207: 1995-08-01

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

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

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

В стандарте описаны 5 основных процессов ЖЦ ПО: процесс приобретения, процесс поставки, процесс разработки, процесс функционирования, процесс сопровождения. Описаны 8 вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО. Вспомогательные процессы это процессы - решения проблем, документирования, управления конфигурацией, гарантирования качества, последний из которых использует результаты остальных процессов группы обеспечения качества, в которую входят: процесс верификации, процесс аттестации, процесс совместной оценки, процесс аудита. Описаны 4 организационных процесса: процесс управления, процесс создания инфраструктуры, процесс усовершенствования, процесс обучения. К ним примыкает особый процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта.

Каких - либо этапов, фаз, стадий не предусмотрено, что дает хорошую степень адаптивности.

Особенности стандарта:

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

Примеры:

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

- в Процессе поставки поставщик должен управлять субподрядчиками согласно Процессу приобретения и выполнять верификацию и аттестацию по соответствующим процессам;

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

Такой характер позволяет реализовывать любую модель ЖЦ.

2. Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.

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

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

- рассматривается область применения системы для определения требований системы;

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

- квалификация требований системы должна быть документирована.

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

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

- внешние связи (интерфейсы) с единицей программного обеспечения;

- требования квалификации;

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

- спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;

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

- определение данных и требований базы данных;

- установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);

- документация пользователя;

- работа пользователя и требования выполнения;

- требования сервиса пользователя.

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

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

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

6. Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать БД вовсе.

Стандарты комплекса ГОСТ 34 на создание и развитие АС.

Эти стандарты на создание и развитие АС -- обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. ГОСТ 34.601--90 распространяется на АС и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание работ на каждом этапе. Стадии и этапы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла. Изначально ГОСТ34 задумывался в конце 1980-х годов как всеобъемлющий комплекс взаимосвязанных межотраслевых документов. Объектами стандартизации являются АС различных видов и все виды их компонентов, а не только ПО и базы данных(БД). Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO 12207 предусмотрено, что заказчик может разрабатывать АС для себя самостоятельно (если создаст для этого специализированное подразделение). Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается, исходя из этого содержания.

В стандарте описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно, и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ 34 и ISO 12207.

Перечень документов согласно ГОСТ 34, который должен фиксировать результаты проведенных работ. Жизненный цикл процесса создания АСУ согласно ГОСТ 34 (ГОСТ 34.601-90) включает следующие стадии:

Разработка концепции АС

Техническое задание

Эскизный проект

Технический проект

Рабочая документация

Ввод в действие

Сопровождение АС

Формирование требований к АС - На начальном этапе создания АС согласно требованиям ГОСТ 34 необходимо проведение обследования объекта автоматизации. В рамках обследования происходит сбор и анализ данных об организации, производственной структуре и функционировании объекта автоматизации. Обследование также должно провести анализ автоматизированных систем, уже функционирующих в рамках объекта автоматизации.

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

Стандартом для разработки данного документа является ГОСТ 34.602-89, регламентирующий содержание разделов и стиль изложения в ТЗ.

Рабочая документация - Данный этап подразумевает разработку рабочей документации на АС или ее части. Данный пакет документов также согласовывается с заказчиком в индивидуальном порядке и фиксируется в ТЗ. Зачастую пакет рабочей документации ограничивается следующими документами:

Руководство пользователя (администратора)

Инструкция по эксплуатации КТС

Общее описание системы (в случае присутствия документа «Пояснительная записка к техническому (эскизному) проекту» данный документ нецелесообразен так большинство разделов дублируются)

Программа и методика испытаний

Ввод в действие - Стадия ввода в действие АС согласно ГОСТ 34 включает подготовку комплекса технических средств, проведение пусконаладочных работ и обучение персонала. Перед вводом АС в эксплуатацию производятся предварительные испытания, по результатам которых формируется «Протокол испытаний». Протокол фиксирует все замечания к системе, порядок и сроки их устранения, и подтверждает ее готовность к вводу в опытную эксплуатацию.

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

Сопровождение АС - Этап сопровождения АС подразумевает выполнение работ по гарантийному и послегарантийному обслуживанию системы.

3. Основы методологии проектирования ИС и жизненный цикл по ИС

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

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

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

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

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

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

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

Модели жизненного цикла ПО

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

каскадная модель (70-85 г.г.); спиральная модель (86-90 г.г.).

4. Методологии и технологии проектирования ИС

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

Технология проектирования определяется как совокупность трех составляющих:

*пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);

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

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

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:

*технология должна поддерживать полный ЖЦ ПО;

*технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

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

*технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

*технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

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

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

*стандарт проектирования;

*стандарт оформления проектной документации;

*стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

*набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

Стандарт оформления проектной документации должен устанавливать:

*комплектность, состав и структуру документации на каждой стадии проектирования;

*требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

*требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

*правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

*правила использования клавиатуры и мыши;

*правила оформления текстов помощи;

*перечень стандартных сообщений;

*правила обработки реакции пользователя.



Заключение

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

*не тратить лишних средств на закупку нестандартного оборудования и приобретение вместе с ним дополнительных проблем;

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

*потребителям информационных систем (ИС) -- для выбора техники, для упорядочения своей деятельности и взаимодействия с поставщиками;

*поставщикам продуктов и услуг - для снижения себестоимости продукции и следования требованиям рынка;

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

Стандарты должны соблюдаться на международном уровне, государственном уровне или на уровне отрасли

Список использованной литературы

1. Избачков С.Ю., Петров В.Н. Информационные системы-СПб.: Питер, 2008. - 655 с

2. #"#">http://www.intuit.ru

3. http://www.emanual.ru

4. Общие требования к методологии и технологии

5. https://ru.wikipedia.org/wiki/ISO/IEC_12207:2008

6. http://it-gost.ru/content/view/93/51/

Размещено на Allbest.ru