Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Требования к технологии






Современная технология проектирования должна обеспечивать:

1. Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех процессов ЖЦ ПО).

2. Гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время.

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

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

5. Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования).

6. Поддержка комплексом согласованных CASE – средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО.

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

Подготовка процесса. Данная работа состоит из следующих задач:

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

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

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

4. Должен быть разработан и документально оформлен план проведения аттестации. План должен определять (но не ограничиваться): a) объекты, подлежащие аттестации; b) задачи, решаемые при аттестации; c) ресурсы, обязанности и график при проведении аттестации; d) процедуры передачи отчетов об аттестации заказчику и другим сторонам.

5. Должен быть реализован план проведения аттестации. Проблемы и несоответствия, обнаруженные при проведении аттестации, должны быть введены в процесс решения проблем. Все возникшие проблемы должны быть решены, а обнаруженные несоответствия устранены. Результаты работ по аттестации должны быть доступны заказчику и другим организациям, участвующим в договоре.

2. Аттестация

Данная работа состоит из следующих задач:

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

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

3 Проведение испытаний с учетом.1 и.2, включая: a) испытания при критических, граничных и особых значениях исходных данных; b) испытание программного продукта на способность изолировать и минимизировать эффект ошибок с постепенным понижением влияния сбоев и запросом помощи оператора при критических, граничных и особых условиях; c) испытание при участии репрезентативно выбранных пользователей, могущих успешно решать свои задачи при использовании данного программного продукта.

4. Подтверждение того, что программный продукт удовлетворяет заявленным возможностям.

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

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

28. Свойства, определяющие качество ПС: Функциональная пригодность, Корректность, Способность к взаимодействию, Защищенность. Для того, чтобы обеспечивать мониторинг создания ПС и информационных систем, необходимо представлять какие свойства ПО в значительной степени определяют качество конечного продукта. Свойства: 1. Функциональная пригодность – способность программного обеспечения выполнять корректно заданную функцию, это наиболее неопределённая и трудно оцениваемая характеристика ПС. 2. Корректность - состоит в формальном определении степени соответствия комплекса реализованных программ требованиям договора на его создание, технического задания и спецификации на программное средство и его компоненты. Корректность обычно устанавливается либо методом сверки входных и выходных документов, либо путём тестирования.

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

3. Способность к взаимодействию, состоящая в том, на сколько качественно компоненты программного средства и баз данных взаимодействуют между собой и компонентами других приложений в различных операционных системах на различных вычислительных платформах. Кроме того, способность к взаимодействию определяется качеством интерфейса, т.е. взаимодействие между программным средством и пользователем. 4. Защищённость – определяет полноту использования доступных средств и методов защиты программного средства от потенциальных угроз и достигнутых при этом безопасности функционирования информационных систем. Различают следующие виды защиты ПС от искажения информации: защита от сбоев аппаратуры; защита от влияния " чужой" программы; защита от отказов " своей" программы; защита от ошибок оператора (пользователя); защита от несанкц. доступа; защита от защиты. Пример: защита программы антивирусным софтом или лицензией. 5. Надёжность. 6. Потребность в ресурсах памяти и производительности компьютера 7. Практичность программного средства. 8. Сопровождаемость. 9. Мобил-ть

5. Виды стандартизованных документов. Программные доки и их сод-е:

1. спецификация – перечень и назначения всех файлов ПС, включая правила документации

2. ведомость держателей подлинников – список предприятий, хранящих подлинники программных док-ов

3. текст программы – запись кодов программы и комментарии к ним

4. описание программы- информация о логической структуре и функционировании программы

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

6. техническое задание – документ, в котором установлены требования, разрешаемые ПС

7. пояснит.записка – обоснование принятых и применяемых технических и экономических решений, схемы и описание алгоритмов, общее описание работы ПС.

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

ü ведомость ЭД, содержащая список таких док-ов;

ü формуляр – документ, который сод. основные хар-ки ПС, состав и свед-я об экспл-ии программы;

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

ü руководство системного программиста – сод.свед-я для проверки и настройки программы при конкретном применении;

ü руководство программиста – сод. свед-я для обслуживания программы в экспл-ии;

ü руководство оператора – сод.подробную информацию для пользователя, необходимую для эффективного исп-ия ПС;

ü описание языка – сод. синтаксис и семантику языка программирования;

ü руководство по техническому обслуживанию – сод. свед-я для прим-я тестовых и диагностических программ при обслуживании технических средств.

Виды стандартизованной проектно-аналитической документации: Постановка задачи; • Техническое задание; Спецификация; Аналитическая записка; Описание технологий; Настройки; Консалтинговый документ; Маркетинговый документ; Нормативный документ; Внутренний регламент, Внешний документ; Организационный документ; Рабочий документ. По основным видам документов разрабатываются стандартные шаблоны, документ должен иметь обязательные части. Постановка задачи — документ, содержащий детальное описание задачи и прикладных требований к ней. Документ должен содержать описание варианта (вариантов) реализации данной задачи на концептуальном уровне. Техническое задание — документ, содержащий, помимо описания прикладных требований, конкретные пути реализации задачи. Если это необходимо, техническое задание должно включать в себя логическую схему данных. Спецификация — документ, содержащий краткое описание задачи и способа ее решения. Аналитическая записка — документ, содержащий аналитическое исследование проблемы и не являющийся заданием на разработку. Описание технологий — документ, описывающий технологическую реализацию различных задач в системе. Настройки — файл, экспортированный из продукта фирмы и содержащий его настройки. Консалтинговый документ — документ, содержащий материалы предпроектного исследования, информационно-технологического консалтинга и пр. Маркетинговый документ — документ, выпускаемый сотрудниками отдела для публикации во внешнем мире. В документы данного типа входят статьи, доклады, рекламные материалы и пр. Нормативный документ — документ, содержащий законодательный акт или инструкцию уполномоченного государственного органа, на основе которого выполняется подготовка проектной документации. Внутренний регламент — документ, содержащий утвержденные организацией для внутреннего использования регламент или инструкцию. Внешний документ — документ, поступивший на фирму извне и содержащий описания технологий, материалы конкурентов, предметные статьи и пр. Организационный документ — документ, регламентирующий работу отдела и фирмы. Рабочий документ — другой документ, не попавший под вышеперечисленную классификацию.

 

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

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

Стандарты бывают следующих типов: 1. Стандарт организации – документ, устанавливающий определённые требования, обязательные для выполнения в данной организации2. Отраслевой стандарт – это документ, сам по себе не являющийся обязательным к исполнению, но устанавливающий определённые требования, характерные для какой либо отрасли3. Национальный стандарт – документ, содержащий требования, которые могут быть распространены в различных отраслях

Эти требования, как правило, являются не обязательными, но могут стать таковыми при наличии ссылок на национальный стандарт в технических регламентах. Кроме того, выделяют международные стандарты, которые в отсутствие аналогичных национальных стандартов играют их роль. Технический регламент – это нормативный документ, имеющий силу закона, устанавливающий обязательные требования при выполнении какой-либо деятельности. Понятие технического регламента введено Федеральным законом о техническом регулировании № 184-ФЗ от 27 декабря 2002 года. Закон разделил понятия технического регламента и стандарта, установив добровольный принцип применения стандартов. Технические регламенты, в отличие от них, носят обязательный характер, однако могут устанавливать только минимально необходимые требования в области безопасности. Технические условия устанавливают технические требования у продукции или услуге, которые выпускаются большим тиражом, серийно. Кроме того, в них должны быть указаны процедуры, с помощью которых можно установить, соблюдены ли данные требования. Технические условия являются техническим документом, который разрабатывается по решению разработчика или по требованию заказчика продукции. Технические условия являются неотъемлемой частью комплекта конструкторской или другой технической документации на продукцию, а при отсутствии документации должны содержать полный комплекс требований к продукции, ее изготовлению, контролю и приемке. Требования, установленные техническими условиями, не должны противоречить обязательным требованиям государственных или межгосударственных стандартов, распространяющихся на данную продукцию. Состав, построение и оформление технических условий должны соответствовать требованиям ГОСТов, входящих в систему ЕСКД (Еди́ ная систе́ ма констру́ кторской документа́ ции). Технические условия и стандарты в соответствии с законом о техническом регулировании не являются обязательными для выпуска продукции за исключением ряда видов продукции, например технических устройств, используемых на опасных производственных объектах.

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

 

 






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.