С. В. Ченцова. В. Чубарьинформатикакрасноярск 2002 введение
 Скачать 0.92 Mb.
|
|
Программотехника процесса разработки Осуществимость Полнота и непротиворичивость Проектируемость Программируемость Комплексируемость Внедряемость Управляемость конфигурацией Сопровождаемость Снимаемость Управление ресурсами разработки Анализируемость затрат Планируемость и оцениваемость Контролируемость рессурсов 84 Область стандартизации разработки ПО постоянно развивается: наряду со стандартами ISO 9000, ISO 12207, появляются новые, учитывающие современный опыт Цели процесса разработки ПО представлены в таблице 13.1. и подразделяются на обеспечение качества собственно программного обеспечения и обеспечение качества и эффективности процесса разработки, причем, первое невозможно без второго. 13.2. Качество программных продуктов Разработка качественного программного обеспечения это многоэтапный процесс проектирования и программирования. На первом этапе создания программного продукта специфицируются (или определяются) основные системные требования к проекту исходя из его целей, назначения и предметной области на которую они ориентируются – это спецификация системных требований. На втором этапе детализируют требования к программной части проекта – это спецификация требований к программному продукту. Третий этап – программная реализация проекта или программирование. Четвертый этап – это отладка и тестирование программ. Пятый этап – это апробация или опытная эксплуатация программного обеспечения. На этом этапе, разработанное программного обеспечение проверяется в условиях близких к реальным для того, чтобы по возможности оптимизировать основные характеристики созданной системы, повысить логический уровень интерфейса с пользователем, уточнить сопровождающую документацию и т. п. Последний – шестой этап – это промышленная эксплуатация программного обеспечения. В настоящее время, в отличие от недавнего прошлого, повысилось требование к качеству сопровождающей программное обеспечение документации. Из-за ее плохого качества, многие отечественные разработки были вытеснены с рынка программных средств зарубежными, зачастую не лучшими аналогами. Кроме того, массовое использование персональных компьютеров предполагает привлечение большого числа непрофессионалов, которые должны иметь точную и исчерпывающую информацию о приобретенном ими пакете прикладных программ или о компьютере. Такая документация должна содержать системные, по применению, обучающие и справочные руководства. Системные руководства – разъясняют взаимодействие данного программного средства с операционной средой, включая его инсталляцию в конкретных условиях эксплуатации и его системные характеристики. Смысл остальных типов документации понятен из их названия. Надежность программного продукта определяется устойчивостью его функционирования в реальных условиях эксплуатации (т.е. при возможности 85 возникновения особых или аварийных ситуаций в системе, ошибках оператора, ошибках в данных). Основными требованиями, предъявляемыми к качеству программного продукта являются, • Легкость использования – разработка документации, средств управления, структур и форматов входных и выходных данных, в результате чего ПИ становится удобным, естественным, гибким и простым для пользователя. • Удовлетворение потребностей пользователя – учет требований пользователя, относящихся к функциональности создаваемого ПО. • Реализация потенциальных способностей пользователя – обеспечение творческого характера труда и возможность получения дополнительных результатов пользователями, эксплуатирующими ПО. • Ресурсная эффективность – ПО должно выполнять свои функции без лишних затрат ресурсов (машинное время, оперативная память, пропускная способность канала передачи данных и т.п.). • Измеряемость – означает, что ПО можно оснастить контрольно- измерительными средствами и замерить его характеристики для определения узких мест и неэффективности. • Программотехника – до начала совместной работы должны быть специфицированы функциональные, технические и интерфейсные требования к ПО. • Специфицированность. Основными характеристиками специфицированности являются: 1. Полнота спецификаций . Любая часть спецификации должна быть тщательно проработана; 2. Непротиворечивость спецификаций. Спецификация непротиворечива, если ее положения не противоречат друг другу и другим главным спецификациям или целям. 3. Осуществимость спецификаций . Спецификация осуществима, если в течении всего жизненного цикла специфицированной системы прибыль превосходит затраты на ее разработку. 4. Проверяемость спецификаций. Спецификация проверяема, если разработанное ПО может быть подвергнуто проверке на соответствие положениям данной спецификации. • Правильность. ПО должно строго соответствовать всем функциям и интерфейсным спецификациям, а также удовлетворять в пределах допусков всем спецификациям технических характеристик. • Адаптируемость. ПО или его компонента могут быть легко использованы или приспособлены для выполнения новых функций. Включает в себя следующие элементы: 1. Структурность. Подразумевает соблюдение принципов абстракции, модульности и минимального числа компонентов; 86 2. Независимость. ПО независимо в том случае, если на его работу не влияют изменения в устройствах, используемых при его функционировании (аппаратная, программная платформы); 3. Понятность. ПО является понятным, если его назначение и функционирование понятны тем специалистам, которые должны с ним работать. 13.3. Показатели эффективности разработки программного обеспечения Качество программного продукта формируется на всех этапах его производства и зависит от мероприятий, проводимых разработчиками, то есть - от эффективности его разработки, В свою очередь На эффективность разработки ПО могут влиять: Человеческие факторы эффективности процесса разработки • Планируемость – поддержка плана разработки ПО. • Организованность – разработка и непрерывная поддержка структуры должностей и обязанностей. Главными элементами организованности являются: передача прав и ответственности подчиненным, разделение труда между исполнителями. • Укомплектованность персонала.- обеспечение необходимого количества исполнителей соответствующей квалификации • Руководимость – предполагает качественное выполнение следующих функций: создание и поддержание интереса и стимулов, побуждающих людей прилагать все усилия для успеха проекта; • Контролируемость персонала – сравнение результатов работы с поставленными в планах целями, исправление отклонений. • Автоматизируемость – возможность использования ВТ для исполнения рутинной работы. • Управление ресурсами для эффективности процесса разработки ПО. • Анализируемость эффективности затрат – обеспечение тщательного анализа затрат ресурсов при выборе оптимального варианта реализации проекта. • Планируемость, оцениваемость – составление плана выполнения проекта и плана координации ресурсов. • Контролируемость – отслеживание выполнения плана выполнения проекта и плана координации ресурсов. • Программотехника процесса разработки • Осуществимость разработки – определение реализуемости проекта с учетом всего ЖЦ и его преимуществ по сравнению с альтернативными вариантами реализации. • Полнота и непротиворечивость требований – разработка спецификации функций, интерфейсов и технических характеристик ПО таким образом, чтобы описание было достаточным для разработки и не содержало противоречий между своими частями. • Проектируемость – возможность получения полных спецификаций функциональных модулей, структур данных и управления, интерфейсных 87 связей, основных алгоритмов, а также определения условий работы каждой из компонент. • Программируемость – возможность реализации полного набора программных компонент. • Комплексируемость – возможность получения правильно функционирующего ПО из отельных компонентов. • Внедряемость – возможность запуска разработанного ПО в эксплуатацию, обучения пользователей. • Сопровождаемость – возможность поддержания работоспособности системы в процессе ее функционирования. • Снимаемость – возможность планомерной передачи функций данного ПО замещающему его изделию. • Управляемость конфигурации – в любой момент разработки ПИ можно представить его текущую версию, либо любую из предыдущих базовых. Достижение перечисленных выше целей и успех проекта во многом зависит от тщательного анализа и проектирования, обеспечения качества и правильной организации управления работами, использования современных методологий и технологий проектирования ИС, международных стандартов, регламентирующих жизненный цикл и требования к качеству ПО. 13.4. Жизненный цикл программного обеспечения информационных систем Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). Жизненный цикл программного обеспечения − это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [25] (ISO − International Organization of Standardization − Международная организация по стандартизации, IEC − International Electrotechnical Commission − Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. ЖЦ ПО базируется на трех группах процессов: • основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение); • вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем); • организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение). 88 13.4.1.Основные этапы жизненного цикла ПО Среди основных процессов ЖЦ наибольшую важность имеют три: разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Разработка Разработка включает в себя все работы по созданию ПО и его компонентов в соответствии с заданными требованиями.: • оформление проектной и эксплуатационной документации; • подготовку материалов, необходимых для проведения тестирования разработанных программных продуктов; • разработку материалов, необходимых для организации обучения персонала. Разработка является одним из важнейших процессов ЖЦ ПО и включает стратегическое планирование, анализ, проектирование и реализацию. Эксплуатация Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся: • конфигурирование Базы Данных и Рабочих Мест пользователей; • обеспечение пользователей эксплуатационной документацией; • обучение персонала. • Основные эксплуатационные работы включают: • непосредственно эксплуатацию; • локализацию проблем и устранение причин их возникновения; • модификацию ПО; • подготовку предложений по совершенствованию системы; • развитие и модернизацию системы. Сопровождение Службы технической поддержки играют весьма заметную роль в жизни любой КИС. Наличие квалифицированного технического обслуживание на этапе эксплуатации ИС является необходимым условием для решения поставленных перед ней задач, причем ошибки обслуживающего персонала могут приводить к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой ИС. Основными предварительными действиями при подготовке к организации технического обслуживания ИС являются следующие: • выделение наиболее ответственных узлов системы и определение для них критичности простоя. Это позволит выделить наиболее критичные составляющие ИС и оптимизировать распределение ресурсов для технического обслуживания; • определение задач технического обслуживания и их разделение на внутренние (решаемые силами обслуживающего подразделения) и внешние (решаемые специализированными сервисными организациями). Таким образом 89 производится четкое определение круга исполняемых функций и разделение ответственности; • проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции. Основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала; • подготовка плана организации технического обслуживания, в котором необходимо определить этапы исполняемых действий, сроки их исполнения, затраты на этапах, ответственность исполнителей. Обеспечение качественного техобслуживания ИС требует привлечения специалистов высокой квалификации, которые в состоянии решать не только каждодневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях. Вспомогательные процессы Среди вспомогательных процессов одно из главных мест занимает управление конфигурацией, поддерживающее основные процессы ЖЦИС, прежде всего процессы разработки и сопровождения. При разработке проектов сложных ИС, состоящих из многих компонентов, каждый из которых может разрабатываться независимо и иметь несколько версий одной реализации, возникает проблема учета из связей и функций, создания единой структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты ИС на всех стадиях ее ЖЦ. Организационные процессы Управление проектами связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает: • выбор методов и инструментальных средств для реализации проекта; • определение методов описания промежуточных состояний разработки; • разработку методов и средств испытаний созданного ПО; • обучение персонала. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов ИС. Верификация – это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа. Проверка – это процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик ИС исходным требованиям. 90 13.4.2. Структура жизненного цикла ПО Полный ЖЦ ПО включает в себя стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. В общем случае ЖЦ можно разбить на ряд стадий. В общем случае деление на стадии достаточно произвольно. Рассмотрим один из вариантов такого деления, который предлагает корпорация Rational Software. Согласно ее методологии, ЖЦ ПО подразделяется на четыре стадии: • начало; • уточнение; • конструирование; • переход (передача в эксплуатации). Границы каждой стадии определены некоторыми моментами времени, в которые необходимо принимать определенные критические решения и в которые должны быть достигнуты определенные ключевые цели. Начальная стадия На этой стадии устанавливается область применения системы и определяются граничные условия. Для этого необходимо идентифицировать все внешние объекты, с которыми должна взаимодействовать разрабатываемая система, и определить характер этого взаимодействия на высоком уровне. На начальной стадии идентифицируются все функциональные возможности системы и производится описание наиболее существенных из них. Деловое применение включает: • критерии успеха разработки; • оценку риска; • оценку ресурсов, необходимых для выполнения разработки; • календарный план с указанием сроков завершения основных этапов. Стадия уточнения На этой стадии производится анализ прикладной области, разрабатывается архитектурная основа ИС. При принятии решений об архитектуре системы необходимо принимать во внимание всю ее целиком. Это означает, что необходимо описать большинство функциональных возможностей системы и учесть взаимосвязи между отдельными ее составляющими. В конце стадии уточнения проводится анализ архитектурных решений и способов устранения главных элементов риска, содержащихся в проекте. Стадия конструирования На этой стадии разрабатывается законченное изделие, готовое к передаче пользователю. По окончании конструирования определяется работоспособность ПО. Стадия перехода На стадии перехода производится передача разработанного ПО пользователям. При эксплуатации системы в реальных условиях часто возникают различные проблемы, требующие дополнительных работ по 91 внесению корректив в разработанный продукт. Это связано с обнаружением ошибок и недоработок. В конце этой стадии необходимо определить, достигнуты цели разработки или нет. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах. 13.4.3. Модели жизненного цикла ПО Модель жизненного цикла – последовательность осуществления процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ПО и специфики условий, в которых последнее создается и функционирует. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: • каскадная модель (70-85 г.г.); • спиральная модель (86-90 г.г.). Каскадная модель, иногда называемая моделью «водопад» (waterfall) , демонстрирует классический подход к разработке различных систем в любых прикладных областях. Ее основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 17.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Положительные стороны применения каскадного подхода заключаются в следующем [2]: • на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; • выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к 92 предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид (рис. 13.1): Рис. 13.1. Каскадная схема разработки ПО Рис. 13.2. Реальный процесс разработки ПО по каскадной схеме Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью 93 завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 13.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Рис 13.3. Спиральная модель ЖЦ Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований 94 Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Контрольные вопросы и задания: 1. Когда программа становится программным продуктом? 2. Какие требования предъявляются к качеству программного продукта? 3. Перечислите этапы проектирования программного продукта. 4. Какие требования предъявляются к качеству программного продукта? 5. Что такое жизненный цикл ПО. 6. Чем отличаются основные этапы жизненного цикла от процессов жизненного цикла. 7. Дайте определение модели жизненного цикла, сравните области применения каскадной и спиральной модели жизненного цикла 8. Перечислите этапы проектирования программного продукта. 9. Проследите этапы жизненного цикла ПО на примере семейства Windows 9x или другого, популярного программного обеспечения. |