Программа по формированию навыков безопасного поведения на дорогах и улицах «Добрая дорога детства» 2
Скачать 1.39 Mb.
|
| Бухаров М.Н. Разработка и стандартизация программных средств и информационных технологий: Учебное пособие. - М.: Московский университет потребительской кооперации, 2004. - 162 с. Учебное пособие по дисциплине «Разработка и стандартизация программных средств и информационных технологий» для специальности 351400 «Прикладная информатика в экономике» подготовлено в соответствии с учебным планом, утвержденным 26 сентября 2000 г., и учебной программой от 04.02.2002 г. Рецензент - доцент, к.т.н. Бабушкин Н.И. Учебное пособие посвящено разработке и стандартизации программных средств и информационных технологий, применяемых для решения экономических задач. Оно будет полезно студентам старших курсов и дипломникам, обучающимся по специальности «Прикладная информатика в экономике» и по аналогичным специальностям. Одобрено и рекомендовано к изданию решением кафедры информационных систем в экономике от 6. 02. 2004, протокол № 6. © Образовательное учреждение «Московский университет потребительской кооперации», 2004 © Бухаров М.Н., 2004 Содержание
2.1 Каскадная технология разработки программ 7
2.2 Итерационная технология разработки программ 9
3. Экстремальные технологии разработки прикладных программ 17
3.3 Особенности применения экстремальных технологий 28 4. Оценка и аттестация процессов создания и сопровождения прикладных программ 29 4.1 Аттестация организаций-разработчиков прикладных программ 29
.ч
5. Универсальный язык для моделирования программ 44
10. Управление конфигурациями и версиями прикладной программы 54 П. О единой системе программной документации 55
12. Два вида документации для прикладных программ 57 12.1 Документация для разработчиков прикладных программ 57
12.2 Документация для пользователей прикладных программ 66
12.3 Оформление документации 75
13. Управление рисками проекта 76 13.1 Планирование управления рисками 77 4
14. Сопровождение прикладных программ 83
1. Введение В мире разработано несколько десятков методологий и подходов к организации процесса создания программного продукта. Условно их можно поделить на «тяжелые» и «легкие». Тяжелые методологии дают наибольший эффект в крупных компаниях, занятых промышленным выпуском программного обеспечения и готовых на многолетние инвестиции в кардинальную перестройку организационной структуры. Такие подходы обычно дают очень хорошие результаты, но процесс внедрения растягивается на несколько лет. Двум наиболее известным технологиям этого типа посвящена глава 2 настоящего учебного пособия. Легкие методологии предназначены для использования небольшими динамичными компаниями, работающими в условиях очень сжатых сроков, быстро меняющихся требований и необходимости обеспечения достаточно высокого качества. Внедрение таких методологий не требует ни серьезных инвестиций, ни перестройки структуры фирмы для своего внедрения - сотрудникам просто надо договориться о новом способе работы. Для знакомства с этими новыми технологиями прочтите главу 3. Рассмотрению специальных инструментальных средств, применяемых на различных этапах создания прикладных программ, посвящены главы с 5 по 10 учебника. В независимости от используемой технологии разработки важным моментом при создании прикладных программ является разработка документации. Качественная и своевременно выпущенная документация на программу может компенсировать имеющиеся недостатки в программе. Стандартам, составу, содержанию и оформлению документации для прикладных программ посвящены главы 11 и 12 настоящего учебника. В семи из десяти случаях программные проекты заканчиваются полной или частичной неудачей. Поэтому управление рисками в программных проектах уделяется большое значение. Управлению рисками посвящена глава 13 настоящего учебника. Разработка прикладной программы не заканчивается никогда. Пока программа используется, она непрерывно изменяется и совершенствуется. Этот процесс называется сопровождением программы. Ему посвящена глава 14 настоящего учебника. 2. Промышленные технологии разработки прикладных программ Классическая методология создания программного обеспечения, используемая в мире уже не один десяток лет, состоит из шести последовательных этапов - анализ требований, проектирование, кодирование, сборка, тестирование, внедрение и сопровождение. На ее основе разработан целый ряд конкретных популярных моделей. Наиболее известной из них является модель «Водопад» (ее называют также каскадной методологией разработки программ). Модель «Водопад» предусматривает последовательный переход от фазы к фазе - поочередно выполняются определение системных требований, анализ требований к продукту, предварительное и детальное проектирование, кодирование, тестирование, объединение модулей, проверка работы всей системы, комплексное и системное тестирование и внедрение. Последовательная модель основана на возможности четкого определения требований к проекту, что позволяет создавать пилотные прототипы, постепенно увеличивая общие функциональные возможности системы и ведя разработку нескольких модулей параллельно. Главная проблема подобных подходов - экспоненциальный рост времени на устранение выявляемых на последних этапах ошибок (особенно если они связаны с неверно спроектированной архитектурой системы или с плохо сформулированными требованиями). На основе последовательной модели была разработана эволюционная (или спиральная) методология. Она ориентирована на использование в условиях, когда все требования не удается сформулировать заранее. При этом происходит многократное повторение цикла «анализ - проектирование -кодирование - тестирование». 2.1 Каскадная технология разработки программ В каскадной методологии разработки программ выделены следующие стадии.
7
2.1.1 Предпроектный анализ На стадии предпроектного анализа выясняют, нужно ли разрабатывать программу, или можно приспособить уже имеющуюся программу. Делается технико-экономическое обоснование разработки. 2.1.2 Научно-исследовательские работы Стадия проведения научно-исследовательских работ проводится редко и только в случае, если решаемая задача очень сложная и нет достаточно проработанных методов ее решения. На этой стадии ведутся научные исследования и экспериментальные работы. Их целью является создание и обоснование методов, которые будут использоваться в разрабатываемом программном проекте. 2.1.3 Техническое задание На стадии разработки технического задания готовится и утверждается документ, определяющий основные функциональные требования к программе. Техническое задание на программу является документом, определяющим требования и порядок создания (развития или модернизации) прикладной программы. В соответствии с техническим заданием проводится разработка программы и ее приемка при сдаче заказчику. Техническое задание разрабатывают на программу в целом. При этом программа может быть предназначена для работы самостоятельно или в составе другой программы. Дополнительно могут быть разработаны технические задания на части программы: на подсистемы программы, программные модули и т.п. Техническое задание на программу разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии «Предпроектные исследования». 2.1.4 Техническое проектирование Стадия технического проектирования состоит из следующих этапов:
2.1.5 Рабочее проектирование На стадии рабочего проектирования программы выполняется собственно написание текста программы, автономная отладка отдельных модулей и подсистем программы, сборка и комплексная отладка программы. 2.1.6 Приемо-сдаточные испытания Приемо-сдаточные испытания программы служат для проверки заказчиком соответствия характеристик программы техническому заданию. 2.1.7 Опытная эксплуатация Опытная эксплуатация программы проводится для проверки программы в условиях ее будущей эксплуатации с целью выявления трудностей при начале ее массовой эксплуатации. 2.1.8 Эксплуатация и сопровождение Эксплуатация и сопровождение программы - это массовое использование программы по ее назначению с одновременным исправлением недочетов и улучшением, при необходимости, ее характеристик. 2.1.9 Вывод из эксплуатации Вывод программы из эксплуатации осуществляется в плановом порядке редко, только для очень важных программ (например, программ управления ракетными установками). Обычно программы умирают сами по себе, постепенно заменяясь новыми программами. 2.2 Итерационная технология разработки программ Типичным представителем итерационной методологии разработки программ является Rational Unified Process фирмы Rational Software. Корпорация Rational Software, ведущий производитель программных продуктов для создания сложных программных систем. В 1998 году эта компания формализовала технологический процесс разработки программного обеспечения и выпустила на рынок структурированную базу знаний под названием Rational Unified Process. Так (Rational Unified Process) называют также и сам процесс разработки программного обеспечения в соответствии с его описанием в одноименной базе знаний. Цель Rational Unified Process гарантировать высокое качество программного продукта, отвечающего потребностям конечного пользователя, в пределах предсказуемого временного графика и бюджета. 2.2.1 Основные характеристики RUP Rational Unified Process как технология характеризуется следующими свойствами. 1. Это итерационный процесс, позволяющий создавать программные системы путем последовательного совершенствования и конкретизации а эффективных решений. Эти решения основаны на выявлении и устранении рисков проекта на более ранних этапах разработки.
^"ЗЩйШЕНГЕнЯЕпГО *[ I | П Ш Г!ТОД1ЮГ p/foroACTrJ ^ 5»Р рааота :;. <*> ,!а,".ом" Добро пожаяоватьв В.аоопа1 Unified Process 5 1! Потратьте пожалуйста пару '.'; Ч!У авле-ние мннут, чтобы прочитать yiy страницу. **. ЦЬС ьный ак ' ts ^ 5 н paborva '£ %« Ф»гур»р Введение Возможности Краткий обзор ^ ^ \ Нам о работ Ч Н'-ю отиец в" Прочитайте ъ-Т^Г^,,. Тчтайт* ОеваааДе-пдгеи» _. О'-то псяюи действительно больше о "З^^зГ^ стран ицыи§2^ ' ' i ^',>С есьгу41 пхохс- возыожностж; ^"^^у ^f^ar краткого итерации потоков ^ JpeqcTc нлгмгзц знакомы с процесса 'tj?^^-. обзора рабств в •"oiocinjo-e™..TpoC процессом? дроцесса Рабинякя и' В Ш|!ега{ю-г Workflows TI aaworfce,..,,rdAd,,,t«s Начните с Структура ь««не ie«ffam . Й Л>^п1эа> i упраЕляемсто справа j «W уЛ=-—'- -Я мм пРо1ит»й1с ——;";. i Срвдотва .,рллта~« ' " 5^' 3 ^l| ^ ^ . '—-- ,-;,::.,' — р—— •• r,,,:, ,r-p p-g^g;—-— ~-~ '-^ Рис. 1. Интерактивная база знаний Rational Unified Process Rational Unified Process как программный продукт состоит из двух компонентов:
База знаний содержит описание архитектуры процесса и его составляющих (потоки работ и стадии разработки), технологии работы (роли, требования к персоналу, методические рекомендации и т.п.), правила создания различных объектов (моделей, отчетов, планов, документов и т.п.) и порядка использования средств инструментальной поддержки. Rational Unified Process содержит комплект настраиваемых шаблонов. Эти шаблоны позволяют использовать различную информацию, порожденную в процессе разработки, для формирования отчетных документов с использованием MS Word и MS Project. Архитектура Rational Unified Process схематично показана на рисунке 2. В соответствии с методологией RUP процесс разработки представлен в двух измерениях:
стадии пЖСНсавПОТО*"ра60Т I "*"» |»°-~Н«~"РУ-*»"">«1 *г£Г Анализ и проектирование __ _, **•'• ~%^%^._ .. ... Выполнение -^—-" *-—^- Основные потоки работ поддержки Упр. конфигурац. и измен. . •^•••^•и •••^•ь, СрбДЗ ^ЙЗЕВав — -. 1радварИТ. Нт«*|Итар. Нгср. I Hre». j Нтвр. Нтвр. I Нто. I итэра10*м »l ' ig »\ 'yi+i'in+a ян ' ял+\* Игерации Рис. 2. Архитектура Rational Unified Process Rational Unified Process состоит из шести основных рабочих процессом и трех вспомогательных процессов: 1. Деловое моделирование - описывает деловой контекст, в рамках которого будет работать разрабатываемое приложение. 2. Управление требованиями - разработка на основе прецедентов требований к разрабатываемому приложению, контроль их реа лизации и управление изменениями требований. 3. Анализ и проектирование - определение архитектуры создаваемой системы.
Весь процесс состоит из нескольких фаз. Внутри каждой фазы происходит несколько итераций. Итерация представляет полный цикл разработки, от выработки требований во время анализа до реализации и тестирования. Конечным результатом итерации является выпуск готового продукта. 2.2.2 Характеристика фаз проекта Все фазы и итерации подразумевают определенные затраты усилий на снижение рисков. В конце каждой фазы находится четко определенная опорная веха. В ней оценивается степень достижения намеченной цели и не следует ли внести в процесс изменения, прежде чем двигаться дальше. На фазе «Начало» определяются цели системы и устанавливаются рамки проекта. Анализ цели включает выработку критерия успешности, оценку рисков, необходимых ресурсов и разрабатывается укрупненный план с указанием основных опорных вех. Нередко создается исполняемый прототип, демонстрирующий реалистичность концепции. 12 На основании результатов работ в фазе «Начало», принимается решение, стоит ли начинать полномасштабную разработку. На фазе «Уточнение» добиваются стабильности базовой архитектуры программы. Архитектура считается устойчивой, если добавление новых сценариев выполнения основных прецедентов мало изменяют архитектуру проекта. Под архитектурой при этом понимают описание классов и их взаимодействия. Это достигается следующим образом.
Фаза «Уточнение» может реализовываться в течение нескольких итераций. На фазе «Конструирование» итерационно и с приращением разрабатывается «бета-версия» системы. Это подразумевает завершение разработки модели прецедентов, полная разработка модели архитектуры системы, модели реализации и модели тестирования. На этой фазе детализируется конструкция, завершается реализация и проверка программного обеспечения, разработка необходимой документации. Фаза «Конструирование» обычно реализуется в течение нескольких итераций. На стадии «Переход» производится необходимая доработка системы, исправление обнаруженных ошибок, завершение реализации некоторых дополнительных возможностей. Стадия «Переход» обычно реализуется в течение нескольких итераций. В конце стадии «Переход» делается заключение о том, достигнуты или нет цели проекта, и надо ли начинать новый цикл разработки. Подводятся итоги работы над проектом и извлекаются уроки, которые могут улучшить процесс разработки. По рекомендациям RUP количество итераций должно составлять от трех до девяти итераций в проекте. Количество итераций по стадиям и их продолжительность зависят от знания прикладной области, надежности проектной группы, надежности группы разработчиков, сроков/условий поставки готовой системы пользователям и количества людей занятых в разработке. Играют роль и другие факторы: степень знакомства организа- 13 пни с итерационным подходом, уровень автоматизации и обмена информацией и т.п. Обычно продолжительность итерации на стадии «Конструирование» короче продолжительности итерации на стадии «Уточнение». Чем меньше количество персонала, участвующего в проекте, тем менее жесткие требования к длительности итераций. Ненадежная проектная группа и новая, незнакомая, прикладная область требуют увеличения продолжительности и количества итераций на стадиях «Уточнение» и «Переход». Ненадежная группа разработки требует увеличения продолжительности и количества итераций на стадии «Конструирование». 2.2.3 Пример простого шаблона Примером шаблона может служить шаблон для полного и подробного описания прецедента. Шаблон описания прецедента Прецедент <Имя прецедента. Имя имеет вид активного глагольного оборота или эквивалентного оборота с существительным и выражает основную цель действующего лица> Главное действующее лицо <Имя роли или краткое описание действующего лица, которое играет ключевую роль во взаимодействии с системой в рамках данного прецедента> Внешний контекст <В этом пункте цель действующего лица раскрывается чуть более полно> Масштаб <описание границ системы: что находится вне системы, которую на этом этапе мы можем представить себе в виде «черного ящика», с чьей точки точки зрения составлено описание> Уровень <один из трех вариантов - Обобщенный, Цель пользователя, Отдельная функция> Заинтересованные лица <список всех заинтересованных лиц и обзор их ключевых интересов, которые должны быть соблюдены при работе системы> Исходные условия <Состояние мира (системы и ее окружения), которое всегда имеет место перед выполнением прецедента> Минимальный результат <Какие цели будут достигнуты в наихудшем варианте из возможных> Результат успешного завершения <Какие цели будут достигнуты, если работа пройдет без малейших отклонений> Триггер <Событие, при возникновении которого стартует наш пре-цедент> 14 Основной успешный сценарий <В этом разделе шаблона перечисляются все шаги, начиная с события-триггера и заканчивая последним шагом, при котором достигается цель действующего лица. В этом же разделе можно описать процедуру освобождения ресурсов после достижения цели> Формат описания <Шаг #> <Описание выполняемого действия> Расширения <Описание возможных отклонений, если на том или ином шаге основного успешного сценария возникают проблемы> Формат описания <Шаг # Отклонение # ...> <Описание выполняемого действия> Варианты изменения технологий и данных <Описание возможных отклонений, при которых может меняться набор шагов основного успешного сценария и т.п.> Формат описания <Отклонение #> -^Необходимые изменениях <0тклонение #><Необходимые изменениях Дополнительная информация <0писание остальной полезной информации, которая может понадобиться разработчику. Здесь можно привести ссылки на документы, содержащие описания нефункциональных требований: дизайн, эргономичность, параметры базы данных, производительности и т.д.> 2.2.4 Пример сложного шаблона В большом программном проекте прецеденты описываются в документе «Требования к системе». План этого документа может быть примерно таким. |
Добавить документ в свой блог или на сайт
