edushk.ru

 

Начальная

Windows Commander

Far
WinNavigator
Frigate
Norton Commander
WinNC
Dos Navigator
Servant Salamander
Turbo Browser

Winamp, Skins, Plugins
Необходимые Утилиты
Текстовые редакторы
Юмор

File managers and best utilites

Реферат: по предмету Управление качеством на тему: «Стандарты при разработке программного обеспечения». Реферат стандарты разработки программного обеспечения


Реферат - по предмету Управление качеством на тему: «Стандарты при разработке программного обеспечения»

Новоуральский политехнический институт

Московского Инженерно ФИзического института

(технического университета)

Кафедра Экономики и управления

Реферат по предмету Управление качеством на тему:

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

Исполнитель:

студент гр. 2ИЭ-56Д

Афонасьев А. Ю.

Принял:

Эйшинский Е. Р.

НОВОУРАЛЬСК

2000

Введение

Не для кого не секрет, что в настоящее время компьютерная техника, а вместе с ней и программное обеспечение достаточно глубоко проникли в нашу жизнь. Практически ни одно современное производство не может обойтись в той или иной степени от применения вычислительной техники. Существующая тенденция на постоянное увеличение объёма информации в современном мире приводит ко всё большей роли программных продуктов – информационных систем, баз данных, и т. д. И производство, и обычные люди попадают во всё большую «зависимость» от компьютеров и ПО (программного обеспечения). От надёжности ИС (информационных систем) зависит уже очень многое. Поэтому сейчас во всём мире всё большее внимание обращается на качественные характеристики ПО. В связи с этим принимаются международные, отраслевые стандарты, стандарты предприятий – производителей ПО. Уделяется внимание соответствующей сертификации предприятий. Крупные разработчики внедряют у себя комплексные автоматизированные технологии управления проектами. Всё это позволяет поднимать качество ПО, обеспечивать конкурентоспособность своих продуктов. А что происходит у нас в стране? Также происходит развитие фирм – разработчиков ПО. Но по большому счёту рынок занят продуктами зарубежного производства (при этом по большинству – контрфактными). Исключение составляют программы, где необходима привязка к российским условиям (бухгалтерские программы). Доля программной продукции России вместе с други­ми странами СНГ в объеме мирового рынка составляет менее 1%.

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

Рассмотрим существующие основные стандарты в области разработки ПО.

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

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

Международная практика показыва­ет, что наиболее успешно эта задача решается на основе системного подхо­да, предусматривающего создание на предприятиях систем качества (сово­купности организационной структуры, методик, процессов и ресурсов, необ­ходимых для осуществления общего руководства качеством — ИСО 8402), соответствующих требованиям стан­дартов ИСО серии 9000.

В настоящее время стандарты ИСО серии 9000 кардинально пересматри­ваются. Предполагается, что новая версия трех базовых стандартов (ИСО 9000:2000, ИСО 9001:2000 и ИСО 9004:2000) с несколькими технически­ми отчетами заменит всю ныне дей­ствующую серию стандартов (около 20 наименований). Примечательно, что ввод в действие новых стандартов не потребует реконструкции действующих систем качества. Для облегчения пере­хода к стандартам версии 2000 г. будут разработаны специальные методичес­кие указания.

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

Стандарты инженерии качества ПС

Упоминаемые здесь стандарты явля­ются общими для всех видов продук­ции и услуг. Но программная продук­ция специфична. Для контроля и оцен­ки ее качества, управления качеством, создания эффективных систем обеспе­чения качества нужны стандарты, учи­тывающие эту специфику. В связи с по­вышением требований к качеству ПС последние пять-шесть лет ПК 7 «Про­граммная инженерия» ИСО/МЭК/СТК 1/ПК 7 (180/IЕС/JTC 1/SС 7) интенсив­но работает в области стандартизации инженерии качества ПС.

Группа планирования работ ПК 7 в 1996 г. разработала программу стан­дартизации в области инженерии ПС (SWEP), включающую общие проблемы и требования инженерии ПС, с предло­жениями путей их решения в рамках системы международных стандартов.

Введены в действие следующие стандарты:

ИСО/МЭК 9126:1991 «Оценивание программного продукта. Характерис­тики качества и руководства по их при­менению»;

ИСО/МЭК 12119:1994 «Информаци­онная технология. Пакеты програм­мных средств. Требования к качеству и испытания»;

ИСО/МЭК 12207:1995 «Информаци­онная технология. Процессы жизнен­ного цикла программного средства»;

ИСО/МЭК 15026:1998 «Информационная технология. Уровни целостности систем и программных средств».

На стадии согласования находятся стандарты:

ИСО/МЭК 9126 «Информационная технология. Характеристики и метрики качества программных средств» (ч. 1: Модель качества; ч. 2: Внешние метри­ки; ч. 3: Внутренние метрики; ч. 4: Пользовательские методики).

Разработана серия стандартов ИСО/ МЭК 14598 «Оценивание программно­го продукта» (ч. 1: Общие положения; ч. 2: Планирование и управление; ч. 3: Оценивание разработчиком; ч. 4: Оце­нивание покупателем; ч. 5: Оценивание оценщиком; Ч. 6: Документирование оценочных модулей). Части 1—5 введе­ны в действие.

Разработана и в 1998 г. введена в действие серия документов типа ТО (Технический отчет) «Информационная технология — Оценка процессов жиз­ненного цикла программных средств» ИСО/МЭК/ТО 15504 (части 1—4, 6—9). Эти документы устанавливают крите­рии и методы оценки процессов жиз­ненного цикла ПС (ИСО/МЭК 12207:1995) с целью определения их способности обеспечить требуемый уровень качества ПС.

Введены в действие международные стандарты по управлению документи­рованием ПС (ИСО/МЭК 6592, 9127, 9294,1 5910) и др.

Системы качества в индустрии ПС

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

Развитие отечественной индустрии ПС, по-видимому, следовало бы начи­нать с кардинальных мер по обеспече­нию заказчиков, разработчиков и пользователей ПС информацией о со­временных методах производства вы­сококачественной программной про­дукции, отраженных в международных, региональных и национальных стан­дартах. По некоторым данным, успех любого дела на 25% зависит от инфор­мационного обеспечения. У нас же обеспеченность основной массы заин­тересованных специалистов информа­цией пока недостаточна. Из 28 дей­ствующих международных стандартов и технических отчетов в области про­граммной инженерии в России введе­ны в действие менее четверти.

Введение в действие основополага­ющих международных стандартов по системам качества в России (ГОСТ Р ИСО 9001 — ГОСТ Р ИСО 9003), а также постановление Правительства РФ от 02.02.98 № 113 принесли определен­ные результаты: к середине 1999 г. в Системе сертификации ГОСТ Р было выдано более 300 сертификатов на си­стемы качества предприятий и произ­водств. К сожалению, среди них нет ни одного на производство програм­мных средств.

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

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

В Сборнике руководств (TickIT), раз­работанном Британским компьютер­ным обществом при Министерстве торговли и промышленности Великоб­ритании, приводятся некоторые дан­ные о затратах на подготовку, проведе­ние и использование сертификации третьей степени, касающиеся пред­приятий с числом работающих от 50 до 100 человек. Затраты составляют (в ан­глийских фунтах): оценка соответствия — 6500—9500; сертификат — 500; ис­пользование сертификата — 500. За вычетом времени, потраченного на улучшение документированных эле­ментов системы качества, трудозатра­ты органа по сертификации распреде­ляются так:

предварительная экспертиза 15—30 человек/дней;

сертификация 10—12 человек/дней;

надзор 5—10 человек/дней.

Прибыль. Прибыль, получаемая за счет внедрения систем качества, в ос­новном достигается благодаря улучше­нию качества ПС и уменьшению числа ошибок. Зарубежные обозреватели приводят данные о том, что для компа­нии с оборотом 3 млн у.е. в год расхо­ды, связанные с обнаружением и уст­ранением ошибок, составляют около 600 тыс. у.е. (20% оборота), а сэконом­ленные средства за счет уменьшения числа ошибок, вероятно, составят 150—300 тыс. у.е. Кроме того, не ме­нее существенная выгода может быть получена за счет роста доверия заказ­чиков и покупателей.

Проблемы. Рассмотренные здесь пионерные фирмы — производители программных средств при создании систем качества, соответствующих требованиям международных стандар­тов ИСО серии 9000, столкнулись с оп­ределенными трудностями и пробле­мами. Отметим некоторые из них:

1) ограниченность и несогласован­ность действующей нормативной базы. Из упомянутых серий основополагаю­щих международных стандартов в Рос­сии введено в действие менее трети, а стандартов инженерии качества ПС — десятая часть. При этом показатели ка­чества ПС, например, определяются тремя не согласованными между со­бой, устаревшими стандартами (ГОСТ 28195-89, ГОСТ 28806-90, ГОСТ Р ИСО/ МЭК 9126:93). А ведь каждый стандарт должен восприниматься как эталон, признанная норма, норма совершен­ства;

2) отсутствие методических руководств по созданию систем качества, аналогичных, например, упомянутым руководствам ТickIT;

3) крайне низкий уровень информа­ционного обеспечения. Рабочие мате­риалы ИСО/МЭК доступны узкому кру­гу лиц, не анализируются и не распрос­траняются;

4) специфика свойств и жизненного цикла программной продукции, отсут­ствие опыта в странах СНГ по созда­нию систем качества этой продукции. Стандарт ИСО 9000-3, содержащий ру­ководства по применению ИСО 9001 при разработке, испытании, инсталля­ции и сопровождении ПС с учетом их специфики в России, в действие не введен;

5) отсутствие специализированных органов по сертификации програм­мной продукции;

6) игнорирование заказчиками влия­ния систем качества на качество и се­бестоимость продукции.

Остановимся более подробно на основных стандартах.

Стандарты, регламентирующие жизненный цикл ПС

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

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

В России разработка и испытания ав­томатизированных систем (АС), в част­ности ПС, регламентированы ГОСТ 34.601—90. Стадии создания АС, ГОСТ 34.602—89. ТЗ на создание АС, ГОСТ 34.603—92. Виды испытаний АС. Одна­ко создание, сопровождение и развитие прикладных ПС для нынешних инфор­мационных систем в этих стандартах от­ражены недостаточно, а отдельные их положения устарели с точки зрения по­строения современных распределенных комплексов прикладных программ вы­сокого качества в системах управления и обработки данных с различной архи­тектурой. Поэтому целесообразно вы­бирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информа­ции и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функ­ционирования, они создаются больши­ми коллективами специалистов в тече­ние длительного времени .

ISO 12207: 1995

Наиболее полно и подробно ЖЦ, тех­нология создания и обеспечения качест­ва сложных ПС отражены в двух пред­ставленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств. Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

— основы жизненного цикла ПС и определяющие работы;

— процессы, поддерживающие жиз­ненный цикл ПС;

— организация и управление жизнен­ным циклом ПС.

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

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

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

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

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

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

В разделе 6 представлено около 70 технологических работ, поддерживаю­щих ЖЦ ПС. Процессы документирова­ния ПС (6.1) охватывают планирование и регламентирование документирова­ния, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комп­лекта документации на ПС. Конфигу­рационное управление (6.2) включает план реализации версий как часть об­щего плана управления проектом, ре­комендации по конфигурационной идентификации, контролю, учету, от­четности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирова­ния, методологии, процедур и стандар­тов качества в соответствии с контрак­том и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в про­цессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Вери­фикация ПС (6.4) включает организа­цию, планирование и техническое обес­печение. Представлена структура контракта на верификацию, содержа­ние процесса, состав требований, про­ектирование процесса верификации, обобщение и документирование резуль­татов. Валидация (6.5) — удостовере­ние правильности (аттестация) — должна гарантировать полное соответ­ствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее вы­полнение независимыми специалиста­ми путем тестирования во всех возмож­ных ситуациях исходных данных. По существу, этот процесс аналогичен сер­тификации, которая в стандарте не упо­минается.

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

Раздел 7 посвящен процессам орга­низации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, про­изводством и средствами для обеспече­ния прикладных процессов по созда­нию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструкту­ры (7.2) включают выбор и установле­ние аппаратных и программных средств, технологии, стандартов и способов об­служивания, используемых для разра­ботки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура дол­жна модифицироваться и сопровож­даться в соответствии с изменениями требований к проекту и подлежит кон­фигурационному управлению. Совер­шенствование ЖЦ ПС (7.3) подразуме­вает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходи­мые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответству­ющему плану.

В приложении А (нормативное) из­ложены основы преобразования и обоб­щения базовой структуры этого между­народного стандарта для конкретного проекта. Следует подчеркнуть необхо­димость реализации двух важнейших вариантов адаптации положений и ре­комендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руко­водство по процессам адаптации и пре­образования ЖЦ ПС для конкретного проекта, а также рекомендации по воз­можным изменениям ряда работ из раз­делов 5 и 6 стандарта в зависимости от характеристик объекта.

ISO 9000-3: 1991

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

— анализ содержания контракта, под­держанного методиками, обеспечиваю­щими качество ПС;

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

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

— планирование обеспечения качест­ва компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведе­ния разработки;

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

— измерения характеристик продук­ции и процессов ее создания, а также регистрацию данных о достигнутом ка­честве ПС и их компонентов;

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

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

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

— формализации состава, содержания и процессам утверждения документации;

— управлению конфигурацией версий ПС и проведению изменений в програм­мах и данных.

Адаптация процессов и работ в стан­дартах жизненного цикла программных средств к характеристикам конкретных проектов.

Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и страте­гиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на спо­соб создания, применения и сопровожде­ния ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедре­нием объектно-ориентированного анали­за и проектирования, а также методов бы­строй разработки прикладных программ, CASE-систем и языков четвертого поко­ления. В новых технологиях сокращаются стадии непосредственного создания про­граммных и информационных компонен­тов и детализируются процессы систем­ного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартиза­ции интерфейсов компонентов в создава­емых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество созда­ваемых ПС и возможности их эффектив­ного итерационного развития длительное время в многочисленных версиях.

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

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

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

Выводы

На мой взгляд, проблема внедрения в российских компаниях – разработчиках ПС систем качества очень актуальна. Она актуальна как для производителей “серьёзных” программ для предприятий, так и для производителей программ для населения – мультимедийных продуктов, справочников, игр. У наших разработчиков очень высокий потенциал, это доказывает и то, что лучшие российские программы с успехом продаются на западе (Fine Reader – распознаватель текста, AVP – антивирусная программа), и то, что многие программисты работают в престижных иностранных компаниях (Алексей Пажитнов – автор тетриса, работает в Microsoft). Введение систем качества могло бы позволить нашим компаниям достигнуть нового уровня производительности, возможно, сократить общие издержки, повысить качество выпускаемых программ. Тогда бы они смогли быть более конкурентоспособными как на российском рынке, так и на мировом. Но… С этим связаны масса проблем, главными из которых, на мой взгляд, являются:

— невысокий платёжеспособный спрос потребителей (слишком большая доля дешёвой пиратской продукции)

— финансовая неустойчивость большинства компаний, не так много инвестиций

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

— не информированность работников компаний, их руководителей.

www.ronl.ru

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

скачать Новоуральский политехнический институт

Московского Инженерно ФИзического института

(технического университета)

Кафедра Экономики и управления

Реферат по предмету Управление качеством на тему:

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

Исполнитель:

студент гр. 2ИЭ-56Д

Афонасьев А. Ю. Принял:

Эйшинский Е. Р.

НОВОУРАЛЬСК

2000
Введение
Не для кого не секрет, что в настоящее время компьютерная техника, а вместе с ней и программное обеспечение достаточно глубоко проникли в нашу жизнь. Практически ни одно современное производство не может обойтись в той или иной степени от применения вычислительной техники. Существующая тенденция на постоянное увеличение объёма информации в современном мире приводит ко всё большей роли программных продуктов – информационных систем, баз данных, и т. д. И производство, и обычные люди попадают во всё большую «зависимость» от компьютеров и ПО (программного обеспечения). От надёжности ИС (информационных систем) зависит уже очень многое. Поэтому сейчас во всём мире всё большее внимание обращается на качественные характеристики ПО. В связи с этим принимаются международные, отраслевые стандарты, стандарты предприятий – производителей ПО. Уделяется внимание соответствующей сертификации предприятий. Крупные разработчики внедряют у себя комплексные автоматизированные технологии управления проектами. Всё это позволяет поднимать качество ПО, обеспечивать конкурентоспособность своих продуктов. А что происходит у нас в стране? Также происходит развитие фирм – разработчиков ПО. Но по большому счёту рынок занят продуктами зарубежного производства (при этом по большинству – контрфактными). Исключение составляют программы, где необходима привязка к российским условиям (бухгалтерские программы). Доля программной продукции России вместе с други­ми странами СНГ в объеме мирового рынка составляет менее 1%.

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

Рассмотрим существующие основные стандарты в области разработки ПО.

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

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

Международная практика показыва­ет, что наиболее успешно эта задача решается на основе системного подхо­да, предусматривающего создание на предприятиях систем качества (сово­купности организационной структуры, методик, процессов и ресурсов, необ­ходимых для осуществления общего руководства качеством — ИСО 8402), соответствующих требованиям стан­дартов ИСО серии 9000.

В настоящее время стандарты ИСО серии 9000 кардинально пересматри­ваются. Предполагается, что новая версия трех базовых стандартов (ИСО 9000:2000, ИСО 9001:2000 и ИСО 9004:2000) с несколькими технически­ми отчетами заменит всю ныне дей­ствующую серию стандартов (около 20 наименований). Примечательно, что ввод в действие новых стандартов не потребует реконструкции действующих систем качества. Для облегчения пере­хода к стандартам версии 2000 г. будут разработаны специальные методичес­кие указания.

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

Стандарты инженерии качества ПС
Упоминаемые здесь стандарты явля­ются общими для всех видов продук­ции и услуг. Но программная продук­ция специфична. Для контроля и оцен­ки ее качества, управления качеством, создания эффективных систем обеспе­чения качества нужны стандарты, учи­тывающие эту специфику. В связи с по­вышением требований к качеству ПС последние пять-шесть лет ПК 7 «Про­граммная инженерия» ИСО/МЭК/СТК 1/ПК 7 (180/IЕС/JTC 1/SС 7) интенсив­но работает в области стандартизации инженерии качества ПС.

Группа планирования работ ПК 7 в 1996 г. разработала программу стан­дартизации в области инженерии ПС (SWEP), включающую общие проблемы и требования инженерии ПС, с предло­жениями путей их решения в рамках системы международных стандартов.

Введены в действие следующие стандарты:

ИСО/МЭК 9126:1991 «Оценивание программного продукта. Характерис­тики качества и руководства по их при­менению»;

ИСО/МЭК 12119:1994 «Информаци­онная технология. Пакеты програм­мных средств. Требования к качеству и испытания»;

ИСО/МЭК 12207:1995 «Информаци­онная технология. Процессы жизнен­ного цикла программного средства»;

ИСО/МЭК 15026:1998 «Информационная технология. Уровни целостности систем и программных средств».

На стадии согласования находятся стандарты:

ИСО/МЭК 9126 «Информационная технология. Характеристики и метрики качества программных средств» (ч. 1: Модель качества; ч. 2: Внешние метри­ки; ч. 3: Внутренние метрики; ч. 4: Пользовательские методики).

Разработана серия стандартов ИСО/ МЭК 14598 «Оценивание программно­го продукта» (ч. 1: Общие положения; ч. 2: Планирование и управление; ч. 3: Оценивание разработчиком; ч. 4: Оце­нивание покупателем; ч. 5: Оценивание оценщиком; Ч. 6: Документирование оценочных модулей). Части 1—5 введе­ны в действие.

Разработана и в 1998 г. введена в действие серия документов типа ТО (Технический отчет) «Информационная технология — Оценка процессов жиз­ненного цикла программных средств» ИСО/МЭК/ТО 15504 (части 1—4, 6—9). Эти документы устанавливают крите­рии и методы оценки процессов жиз­ненного цикла ПС (ИСО/МЭК 12207:1995) с целью определения их способности обеспечить требуемый уровень качества ПС.

Введены в действие международные стандарты по управлению документи­рованием ПС (ИСО/МЭК 6592, 9127, 9294,1 5910) и др.

Системы качества в индустрии ПС

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

Развитие отечественной индустрии ПС, по-видимому, следовало бы начи­нать с кардинальных мер по обеспече­нию заказчиков, разработчиков и пользователей ПС информацией о со­временных методах производства вы­сококачественной программной про­дукции, отраженных в международных, региональных и национальных стан­дартах. По некоторым данным, успех любого дела на 25% зависит от инфор­мационного обеспечения. У нас же обеспеченность основной массы заин­тересованных специалистов информа­цией пока недостаточна. Из 28 дей­ствующих международных стандартов и технических отчетов в области про­граммной инженерии в России введе­ны в действие менее четверти.

Введение в действие основополага­ющих международных стандартов по системам качества в России (ГОСТ Р ИСО 9001 - ГОСТ Р ИСО 9003), а также постановление Правительства РФ от 02.02.98 № 113 принесли определен­ные результаты: к середине 1999 г. в Системе сертификации ГОСТ Р было выдано более 300 сертификатов на си­стемы качества предприятий и произ­водств. К сожалению, среди них нет ни одного на производство програм­мных средств.

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

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

В Сборнике руководств (TickIT), раз­работанном Британским компьютер­ным обществом при Министерстве торговли и промышленности Великоб­ритании, приводятся некоторые дан­ные о затратах на подготовку, проведе­ние и использование сертификации третьей степени, касающиеся пред­приятий с числом работающих от 50 до 100 человек. Затраты составляют (в ан­глийских фунтах): оценка соответствия — 6500—9500; сертификат — 500; ис­пользование сертификата — 500. За вычетом времени, потраченного на улучшение документированных эле­ментов системы качества, трудозатра­ты органа по сертификации распреде­ляются так:

предварительная экспертиза 15—30 человек/дней;

сертификация 10—12 человек/дней;

надзор 5—10 человек/дней.

Прибыль. Прибыль, получаемая за счет внедрения систем качества, в ос­новном достигается благодаря улучше­нию качества ПС и уменьшению числа ошибок. Зарубежные обозреватели приводят данные о том, что для компа­нии с оборотом 3 млн у.е. в год расхо­ды, связанные с обнаружением и уст­ранением ошибок, составляют около 600 тыс. у.е. (20% оборота), а сэконом­ленные средства за счет уменьшения числа ошибок, вероятно, составят 150—300 тыс. у.е. Кроме того, не ме­нее существенная выгода может быть получена за счет роста доверия заказ­чиков и покупателей.

Проблемы. Рассмотренные здесь пионерные фирмы — производители программных средств при создании систем качества, соответствующих требованиям международных стандар­тов ИСО серии 9000, столкнулись с оп­ределенными трудностями и пробле­мами. Отметим некоторые из них:

1) ограниченность и несогласован­ность действующей нормативной базы. Из упомянутых серий основополагаю­щих международных стандартов в Рос­сии введено в действие менее трети, а стандартов инженерии качества ПС — десятая часть. При этом показатели ка­чества ПС, например, определяются тремя не согласованными между со­бой, устаревшими стандартами (ГОСТ 28195-89, ГОСТ 28806-90, ГОСТ Р ИСО/ МЭК 9126:93). А ведь каждый стандарт должен восприниматься как эталон, признанная норма, норма совершен­ства;

2) отсутствие методических руководств по созданию систем качества, аналогичных, например, упомянутым руководствам ТickIT;

3) крайне низкий уровень информа­ционного обеспечения. Рабочие мате­риалы ИСО/МЭК доступны узкому кру­гу лиц, не анализируются и не распрос­траняются;

4) специфика свойств и жизненного цикла программной продукции, отсут­ствие опыта в странах СНГ по созда­нию систем качества этой продукции. Стандарт ИСО 9000-3, содержащий ру­ководства по применению ИСО 9001 при разработке, испытании, инсталля­ции и сопровождении ПС с учетом их специфики в России, в действие не введен;

5) отсутствие специализированных органов по сертификации програм­мной продукции;

6) игнорирование заказчиками влия­ния систем качества на качество и се­бестоимость продукции.

Остановимся более подробно на основных стандартах.

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

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

В России разработка и испытания ав­томатизированных систем (АС), в част­ности ПС, регламентированы ГОСТ 34.601—90. Стадии создания АС, ГОСТ 34.602—89. ТЗ на создание АС, ГОСТ 34.603—92. Виды испытаний АС. Одна­ко создание, сопровождение и развитие прикладных ПС для нынешних инфор­мационных систем в этих стандартах от­ражены недостаточно, а отдельные их положения устарели с точки зрения по­строения современных распределенных комплексов прикладных программ вы­сокого качества в системах управления и обработки данных с различной архи­тектурой. Поэтому целесообразно вы­бирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информа­ции и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функ­ционирования, они создаются больши­ми коллективами специалистов в тече­ние длительного времени .

ISO 12207: 1995
Наиболее полно и подробно ЖЦ, тех­нология создания и обеспечения качест­ва сложных ПС отражены в двух пред­ставленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств. Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

— основы жизненного цикла ПС и определяющие работы;

— процессы, поддерживающие жиз­ненный цикл ПС;

— организация и управление жизнен­ным циклом ПС.

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

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

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

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

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

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

В разделе 6 представлено около 70 технологических работ, поддерживаю­щих ЖЦ ПС. Процессы документирова­ния ПС (6.1) охватывают планирование и регламентирование документирова­ния, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комп­лекта документации на ПС. Конфигу­рационное управление (6.2) включает план реализации версий как часть об­щего плана управления проектом, ре­комендации по конфигурационной идентификации, контролю, учету, от­четности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирова­ния, методологии, процедур и стандар­тов качества в соответствии с контрак­том и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в про­цессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Вери­фикация ПС (6.4) включает организа­цию, планирование и техническое обес­печение. Представлена структура контракта на верификацию, содержа­ние процесса, состав требований, про­ектирование процесса верификации, обобщение и документирование резуль­татов. Валидация (6.5) — удостовере­ние правильности (аттестация) — должна гарантировать полное соответ­ствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее вы­полнение независимыми специалиста­ми путем тестирования во всех возмож­ных ситуациях исходных данных. По существу, этот процесс аналогичен сер­тификации, которая в стандарте не упо­минается.

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

Раздел 7 посвящен процессам орга­низации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, про­изводством и средствами для обеспече­ния прикладных процессов по созда­нию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструкту­ры (7.2) включают выбор и установле­ние аппаратных и программных средств, технологии, стандартов и способов об­служивания, используемых для разра­ботки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура дол­жна модифицироваться и сопровож­даться в соответствии с изменениями требований к проекту и подлежит кон­фигурационному управлению. Совер­шенствование ЖЦ ПС (7.3) подразуме­вает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходи­мые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответству­ющему плану.

В приложении А (нормативное) из­ложены основы преобразования и обоб­щения базовой структуры этого между­народного стандарта для конкретного проекта. Следует подчеркнуть необхо­димость реализации двух важнейших вариантов адаптации положений и ре­комендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руко­водство по процессам адаптации и пре­образования ЖЦ ПС для конкретного проекта, а также рекомендации по воз­можным изменениям ряда работ из раз­делов 5 и 6 стандарта в зависимости от характеристик объекта.

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

— анализ содержания контракта, под­держанного методиками, обеспечиваю­щими качество ПС;

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

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

— планирование обеспечения качест­ва компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведе­ния разработки;

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

— измерения характеристик продук­ции и процессов ее создания, а также регистрацию данных о достигнутом ка­честве ПС и их компонентов;

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

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

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

— формализации состава, содержания и процессам утверждения документации;

— управлению конфигурацией версий ПС и проведению изменений в програм­мах и данных.

Адаптация процессов и работ в стан­дартах жизненного цикла программных средств к характеристикам конкретных проектов.
Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и страте­гиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на спо­соб создания, применения и сопровожде­ния ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедре­нием объектно-ориентированного анали­за и проектирования, а также методов бы­строй разработки прикладных программ, CASE-систем и языков четвертого поко­ления. В новых технологиях сокращаются стадии непосредственного создания про­граммных и информационных компонен­тов и детализируются процессы систем­ного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартиза­ции интерфейсов компонентов в создава­емых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество созда­ваемых ПС и возможности их эффектив­ного итерационного развития длительное время в многочисленных версиях.

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

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

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

Выводы
На мой взгляд, проблема внедрения в российских компаниях – разработчиках ПС систем качества очень актуальна. Она актуальна как для производителей “серьёзных” программ для предприятий, так и для производителей программ для населения – мультимедийных продуктов, справочников, игр. У наших разработчиков очень высокий потенциал, это доказывает и то, что лучшие российские программы с успехом продаются на западе (Fine Reader – распознаватель текста, AVP – антивирусная программа), и то, что многие программисты работают в престижных иностранных компаниях (Алексей Пажитнов – автор тетриса, работает в Microsoft). Введение систем качества могло бы позволить нашим компаниям достигнуть нового уровня производительности, возможно, сократить общие издержки, повысить качество выпускаемых программ. Тогда бы они смогли быть более конкурентоспособными как на российском рынке, так и на мировом. Но… С этим связаны масса проблем, главными из которых, на мой взгляд, являются:
  • невысокий платёжеспособный спрос потребителей (слишком большая доля дешёвой пиратской продукции)
  • финансовая неустойчивость большинства компаний, не так много инвестиций
  • плохо разработанные на государственном уровне стандарты в этой области, а самим компаниям это пока чересчур дорого
  • не информированность работников компаний, их руководителей.
скачать

nenuda.ru

Реферат по предмету Управление качеством на тему: «Стандарты при разработке программного обеспечения»

Новоуральский политехнический институт

Московского Инженерно ФИзического института

(технического университета)

Кафедра Экономики и управления

Реферат по предмету Управление качеством на тему:

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

Исполнитель:

студент гр. 2ИЭ-56Д

Афонасьев А. Ю.

Принял:

Эйшинский Е. Р.

НОВОУРАЛЬСК

2000

Введение

Не для кого не секрет, что в настоящее время компьютерная техника, а вместе с ней и программное обеспечение достаточно глубоко проникли в нашу жизнь. Практически ни одно современное производство не может обойтись в той или иной степени от применения вычислительной техники. Существующая тенденция на постоянное увеличение объёма информации в современном мире приводит ко всё большей роли программных продуктов – информационных систем, баз данных, и т. д. И производство, и обычные люди попадают во всё большую «зависимость» от компьютеров и ПО (программного обеспечения). От надёжности ИС (информационных систем) зависит уже очень многое. Поэтому сейчас во всём мире всё большее внимание обращается на качественные характеристики ПО. В связи с этим принимаются международные, отраслевые стандарты, стандарты предприятий – производителей ПО. Уделяется внимание соответствующей сертификации предприятий. Крупные разработчики внедряют у себя комплексные автоматизированные технологии управления проектами. Всё это позволяет поднимать качество ПО, обеспечивать конкурентоспособность своих продуктов. А что происходит у нас в стране? Также происходит развитие фирм – разработчиков ПО. Но по большому счёту рынок занят продуктами зарубежного производства (при этом по большинству – контрфактными). Исключение составляют программы, где необходима привязка к российским условиям (бухгалтерские программы). Доля программной продукции России вместе с други­ми странами СНГ в объеме мирового рынка составляет менее 1%.

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

Рассмотрим существующие основные стандарты в области разработки ПО.

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

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

Международная практика показыва­ет, что наиболее успешно эта задача решается на основе системного подхо­да, предусматривающего создание на предприятияхсистем качества (сово­купности организационной структуры, методик, процессов и ресурсов, необ­ходимых для осуществления общего руководства качеством — ИСО 8402), соответствующих требованиям стан­дартов ИСО серии 9000.

В настоящее время стандарты ИСО серии 9000 кардинально пересматри­ваются. Предполагается, что новая версия трех базовых стандартов (ИСО 9000:2000, ИСО 9001:2000 и ИСО 9004:2000) с несколькими технически­ми отчетами заменит всю ныне дей­ствующую серию стандартов (около 20 наименований). Примечательно, что ввод в действие новых стандартов не потребует реконструкции действующих систем качества. Для облегчения пере­хода к стандартам версии 2000 г. будут разработаны специальные методичес­кие указания.

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

Стандарты инженерии качества ПС

Упоминаемые здесь стандарты явля­ются общими для всех видов продук­ции и услуг. Но программная продук­ция специфична. Для контроля и оцен­ки ее качества, управления качеством, создания эффективных систем обеспе­чения качества нужны стандарты, учи­тывающие эту специфику. В связи с по­вышением требований к качеству ПС последние пять-шесть лет ПК 7 «Про­граммная инженерия» ИСО/МЭК/СТК 1/ПК 7 (180/IЕС/JTC 1/SС 7) интенсив­но работает в области стандартизации инженерии качества ПС.

Группа планирования работ ПК 7 в 1996 г. разработала программу стан­дартизации в области инженерии ПС (SWEP), включающую общие проблемы и требования инженерии ПС, с предло­жениями путей их решения в рамках системы международных стандартов.

Введены в действие следующие стандарты:

ИСО/МЭК 9126:1991 «Оценивание программного продукта. Характерис­тики качества и руководства по их при­менению»;

ИСО/МЭК 12119:1994 «Информаци­онная технология. Пакеты програм­мных средств. Требования к качеству и испытания»;

ИСО/МЭК 12207:1995 «Информаци­онная технология. Процессы жизнен­ного цикла программного средства»;

ИСО/МЭК 15026:1998 «Информационная технология. Уровни целостности систем и программных средств».

На стадии согласования находятся стандарты:

ИСО/МЭК 9126 «Информационная технология. Характеристики и метрики качества программных средств» (ч. 1: Модель качества; ч. 2: Внешние метри­ки; ч. 3: Внутренние метрики; ч. 4: Пользовательские методики).

Разработана серия стандартов ИСО/ МЭК 14598 «Оценивание программно­го продукта» (ч. 1: Общие положения; ч. 2: Планирование и управление; ч. 3: Оценивание разработчиком; ч. 4: Оце­нивание покупателем; ч. 5: Оценивание оценщиком; Ч. 6: Документирование оценочных модулей). Части 1—5 введе­ны в действие.

Разработана и в 1998 г. введена в действие серия документов типа ТО (Технический отчет) «Информационная технология — Оценка процессов жиз­ненного цикла программных средств» ИСО/МЭК/ТО 15504 (части 1—4, 6—9). Эти документы устанавливают крите­рии и методы оценки процессов жиз­ненного цикла ПС (ИСО/МЭК 12207:1995) с целью определения их способности обеспечить требуемый уровень качества ПС.

Введены в действие международные стандарты по управлению документи­рованием ПС (ИСО/МЭК 6592, 9127, 9294,1 5910) и др.

Системы качества в индустрии ПС

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

Развитие отечественной индустрии ПС, по-видимому, следовало бы начи­нать с кардинальных мер по обеспече­нию заказчиков, разработчиков и пользователей ПС информацией о со­временных методах производства вы­сококачественной программной про­дукции, отраженных в международных, региональных и национальных стан­дартах. По некоторым данным, успех любого дела на 25% зависит от инфор­мационного обеспечения. У нас же обеспеченность основной массы заин­тересованных специалистов информа­цией пока недостаточна. Из 28 дей­ствующих международных стандартов и технических отчетов в области про­граммной инженерии в России введе­ны в действие менее четверти.

Введение в действие основополага­ющих международных стандартов по системам качества в России (ГОСТ Р ИСО 9001 - ГОСТ Р ИСО 9003), а также постановление Правительства РФ от 02.02.98 № 113 принесли определен­ные результаты: к середине 1999 г. в Системе сертификации ГОСТ Р было выдано более 300 сертификатов на си­стемы качества предприятий и произ­водств. К сожалению, среди них нет ни одного на производство програм­мных средств.

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

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

В Сборнике руководств (TickIT), раз­работанном Британским компьютер­ным обществом при Министерстве торговли и промышленности Великоб­ритании, приводятся некоторые дан­ные о затратах на подготовку, проведе­ние и использование сертификации третьей степени, касающиеся пред­приятий с числом работающих от 50 до 100 человек. Затраты составляют (в ан­глийских фунтах): оценка соответствия — 6500—9500; сертификат — 500; ис­пользование сертификата — 500. За вычетом времени, потраченного на улучшение документированных эле­ментов системы качества, трудозатра­ты органа по сертификации распреде­ляются так:

предварительная экспертиза 15—30 человек/дней;

сертификация 10—12 человек/дней;

надзор 5—10 человек/дней.

Прибыль. Прибыль, получаемая за счет внедрения систем качества, в ос­новном достигается благодаря улучше­нию качества ПС и уменьшению числа ошибок. Зарубежные обозреватели приводят данные о том, что для компа­нии с оборотом 3 млн у.е. в год расхо­ды, связанные с обнаружением и уст­ранением ошибок, составляют около 600 тыс. у.е. (20% оборота), а сэконом­ленные средства за счет уменьшения числа ошибок, вероятно, составят 150—300 тыс. у.е. Кроме того, не ме­нее существенная выгода может быть получена за счет роста доверия заказ­чиков и покупателей.

Проблемы. Рассмотренные здесь пионерные фирмы — производители программных средств при создании систем качества, соответствующих требованиям международных стандар­тов ИСО серии 9000, столкнулись с оп­ределенными трудностями и пробле­мами. Отметим некоторые из них:

1) ограниченность и несогласован­ность действующей нормативной базы. Из упомянутых серий основополагаю­щих международных стандартов в Рос­сии введено в действие менее трети, а стандартов инженерии качества ПС — десятая часть. При этом показатели ка­чества ПС, например, определяются тремя не согласованными между со­бой, устаревшими стандартами (ГОСТ 28195-89, ГОСТ 28806-90, ГОСТ Р ИСО/ МЭК 9126:93). А ведь каждый стандарт должен восприниматься как эталон, признанная норма, норма совершен­ства;

2) отсутствие методических руководств по созданию систем качества, аналогичных, например, упомянутым руководствам ТickIT;

3) крайне низкий уровень информа­ционного обеспечения. Рабочие мате­риалы ИСО/МЭК доступны узкому кру­гу лиц, не анализируются и не распрос­траняются;

4) специфика свойств и жизненного цикла программной продукции, отсут­ствие опыта в странах СНГ по созда­нию систем качества этой продукции. Стандарт ИСО 9000-3, содержащий ру­ководства по применению ИСО 9001 при разработке, испытании, инсталля­ции и сопровождении ПС с учетом их специфики в России, в действие не введен;

5) отсутствие специализированных органов по сертификации програм­мной продукции;

6) игнорирование заказчиками влия­ния систем качества на качество и се­бестоимость продукции.

Остановимся более подробно на основных стандартах.

Стандарты, регламентирующие жизненный цикл ПС

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

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

В России разработка и испытания ав­томатизированных систем (АС), в част­ности ПС, регламентированы ГОСТ 34.601—90. Стадии создания АС, ГОСТ 34.602—89. ТЗ на создание АС, ГОСТ 34.603—92. Виды испытаний АС. Одна­ко создание, сопровождение и развитие прикладных ПС для нынешних инфор­мационных систем в этих стандартах от­ражены недостаточно, а отдельные их положения устарели с точки зрения по­строения современных распределенных комплексов прикладных программ вы­сокого качества в системах управления и обработки данных с различной архи­тектурой. Поэтому целесообразно вы­бирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информа­ции и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функ­ционирования, они создаются больши­ми коллективами специалистов в тече­ние длительного времени .

ISO 12207: 1995

Наиболее полно и подробно ЖЦ, тех­нология создания и обеспечения качест­ва сложных ПС отражены в двух пред­ставленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств.Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

— основы жизненного цикла ПС и определяющие работы;

— процессы, поддерживающие жиз­ненный цикл ПС;

— организация и управление жизнен­ным циклом ПС.

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

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

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

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

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

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

В разделе 6 представлено около 70 технологических работ, поддерживаю­щих ЖЦ ПС. Процессы документирова­ния ПС (6.1) охватывают планирование и регламентирование документирова­ния, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комп­лекта документации на ПС. Конфигу­рационное управление (6.2) включает план реализации версий как часть об­щего плана управления проектом, ре­комендации по конфигурационной идентификации, контролю, учету, от­четности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирова­ния, методологии, процедур и стандар­тов качества в соответствии с контрак­том и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в про­цессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Вери­фикация ПС (6.4) включает организа­цию, планирование и техническое обес­печение. Представлена структура контракта на верификацию, содержа­ние процесса, состав требований, про­ектирование процесса верификации, обобщение и документирование резуль­татов. Валидация (6.5) — удостовере­ние правильности (аттестация) — должна гарантировать полное соответ­ствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее вы­полнение независимыми специалиста­ми путем тестирования во всех возмож­ных ситуациях исходных данных. По существу, этот процесс аналогичен сер­тификации, которая в стандарте не упо­минается.

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

Раздел 7 посвящен процессам орга­низации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, про­изводством и средствами для обеспече­ния прикладных процессов по созда­нию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструкту­ры (7.2) включают выбор и установле­ние аппаратных и программных средств, технологии, стандартов и способов об­служивания, используемых для разра­ботки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура дол­жна модифицироваться и сопровож­даться в соответствии с изменениями требований к проекту и подлежит кон­фигурационному управлению. Совер­шенствование ЖЦ ПС (7.3) подразуме­вает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходи­мые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответству­ющему плану.

В приложении А (нормативное) из­ложены основы преобразования и обоб­щения базовой структуры этого между­народного стандарта для конкретного проекта. Следует подчеркнуть необхо­димость реализации двух важнейших вариантов адаптации положений и ре­комендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руко­водство по процессам адаптации и пре­образования ЖЦ ПС для конкретного проекта, а также рекомендации по воз­можным изменениям ряда работ из раз­делов 5 и 6 стандарта в зависимости от характеристик объекта.

ISO 9000-3: 1991

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

— анализ содержания контракта, под­держанного методиками, обеспечиваю­щими качество ПС;

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

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

— планирование обеспечения качест­ва компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведе­ния разработки;

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

— измерения характеристик продук­ции и процессов ее создания, а также регистрацию данных о достигнутом ка­честве ПС и их компонентов;

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

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

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

— формализации состава, содержания и процессам утверждения документации;

— управлению конфигурацией версий ПС и проведению изменений в програм­мах и данных.

Адаптация процессов и работ в стан­дартах жизненного цикла программных средств к характеристикам конкретных проектов.

Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и страте­гиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на спо­соб создания, применения и сопровожде­ния ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедре­нием объектно-ориентированного анали­за и проектирования, а также методов бы­строй разработки прикладных программ, CASE-систем и языков четвертого поко­ления. В новых технологиях сокращаются стадии непосредственного создания про­граммных и информационных компонен­тов и детализируются процессы систем­ного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартиза­ции интерфейсов компонентов в создава­емых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество созда­ваемых ПС и возможности их эффектив­ного итерационного развития длительное время в многочисленных версиях.

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

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

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

Выводы

На мой взгляд, проблема внедрения в российских компаниях – разработчиках ПС систем качества очень актуальна. Она актуальна как для производителей “серьёзных” программ для предприятий, так и для производителей программ для населения – мультимедийных продуктов, справочников, игр. У наших разработчиков очень высокий потенциал, это доказывает и то, что лучшие российские программы с успехом продаются на западе (Fine Reader – распознаватель текста, AVP – антивирусная программа), и то, что многие программисты работают в престижных иностранных компаниях (Алексей Пажитнов – автор тетриса, работает в Microsoft). Введение систем качества могло бы позволить нашим компаниям достигнуть нового уровня производительности, возможно, сократить общие издержки, повысить качество выпускаемых программ. Тогда бы они смогли быть более конкурентоспособными как на российском рынке, так и на мировом. Но… С этим связаны масса проблем, главными из которых, на мой взгляд, являются:

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

  • финансовая неустойчивость большинства компаний, не так много инвестиций

  • плохо разработанные на государственном уровне стандарты в этой области, а самим компаниям это пока чересчур дорого

  • не информированность работников компаний, их руководителей.

uchebana5.ru

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

Стандарты при разработке программного обеспечения - страница №1/1

Новоуральский политехнический институт

Московского Инженерно ФИзического института

(технического университета)

Кафедра Экономики и управления

Реферат по предмету Управление качеством на тему:

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

Исполнитель:

студент гр. 2ИЭ-56Д

Афонасьев А. Ю. Принял:

Эйшинский Е. Р.

НОВОУРАЛЬСК

2000
Введение
Не для кого не секрет, что в настоящее время компьютерная техника, а вместе с ней и программное обеспечение достаточно глубоко проникли в нашу жизнь. Практически ни одно современное производство не может обойтись в той или иной степени от применения вычислительной техники. Существующая тенденция на постоянное увеличение объёма информации в современном мире приводит ко всё большей роли программных продуктов – информационных систем, баз данных, и т. д. И производство, и обычные люди попадают во всё большую «зависимость» от компьютеров и ПО (программного обеспечения). От надёжности ИС (информационных систем) зависит уже очень многое. Поэтому сейчас во всём мире всё большее внимание обращается на качественные характеристики ПО. В связи с этим принимаются международные, отраслевые стандарты, стандарты предприятий – производителей ПО. Уделяется внимание соответствующей сертификации предприятий. Крупные разработчики внедряют у себя комплексные автоматизированные технологии управления проектами. Всё это позволяет поднимать качество ПО, обеспечивать конкурентоспособность своих продуктов. А что происходит у нас в стране? Также происходит развитие фирм – разработчиков ПО. Но по большому счёту рынок занят продуктами зарубежного производства (при этом по большинству – контрфактными). Исключение составляют программы, где необходима привязка к российским условиям (бухгалтерские программы). Доля программной продукции России вместе с други­ми странами СНГ в объеме мирового рынка составляет менее 1%.

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

Рассмотрим существующие основные стандарты в области разработки ПО.

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

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

Международная практика показыва­ет, что наиболее успешно эта задача решается на основе системного подхо­да, предусматривающего создание на предприятиях систем качества (сово­купности организационной структуры, методик, процессов и ресурсов, необ­ходимых для осуществления общего руководства качеством — ИСО 8402), соответствующих требованиям стан­дартов ИСО серии 9000.

В настоящее время стандарты ИСО серии 9000 кардинально пересматри­ваются. Предполагается, что новая версия трех базовых стандартов (ИСО 9000:2000, ИСО 9001:2000 и ИСО 9004:2000) с несколькими технически­ми отчетами заменит всю ныне дей­ствующую серию стандартов (около 20 наименований). Примечательно, что ввод в действие новых стандартов не потребует реконструкции действующих систем качества. Для облегчения пере­хода к стандартам версии 2000 г. будут разработаны специальные методичес­кие указания.

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

Стандарты инженерии качества ПС
Упоминаемые здесь стандарты явля­ются общими для всех видов продук­ции и услуг. Но программная продук­ция специфична. Для контроля и оцен­ки ее качества, управления качеством, создания эффективных систем обеспе­чения качества нужны стандарты, учи­тывающие эту специфику. В связи с по­вышением требований к качеству ПС последние пять-шесть лет ПК 7 «Про­граммная инженерия» ИСО/МЭК/СТК 1/ПК 7 (180/IЕС/JTC 1/SС 7) интенсив­но работает в области стандартизации инженерии качества ПС.

Группа планирования работ ПК 7 в 1996 г. разработала программу стан­дартизации в области инженерии ПС (SWEP), включающую общие проблемы и требования инженерии ПС, с предло­жениями путей их решения в рамках системы международных стандартов.

Введены в действие следующие стандарты:

ИСО/МЭК 9126:1991 «Оценивание программного продукта. Характерис­тики качества и руководства по их при­менению»;

ИСО/МЭК 12119:1994 «Информаци­онная технология. Пакеты програм­мных средств. Требования к качеству и испытания»;

ИСО/МЭК 12207:1995 «Информаци­онная технология. Процессы жизнен­ного цикла программного средства»;

ИСО/МЭК 15026:1998 «Информационная технология. Уровни целостности систем и программных средств».

На стадии согласования находятся стандарты:

ИСО/МЭК 9126 «Информационная технология. Характеристики и метрики качества программных средств» (ч. 1: Модель качества; ч. 2: Внешние метри­ки; ч. 3: Внутренние метрики; ч. 4: Пользовательские методики).

Разработана серия стандартов ИСО/ МЭК 14598 «Оценивание программно­го продукта» (ч. 1: Общие положения; ч. 2: Планирование и управление; ч. 3: Оценивание разработчиком; ч. 4: Оце­нивание покупателем; ч. 5: Оценивание оценщиком; Ч. 6: Документирование оценочных модулей). Части 1—5 введе­ны в действие.

Разработана и в 1998 г. введена в действие серия документов типа ТО (Технический отчет) «Информационная технология — Оценка процессов жиз­ненного цикла программных средств» ИСО/МЭК/ТО 15504 (части 1—4, 6—9). Эти документы устанавливают крите­рии и методы оценки процессов жиз­ненного цикла ПС (ИСО/МЭК 12207:1995) с целью определения их способности обеспечить требуемый уровень качества ПС.

Введены в действие международные стандарты по управлению документи­рованием ПС (ИСО/МЭК 6592, 9127, 9294,1 5910) и др.

Системы качества в индустрии ПС

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

Развитие отечественной индустрии ПС, по-видимому, следовало бы начи­нать с кардинальных мер по обеспече­нию заказчиков, разработчиков и пользователей ПС информацией о со­временных методах производства вы­сококачественной программной про­дукции, отраженных в международных, региональных и национальных стан­дартах. По некоторым данным, успех любого дела на 25% зависит от инфор­мационного обеспечения. У нас же обеспеченность основной массы заин­тересованных специалистов информа­цией пока недостаточна. Из 28 дей­ствующих международных стандартов и технических отчетов в области про­граммной инженерии в России введе­ны в действие менее четверти.

Введение в действие основополага­ющих международных стандартов по системам качества в России (ГОСТ Р ИСО 9001 - ГОСТ Р ИСО 9003), а также постановление Правительства РФ от 02.02.98 № 113 принесли определен­ные результаты: к середине 1999 г. в Системе сертификации ГОСТ Р было выдано более 300 сертификатов на си­стемы качества предприятий и произ­водств. К сожалению, среди них нет ни одного на производство програм­мных средств.

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

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

В Сборнике руководств (TickIT), раз­работанном Британским компьютер­ным обществом при Министерстве торговли и промышленности Великоб­ритании, приводятся некоторые дан­ные о затратах на подготовку, проведе­ние и использование сертификации третьей степени, касающиеся пред­приятий с числом работающих от 50 до 100 человек. Затраты составляют (в ан­глийских фунтах): оценка соответствия — 6500—9500; сертификат — 500; ис­пользование сертификата — 500. За вычетом времени, потраченного на улучшение документированных эле­ментов системы качества, трудозатра­ты органа по сертификации распреде­ляются так:

предварительная экспертиза 15—30 человек/дней;

сертификация 10—12 человек/дней;

надзор 5—10 человек/дней.

Прибыль. Прибыль, получаемая за счет внедрения систем качества, в ос­новном достигается благодаря улучше­нию качества ПС и уменьшению числа ошибок. Зарубежные обозреватели приводят данные о том, что для компа­нии с оборотом 3 млн у.е. в год расхо­ды, связанные с обнаружением и уст­ранением ошибок, составляют около 600 тыс. у.е. (20% оборота), а сэконом­ленные средства за счет уменьшения числа ошибок, вероятно, составят 150—300 тыс. у.е. Кроме того, не ме­нее существенная выгода может быть получена за счет роста доверия заказ­чиков и покупателей.

Проблемы. Рассмотренные здесь пионерные фирмы — производители программных средств при создании систем качества, соответствующих требованиям международных стандар­тов ИСО серии 9000, столкнулись с оп­ределенными трудностями и пробле­мами. Отметим некоторые из них:

1) ограниченность и несогласован­ность действующей нормативной базы. Из упомянутых серий основополагаю­щих международных стандартов в Рос­сии введено в действие менее трети, а стандартов инженерии качества ПС — десятая часть. При этом показатели ка­чества ПС, например, определяются тремя не согласованными между со­бой, устаревшими стандартами (ГОСТ 28195-89, ГОСТ 28806-90, ГОСТ Р ИСО/ МЭК 9126:93). А ведь каждый стандарт должен восприниматься как эталон, признанная норма, норма совершен­ства;

2) отсутствие методических руководств по созданию систем качества, аналогичных, например, упомянутым руководствам ТickIT;

3) крайне низкий уровень информа­ционного обеспечения. Рабочие мате­риалы ИСО/МЭК доступны узкому кру­гу лиц, не анализируются и не распрос­траняются;

4) специфика свойств и жизненного цикла программной продукции, отсут­ствие опыта в странах СНГ по созда­нию систем качества этой продукции. Стандарт ИСО 9000-3, содержащий ру­ководства по применению ИСО 9001 при разработке, испытании, инсталля­ции и сопровождении ПС с учетом их специфики в России, в действие не введен;

5) отсутствие специализированных органов по сертификации програм­мной продукции;

6) игнорирование заказчиками влия­ния систем качества на качество и се­бестоимость продукции.

Остановимся более подробно на основных стандартах.

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

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

В России разработка и испытания ав­томатизированных систем (АС), в част­ности ПС, регламентированы ГОСТ 34.601—90. Стадии создания АС, ГОСТ 34.602—89. ТЗ на создание АС, ГОСТ 34.603—92. Виды испытаний АС. Одна­ко создание, сопровождение и развитие прикладных ПС для нынешних инфор­мационных систем в этих стандартах от­ражены недостаточно, а отдельные их положения устарели с точки зрения по­строения современных распределенных комплексов прикладных программ вы­сокого качества в системах управления и обработки данных с различной архи­тектурой. Поэтому целесообразно вы­бирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информа­ции и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функ­ционирования, они создаются больши­ми коллективами специалистов в тече­ние длительного времени .

ISO 12207: 1995
Наиболее полно и подробно ЖЦ, тех­нология создания и обеспечения качест­ва сложных ПС отражены в двух пред­ставленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств. Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

— основы жизненного цикла ПС и определяющие работы;

— процессы, поддерживающие жиз­ненный цикл ПС;

— организация и управление жизнен­ным циклом ПС.

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

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

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

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

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

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

В разделе 6 представлено около 70 технологических работ, поддерживаю­щих ЖЦ ПС. Процессы документирова­ния ПС (6.1) охватывают планирование и регламентирование документирова­ния, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комп­лекта документации на ПС. Конфигу­рационное управление (6.2) включает план реализации версий как часть об­щего плана управления проектом, ре­комендации по конфигурационной идентификации, контролю, учету, от­четности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирова­ния, методологии, процедур и стандар­тов качества в соответствии с контрак­том и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в про­цессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Вери­фикация ПС (6.4) включает организа­цию, планирование и техническое обес­печение. Представлена структура контракта на верификацию, содержа­ние процесса, состав требований, про­ектирование процесса верификации, обобщение и документирование резуль­татов. Валидация (6.5) — удостовере­ние правильности (аттестация) — должна гарантировать полное соответ­ствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее вы­полнение независимыми специалиста­ми путем тестирования во всех возмож­ных ситуациях исходных данных. По существу, этот процесс аналогичен сер­тификации, которая в стандарте не упо­минается.

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

Раздел 7 посвящен процессам орга­низации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, про­изводством и средствами для обеспече­ния прикладных процессов по созда­нию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструкту­ры (7.2) включают выбор и установле­ние аппаратных и программных средств, технологии, стандартов и способов об­служивания, используемых для разра­ботки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура дол­жна модифицироваться и сопровож­даться в соответствии с изменениями требований к проекту и подлежит кон­фигурационному управлению. Совер­шенствование ЖЦ ПС (7.3) подразуме­вает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходи­мые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответству­ющему плану.

В приложении А (нормативное) из­ложены основы преобразования и обоб­щения базовой структуры этого между­народного стандарта для конкретного проекта. Следует подчеркнуть необхо­димость реализации двух важнейших вариантов адаптации положений и ре­комендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руко­водство по процессам адаптации и пре­образования ЖЦ ПС для конкретного проекта, а также рекомендации по воз­можным изменениям ряда работ из раз­делов 5 и 6 стандарта в зависимости от характеристик объекта.

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

— анализ содержания контракта, под­держанного методиками, обеспечиваю­щими качество ПС;

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

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

— планирование обеспечения качест­ва компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведе­ния разработки;

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

— измерения характеристик продук­ции и процессов ее создания, а также регистрацию данных о достигнутом ка­честве ПС и их компонентов;

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

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

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

— формализации состава, содержания и процессам утверждения документации;

— управлению конфигурацией версий ПС и проведению изменений в програм­мах и данных.

Адаптация процессов и работ в стан­дартах жизненного цикла программных средств к характеристикам конкретных проектов.
Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и страте­гиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на спо­соб создания, применения и сопровожде­ния ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедре­нием объектно-ориентированного анали­за и проектирования, а также методов бы­строй разработки прикладных программ, CASE-систем и языков четвертого поко­ления. В новых технологиях сокращаются стадии непосредственного создания про­граммных и информационных компонен­тов и детализируются процессы систем­ного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартиза­ции интерфейсов компонентов в создава­емых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество созда­ваемых ПС и возможности их эффектив­ного итерационного развития длительное время в многочисленных версиях.

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

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

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

Выводы
На мой взгляд, проблема внедрения в российских компаниях – разработчиках ПС систем качества очень актуальна. Она актуальна как для производителей “серьёзных” программ для предприятий, так и для производителей программ для населения – мультимедийных продуктов, справочников, игр. У наших разработчиков очень высокий потенциал, это доказывает и то, что лучшие российские программы с успехом продаются на западе (Fine Reader – распознаватель текста, AVP – антивирусная программа), и то, что многие программисты работают в престижных иностранных компаниях (Алексей Пажитнов – автор тетриса, работает в Microsoft). Введение систем качества могло бы позволить нашим компаниям достигнуть нового уровня производительности, возможно, сократить общие издержки, повысить качество выпускаемых программ. Тогда бы они смогли быть более конкурентоспособными как на российском рынке, так и на мировом. Но… С этим связаны масса проблем, главными из которых, на мой взгляд, являются:
  • невысокий платёжеспособный спрос потребителей (слишком большая доля дешёвой пиратской продукции)
  • финансовая неустойчивость большинства компаний, не так много инвестиций
  • плохо разработанные на государственном уровне стандарты в этой области, а самим компаниям это пока чересчур дорого
  • не информированность работников компаний, их руководителей.

umotnas.ru

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

Новоуральский политехнический институт

Московского Инженерно ФИзического института

(технического университета)

Кафедра Экономики и управления

Реферат по предметуУправление качествомна тему:

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

Исполнитель:

студент гр. 2ИЭ-56Д

Афонасьев А. Ю.

Принял:

Эйшинский Е. Р.

НОВОУРАЛЬСК

2000

Введение

Не для кого не секрет, что в настоящее время компьютерная техника, а вместе с ней и программное обеспечение достаточно глубоко проникли в нашу жизнь. Практически ни одно современное производство не может обойтись в той или иной степени от применения вычислительной техники. Существующая тенденция на постоянное увеличение объёма информации в современном мире приводит ко всё большей роли программных продуктов – информационных систем, баз данных, и т. д. И производство, и обычные люди попадают во всё большую «зависимость» от компьютеров и ПО (программного обеспечения). От надёжности ИС (информационных систем) зависит уже очень многое. Поэтому сейчас во всём мире всё большее внимание обращается на качественные характеристики ПО. В связи с этим принимаются международные, отраслевые стандарты, стандарты предприятий – производителей ПО. Уделяется внимание соответствующей сертификации предприятий. Крупные разработчики внедряют у себя комплексные автоматизированные технологии управления проектами. Всё это позволяет поднимать качество ПО, обеспечивать конкурентоспособность своих продуктов. А что происходит у нас в стране? Также происходит развитие фирм – разработчиков ПО. Но по большому счёту рынок занят продуктами зарубежного производства (при этом по большинству – контрфактными). Исключение составляют программы, где необходима привязка к российским условиям (бухгалтерские программы). Доля программной продукции России вместе с други­ми странами СНГ в объеме мирового рынка составляет менее 1%.

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

Рассмотрим существующие основные стандарты в области разработки ПО.

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

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

Международная практика показыва­ет, что наиболее успешно эта задача решается на основе системного подхо­да, предусматривающего создание на предприятиях систем качества (сово­купности организационной структуры, методик, процессов и ресурсов, необ­ходимых для осуществления общего руководства качеством — ИСО 8402), соответствующих требованиям стан­дартов ИСО серии 9000.

В настоящее время стандарты ИСО серии 9000 кардинально пересматри­ваются. Предполагается, что новая версия трех базовых стандартов (ИСО 9000:2000, ИСО 9001:2000 и ИСО 9004:2000) с несколькими технически­ми отчетами заменит всю ныне дей­ствующую серию стандартов (около 20 наименований). Примечательно, что ввод в действие новых стандартов не потребует реконструкции действующих систем качества. Для облегчения пере­хода к стандартам версии 2000 г. будут разработаны специальные методичес­кие указания.

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

Стандарты инженерии качества ПС

Упоминаемые здесь стандарты явля­ются общими для всех видов продук­ции и услуг. Но программная продук­ция специфична. Для контроля и оцен­ки ее качества, управления качеством, создания эффективных систем обеспе­чения качества нужны стандарты, учи­тывающие эту специфику. В связи с по­вышением требований к качеству ПС последние пять-шесть лет ПК 7 «Про­граммная инженерия» ИСО/МЭК/СТК 1/ПК 7 (180/IЕС/JTC 1/SС 7) интенсив­но работает в области стандартизации инженерии качества ПС.

Группа планирования работ ПК 7 в 1996 г. разработала программу стан­дартизации в области инженерии ПС (SWEP), включающую общие проблемы и требования инженерии ПС, с предло­жениями путей их решения в рамках системы международных стандартов.

Введены в действие следующие стандарты:

ИСО/МЭК 9126:1991 «Оценивание программного продукта. Характерис­тики качества и руководства по их при­менению»;

ИСО/МЭК 12119:1994 «Информаци­онная технология. Пакеты програм­мных средств. Требования к качеству и испытания»;

ИСО/МЭК 12207:1995 «Информаци­онная технология. Процессы жизнен­ного цикла программного средства»;

ИСО/МЭК 15026:1998 «Информационная технология. Уровни целостности систем и программных средств».

На стадии согласования находятся стандарты:

ИСО/МЭК 9126 «Информационная технология. Характеристики и метрики качества программных средств» (ч. 1: Модель качества; ч. 2: Внешние метри­ки; ч. 3: Внутренние метрики; ч. 4: Пользовательские методики).

Разработана серия стандартов ИСО/ МЭК 14598 «Оценивание программно­го продукта» (ч. 1: Общие положения; ч. 2: Планирование и управление; ч. 3: Оценивание разработчиком; ч. 4: Оце­нивание покупателем; ч. 5: Оценивание оценщиком; Ч. 6: Документирование оценочных модулей). Части 1—5 введе­ны в действие.

Разработана и в 1998 г. введена в действие серия документов типа ТО (Технический отчет) «Информационная технология — Оценка процессов жиз­ненного цикла программных средств» ИСО/МЭК/ТО 15504 (части 1—4, 6—9). Эти документы устанавливают крите­рии и методы оценки процессов жиз­ненного цикла ПС (ИСО/МЭК 12207:1995) с целью определения их способности обеспечить требуемый уровень качества ПС.

Введены в действие международные стандарты по управлению документи­рованием ПС (ИСО/МЭК 6592, 9127, 9294,1 5910) и др.

Системы качества в индустрии ПС

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

Развитие отечественной индустрии ПС, по-видимому, следовало бы начи­нать с кардинальных мер по обеспече­нию заказчиков, разработчиков и пользователей ПС информацией о со­временных методах производства вы­сококачественной программной про­дукции, отраженных в международных, региональных и национальных стан­дартах. По некоторым данным, успех любого дела на 25% зависит от инфор­мационного обеспечения. У нас же обеспеченность основной массы заин­тересованных специалистов информа­цией пока недостаточна. Из 28 дей­ствующих международных стандартов и технических отчетов в области про­граммной инженерии в России введе­ны в действие менее четверти.

Введение в действие основополага­ющих международных стандартов по системам качества в России (ГОСТ Р ИСО 9001 - ГОСТ Р ИСО 9003), а также постановление Правительства РФ от 02.02.98 № 113 принесли определен­ные результаты: к середине 1999 г. в Системе сертификации ГОСТ Р было выдано более 300 сертификатов на си­стемы качества предприятий и произ­водств. К сожалению, среди них нет ни одного на производство програм­мных средств.

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

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

В Сборнике руководств (TickIT), раз­работанном Британским компьютер­ным обществом при Министерстве торговли и промышленности Великоб­ритании, приводятся некоторые дан­ные о затратах на подготовку, проведе­ние и использование сертификации третьей степени, касающиеся пред­приятий с числом работающих от 50 до 100 человек. Затраты составляют (в ан­глийских фунтах): оценка соответствия — 6500—9500; сертификат — 500; ис­пользование сертификата — 500. За вычетом времени, потраченного на улучшение документированных эле­ментов системы качества, трудозатра­ты органа по сертификации распреде­ляются так:

предварительная экспертиза 15—30 человек/дней;

сертификация 10—12 человек/дней;

надзор 5—10 человек/дней.

Прибыль.Прибыль, получаемая за счет внедрения систем качества, в ос­новном достигается благодаря улучше­нию качества ПС и уменьшению числа ошибок. Зарубежные обозреватели приводят данные о том, что для компа­нии с оборотом 3 млн у.е. в год расхо­ды, связанные с обнаружением и уст­ранением ошибок, составляют около 600 тыс. у.е. (20% оборота), а сэконом­ленные средства за счет уменьшения числа ошибок, вероятно, составят 150—300 тыс. у.е. Кроме того, не ме­нее существенная выгода может быть получена за счет роста доверия заказ­чиков и покупателей.

Проблемы.Рассмотренные здесь пионерные фирмы — производители программных средств при создании систем качества, соответствующих требованиям международных стандар­тов ИСО серии 9000, столкнулись с оп­ределенными трудностями и пробле­мами. Отметим некоторые из них:

1) ограниченность и несогласован­ность действующей нормативной базы. Из упомянутых серий основополагаю­щих международных стандартов в Рос­сии введено в действие менее трети, а стандартов инженерии качества ПС — десятая часть. При этом показатели ка­чества ПС, например, определяются тремя не согласованными между со­бой, устаревшими стандартами (ГОСТ 28195-89, ГОСТ 28806-90, ГОСТ Р ИСО/ МЭК 9126:93). А ведь каждый стандарт должен восприниматься как эталон, признанная норма, норма совершен­ства;

2) отсутствие методических руководств по созданию систем качества, аналогичных, например, упомянутым руководствам ТickIT;

3) крайне низкий уровень информа­ционного обеспечения. Рабочие мате­риалы ИСО/МЭК доступны узкому кру­гу лиц, не анализируются и не распрос­траняются;

4) специфика свойств и жизненного цикла программной продукции, отсут­ствие опыта в странах СНГ по созда­нию систем качества этой продукции. Стандарт ИСО 9000-3, содержащий ру­ководства по применению ИСО 9001 при разработке, испытании, инсталля­ции и сопровождении ПС с учетом их специфики в России, в действие не введен;

5) отсутствие специализированных органов по сертификации програм­мной продукции;

6) игнорирование заказчиками влия­ния систем качества на качество и се­бестоимость продукции.

Остановимся более подробно на основных стандартах.

Стандарты, регламентирующие жизненный цикл ПС

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

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

В России разработка и испытания ав­томатизированных систем (АС), в част­ности ПС, регламентированы ГОСТ 34.601—90. Стадии создания АС, ГОСТ 34.602—89. ТЗ на создание АС, ГОСТ 34.603—92. Виды испытаний АС. Одна­ко создание, сопровождение и развитие прикладных ПС для нынешних инфор­мационных систем в этих стандартах от­ражены недостаточно, а отдельные их положения устарели с точки зрения по­строения современных распределенных комплексов прикладных программ вы­сокого качества в системах управления и обработки данных с различной архи­тектурой. Поэтому целесообразно вы­бирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информа­ции и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функ­ционирования, они создаются больши­ми коллективами специалистов в тече­ние длительного времени .

ISO 12207: 1995

Наиболее полно и подробно ЖЦ, тех­нология создания и обеспечения качест­ва сложных ПС отражены в двух пред­ставленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств. Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

— основы жизненного цикла ПС и определяющие работы;

— процессы, поддерживающие жиз­ненный цикл ПС;

— организация и управление жизнен­ным циклом ПС.

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

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

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

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

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

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

В разделе 6 представлено около 70 технологических работ, поддерживаю­щих ЖЦ ПС. Процессы документирова­ния ПС (6.1) охватывают планирование и регламентирование документирова­ния, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комп­лекта документации на ПС. Конфигу­рационное управление (6.2) включает план реализации версий как часть об­щего плана управления проектом, ре­комендации по конфигурационной идентификации, контролю, учету, от­четности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирова­ния, методологии, процедур и стандар­тов качества в соответствии с контрак­том и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в про­цессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Вери­фикация ПС (6.4) включает организа­цию, планирование и техническое обес­печение. Представлена структура контракта на верификацию, содержа­ние процесса, состав требований, про­ектирование процесса верификации, обобщение и документирование резуль­татов. Валидация (6.5) — удостовере­ние правильности (аттестация) — должна гарантировать полное соответ­ствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее вы­полнение независимыми специалиста­ми путем тестирования во всех возмож­ных ситуациях исходных данных. По существу, этот процесс аналогичен сер­тификации, которая в стандарте не упо­минается.

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

Раздел 7 посвящен процессам орга­низации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, про­изводством и средствами для обеспече­ния прикладных процессов по созда­нию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструкту­ры (7.2) включают выбор и установле­ние аппаратных и программных средств, технологии, стандартов и способов об­служивания, используемых для разра­ботки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура дол­жна модифицироваться и сопровож­даться в соответствии с изменениями требований к проекту и подлежит кон­фигурационному управлению. Совер­шенствование ЖЦ ПС (7.3) подразуме­вает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходи­мые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответству­ющему плану.

В приложении А (нормативное) из­ложены основы преобразования и обоб­щения базовой структуры этого между­народного стандарта для конкретного проекта. Следует подчеркнуть необхо­димость реализации двух важнейших вариантов адаптации положений и ре­комендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руко­водство по процессам адаптации и пре­образования ЖЦ ПС для конкретного проекта, а также рекомендации по воз­можным изменениям ряда работ из раз­делов 5 и 6 стандарта в зависимости от характеристик объекта.

ISO 9000-3: 1991

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

— анализ содержания контракта, под­держанного методиками, обеспечиваю­щими качество ПС;

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

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

— планирование обеспечения качест­ва компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведе­ния разработки;

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

— измерения характеристик продук­ции и процессов ее создания, а также регистрацию данных о достигнутом ка­честве ПС и их компонентов;

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

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

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

— формализации состава, содержания и процессам утверждения документации;

— управлению конфигурацией версий ПС и проведению изменений в програм­мах и данных.

Адаптация процессов и работ в стан­дартах жизненного цикла программных средств к характеристикам конкретных проектов.

Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и страте­гиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на спо­соб создания, применения и сопровожде­ния ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедре­нием объектно-ориентированного анали­за и проектирования, а также методов бы­строй разработки прикладных программ, CASE-систем и языков четвертого поко­ления. В новых технологиях сокращаются стадии непосредственного создания про­граммных и информационных компонен­тов и детализируются процессы систем­ного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартиза­ции интерфейсов компонентов в создава­емых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество созда­ваемых ПС и возможности их эффектив­ного итерационного развития длительное время в многочисленных версиях.

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

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

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

Выводы

На мой взгляд, проблема внедрения в российских компаниях – разработчиках ПС систем качества очень актуальна. Она актуальна как для производителей “серьёзных” программ для предприятий, так и для производителей программ для населения – мультимедийных продуктов, справочников, игр. У наших разработчиков очень высокий потенциал, это доказывает и то, что лучшие российские программы с успехом продаются на западе (Fine Reader – распознаватель текста, AVP – антивирусная программа), и то, что многие программисты работают в престижных иностранных компаниях (Алексей Пажитнов – автор тетриса, работает в Microsoft). Введение систем качества могло бы позволить нашим компаниям достигнуть нового уровня производительности, возможно, сократить общие издержки, повысить качество выпускаемых программ. Тогда бы они смогли быть более конкурентоспособными как на российском рынке, так и на мировом. Но… С этим связаны масса проблем, главными из которых, на мой взгляд, являются:

- невысокий платёжеспособный спрос потребителей (слишком большая доля дешёвой пиратской продукции)

- финансовая неустойчивость большинства компаний, не так много инвестиций

- плохо разработанные на государственном уровне стандарты в этой области, а самим компаниям это пока чересчур дорого

- не информированность работников компаний, их руководителей.

superbotanik.net

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

Новоуральский политехнический институт

Московского Инженерно ФИзического института

(технического университета)

Кафедра Экономики и управления

Реферат по предмету Управление качеством на тему:

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

Исполнитель:

студент гр. 2ИЭ-56Д

Афонасьев А. Ю.Принял:

Эйшинский Е. Р.

НОВОУРАЛЬСК

2000
Введение
Не для кого не секрет, что в настоящее время компьютерная техника, а вместе с ней и программное обеспечение достаточно глубоко проникли в нашу жизнь. Практически ни одно современное производство не может обойтись в той или иной степени от применения вычислительной техники. Существующая тенденция на постоянное увеличение объёма информации в современном мире приводит ко всё большей роли программных продуктов – информационных систем, баз данных, и т. д. И производство, и обычные люди попадают во всё большую «зависимость» от компьютеров и ПО (программного обеспечения). От надёжности ИС (информационных систем) зависит уже очень многое. Поэтому сейчас во всём мире всё большее внимание обращается на качественные характеристики ПО. В связи с этим принимаются международные, отраслевые стандарты, стандарты предприятий – производителей ПО. Уделяется внимание соответствующей сертификации предприятий. Крупные разработчики внедряют у себя комплексные автоматизированные технологии управления проектами. Всё это позволяет поднимать качество ПО, обеспечивать конкурентоспособность своих продуктов. А что происходит у нас в стране? Также происходит развитие фирм – разработчиков ПО. Но по большому счёту рынок занят продуктами зарубежного производства (при этом по большинству – контрфактными). Исключение составляют программы, где необходима привязка к российским условиям (бухгалтерские программы). Доля программной продукции России вместе с други­ми странами СНГ в объеме мирового рынка составляет менее 1%.

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

Рассмотрим существующие основные стандарты в области разработки ПО.

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

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

Международная практика показыва­ет, что наиболее успешно эта задача решается на основе системного подхо­да, предусматривающего создание на предприятиях систем качества (сово­купности организационной структуры, методик, процессов и ресурсов, необ­ходимых для осуществления общего руководства качеством — ИСО 8402), соответствующих требованиям стан­дартов ИСО серии 9000.

В настоящее время стандарты ИСО серии 9000 кардинально пересматри­ваются. Предполагается, что новая версия трех базовых стандартов (ИСО 9000:2000, ИСО 9001:2000 и ИСО 9004:2000) с несколькими технически­ми отчетами заменит всю ныне дей­ствующую серию стандартов (около 20 наименований). Примечательно, что ввод в действие новых стандартов не потребует реконструкции действующих систем качества. Для облегчения пере­хода к стандартам версии 2000 г. будут разработаны специальные методичес­кие указания.

Стандарты ИСО серии 9000 ориентированы не на проверку качества гото­вого продукта, а на принятие мер по предотвращению, оперативному выяв­лению и устранению дефектов в про­дукте, начиная с самых ранних этапов его жизненного цикла.^ Упоминаемые здесь стандарты явля­ются общими для всех видов продук­ции и услуг. Но программная продук­ция специфична. Для контроля и оцен­ки ее качества, управления качеством, создания эффективных систем обеспе­чения качества нужны стандарты, учи­тывающие эту специфику. В связи с по­вышением требований к качеству ПС последние пять-шесть лет ПК 7 «Про­граммная инженерия» ИСО/МЭК/СТК 1/ПК 7 (180/IЕС/JTC 1/SС 7) интенсив­но работает в области стандартизации инженерии качества ПС.

Группа планирования работ ПК 7 в 1996 г. разработала программу стан­дартизации в области инженерии ПС (SWEP), включающую общие проблемы и требования инженерии ПС, с предло­жениями путей их решения в рамках системы международных стандартов.

Введены в действие следующие стандарты:

ИСО/МЭК 9126:1991 «Оценивание программного продукта. Характерис­тики качества и руководства по их при­менению»;

ИСО/МЭК 12119:1994 «Информаци­онная технология. Пакеты програм­мных средств. Требования к качеству и испытания»;

ИСО/МЭК 12207:1995 «Информаци­онная технология. Процессы жизнен­ного цикла программного средства»;

ИСО/МЭК 15026:1998 «Информационная технология. Уровни целостности систем и программных средств».

На стадии согласования находятся стандарты:

ИСО/МЭК 9126 «Информационная технология. Характеристики и метрики качества программных средств» (ч. 1: Модель качества; ч. 2: Внешние метри­ки; ч. 3: Внутренние метрики; ч. 4: Пользовательские методики).

Разработана серия стандартов ИСО/ МЭК 14598 «Оценивание программно­го продукта» (ч. 1: Общие положения; ч. 2: Планирование и управление; ч. 3: Оценивание разработчиком; ч. 4: Оце­нивание покупателем; ч. 5: Оценивание оценщиком; Ч. 6: Документирование оценочных модулей). Части 1—5 введе­ны в действие.

Разработана и в 1998 г. введена в действие серия документов типа ТО (Технический отчет) «Информационная технология — Оценка процессов жиз­ненного цикла программных средств» ИСО/МЭК/ТО 15504 (части 1—4, 6—9). Эти документы устанавливают крите­рии и методы оценки процессов жиз­ненного цикла ПС (ИСО/МЭК 12207:1995) с целью определения их способности обеспечить требуемый уровень качества ПС.

Введены в действие международные стандарты по управлению документи­рованием ПС (ИСО/МЭК 6592, 9127, 9294,1 5910) и др.

Системы качества в индустрии ПС

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

Развитие отечественной индустрии ПС, по-видимому, следовало бы начи­нать с кардинальных мер по обеспече­нию заказчиков, разработчиков и пользователей ПС информацией о со­временных методах производства вы­сококачественной программной про­дукции, отраженных в международных, региональных и национальных стан­дартах. По некоторым данным, успех любого дела на 25% зависит от инфор­мационного обеспечения. У нас же обеспеченность основной массы заин­тересованных специалистов информа­цией пока недостаточна. Из 28 дей­ствующих международных стандартов и технических отчетов в области про­граммной инженерии в России введе­ны в действие менее четверти.

Введение в действие основополага­ющих международных стандартов по системам качества в России (ГОСТ Р ИСО 9001 - ГОСТ Р ИСО 9003), а также постановление Правительства РФ от 02.02.98 № 113 принесли определен­ные результаты: к середине 1999 г. в Системе сертификации ГОСТ Р было выдано более 300 сертификатов на си­стемы качества предприятий и произ­водств. К сожалению, среди них нет ни одного на производство програм­мных средств.

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

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

В Сборнике руководств (TickIT), раз­работанном Британским компьютер­ным обществом при Министерстве торговли и промышленности Великоб­ритании, приводятся некоторые дан­ные о затратах на подготовку, проведе­ние и использование сертификации третьей степени, касающиеся пред­приятий с числом работающих от 50 до 100 человек. Затраты составляют (в ан­глийских фунтах): оценка соответствия — 6500—9500; сертификат — 500; ис­пользование сертификата — 500. За вычетом времени, потраченного на улучшение документированных эле­ментов системы качества, трудозатра­ты органа по сертификации распреде­ляются так:

предварительная экспертиза 15—30 человек/дней;

сертификация 10—12 человек/дней;

надзор 5—10 человек/дней.

Прибыль. Прибыль, получаемая за счет внедрения систем качества, в ос­новном достигается благодаря улучше­нию качества ПС и уменьшению числа ошибок. Зарубежные обозреватели приводят данные о том, что для компа­нии с оборотом 3 млн у.е. в год расхо­ды, связанные с обнаружением и уст­ранением ошибок, составляют около 600 тыс. у.е. (20% оборота), а сэконом­ленные средства за счет уменьшения числа ошибок, вероятно, составят 150—300 тыс. у.е. Кроме того, не ме­нее существенная выгода может быть получена за счет роста доверия заказ­чиков и покупателей.

Проблемы. Рассмотренные здесь пионерные фирмы — производители программных средств при создании систем качества, соответствующих требованиям международных стандар­тов ИСО серии 9000, столкнулись с оп­ределенными трудностями и пробле­мами. Отметим некоторые из них:

1) ограниченность и несогласован­ность действующей нормативной базы. Из упомянутых серий основополагаю­щих международных стандартов в Рос­сии введено в действие менее трети, а стандартов инженерии качества ПС — десятая часть. При этом показатели ка­чества ПС, например, определяются тремя не согласованными между со­бой, устаревшими стандартами (ГОСТ 28195-89, ГОСТ 28806-90, ГОСТ Р ИСО/ МЭК 9126:93). А ведь каждый стандарт должен восприниматься как эталон, признанная норма, норма совершен­ства;

2) отсутствие методических руководств по созданию систем качества, аналогичных, например, упомянутым руководствам ТickIT;

3) крайне низкий уровень информа­ционного обеспечения. Рабочие мате­риалы ИСО/МЭК доступны узкому кру­гу лиц, не анализируются и не распрос­траняются;

4) специфика свойств и жизненного цикла программной продукции, отсут­ствие опыта в странах СНГ по созда­нию систем качества этой продукции. Стандарт ИСО 9000-3, содержащий ру­ководства по применению ИСО 9001 при разработке, испытании, инсталля­ции и сопровождении ПС с учетом их специфики в России, в действие не введен;

5) отсутствие специализированных органов по сертификации програм­мной продукции;

6) игнорирование заказчиками влия­ния систем качества на качество и се­бестоимость продукции.

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

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

В России разработка и испытания ав­томатизированных систем (АС), в част­ности ПС, регламентированы ГОСТ 34.601—90. Стадии создания АС, ГОСТ 34.602—89. ТЗ на создание АС, ГОСТ 34.603—92. Виды испытаний АС. Одна­ко создание, сопровождение и развитие прикладных ПС для нынешних инфор­мационных систем в этих стандартах от­ражены недостаточно, а отдельные их положения устарели с точки зрения по­строения современных распределенных комплексов прикладных программ вы­сокого качества в системах управления и обработки данных с различной архи­тектурой. Поэтому целесообразно вы­бирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информа­ции и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функ­ционирования, они создаются больши­ми коллективами специалистов в тече­ние длительного времени .

ISO 12207: 1995
Наиболее полно и подробно ЖЦ, тех­нология создания и обеспечения качест­ва сложных ПС отражены в двух пред­ставленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств. Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

— основы жизненного цикла ПС и определяющие работы;

— процессы, поддерживающие жиз­ненный цикл ПС;

— организация и управление жизнен­ным циклом ПС.

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

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

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

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

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

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

В разделе 6 представлено около 70 технологических работ, поддерживаю­щих ЖЦ ПС. Процессы документирова­ния ПС (6.1) охватывают планирование и регламентирование документирова­ния, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комп­лекта документации на ПС. Конфигу­рационное управление (6.2) включает план реализации версий как часть об­щего плана управления проектом, ре­комендации по конфигурационной идентификации, контролю, учету, от­четности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирова­ния, методологии, процедур и стандар­тов качества в соответствии с контрак­том и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в про­цессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Вери­фикация ПС (6.4) включает организа­цию, планирование и техническое обес­печение. Представлена структура контракта на верификацию, содержа­ние процесса, состав требований, про­ектирование процесса верификации, обобщение и документирование резуль­татов. Валидация (6.5) — удостовере­ние правильности (аттестация) — должна гарантировать полное соответ­ствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее вы­полнение независимыми специалиста­ми путем тестирования во всех возмож­ных ситуациях исходных данных. По существу, этот процесс аналогичен сер­тификации, которая в стандарте не упо­минается.

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

Раздел 7 посвящен процессам орга­низации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, про­изводством и средствами для обеспече­ния прикладных процессов по созда­нию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструкту­ры (7.2) включают выбор и установле­ние аппаратных и программных средств, технологии, стандартов и способов об­служивания, используемых для разра­ботки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура дол­жна модифицироваться и сопровож­даться в соответствии с изменениями требований к проекту и подлежит кон­фигурационному управлению. Совер­шенствование ЖЦ ПС (7.3) подразуме­вает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходи­мые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответству­ющему плану.

В приложении А (нормативное) из­ложены основы преобразования и обоб­щения базовой структуры этого между­народного стандарта для конкретного проекта. Следует подчеркнуть необхо­димость реализации двух важнейших вариантов адаптации положений и ре­комендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руко­водство по процессам адаптации и пре­образования ЖЦ ПС для конкретного проекта, а также рекомендации по воз­можным изменениям ряда работ из раз­делов 5 и 6 стандарта в зависимости от характеристик объекта.

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

— анализ содержания контракта, под­держанного методиками, обеспечиваю­щими качество ПС;

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

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

— планирование обеспечения качест­ва компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведе­ния разработки;

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

— измерения характеристик продук­ции и процессов ее создания, а также регистрацию данных о достигнутом ка­честве ПС и их компонентов;

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

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

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

— формализации состава, содержания и процессам утверждения документации;

— управлению конфигурацией версий ПС и проведению изменений в програм­мах и данных.^ Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и страте­гиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на спо­соб создания, применения и сопровожде­ния ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедре­нием объектно-ориентированного анали­за и проектирования, а также методов бы­строй разработки прикладных программ, CASE-систем и языков четвертого поко­ления. В новых технологиях сокращаются стадии непосредственного создания про­граммных и информационных компонен­тов и детализируются процессы систем­ного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартиза­ции интерфейсов компонентов в создава­емых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество созда­ваемых ПС и возможности их эффектив­ного итерационного развития длительное время в многочисленных версиях.

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

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

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

Выводы
На мой взгляд, проблема внедрения в российских компаниях – разработчиках ПС систем качества очень актуальна. Она актуальна как для производителей “серьёзных” программ для предприятий, так и для производителей программ для населения – мультимедийных продуктов, справочников, игр. У наших разработчиков очень высокий потенциал, это доказывает и то, что лучшие российские программы с успехом продаются на западе (Fine Reader – распознаватель текста, AVP – антивирусная программа), и то, что многие программисты работают в престижных иностранных компаниях (Алексей Пажитнов – автор тетриса, работает в Microsoft). Введение систем качества могло бы позволить нашим компаниям достигнуть нового уровня производительности, возможно, сократить общие издержки, повысить качество выпускаемых программ. Тогда бы они смогли быть более конкурентоспособными как на российском рынке, так и на мировом. Но… С этим связаны масса проблем, главными из которых, на мой взгляд, являются:
  • невысокий платёжеспособный спрос потребителей (слишком большая доля дешёвой пиратской продукции)
  • финансовая неустойчивость большинства компаний, не так много инвестиций
  • плохо разработанные на государственном уровне стандарты в этой области, а самим компаниям это пока чересчур дорого
  • не информированность работников компаний, их руководителей.

Смотрите также

 

..:::Новинки:::..

Windows Commander 5.11 Свежая версия.

Новая версия
IrfanView 3.75 (рус)

Обновление текстового редактора TextEd, уже 1.75a

System mechanic 3.7f
Новая версия

Обновление плагинов для WC, смотрим :-)

Весь Winamp
Посетите новый сайт.

WinRaR 3.00
Релиз уже здесь

PowerDesk 4.0 free
Просто - напросто сильный upgrade проводника.

..:::Счетчики:::..

 

     

 

 

.