• Результаты применения и контроля соответствия ПС утвержденным профилям.
• Модернизированная версия профилей ЖЦ ПС.
• Модернизированное руководство по применению профилей.
Третий массив описания действий проектировщика:
• Первичный отбор комплекта стандартов для оформления профилей ЖЦ ПС.
• Выбор положений стандартов и доп. нормативных документов для формирования профилей ЖЦ ПС.
• Адаптация и утверждение стандартов и нормативных документов для конкретного профиля ЖЦ ПС.
• Применение профиля ЖЦ ПС, контроль и тестирование комплекса программ.
• Сопровождение и модернизация профилей ЖЦ ПС и утверждение новых версий профилей.
5. ИССЛЕДОВАНИЕ И РАЗРАБОТКА ПОЛНОГО ЖИЗНЕННОГО ЦИКЛА (ЖЦ) БАЗОВОЙ ВЕРСИИ ПРОГРАММНЫХ СРЕДСТВ (ПС) ИНФОРМАЦИОННОЙ СИСТЕМЫ (ИС) При создании полного профиля ЖЦ ПС следует применять выборку из всей совокупности стандартов, детализирующих частные процессы, работы и документы.
Имеющиеся пробелы в профиле ЖЦ ПС следует заполнять спецификациями, нормативными и руководящими документами, вносимыми в проект. Следовательно, разработке полного жизненного цикла базовой версии ПС ИС, должно предшествовать всестороннее исследование ЖЦ ПС, чему, собственно, посвящена важнейшая часть предпроектных – проектных работ. Эта работа комплексная. Во-первых, потому, что исследование перерастает в разработку профиля полного жизненного цикла ЖЦ ПС.
Во-вторых, потому, что задача воспроизводится несколько раз применительно к различным этапам проектирования ИС: от стадии системного анализа до эксплуатации ИС.
6. РАСЧЕТ И ОБЕСПЕЧЕНИЕ НАДЕЖНОСТИ ИС НА СТАДИИ РАБОЧЕГО ПРОЕКТИРОВАНИЯ Надежность функционирования ИС определяется как результат взаимодействия трех важнейших взаимосвязанных компонент, каждой из которых свойственна своя мера надежности и качества:
• компьютерно-сетевых аппаратных средств;
• установленного на них штатного базового программного обеспечения и вспомогательного дополнительного обеспечения, не входящего непосредственно в состав программных средств, поддерживающих ИС и созданных для нее;
• ПС, относящиеся непосредственно к создаваемой ИС.
Если по вопросам оценки качества и надежности аппаратных средств методики расчета, диагностики и обеспечения сложились достаточно давно (с опорой на теорию вероятностей), то с оценкой и обеспечением надежности современных ПС ввиду новизны ситуации и слабой детерменированности модели отказов вопрос выглядит несколько сложнее. Разрешается вопрос главным образом на методологическом уровне, предполагающем набор тех или иных последовательных действий и процедур еще на стадии рабочего проектирования ИС, опирающихся на соответствующие международные стандарты и учитывающие требования по сертификации ПС.
В стандартах и моделях жизненного цикла ПС определено содержание этапов и частных работ при создании и модификации компонент и ПС в целом. Для планирования и управления обеспечением качества и надежности ПС эти модели служат структурной базой объектов, работ и документов при детализации и реализации требований к показателям качества ожидаемых результатов. Необходимая надежность объектов формируется и обеспечивается в процессе выполнения частных работ каждого этапа и окончательно удостоверяется испытаниями и документами при их завершении. Для обеспечения качества и надежности ПС стандартами рекомендуется формулировать требования:
• к объекту разработки на данном этапе - к его программным и информационным компонентам, а также к интерфейсу между ними и с внешней средой;
• к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа;
• к методам и характеристикам средств автоматизации выполнения работ, обеспечивающим необходимую надежность функционирования и качеству ПС;
• к методам и средствам контроля, измерения и документирования качества процессов и результатов выполненных работ.
Требования к инструментальным средствам автоматизации разработки надежных ПС наиболее полно изложены в стандарте IEEE 1209-1992. Стандарт содержит рекомендации по оценке и выбору инструментальных средств, поддерживающих процессы жизненного цикла программных средств, включая процессы управления проектами, процессы разработки и процессы, следующие за разработкой, а также интегральные процессы жизненного цикла ПС. Для оценки и выбора инструментальной среды и CASE-средств стандартом рекомендуется использовать, приведенные ниже, наборы правил и критериев. Группы критериев в стандарте выделены и сформированы с учетом общих требований стандарта ISO 9126:1991 по оценке качества программных продуктов.
Технологическую среду и CASE-средства стандартом рекомендуется описывать и выбирать в соответствии с показателями:
• соответствие стандартам среды, указанным в списке характеристик и функций, поддерживаемых CASE-средством, включая стандарты на: языки, базы данных, репозиторий, коммуникации, графический интерфейс пользователя, документацию, разработку, управление конфигурацией, безопасность, обмен информацией, интеграцию данных, управление или пользовательский интерфейс;
• совместимость с другими инструментальными средствами, включая:
возможность взаимодействия и/или прямого обмена данными, например, с системами подготовки текстов и другими средствами документирования, базами данных, репозиториями и другими CASE - средствами;
• поддержка конкретных методологий, например, объектно-ориентированного анализа, объектно-ориентированного проектирования, проектирования "сверхувниз";
• языковая поддержка, включая: языки программирования, языки определения данных, языки структурированных запросов, графические языки;
• ввод и редактирование спецификаций требований к разрабатываемому ПС, включая требования к функциям, данным, интерфейсам, качеству, производительности, среде функционирования, стоимости и планированию;
• языки спецификаций требований - возможность CASE-средства импортировать, экспортировать или редактировать информацию требований, используя формальный язык, контроль непротиворечивости спецификаций и полноты:
• возможность моделировать аспекты потенциального функционирования разрабатываемой системы, на основе требований и/или проектных данных, имеющихся, в распоряжении CASE-средства, включая эффективность системы, интерфейс оператора, архитектурную производительность (время отклика, загрузку, пропускную способность);
• прототипирование - возможность проектирования и генерации предварительной версии всей системы или ее части, на основе требований и/или проектных данных, имеющихся в распоряжении CASE-средства;
• формирование структуры отчетов, которые будут автоматизирование выпускаться разрабатываемой системой.
• В соответствии со стандартом должен быть обеспечен анализ потенциальной корректности и надежности, входящих в ПС программных компонент, включающий процедуры оценки:
• сложности программ, связанной с числом вложенных циклов, полноты покрытия тестами, оценку количества остающихся ошибок;
• обратную (реверсную) инженерию, т.е. возможность ввода существующего исходного кода в одном или нескольких языках и извлечения из него проектных данных с предоставлением результатов пользователю;
• реструктуризацию исходного кода: ввод исходного кода в одном или нескольких языках, модифицирование его формата и/или структуры и выдача файла исходного кода в том же самом языке;
• анализ исходного кода и предоставления результатов пользователю: измерения размеров, вычисление метрик сложности, генерацию перекрестных ссылок, обзор соответствия использованным стандартам;
• отладка: поддержка идентификации и изоляции ошибок в программе, включая выполнение программ с трассировкой, обеспечение обратного выполнения и ловушек, идентификацию мест, где имеются ошибки и часто выполняемых сегментов в терминах исходного кода.
Требования стандарта к средствам управления проектом сложного ПС включают.
• способность CASE-средства оценивать стоимость, формировать планы и другие показатели проекта по данным, вводимым пользователем;
• управление действиями и ресурсами путем поддержки ввода пользователем данных для планирования проекта, данных о фактических действиях и анализ этих данных, включая: планы, ресурсы компьютеров, назначение персонала, бюджет проекта, а также возможность определения условий выполнения проекта;
• управление тестовыми процедурами: возможность поддержки управления действиями по тестированию и тестовыми программами, планирования действий по тестированию, регистрации результатов тестирования, генерации отчетов о состоянии тестируемых программ;
• управление качеством разрабатываемого ПС - ввод и обработка данных о качестве, их анализ и генерация отчетов об управлении качеством;
• управление действиями по корректировке плана проекта, отчетов о проблемах и дефектах, возникших в ходе выполнения проекта.
Управление конфигурацией версий проекта ПС должно обеспечивать:
• возможность управлять физическим доступом к элементам данных и их изменением, включая возможность специфицировать с помощью идентификаторов компоненты, к которым возможен доступ только для чтения, запрещен доступ, а также возможность отлаживать элементы данных для их модификации, ограничивать доступ к ним до тех пор, пока они не исправлены и не проверены, и отменять ограничения после внесения изменений;
• трассирование модификаций - запись всех модификаций, сделанных в системе при ее разработке или сопровождении;
• управление версиями, возможность записи и выполнения функций управления многократными версиями системы, которые могут иметь общие компоненты;
• учет конфигурационного статуса и предоставление пользователю отчетов, устанавливающих историю, содержимое и статус различных единиц конфигурации, находящихся под управлением;
• генерация выпусков (релизов) ПС и его компонент, возможность поддержки определения пользователем шагов, необходимых для создания версии и автоматизированного выполнения этих шагов;
• возможности автоматического архивирования элементов данных для последующего поиска и применения.
Поддержка разработки технологической и эксплуатационной документации на комплекс программ и его компоненты по требованиям стандарта IEEE 1209 должна включать:
• редактирование текстов - возможность вводить и редактировать данные в текстовом формате;
• графическое редактирование - ввод и редактирование данных в графическом формате;
• редактирование на базе форм - поддержка ввода и редактирования данных в форме, определенной пользователем;
• возможности настольного издательства для оформления документации;
• контроль соответствия выходных результатов CASE-средства стандартам на документацию ПС;
• автоматическое извлечение текстовых и графических данных и генерация документов, специфицированных пользователем.
Критерии удобства применения CASE-средства в процессе разработки ПС включают:
• непротиворечивость пользовательского интерфейса, включая размещение и представление экранных элементов, совместно появляющихся на экране, и методы входа пользователя в систему;
• легкость изучения, измеряемая количеством времени и усилий, которые требуются от пользователя, чтобы понять штатные операции CASE-средства и производительно его использовать;
• адаптируемость CASE-средства силами пользователя к его специфичным потребностям, включая: различные наборы символов, разные способы представления символов и графики, разные форматы данных, методы ввода и вывода;
• качество документации CASE-средства, включая: полноту, ясность, читаемость, полезность;
• доступность и качество учебных материалов, включая: учебные материалы, доступные в режиме on-line, руководства по обучению, курсы обучения и визуальные материалы;
• уровень требований к знаниям пользователя, необходимым для эффективного использования CASE-средства и легкость работы с CASE-средством как для новичков, так и для опытных пользователей;
• общность пользовательского интерфейса между CASE-средством и другими инструментальными средствами, функционирующими в среде проектируемой системы;
• полнота и качество функций помощи в режиме help;
• приемлемое время отклика - время, требующееся для того, чтобы ответить на запрос пользователя в условиях применяемой операционной среды CASEсредства;
• легкость инсталляции CASE-средства, как первоначальной, так и при последующих изменениях.
Критерии оценки эффективности CASE-средства по требованиям стандарта должны учитывать данные для выполняемых проектов и работ, как типичного, так и максимального размеров и сложности:
• оптимальные требования к объему внешней, общей памяти, чтобы обеспечить работу с любыми требующимися и/или генерируемыми данными на приемлемом уровне производительности;
• оптимальные требования к объему оперативной памяти, адресуемой центральным процессором, для того, чтобы CASE-средство могло загружаться и функционировать на приемлемом уровне производительности;
• оптимальные требования к процессору для функционирования CASE-средства на приемлемом уровне производительности;
• производительность, измеряемая как время, в течение которого CASE-средство выполняет характерные задачи, например, время ответа на запрос.
• Важнейшим звеном всего этого комплекса критериальных оценок и подходов к проектированию ИС является планирование и управление обеспечением качества и надежности программ.
Наличие плана обеспечения качества ПС еще не гарантирует его выполнения и достижения заданных характеристик ПС. Реальные ограничения ресурсов, используемых в процессе разработки, изменения внешней среды и другие факторы объективно приводят к отклонениям реализации плана от предполагавшегося.
Величина таких отклонений в значительной степени зависит от принятой технологии разработки, от уровня и характеристик средств автоматизации создания программ.
Это требует введения в проект ИС дополнительных ресурсов, необходимых для обеспечения надежности функционирования программных средств. В различных ПС ресурсы на обеспечение надежности могут составлять от 5-20% до 100-300% от ресурсов, используемых на решение функциональных задач, то есть в некоторых случаях могут превышать последние в 2-4 раза. Дополнительное ресурсное обеспечение опирается на совокупность следующих вложений:
• временная избыточность;
• информационная избыточность;
• программная избыточность, сочетаемая с поиском решений, направленных на достижение максимальной устойчивости программ к внешним воздействиям и изменениям среды функционирования.
При этом необходимо обеспечение безукоризненных откатов при отказах и незавершаемых действиях программы и минимизированное время восстановления системы в любой комбинаторике отказов и осложнений. Само же необнаружение ошибки и ее природы имеет значительно меньшее значение. При нехватке вводимого резерва ресурса имеется альтернативный путь – повышение инерционности внешних объектов, что, однако, отрицательно сказывается на конечной производительности ИС.
В конечном счете, оценка надежности ПС напрямую связана с пропускной способностью системы. Для корректного определения пропускной способности информационной системы с данным ПС нужно иметь и использовать в проекте ИС следующие характеристики функциональных групп программ, учитывающих характеристики внешней среды:
• экстремальные значения длительностей исполнения и маршруты, на которых эти значения достигаются;
• среднее значение длительности исполнения каждой функциональной группы программ на всем возможном множестве маршрутов ПС и его дисперсию;
• распределение вероятностей значений длительностей исполнения функциональных групп программ;
• перечисление реализующихся маршрутов, упорядоченное по значениям их длительностей исполнения.
Соответственно, в состав проектной документации на ИС должны входить следующие документы, поддерживающие интеграцию программных компонент:
• план и методика комплексирования и сборки программных и информационных компонент версии ПС;
• план и методика интеграции версии ПС с аппаратными средствами в реальной операционной и внешней среде;
• тесты, сценарии и генераторы тестовых данных, использованные для отладки программных и информационных компонент и версии ПС в целом;
