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

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

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

Качество средств и систем информатизации сегод­ня определяется:

• качеством элементной базы средств информати­зации;

• их безопасностью;

• совместимостью с другими средствами;

• уровнем помех;

• степенью экологичности;

• функциональными характеристиками;

• устойчивостью к внешним воздействиям;

• надежностью;

• конструкцией;

• параметрами электропитания;

• соответствием принципам открытых систем.

Качество средств и систем информатизации сегод­ня определяется:

• качеством элементной базы средств информати­зации;

• их безопасностью;

• совместимостью с другими средствами;

• уровнем помех;

• степенью экологичности;

• функциональными характеристиками;

• устойчивостью к внешним воздействиям;

• надежностью;

• конструкцией;

• параметрами электропитания;• соответствием принципам открытых систем.

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

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

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

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

Международный стандарт - стандарт, принятый международным органом, занимающимся стандартиза­цией.

Региональный стандарт — стандарт, принятый региональной организацией по стандартизации.

ГОСТ Р – нормативный документ, являющийся национальным стандартом, утвержденным Центральным органом исполнительной власти по стандартизации – Госстандартом России.

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

Стандарты предприятий разрабатываются и принимаются самими предприятиями.

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

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

Норма – положение, устанавливающее количественные или качественные критерии, которые должны быть удовлетворены.

Регламент – документ, содержащий обязательные правовые нормы и принятый органом власти.

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

Можно выделить несколько основных принципов стандартизации.

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

2. Системность и комплексность стандартизации. Системность - это рассмотрение каждого объекта как части более сложной системы.

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

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

5. Приоритетность разработки стандартов, способствующих безопасности, совместимости и взаимозаменяемости продукции и услуг.

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

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

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

Лицензирование

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

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

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

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

Этапы ЖЦ ПС

1. с малым ЖЦ (до 3 лет)

2. с большим временем ЖЦ (10-20лет),из которых 70-90% приходится на эксплуатацию и сопровождение

Этапы :

1. системный анализ

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

3. эксплуатацию

4. сопровождение

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

Виды поддержки и стадии этапа проектирования.

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

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

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

Процесс разработки ПС делится на стадии:

• техническое проектирование

• рабочее проектирование.

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

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

Все виды работ и задач, выполняемых на этих этапах, сгруппированы для оценки трудоёмкости разработки ПС в 5 групп: анализ разработки, проектирование, программирование, тестирование, внедрение.

Понятия качества ПС

Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей.

Сейчас критериями качества ПС принято считать:

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

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

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

4) эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

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

6) мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.

Спецификация качества ПС

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

Функциональность: завершенность.

Надежность: завершенность, точность, автономность, устойчивость, защищенность.

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

Эффективность: временнaя эффективность, эффективность по памяти, эффективность по устройствам.

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

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

Модифицируемость: расширяемость, структурированность, модульность.

Мобильность: независимость от устройств, автономность, структурированность, модульность.

Ниже даются определения используемых примитивов качества ПС

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

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

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

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

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

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

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

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

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

Понятность — свойство, характеризующее степень в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ИСО [4.4], как согласованность, самодокументированность, четкость и, собственно, понятность.

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

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

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

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

Независимость от устройств — свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях ЭВМ).

Обеспечение надежности основной мотив разработки программных средств

• предупреждение ошибок;

• самообнаружение ошибок;

• самоисправление ошибок;

• обеспечение устойчивости к ошибкам.

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

• борьбе со сложностью,

• обеспечении точности перевода,

• преодоления барьера между пользователем и разработчиком,

• обеспечения контроля принимаемых решений.

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

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

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

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

Методы борьбы со сложностью.

Известны два общих метода борьбы со сложностью систем:

• обеспечения независимости компонент системы;

• использование в системах иерархических структур.

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

Единая система программной документации

• СТАНДАРТЫ ДОКУМЕНТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ.

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

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

Общая характеристика состояния в области документирования ПС. Этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.

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

1. основополагающие и организационно-методические стандарты;

2. стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;

3. стандарты, обеспечивающие автоматизацию разработки программных документов.

ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС

Разработка программных продуктов

Эволюция программного обеспечения

• Язык программирования - это специальный язык, на котором пишут команды для управления компьютером.

• Язык низкого уровня - это язык программирования предназначенный для определенного типа компьютера и отражающий его внутренний машинный код; языки низкого уровня часто называют машинно-ориентированными языками

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

Виды программных продуктов и их структура

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

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

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

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

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

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

Среди множества модулей различают:

• головной модуль - управляет запуском программного продукта (существует в единственном числе);

• управляющий модуль - обеспечивает вызов других модулей на обработку;

• рабочие модули - выполняют функции обработки;

• сервисные модули и библиотеки, утилиты - осуществляют обслуживающие функции.

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

ППП (application program package) - это система программ, предназначенных для решения задач определенного класса.

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

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

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

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

Технология проектирования систем

Методы проектирования.

• При исходящем проектировании

• при восходящем проектировании

• при проектировании методом расширения ядра

наиболее часто используют смешанный подход.

Понятие архитектуры ПС

Архитектура ПС представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем.

Основные задачи разработки архитектуры ПС:

• выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

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

• выделение программных модулей

• определение способов взаимодействия между модулями

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

• цельная программа;

• комплекс автономно выполняемых программ;

• слоистая программная система;

• коллектив параллельно выполняемых программ

Комплекс автономно выполняемых программ состоит из набора программ, такого, что:

• любая из этих программ может быть активизирована (запущена) пользователем;

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

• все программы этого набора применятся к одной и той же информационной среде.

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

• на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоёв;

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

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

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

Тестирование ПС

Тестирование ПС - это процесс выполнения его программ с намерением найти ошибки.

Доказательство-это попытки найти ошибки в программе безотносительно к внешней для программы среде

Контроль (verification) — попытка найти ошибки, выполняя программу в

тестовой, или моделируемой, среде.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация (certification) — авторитетное подтверждение правильности

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

Underwriters Laboratories. При тестировании с целью аттестации выполняется

сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) не является разновидностью тестирования. Хотя

слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.

Тестирование модуля, или автономное тестирование (module testing, unit

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

Тестирование сопряжении (integration testing) — контроль сопряжении

между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing) — контроль

внешнего поведения системы, определенного внешними спецификациями.

Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) — проверка соответствия

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

Тестирование программ как черного и белого ящика

Черный ящик тестирование по входу-выходу.

ЦЕЛЬ:выяснение обстоятельств в которых поведение программы не соответствует спецификации

Белый ящик-позволяет исследовать внутреннюю структуру программы.

Аксиомы тестирования

• Хорош тот тест, для которого высока вероятность обнару­жить ошибку

• Одна из самых сложных проблем при тестировании — решить, когда нужно его закончить

• Не нужно тестировать свою собственную программу.

• Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов.

• Избегайте невоспроизводимых тестов, не тестируйте «слету»

• Готовьте тесты как для правильных, так и для неправильных входных данных.

• Детально изучите результаты каждого теста.

• По мере того как число ошибок, обнаруженных в некотором компоненте программного обеспечения, увеличивается, растет относительная вероятность существования в нем необнаружен­ных ошибок.

• Поручайте тестирование самым способным программистам.

• Проект системы должен быть таким, чтобы каждый модуль подключался к системе только один раз.

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

• Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей.

ГОСТ Р ИСО/МЭК 12119-2000 описывает только функциональное тестирование (тес­тирование по принципу «черного ящика»), а структурное тести­рование не охватывается, потому что для его проведения необ­ходимо наличие исходного кода. В нем рассматривают только тестирование продукта в необходимых для него системах.

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

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

• Установка (инсталляция)

• Выполнение программы

  • Протоколы тестирования

Протоколы тестирования.

Протоколы по каждому тесту должны содержать информацию, достаточную для повторения теста (Руководство ИСО/МЭК 25 [6]). Данная информация должна включать:

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

   - все результаты, связанные с контрольными примерами, включая все ошибки, выявленные при выполнении теста;

   - штат персонала, вовлеченного в тестирование.

Отчет о тестировании

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

   1 Обозначение продукта.

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

   3 Использованные документы (включая их обозначения).

   4 Результаты тестирования описания продукта, документации пользователя, программ и данных.

   5 Перечень несоответствий требованиям.

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

   7 Дата окончания тестирования.

   8 раздел 4 отчета о тестировании (Результаты тестирования) должны быть включены формулировки, соответствующие наименованию каждого пункта 3.1-4.2.

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

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

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

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

Дополнительное тестирование

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

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

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

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

Разработка программных продуктов с элементами искусственного интеллекта. Рынок программных продуктов.

формирование представления знаний с элементами искусственного интеллекта.

Методы:

• правила

• семантические сети

Разработка и стандартизация ПС

ИТ Автоматизация деятельности предприятия

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

Два подхода к решению задачи комплексной автоматизации деятельности предприятия:

• Поэтапная разработка корпоративной системы собственными силами

• Внедрение готовой информационной системы корпоративного уровня