РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

1-Разработка и стандартизация программных средств и информационных технологий

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

СТАНДАРТ - нормативно-технический документ, устанавливающий комплекс норм, правил, требований к объекту стандартизации и утвержденный компетентным государственным органом.

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

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

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

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

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

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

Тести́рование програ́ммного обеспе́чения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

2-Основные уровни стандартизации. Внутрифирменные стандарты

Стандартизация осуществляется на разных уровнях Уровень стан¬дартизации зависит от того, участники какого географического, экономического, политического региона мира принимав стандарт Если участие в стандартизации открыто для соответствующих органов любой страны, то это международная стандартизация. Международные организации по стандартизации ISO,МЭК(м/н электрическая комиссия)

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

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

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

Указанный фонд представляет четырехуровневую систему:

I уровень: Техническое законодательство, которое является правовой основой ГСС. Оно представляет совокупность законов РФ («О стандартизации»; «Об обеспечении единства измерений»; «О сертификации продукции и услуг»), подзаконных актов по стандартизации (постановлений Правительства РФ, приказов федеральных органов исполнительной власти), применяемых для государственного регулирования качества продукции, работ и услуг. По существу, это технические регламенты I уровня.

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

II уровень: Государственные стандарты, общероссийские классификаторы технико-экономической информации.

Нормативные документы II уровня представлены:

1. Государственными стандартами Российской Федерации (ГОСТ Р);

2. Межгосударственными стандартами (ГОСТами), введенными в действие постановлением Госстандарта России (Госстроя России) в качестве государственных стандартов Российской Федерации;

3. Правилами, нормами и рекомендациями по стандартизации;

4. Общероссийскими классификаторами технико-экономической и социальной информации.

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

III уровень: Стандарты отрасли и стандарты научно-технических и инженерных обществ.

Нормативные документы III уровня представлены:

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

IV уровень: Стандарты предприятий и технические условия.

Нормативными документами, сфера действия которых ограничена рамками организации (предприятия) - стандартами предприятий (СТП) и техническими условиями (ТУ).

1 - международная (ISO, IEC);

2 - региональная (EN, ГОСТ);

3 - национальная (СТБ, ГОСТ R ДСТУ, DIN);

4 - отраслевая (ОСТ, РД РБ);

5 - стандарты предприятия (ТУ РБ, ТО РБ, СТП)

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

Международная организация по стандартизации (ИСО) [(ISO) International Organization for Standardization] была создана по решению ООН в октябре 1946 г. (рисунок 29). Ее целью является содействие развитию стандартизации в мировом масштабе для облегчения международного товарообмена и взаимопомощи, а также для расширения сотрудничества в области интеллектуальной, научной, технической и экономической деятельности. ИСО разрабатывает стандарты по всем направлениям, кроме электротехники,

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

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

3-Процессы жизненного цикла программного средства, описанные в стандарте ГОСТ Р ИСО/МЭК 12207.

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

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

Процессы жизненного цикла по

• Основные:

  • Приобретение (действия и задачи заказчика, приобретающего ПО)

  • Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)

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

  • Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

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

• Вспомогательные

  • Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)

  • Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

  • Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

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

  • Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

  • Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

  • Аудит (определение соответствия требованиям, планам и условиям договора)

  • Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)

• Организационные

  • Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)

  • Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)

  • Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

  • Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

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

1. Инициирование приобретения

2. Подготовка заявочных предложений

3. Подготовка и корректировка договора

4. Надзор за деятельностью поставщика

5. Приемка и завершение работ

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

1. Формирование требований к системе

2. Формирование списка программных продуктов

3. Установление условий и соглашений

4. Описание технических ограничений (среда функционирования системы и т. д.)

4-Модели жизненного цикла программного средства. Каскадная модель. Спиральная модель.

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

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

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

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

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. «Разрыв» в квалификации специалистов разных областей знаний.

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

• оценка и разрешение рисков,

• определение целей,

• разработка и тестирование,

• планирование.

Каскадная модель (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:

1. Определение требований

2. Проектирование

3. Конструирование (также «реализация» либо «кодирование»)

4. Интеграция

5. Тестирование и отладка (также «верификация»)

6. Инсталляция

7. Поддержка

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

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

5-Внешняя и внутренняя программная документация. Документация пользователя.

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

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

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

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