Стандарт по

Стандарты и шаблоны для ТЗ на разработку ПО

Стандарт по

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её.

Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел.

Придется сделать такую статейку самому… И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification): • Гост 34 • Гост 19 • IEEE STD 830-1998 • ISO/IEC/ IEEE 29148-2011 • RUP • SWEBOK, BABOK и пр.

Гост 34

Гост 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно Гост 34 техническое задание должно включать следующие разделы: 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6.

Порядок контроля и приемки системы 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 8. Требования к документированию 9.

Источники разработки При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.

Гост 19

“Гост 19.

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

Согласно Гост 19.201-78 Техническое задание, требования и оформлению техническое задание должно включать следующие разделы:

1. Введение; 2. Основания для разработки; 3. Назначение разработки; 4. Требования к программе или программному изделию; 5. Требования к программной документации; 6. Технико-экономические показатели; 7. Стадии и этапы разработки; 8. Порядок контроля и приемки; 9. Приложения. Естественно Гост 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании: Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS.

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

  • 1. Назначение
  • 2. Область действия
  • 3. Определения, акронимы и сокращения
  • 4. Ссылки
  • 5. Краткий обзор

2. Общее описание

  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователя
  • 4. Ограничения
  • 5. Допущения и зависимости

3.

Детальные требования (могут быть организованы по разному, н-р, так)

  • 1. Требования к внешним интерфейсам
    • 1. Интерфейсы пользователя
    • 2. Интерфейсы аппаратного обеспечения
    • 3. Интерфейсы программного обеспечения
    • 4. Интерфейсы взаимодействия
  • 2. Функциональные требования
  • 3.

    Требования к производительности

  • 4. Проектные ограничения (и ссылки на стандарты)
  • 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
  • 6. Другие требования

4. Приложения 5.

Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований: • System requirements specification (SyRS) • Software requirements specification (SRS) System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека.

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

Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в Гост 34. SyRS может содержать следующие разделы: 1. Введение

  • 1. Назначение системы
  • 2. системы (границы системы)
  • 3. Обзор системы
    • 1. системы
    • 2. Функции системы
    • 3. Характеристики пользователей
  • 4. Термины и определения

2. Ссылки 3. Системные требования

  • 1. Функциональные требования
  • 2. Требования к юзабилити
  • 3. Требования к производительности
  • 4. Интерфейс (взаимодействие) системы
  • 5. Операции системы
  • 6. Состояния системы
  • 7. Физические характеристики
  • 8. Условия окружения
  • 9. Требования к безопасности
  • 10. Управление информацией
  • 11. Политики и правила
  • 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
  • 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в Гост 19, а по структуре очень напоминает SRS из стандарта IEEE 830. SRS может содержать следующие разделы: 1.

Введение

  • 1. Назначение
  • 2. (границы)
    • 3. Обзор продукта
    • 1. Взаимодействие продукта (с другими продуктами и компонентами)
    • 2. Функции продукта (краткое описание)
    • 3. Характеристики пользователей
    • 4. Ограничения
  • 4. Термины и определения

2. Ссылки 3. Детальные требования

  • 1. Требования к внешним интерфейсам
  • 2. Функции продукта
  • 3. Требования к юзабилити
  • 4. Требования к производительности
  • 5. Требования к логической структуре БД
  • 6. Ограничения проектирования
  • 7. Системные свойства ПО
  • 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3) 5. Приложения

  • 1. Предположения и зависимости
  • 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт. • Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases): 1. Введение.

  • 1. Цель.
  • 2. Краткая сводка возможностей.
  • 3. Определения, акронимы и сокращения.
  • 4. Ссылки.
  • 5. Краткое содержание.

2. Обзор системы

  • 1. Обзор вариантов использований.
  • 2. Предположения и зависимости.

3. Детальные требований

  • 1. Описание вариантов использования.
  • 2. Дополнительные требования.
  • 3. Другие функциональные требования.
  • 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр.

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

А как же agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места. Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

https://www.youtube.com/watch?v=NSKJhs3jTJk

Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

Также рекомендую ознакомиться со следующими материалами: Hubs:

  • System Analysis and Design

Ads AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Источник: https://habr.com/en/post/328822/

Гост p, din, iso, en – что это такое, и какие есть отличия?

Стандарт по

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

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

Особенности и разновидности систем стандартизации

Для начала стоит разобраться с особенностями и разновидностями самих стандартов, а после разобрать каждый из них.

На упаковках товаров можно встретить следующие стандарты:

  • ГОСТ и ГОСТ P — межгосударственный и государственный (только на территории РФ) стандарты. Встретить такое обозначение можно на всех товарах, производимых на территории России, и некоторых других стран СНГ.
  • DIN — госстандарт Германии, которые начал действовать еще с начала XIX века (1917 год). Используется исключительно на территории страны, хотя и упоминается в других европейских странах.
  • ISO — международная система стандартов, которая была введена в действие в 1946 году самой Международной организации по стандартизации. На данный момент количество стран, которые являются членами этой организации, составляет более 160.
  • EN — региональная система, которая используется в первую очередь в Великобритании, и других европейских странах, членах Евросоюза.

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

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

Если говорить простыми словами — трубная резьба по ISO 7 будет одинаковой во всех странах, чьи производители используют этот стандарт, поэтому не возникнет никаких проблем со стыковкой изделий двух разных брендов.

Теперь давайте углубимся в особенности каждой системы стандартов.

Международная система стандартов ISO

International Organization for Standardization— была создана в 1946 году, и на данный момент является единственной системой международных стандартов, принятой более чем 160 странами.

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

В зависимости от полномочий, представители ISO разделяются на несколько групп:

  • Подписчики — не могут разрабатывать стандарты и принимать стратегии развития, но получают полную и своевременную информацию о её работе. Не имеют права продажи и принятия стандартов на национальном уровне.
  • Корреспонденты — участвуют в заседаниях в качестве наблюдателя при разработке и принятии стандартов, при этом имеют право продажи и принятия стандартов на национальном уровне.
  • Полноправные члены — непосредственно участвуют в аниях в процессе рассмотрения и принятия стандартов, а также имеют право внедрять их на национальном уровне.

Узнать еще больше информации о членах, их полномочиях и особенностях стандартизации можно на сайте организации.

ГОСТ и ГОСТ Р — российский государственный стандарт

Стандарт ГОСТ является межгосударственным, а ГОСТ Р — национальный (государственный) стандарт. Для контроля создано Федеральное агентство по техническому регулированию и метрологии, соответственно, как следует из названия, учреждение занимается не только разработкой и внедрением стандартов, но и контролем их соблюдения.

Основные направления деятельности:

  • Классификация и каталогизация стандартов.
  • Государственный контроль.
  • Контроль соответствия.
  • Метрология.
  • Техническое регулирование.

Как и другие страны, ГОСТ и ГОСТ Р приняли направление на унификацию с международными стандартами ISO, поэтому некоторые ГОСТ уже сейчас носят рекомендательный характер, или вовсе выводятся из эксплуатации.

  • Заказать молоток кровельщика: https://.cc/atLPMT
  • Заказать ножовку по дереву https://.cc/atGoMG
  • Заказать ключ разводной https://.cc/atDvG5

EN — региональные европейские стандарты и стандарты DIN

Разработкой этих стандартов занимается несколько организаций — CEN, CENELEC и ETSI, благодаря чему достигается качественная проработка всех нюансов. Эту систему стандартизации практически не встретить на отечественном рынке, поэтому не стоит уделять ей много внимания.

https://www.youtube.com/watch?v=UjTT_9bbCQI

Если же говорить о системе DIN — контролирующая организация была создана ещё в 1917 го, и функционирует до сих пор. Как и другие системы, «din» сейчас также находится на этапе унификации с ISO, хотя многие европейские производители продолжают использовать спецификации именно госстандарта Германии.

Особенности унификации стандартов

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

Таким образом возник ряд переходных систем:

  • ГОСТ Р ИСО — стандарт основывается на нормах ISO, но используется только на территории Российской Федерации.
  • EN ISO — практически не измененный международный стандарт, который используется в Европе.
  • DIN ISO, DIN EN — принятие без каких-либо изменений стандарты ИСО и EN в Германии.
  • DIN EN ISO — разработан совместными усилиями CEN и ISO и принятый в Германии.

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

Источник: https://zen.yandex.ru/media/vira_tools/gost-p-din-iso-en-chto-eto-takoe-i-kakie-est-otlichiia-5f1570e8b36146186d781645

Стандарты в области программного обеспечения

Стандарт по

В Толковом словаре по информатике В.И. Першикова и ИМ.

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

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

Такие стандарты регламентируют взаимодействие между раз­личными программами. Для этого предназначены стандарты меж­программного интерфейса, например ОLE (Оbject Linking and Embedding — связывание и встраивание объектов). Без таких стандартов программные продукты были бы «закрытыми» друг для друга.

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

Более 1000 стандартов или уже приняты этими организациями, или находятся в процессе разработки.

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

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

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

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

Для этого разработаны стандарты на пользовательский интерфейс — GUI(Graphical User Interfase). Все это регламентируется стандартами, действующими в сфере информационных технологий.

Необходимость стандартизации разработки программного обеспечения наиболее удачно описана во введении в стандарт ISO/IEC 12207: «Программное обеспечение является неотъемлемой частью информационных технологий и традиционных систем, таких, как транспортные, военные, медицинские и финансовые' Имеется множество разнообразных стандартов, процедур, мето­дов, инструментальных средств и типов операционной среды для разработки и управления программным обеспечением. Это раз­нообразие создает трудности при проектировании и управлении программным обеспечением, особенно при объединении про­граммных продуктов и сервисных программ. Стратегия разра­ботки программного обеспечения требует перехода от этого мно­жества к общему порядку, который позволит специалистам, прак­тикующимся в программном обеспечении, «говорить на одном языке» при разработке и управлении программным обеспечени­ем. Этот международный стандарт обеспечивает такой общий порядок».

Попробуем внести порядок в многообразие стандартов, дей­ствующих в сфере ИТ, и классифицировать их (рис. 1.3).

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

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

https://www.youtube.com/watch?v=M1oinnSzwB4

Одна из главных причин значимости современной програм­мы стандартизации — осознание опасности злоупотребления стандартами «де-факто».

В 60-е и 70-е годы XX века создание стандартов «де-факто»ставило пользователей в зависимое от про­изводителей положение при использовании основных средств об­работки данных и телекоммуникаций.

Важный аспект сегодняш­ней работы по стандартизации — преодоление этой зависимости через продвижение стандартных интерфейсов. Долгое время такими стандартами были SQL (Structured Query Language) и язык диаграмм Д. Росса SADT (Structured Analysis and Design Technique).

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

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

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

Стандарты ОSI (Open System Interconnection reference model), Ethernet, POSIX, SQL и большинство стандартов языков — примеры такого рода стандартов.

В качестве примера перехода стандарта «де-факто» в стандарт «де-юре» рассмотрим историю развития и стандартизации языка SQL.

Работы по созданию языка SQL были начаты в 70-х годах прошлого столетия в исследовательских лабораториях компании IВМ.

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

Несмотря на то, что он был коммерчески реализо­ван в начале 80-х годов лишь для небольшой группы программ­ных продуктов, SQL, бесспорно, получил признание с принятием АNSI и ISOстандарта SQL-86. Позднее, при подготовке стан­дарта SQL-89, в язык был включен ряд дополнительных возмож­ностей.

Истоки SQL следует отнести к периоду рождения реляцион­ной модели данных (описанной в статье Э.Ф. Кодда) [65].

По­скольку в течение нескольких последующих лет не появилось ни­каких языков, подобных SQL, в исследовательских проектах, ини­циированных компанией 1ВМпосле публикации статьи Э.Ф.

Кодда, придавалось особое значение необходимости создания языков интерфейса создаваемых СУБД для проверки возможнос­тей реляционной модели. Историю разработки языка SQL иллю­стрирует рис. 1.4.

Ожидаемое

Принятие SQL3

Работа над

SQL 3

Работа над

SQL 2

(SQL. 92)

SQL -89

SQL -86

Работа комитета

по стандартами

над SQL

Появление

Коммерческих

SQL -продуктов

Появление

реляционной Прототипы, основанные наSQL

модели

1970 1975 1980 1985 1990 1995 2000

Рис. 1.4.Схема истории и истоков SQL

В исследовательских лабораториях IBM в начале 70-х годов 20 века одновременно с работой над будущим языком SQL раз­рабатывались и другие проекты по созданию и эксперименталь­ной реализации реляционных языков.

Вероятно, наиболее извес­тным из них является созданный М. Злуфом из лаборатории IВМ в Йорктаун-Хейтс примерно в одно и то же время с SEQUEL (ранней версией SQL) реляционный язык Query-By-Example (QВЕ).

Этот язык используется в настоящее время во многих коммерчес­ких программных продуктах наряду с SQL.

В 1974 г. Дональд Д. Чамберлин из Исследовательской лабо­ратории IВМ в Сан-Хосе предложил спецификации реляционно­го языка, названного SEQUEL (Structured English QUEry Language). Пересмотренная версия этого языка (SEQUEL /2) была разработана в 1976—1977 годах, и он приобрел свое окончатель­ное название — SQL (Structured Query Language).

Еще перед тем, как коммерческие продукты IВМ в начале 80-х годов 20 века вышли на рынок программного обеспечения, ком­пания Relation Software Inc. (называющаяся теперь Огас1е Corporation) объявила о выпуске реляционной СУБД, основан­ной на языке SQL. Эта система в результате ее эволюции стала одной из доминирующих коммерческих систем и носит название ORACLE.

Продукт ORACLE с его языком SQL столкнулся с конкурен­цией в сфере средних ЭВМ и мини-ЭВМ со стороны продуктов ряда других разработчиков, в частности СУБД Ingres с языком QUEL компании Relation Technology Inc., а также продукта Rdb/ VMS с языком RDML компании Digital Equipment Corporation.

Одной из причин преуспевания SQL послужило формирование Американским национальным институтом стандартов (American National Standarts Institute, ANSI) комитета ХЗН2, учрежденного для разработки стандартов языков баз данных.

Представитель IВМ предложил использовать в качестве предварительных специфика­ций реляционного языка результаты ранее проведенной IВМ ра­боты над SEQUEL/2, и разработчики стандарта приступили к ра­боте.

Документ, озаглавленный «SQL», представлял собой по боль­шей части трактат о различных формах SQL , используемых в коммерческих программных продуктах.

Международная организация по стандартизации (International Standarts Organization, ISO) в рамках технического комитета ТС97 (называемого теперь как ISO/IЕС JTC1) также вела работу по

созданию стандарта языков реляционных баз данных. В середине 80-х годов как АNSI, так и ISO одобрили стандарты SQL (ANSI — в 1986 г., а ISO — в начале 1987 г.).

Первый стандарт SQL в связи со способом его разработки был весьма неполным в части функциональных возможностей систем ,и'| данных, и многие из поставщиков продолжали вносить в свои Программные продукты большой ряд расширений к стандарту. В ЧК9 I. была принята пересмотренная версия стандарта SQL, которая отличалась от стандарта 1986 г. главным образом именно возможностями поддержки целостности по ссылкам.

Однако еще до 1989 г. как в ANSI, так и в ISO началась работа по радикальным расширениям SQL. Эта работа, первоначально днем инфицированная как «SQL2», началась в 1987 г., и ее результаты были спустя пять лет приняты в качестве стандарта SQL -92.

Добавляет путаницы еще и то обстоятельство, что работа над

SQL 2 перекрывалась работой над SQL З, новой версией стандар­та SQL, которая еще до сих пор находится в стадии разработки. Работа над SQL 3 началась еще в 1990 г.

параллельно с SQL2, глав­ным образом как над «запасным резервуаром» для возможнос­тей, которые предполагалось не включать по тем или иным при­чинам в SQL 2.

SQL З включает объектно-ориентированные рас­ширения языка, а также дополнительные реляционные возмож­ности, которым не нашлось места в SQL 2 [53].

Проиллюстрируем на рис. 1.5 с привязкой к оси времени про­цесс разработки различных стандартов SQL.

Работа над SQL3

Работа над SQL – 92 (SQL2) Значительные

Изменения стандарта

(SQL -92)

Начальное Первый стандарт SQL Добавлена целостность

Предложение (SQL -86) по ссылкам (SQL – 89)

1984 1986 1989 1992

Рис. 1.5. Схема истории стандартизации SQL

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

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

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

Во втором случае компании — разработчики ПО разрабатывают каждая свое решение, и самое популярное, массовое с точки зрения частоты использования решение обретает статус стандарта (необязательно юридически).

Так, SQL стал стан­дартом языка обращения к базам данных, что называется «де-факто», хотя потом статус стандарта был закреплен юридически.

Недостаток этого подхода состоит в том, что стандартом ста­новится не самое сильное, а самое массовое коммерческое решение.

В качестве еще одного примера появления стандарта можно привести появление ныне популярного UML — Unified Modeling Language. Основные разработки по методам объектно-ориенти­рованного анализа и проектирования появились между 1988 и 1992 гг. К 1994 г.

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

Команда из ОМG пыталась рассмотреть проблему стандартизации, но в ответ получила открытое письмо с протестом от всех авторов. В 1996 г.

три ведущих специалиста в области объектно-ориентированного анализа и проектирования Джеймс Рамбо ( James Rumbaugh), Гради Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) объедини­лись, и появился на свет Унифицированный метод версии 0.8, в 1996 г.

«трое друзей» работали над своим методом, который полу­чил название Unified Modeling Language. В январе 1997 г. различ­ные организации представили свои предложения по стандартиза­ции методов, предусматривающие в первую очередь возможность обмена информацией между различными моделями. В результате сейчас имеется единственное предложение — стандарт UML.

Источник: https://studopedia.ru/18_30943_standarti-v-oblasti-programmnogo-obespecheniya.html

Стандарты в области разработки программного обеспечения

Стандарт по

Среди всех стандартов в области разработки программного обеспечения, используемых в настоящее время в мире, наиболее популярными моделями являются: ISO 9001, TickIT, SEI SW-CMM.

Стандарты ISO серии 9000

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

Но основным преимуществом модели ISO является известность, распространенность, признание на мировом уровне. Сейчас стандарты ISO являются обязательным минимумом который должна иметь любая организация существующая на рынке. Но конечно же, вследствие своей универсальности, модель на основе стандартов ISO серии 9000 получилась достаточно “высокоуровневой”

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

Стандарт TickIT

Достаточно широкую известность получил британский стандарт TickIT. Этот отраслевой стандарт регламентирует требования к системе качества для организаций разработчиков программного обеспечения и базируется на модели ISO 9001:94.

В отличие от модели ISO 9001, которая регламентирует “что необходимо сделать”, разработчики данного стандарта попытались ответить на вопрос “как” можно выполнить требования, определенные в ISO 9001.

TickIT объединяет в себе модель ISO 9001 с набором рекомендательных стандартов ISO 12207 и ISO 9000-3.

Стандарты SEI SW-CMM

Очень интересный подход к улучшению внутренних процессов разработки программного обеспечения определен в модели SEI SW-CMM. В основу данной модели (также как и в основу стандартов ISO серии 9000) положена теория TQM.

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

Однако, модели ISO и CMM несколько различаются в своих подходах к построению самосовершенствующихся систем управления качеством и улучшению производственных процессов.

В отличие от модели ISO, где для того, чтобы соответствовать требованиям, необходимо продемонстрировать 100%-ное соответствие модели (и только оно позволяет компании самосовершенствоваться), в модели SEI SW-CMM предусмотрен поэтапный подход к построению системы совершенствования процессов.

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

Стандарты по Project Management

Одним из важных моментов, который необходимо иметь в виду при внедрении каких-либо стандартов (ISO 9000, SEI SW-CMM, TickIT, Spice ISO 15504 и т.п.

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

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

Управление проектами – это приложение знаний, опыта, методов и средств к работам проекта для удовлетворения требований, предъявляемых к проекту, и ожиданий участников проекта. Чтобы удовлетворить эти требования и ожидания, необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта.

176 комитет ISO разработал рекомендательный стандарт ISO 10006 “Менеджмент качества. Руководство качеством при управлении проектами”, который определяет основные подходы к управлению проектами и определяет его место в модели обеспечения качеством.

Авторы стандартов ISO серии 9000 определяют процесс управления проектами как часть системы менеджмента качества.

С другой стороны, возможен и противоположный взгляд (которого придерживаются оппоненты стандартов ISO серии 9000), согласно которому менеджмент качества является одной из составной частей системы управления проектами.

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

Поэтому неудивительно, что для приведения в соответствие системы управления качеством производства к требованиям модели ISO 9001 и к требованиям модели улучшения процессов производства SEI SW-CMM использование стандартов и признанных в мире технологий по управлению проектами является краеугольным камнем развития внутренних технологий в IT-компаниях.

Взаимосвязь наиболее признанных и применяемых в мире стандартов менеджмента качества и управления проектами:

Источник: материалы сайта adj.ru

Источник: https://blog.iteam.ru/standarty-v-oblasti-razrabotki-programmnogo-obespecheniya/

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.