курсовая работа. Учебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах
 Скачать 7.57 Mb.
|
|
Глава 20 Стандартизация ПО. Экономические аспекты создания ПО 1.Краткая характеристика программных средств как объекта разработки и стандартизации В стоимостном исчислении ПО и информационные услуги составляют более половины объёма рынка всех продуктов информационных технологий. На российском рынке программных средств (ПС) заметно определённое завоевание отечественными производителями таких направлений, как бухгалтерские системы, системы распознавания текстов, различные корпоративные и управленческие программы, а также системы распределённой обработки данных. Характеризуя общие тенденции в области информатизации, следует отметить высокую динамичность изменений технических и потребительских свойств ИТ и средств их реализации. В настоящее время срок смены поколений аппаратных и программных средств составляет 3 – 4 года, что предъявляет высокие требования к срокам и качеству их разработки, особенно ПС. Опыт организации работ на всех фазах жизненного цикла ПС показывает, что это сложная, трудоёмкая и длительная работа, требующая высокой квалификации специалистов и новых подходов к проектированию на основе широкого использования методов программной индустрии, стандартизации и сертификации. Чрезвычайно важными показателями для разработчиков и пользователей программной продукции являются трудоёмкость изготовления и сопровождения ПС, а также стоимостные показатели и уровень качества программной продукции. Технические особенности разработки программных средств Рост объёмов и сложности ПС и баз данных (БД) информационных систем (ИС), а также требований к их качеству привели к созданию программной индустрии с большими коллективами специалистов и применению технологий автоматизированного проектирования и сопровождения, базирующихся на стандартах и нормативных документах. Комплекс таких документов должен регламентировать технологические процессы и объекты проектирования комплексов программ на всех этапах их жизненного цикла (ЖЦ). Структура ЖЦ ПС базируется на трёх группах процессов: основные (приобретение, поставка, разработка, эксплуатация, сопровождение); вспомогательные, обеспечивающие выполнение основных (документирование, конфигурационное управление, обеспечение качества, верификация, аттестация, оценка, аудит); организационные (управление проектами, создание инфраструктуры проекта, определение, оценка и совершенствование ЖЦ ПС, обучение).  При этом особое внимание уделяется качеству документации, которое во многом определяет конкурентоспособность программ и БД. При создании сложных ПС и обеспечении их ЖЦ надо сделать выборку нужных стандартов, то есть сформировать весь комплект документов (профиль), обеспечивающий регламентирование всех этапов и работ. Это позволяет строить комплексы ПС из крупных функциональных модулей, отвечающих требованиям стандартов профиля, и применять отработанные проектные решения и методы, обеспечивающие повторное использование компонентов ПС и БД на иных аппаратных и операционных платформах, то есть эффективно решать проблему мобильности и адаптируемости ПС и БД на основе CASE-технологий. Для этого применяют стандартизацию структуры ПС и их интерфейсов с операционной и внешней средой и фиксируют показатели качества ПС, которые не должны снижаться при переносе программ на другие платформы . Экономические особенности разработки программных средств Высокая стоимость и большие ресурсы, используемые при создании сложных ПС и БД, привели к необходимости детального технико-экономического анализа и обоснования проектов ИС до начала их осуществления. Создание ПС и БД не завершается после первичных испытаний и сертификации 1-й версии, и длительное время они развиваются и модифицируются в серию версий в ходе сопровождения разработки и эксплуатации ПС. Программы и данные в ИС являются наиболее гибкими компонентами, подверженными изменению в течение всего их жизненного цикла. Поэтому они должны контролироваться и упорядочиваться участниками проекта. Для координации их действий применяют специальные методы, методики и средства автоматизации конфигурационного управления. Они позволяют на основе отслеживания динамики изменения ПС и БД представить специалистам и руководителям состояние проекта и его компонентов в любой момент времени и не допускать хаоса при модификации программ и данных. Процессы документирования и конфигурационного управления играют стабилизирующую роль во всём ЖЦ ПС. Поэтому они располагаются на первых позициях в стандартах и обеспечивают отражение состояния и динамики проектов. Их строгое выполнение определяет технико-экономические показатели (ТЭП) проекта, его качество, длительность применения и конкурентоспособность ПС и ИС в целом. Освоение основ экономики создания и применения ИС и их компонентов позволяет рационализировать капиталовложения в средства автоматизации, прогнозировать затраты и длительность разработки систем, научно планировать создание крупных ПС и БД. Так как их разработка требует больших затрат и происходит в условиях ограниченных ресурсов, надо осуществлять баланс между достигаемым их качеством и ресурсами для их реализации, поддерживая его на всём ЖЦ. При этом особенно остро стоит задача борьбы с ростом ошибок в сложных ПС и БД, угрожающим безопасности и надёжности ИС . Для их сокращения применяют типизацию проектов ИС в определённых проблемно ориентированных областях, сборочное программирование, процессы, средства и стандарты управления конфигурацией и качеством ПС и БД. Вопросы оценки трудоёмкости разработки ПС в свете требований стандартизации Современный подход к оценке трудоёмкости разработки ПС состоит в учёте особенностей ЖЦ ПС на различных этапах и влияния технологических факторов не только на трудозатраты, но и на уровень качества, надёжность и экономические показатели ПС. Разработка ПС является важнейшим элементом основных процессов ЖЦ и состоит из следующих работ и задач, сгруппированных в 5 групп (этапов) : 1. Анализ разработки: а) подготовка процесса: определение или выбор модели жизненного цикла ПС; документальное оформление выходных результатов в соответствии с процессом документирования; выполнение вспомогательных процессов в соответствии с условиями договора; выбор стандартов, методов, инструментария, языков программирования (если они не установлены в договоре); разработка плана проведения процесса разработки. б) анализ требований: технические требования к системе должны включать: требования к функциям и возможностям системы; коммерческие и организационные требования; требования пользователя; требования безопасности и защиты; эргономические требования; требования к интерфейсам; эксплуатационные требования; требования к сопровождению и квалификационные требования. Технические требования к системе должны быть оформлены документально; оценка и документальное оформление оценки требований к системе с учетом потребностей заказчика, соответствия потребностям заказчика, тестируемости, выполнимости проектирования системной архитектуры, возможности эксплуатации и сопровождения. 2. Проектирование: а) проектирование программной архитектуры (применительно к каждому программному объекту): трансформирование требований к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта; распределение требований к программному объекту между его компонентами; документальное оформление архитектуры программного объекта; разработка и документальное оформление общего (эскизного) проекта внешних интерфейсов и интерфейсов между компонентами объектов; разработка и документальное оформление общего (эскизного) проекта базы данных; разработка и документальное оформление предварительной версии документации пользователя; разработка и документальное оформление предварительных требований к тестированию программного объекта, разработка графика сборки программного продукта; оценка и документальное оформление архитектуры программного объекта и эскизных проектов. б) техническое проектирование ПС: разработка и документальное оформление технического проекта для каждого программного объекта. Компоненты программного объекта должны быть уточнены на уровне программных модулей, которые можно программировать, компилировать и тестировать независимо. Распределение технических требований к компонентам между программными модулями; разработка технического проекта внешних интерфейсов, интерфейсов между программными компонентами и программными модулями; разработка технического проекта базы данных; уточнение документации пользователя; определение и документальное оформление требований к испытаниям и программе испытаний программных модулей; оценка технического проекта и требований к тестированию, документальное оформление оценки. 3. Программирование: а) программирование и тестирование компонентов ПС: разработка и документальное оформление каждого программного модуля и базы данных; разработка и документальное оформление процедур испытаний и данных для тестирования каждого программного модуля и базы данных; тестирование каждого программного модуля и базы данных; уточнение документации пользователя; уточнение программы сборки ПС; оценка запрограммированных элементов программного объекта и документальное оформление оценки; б) сборка ПС: разработка плана сборки и тестирования, документальное оформление плана; сборка и тестирование программных модулей и компонентов, документальное оформление результатов; подготовка к квалификационным испытаниям: разработка и документальное оформление наборов тестов, контрольных примеров, процедур испытаний; оценка и документальное оформление оценки плана сборки, проекта, запрограммированного программного объекта, проведенных испытаний, результатов тестирования, документации пользователя. 4. Квалификационные испытания (тестирование) ПС: проведение квалификационных испытаний на соответствие квалификационным требованиям к программному объекту; уточнение документации пользователя (при необходимости); проведение аудиторской проверки и документальное оформление результатов; доработка программного продукта по результатам аудиторской проверки (при необходимости); подготовка ПС к вводу в действие. 5. Внедрение ПС: а) ввод в действие ПС: разработка и документальное оформление плана ввода в действие программного продукта в среде эксплуатации, определенной в договоре; ввод в действие программного продукта в соответствии с планом и условиями договора; документальное оформление работ; б) обеспечение приемки ПС: обеспечение проведения заказчиком оценки готовности к приемке и приемочным испытаниям; документальное оформление результатов оценки готовности; поставка программного продукта заказчику; первоначальное и непрерывное обучение и поддержка персонала заказчика в соответствии с условиями договора. Вспомогательные процессы ЖЦ 1) Документирование – процесс формализованного описания информации, созданной в процессе или работе жизненного цикла. Данный процесс состоит из набора работ, при помощи которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают те документы, в которых нуждаются все заинтересованные лица. Данный процесс состоит из работ: подготовка процесса; проектирование и разработка; выпуск. 2) Обеспечение качества – процесс обеспечения соответствующих гарантий того, что программные продукты и процессы в жизненном цикле проекта соответствуют установленным требованиям и утвержденным планам. Обеспечение качества должно быть организационно и полномочно независимым от субъектов, непосредственно связанных с разработкой программного продукта. Данный процесс состоит из подготовки процесса; обеспечения продукта; обеспечения процесса; обеспечения систем качества. Организационные процессы ЖЦ 1) Управление – процесс, состоящий из общих работ и задач, которые могут быть использованы любой стороной, управляющей соответствующим процессом. Администратор отвечает за управление продуктом, проектом, работами и задачами соответствующего процесса, который состоит из подготовки и определения области управления; планирования; выполнения и контроля; проверки и оценки; завершения. 2) Создание инфраструктуры – процесс установления и обеспечения инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки. Этот процесс состоит из подготовки процесса; создания инфраструктуры; сопровождения инфраструктуры. 3) Усовершенствование – процесс установления, оценки, измерения, контроля и улучшения любого процесса жизненного цикла ПС. Процесс состоит из создания процесса; оценки процесса; усовершенствования процесса. 4) Обучение – процесс обеспечения первоначального и продолженного обучения персонала. Должно быть запланировано и заранее выполнено обучение персонала с целью готовности его к работам по разработке программного проекта. Данный процесс состоит из подготовки процесса; разработки учебных материалов; реализация плана обучения. Методика оценки трудоёмкости должна охватывать все указанные выше работы процесса разработки ПС, а также вспомогательные и организационные процессы. 2. Основные понятия и положения технологии разработки программных средств ПС современных ИС являются типичными сложными системами со всеми их особенностями (наличие общей задачи и единой цели функционирования, иерархическая система связей, сложность поведения системы и др.), обуславливающими проблемы их проектирования. К ним относятся : 1) проблемы рационального структурного построения ПС, включающие: оптимизацию структуры ПС по критерию максимального использования ресурсов ЭВМ; контроль вычислительного процесса и обеспечение надёжности ПС; обеспечение простой корректировки ПС и др.; 2) проблемы технологии разработки ПС, включающие: разработку моделей алгоритмов и др. компонентов ИС; автоматизацию программирования на основе унификации типовых компонент программ; обеспечение отладки и испытаний программ; автоматизацию изготовления документации и др.; 3) проблемы стандартизации и унификации ПС, включающие: стандартизацию структуры и правил сопряжения программ по передаче управления и по обменной информации; унификацию правил и методов построения ПС, общих правил иерархии и взаимодействия программ и методов организации вычислительного процесса; стандартизацию методов и требований к обеспечению и измерению качества ПС; стандартизацию языков программирования. По длительности ЖЦ ПС можно разделить на 2 класса : а) с малым, б) большим временем жизни. ПС с малым временем ЖЦ (до 3 лет) и объёмом 1 – 10 тысяч команд разрабатываются обычно одним специалистом. ПС с большим временем ЖЦ (10 – 20 лет, из которых 70 – 90 % приходится на эксплуатацию и сопровождение), с объёмом 10 – 1000 тысяч команд разрабатываются большими коллективами специалистов и создаются на основе промышленного регламентированного проектирования. ЖЦ таких программ включает в себя этапы: системный анализ, проектирование, эксплуатацию, сопровождение. Наиболее специфическим, трудно формализуемым и тесно связанным с функциональным назначением является этап системного анализа, на котором формируются назначение и основные показатели качества ПС. Этапы проектирования, эксплуатации и сопровождения сильно различаются целями, задачами, методами и средствами. Процесс эксплуатации идёт параллельно и независимо от этапа сопровождения и сводится к исполнению программ на ЭВМ и обеспечению достоверности и надёжности результатов. Этап сопровождения состоит в эксплуатационном обслуживании, развитии функциональных возможностей и характеристик ПС, а также в тиражировании ПС и переносе их на различные типы ЭВМ. Наиболее трудоёмким является этап проектирования, требующий методической, технологической, инструментальной и организационной поддержки. Методическая поддержка включает в себя комплекс стандартов, инструкций и методик, определяющих правила создания программ и конкретизирующих языки проектирования, правила использования символов, структурного построения и другие методические основы процесса создания программ. Технологическая поддержка является детализацией документов методической поддержки, регламентирующей конкретную технологию обеспечения ЖЦ программ. Эти документы определяют допустимую трудоёмкость и длительность каждого этапа и обеспечивают нужное качество при допустимых затратах ресурсов. Инструментальная поддержка состоит из ПС и средств вычислительной техники, обеспечивающих автоматизацию создания ПС и определяющих её программную и аппаратную оснащённость. Процесс разработки ПС делится на стадии: техническое проектирование и рабочее проектирование. Первая стадия включает этапы: структурное проектирование, подготовка технических средств, разработка программ. Вторая стадия включает этапы: завершение разработки программ, отладка программ в статике, комплексная динамическая отладка программ, выпуск машинных носителей, испытания ПС. Важное значение имеют результаты статического анализа программных средств. Статический анализ (СА) – это процесс анализа исходного текста программы без её выполнения на ЭВМ. СА программ проводится: для проверки модульной структуры программного средства, а также логической структуры отдельных модулей и сравнения этих структур с приведенными в программной документации; подготовки исходных данных для проведения динамического анализа ПС и разработки плана тестирования ПС; оценки конструктивных характеристик программы, степени простоты модификации и сопровождения программы; определения наличия несовершенства в программе, неиспользуемых участков программы, лишних переменных; оценки текстовой сложности программы, затрат на ее разработку и освоение; экспертизы идентичности программ при установлении авторства и разрешении правовых споров; определения количественных характеристик при оценке уровня качества программы. Статический анализ начинается со стадии проектирования программы (укрупненный анализ) и продолжается на всех последующих фазах жизненного цикла программного средства. Статический анализ программного средства предусматривает получение следующих характеристик (графических и метрических): модульная структура ПС; логическая структура отдельного программного модуля; характеристика текста программы. Модульная структура анализируемого ПС представляется в виде графа вызовов; списка путей вызовов; матрицы вызовов и достижимости; точек вызовов; метрик иерархии вызовов. Логическая структура отдельного программного модуля представляется в виде графа управления; путей тестирования; метрик структуры управления. Характеристики текста программ включают в себя: статистические данные о комментированности программы и текстовые метрики Холстеда. Кроме этого статический анализ предусматривает определение ряда количественных характеристик, таких как иерархическая и структурная сложность, тестируемость и др. Иерархическая сложность: I = N / L, где N – количество вершин в графе вызовов модулей; L – количество уровней. Иерархическая сложность характеризует среднюю ширину уровня в графе вызовов, т.е. количество проектных решений, принимаемых на отдельном шаге разработки программы. Структурная сложность: S = D / N, где D – количество ребер в графе вызовов модулей; N – количество вершин. Тестируемость – это свойство ПС, заключающееся в их приспособленности к эффективному применению контрольных тестов, зависящей от степени разветвления вычислительного процесса и доступности модулей. Доступность узла (модуля) характеризует структурную вероятность вызова этого модуля, зависящую от разветвленности дерева вызовов. Если показатель тестируемости имеет малое значение, то затрудняется тестирование модулей нижних уровней иерархии, особенно при применении автоматизированных методов тестирования. |