1. Термины и сокращения, встечающиеся в тексте
(ПС) - программная система
(ПО) - ппрограммное обеспечение
CASE - (Computer Aided Software Engineering)
(ЖЦ ПО) - Жизненный цикл программного обеспечения
(ТК ПО) - Технология конструирования программного обеспечения
(ISO - International Organization of Standardization) - международная организация по
стандартизации
(IEC - International Electro technical Commission) - международная комиссия по
электротехнике
(Acquisition process) - процесс приобретения
(supply process) - процесс поставки
(operation process) - процесс эксплуатации
(maintenance process) - процесс сопровождения
(documentation process) - процесс документирования
(quality assurance process) - процесс обеспечения качества
(verification process) - процесс верификации
(validation process) - процесс аттестации
(joint review process) - процесс совместной оценки
(audit process) - процесс аудита
(problem resolution process) - процесс разрешения проблем
(management process) - процесс управления
(infrastructure process) - процесс создания инфраструктуры
(improvement process) - процесс усовершенствования
(training process) - процесс обучения
(СУБД) - система управления базами данных
RAD - (Rapid Application Development)
(Capability Maturity Model - CMM) - института программной инженерии при
американском университете Карнеги-Меллон.
(ICAM )- интеграция компьютерных и промышленных технологий
(DFD) - диаграммы потоков данных
(ООАП) - объектно-ориентированного анализа и проектирования
(Сlass diagram) - диаграмма классов
(Association End) - конец ассоциации
(state machine) - автомат
(simple transition) - простой переход
(concurrent substates) - параллельные подсостояния
(history state) - историческое состояние
(shallow history state) - недавнее историческое состояние
(synch state) - синхронизирующее состояние
(object lifeline) - линия жизни объекта
("call") - вызвать
("return") - возвратить
("create") - создать
("destroy") - уничтожить
("send") - послать
3. Введение
В настоящее время в условиях развивающегося информационного общества с
учетом всеобщего применения и распространения компьютерных и
телекоммуникационных технологий и систем, а так же в связи с реализацией
программы на создание в стране единого образовательного информационного
пространства появление учебного пособия, освещающего теоретические и
практические вопросы разработки программного обеспечения, особенно актуально.
В представленном учебном пособии достаточно полно изложены понятия
жизненного цикла программного обеспечения, процесс его производства: методы,
технология и инструментальные средства, тестирование, отладка и сопровождение
программ.
На базе основных понятий и определений в области разработки программных
средств возможно освещение проблем документирования, проектирования
программного обеспечения; рассмотрение вопросов технологического цикла
разработки программных систем. Весьма интересными и своевременными для
будущих специалистов современного глобального общества являются разделы об
организации коллективной работы по созданию программ и организации процесса
разработки с применением инструментальных средств поддержки.
4. 1. ТЕХНОЛОГИЯ КОНСТРУИРОВАНИЯ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Основными составляющими технологии конструирования программного
обеспечения являются продукты (программные системы) и процессы,
обеспечивающие создание продуктов. Данный раздел посвящён процессам. Здесь
рассматриваются основные подходы к организации процесса конструирования.
Приводятся примеры классических, современных и перспективных процессов
конструирования, обсуждаются модели качества процессов конструирования.
1.1. Базовые понятия технологии конструирования и жизненного
цикла программного обеспечения
Тенденции развития современных информационных технологий приводят к
постоянному возрастанию сложности программных систем (ПС). Современные
крупные проекты ПС характеризуются, как правило, следующими особенностями:
• сложность описания (достаточно большое количество функций, процессов,
элементов данных и сложные взаимосвязи между ними), требующая тщательного
моделирования и анализа данных и процессов;
• наличие совокупности тесно взаимодействующих компонентов (подсистем),
имеющих свои локальные задачи и цели функционирования;
• отсутствие прямых аналогов, ограничивающее возможность использования
каких-либо типовых проектных решений и прикладных систем;
• необходимость интеграции существующих и вновь разрабатываемых
приложений;
• функционирование в неоднородной среде на нескольких аппаратных
платформах;
• разобщенность и разнородность отдельных групп разработчиков по уровню
квалификации и сложившимся традициям использования тех или иных инструмен-
тальных средств;
• существенная временная протяженность проекта, обусловленная, с одной
стороны, ограниченными возможностями коллектива разработчиков и, с другой сто-
роны, масштабами организации-заказчика и различной степенью готовности
отдельных ее подразделений к внедрению программных систем.
Для успешной реализации проекта объект проектирования должен быть
прежде всего адекватно описан, должны быть построены полные и
непротиворечивые функциональные и информационные модели ПС. Накопленный к
настоящему времени опыт проектирования ПС показывает, что это логически
сложная, трудоемкая и длительная по времени работа, требующая высокой ква-
лификации участвующих в ней специалистов. Однако до недавнего времени
проектирование выполнялось в основном на интуитивном уровне с применением
неформализованных методов, основанных на искусстве, практическом опыте,
экспертных оценках и дорогостоящих экспериментальных проверках качества
функционирования ПС. Кроме того, в процессе создания и функционирования ПС
информационные потребности пользователей могут изменяться или уточняться, что
еще более усложняет разработку и сопровождение таких систем.
В 70-х и 80-х годах при разработке ПС достаточно широко применялась
структурная методология, предоставляющая в распоряжение разработчиков строгие
5. формализованные методы описания ПС и принимаемых технических решений. Она
основана на наглядной графической технике: для описания различного рода моделей
ПС используются схемы и диаграммы. Наглядность и строгость средств
структурного анализа позволяла разработчикам и будущим пользователям системы
с самого начала неформально участвовать в ее создании, обсуждать и закреплять
понимание основных технических решений. Однако широкое применение этой
методологии и следование ее рекомендациям при разработке конкретных ИС
встречалось достаточно редко, поскольку при неавтоматизированной (ручной)
разработке это практически невозможно. Действительно, вручную очень трудно
разработать и графически представить строгие формальные спецификации системы,
проверить их на полноту и непротиворечивость и тем более изменить. Если все же
удается создать строгую систему проектных документов, то ее переработка при
появлении серьезных изменений практически неосуществима. Ручная разработка
обычно порождала следующие проблемы:
• неадекватная спецификация требований;
• неспособность обнаруживать ошибки в проектных решениях;
• низкое качество документации, снижающее эксплуатационные качества;
• затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ПС исторически всегда стояли последними в
ряду тех, кто использовал компьютерные технологии для повышения качества,
надежности и производительности в своей собственной работе.
Перечисленные факторы способствовали появлению программно-
технологических средств специального класса - CASE-средств, реализующих CASE-
технологию создания и сопровождения ПС. Термин CASE (Computer Aided Software
Engineering - Программная инженерия с компьютерной поддержкой) используется в
настоящее время в весьма широком смысле. Первоначальное значение термина
CASE, ограниченное вопросами автоматизации разработки только лишь
программного обеспечения (ПО), в настоящее время приобрело новый смысл,
охватывающий процесс разработки сложных ПС в целом. Теперь под термином
CASE-средства понимаются программные средства, поддерживающие процессы
создания и сопровождения ПС, включая анализ и формулировку требований,
проектирование прикладного ПО (приложений) и баз данных, генерацию кода,
тестирование, документирование, обеспечение качества, конфигурационное
управление и управление проектом, а также другие процессы. CASE-средства
вместе с системным ПО и техническими средствами образуют полную среду раз-
работки ИС.
CASE-технология представляет собой методологию проектирования ПС, а
также набор инструментальных средств, позволяющих в наглядной форме
моделировать предметную область, анализировать на всех этапах разработки и
сопровождения ПС и разрабатывать приложения в соответствии с
информационными потребностями пользователей. Большинство существующих
CASE-средств основано на методологиях структурного (в основном) или объектно
ориентированного анализа и проектирования, использующих спецификации в виде
диаграмм или текстов для описания внешних требований, связей между моделями
системы, динамики поведения системы и архитектуры
Для успешного внедрения CASE-средств организация должна обладать
следующими качествами:
6. • Технология. Понимание ограниченности существующих возможностей и
способность принять новую технологию;
• Культура. Готовность к внедрению новых процессов и взаимоотношений
между разработчиками и пользователями;
• Управление. Четкое руководство и организованность по отношению к
наиболее важным этапам и процессам внедрения.
Если организация не обладает хотя бы одним из перечисленных качеств, то
внедрение CASE-средств может закончиться неудачей независимо от степени
тщательности следования различным рекомендациям по внедрению.
Успешное внедрение CASE-средств должно обеспечить такие выгоды, как:
• высокий уровень технологической поддержки процессов разработки и
сопровождения ПО;
• положительное воздействие на некоторые или все из перечисленных
факторов: производительность, качество продукции, соблюдение стандартов,
документирование;
• приемлемый уровень отдачи от инвестиций в CASE-средства.
Как и в любой инженерной дисциплине, основными составляющими
технологии конструирования ПО являются продукты (программные системы) и
процессы, обеспечивающие создание этих продуктов.
Технология конструирования программного обеспечения (ТКПО) - это есть
система инженерных принципов для создания экономичного ПО, которая надежно и
эффективно работает в реальных компьютерах.
В современных ТКПО различают:
методы;
средства;
процедуры.
Методы обеспечивают решение следующих задач:
• планирование и оценка проекта;
• анализ и оценка проекта;
• проектирование алгоритмов, структур данных и программных
структур;
• кодирование;
• тестирование;
• сопровождение.
Средства (утилиты) ТКПО обеспечивают автоматизированную или
автоматическую поддержку методов. В целях совместного применения утилиты
могут объединяться в системы автоматизированного конструирования ПО - Case-
системы.
Процедуры являются "клеем", который соединяет методы и утилиты так,
чтобы они обеспечивали непрерывную технологическую цепочку разработки.
Процедуры определяют:
• порядок применения методов и утилит
• формирование отчетов, форм по соответствующим требованиям
• контроль, который помогает обеспечивать качество и координировать
изменения
• формирование "вех" (недоделок), по которым руководители оценивают
прогресс.
7. Одним из базовых понятий методологии проектирования ПС является понятие
жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непре-
рывный процесс, который начинается с момента принятия решения о
необходимости его создания и заканчивается в момент его полного изъятия из
эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является
международный стандарт ISO/ IEC 12207 (ISO - International Organization of
Standardization - Международная организация по стандартизации, IEC - International
Electrotechnical Commission - Международная комиссия по электротехнике). Он
определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые
должны быть выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах
процессов:
• основные процессы ЖЦ ПО;
• вспомогательные процессы;
• организационные процессы.
1.1.1 Основные процессы ЖЦ ПО
Процесс приобретения (acquisition process)
Процесс состоит из действий и задач заказчика, приобретающего
программный продукт. Инициирование приобретения заключается в определении
заказчиком своих потребностей в приобретении, разработке или усо-
вершенствовании ПО и анализе требований к системе. Заявочные предложения
должны содержать:
• требования к системе;
• перечень программных продуктов;
• условия и соглашения;
• технические ограничения.
В процессе приемки подготавливаются и выполняются необходимые тесты.
Завершение работ по договору осуществляется в случае удовлетворения всех
условий приемки.
Процесс поставки (supply process)
Процесс охватывает действия и задачи, выполняемые поставщиком, который
снабжает заказчика программным продуктом. Поставщик рассматривает заявочные
предложения и принимает решение согласиться с выставленными требованиями и
условиями или предложить свои, разрабатывает план управления проектом, содер-
жащий организационную структуру проекта, разграничение ответственности,
технические требования к среде разработки и ресурсам и др.
Процесс разработки (development process)
Этот процесс предусматривает действия и задачи, выполняемые
разработчиком, и охватывает работы по созданию ПО и его компонентов в
соответствии с заданными требованиями. Эти требования включают: оформление
проектной и эксплуатационной документации, подготовку материалов,
необходимых для проверки работоспособности и соответствующего качества
программных продуктов, материалов, необходимых для организации обучения
персонала, и т. д. Процесс разработки ПО, как правило, разбивается на следующие
части:
8. • подготовительная работа;
• анализ требований к системе;
• проектирование архитектуры системы;
• анализ требований к ПО;
• проектирование архитектуры ПО;
• детальное проектирование ПО;
• кодирование и тестирование ПО;
• интеграция ПО;
• квалификационное тестирование ПО;
• интеграция системы;
• квалификационное тестирование системы;
• установка ПО;
• приемка ПО.
Анализ требований к системе подразумевает определение ее функциональных
возможностей, пользовательских требований, требований к надежности и
безопасности, требований к внешним интерфейсам и т. д.
Проектирование архитектуры системы на высоком уровне заключается в
определении компонентов ее оборудования, ПО и операций, выполняемых
персоналом системы.
Анализ требований к ПО предполагает определение следующих
характеристик и требований для каждого компонента ПО:
Функциональные возможности, включая характеристики
производительности и среду функционирования компонента;
внешние интерфейсы;
спецификации надежности и безопасности;
требования к используемым данным;
требования к установке и приемке;
требования к пользовательской документации;
требования к эксплуатации и сопровождению.
Кодирование и тестирование ПО охватывают задачи разработки
(кодирования) и документирования каждого компонента ПО и базы данных, а также
тестирования каждого компонента ПО на соответствие предъявляемым к ним
требованиям.
Интеграция ПО предусматривает сборку разработанных компонентов ПО в
соответствии с планом интеграции и тестирование агрегированных компонентов.
Квалификационное требование - это набор критериев или условий, которые
необходимо выполнить, чтобы квалифицировать программный продукт как
соответствующий своим спецификациям и готовый к использованию в условиях
эксплуатации.
Квалификационное тестирование ПО проводится разработчиком в
присутствии заказчика (по возможности) для демонстрации того, что ПО
удовлетворяет своим спецификациям и готово к использованию в условиях эк-
сплуатации.
Интеграция системы заключается в сборке всех ее компонентов, включая ПО
и оборудование. После интеграции система, в свою очередь, подвергается квалифи-
кационному тестированию.
9. Установка ПО осуществляется разработчиком в соответствии с планом в той
среде и на том оборудовании, которые предусмотрены договором. В процессе
установки проверяется работоспособность ПО и баз данных.
Приемка ПО предусматривает оценку результатов квалификационного
тестирования ПО и системы и документирование результатов оценки, которые
проводятся заказчиком с помощью разработчика. Разработчик выполняет
окончательную передачу ПО заказчику в соответствии с договором, обеспечивая
при этом необходимое обучение и поддержку.
Процесс эксплуатации (operation process)
Процесс включает в себя работы по внедрению компонентов ПО в
эксплуатацию, в том числе конфигурирование базы данных и рабочих мест
пользователей, обеспечение эксплуатационной документацией, проведение
обучения персонала и т.д. Также процесс включает в себя и непосредственно
эксплуатацию, в том числе локализацию проблем и устранение причин их
возникновения, модификацию ПО в рамках установленного регламента, подготовку
предложений по совершенствованию, развитию и модернизации системы.
Процесс сопровождения (maintenance process)
Процесс предусматривает действия и задачи, выполняемые службой
сопровождения. Данный процесс активизируется при изменениях (модификациях)
программного продукта и соответствующей документации, вызванных возникшими
проблемами или потребностями в модернизации либо адаптации ПО.
Сопровождение - внесение изменений в ПО в целях исправления ошибок,
повышения производительности или адаптации к изменившимся условиям работы
или требованиям. (Стандарт IEEE-90).
Грейди Буч разделяет термины «сопровождение», «эволюция» и
«сохранение»:
Сопровождение - под этим термином понимается устранение ошибок;
Эволюция - внесение изменений в систему в ответ на изменившиеся
требования к ней.
Сохранение - использование всех возможных способов для поддержания
жизни в устаревшей (дряхлой и распадающейся на части) системе.
1.1.2 Вспомогательные процессы ЖЦ
Процесс документирования (documentation process)
Процесс предусматривает формализованное описание информации, созданной
в течение ЖЦ ПО.
Процесс управления конфигурацией (configuration management process)
При создании проектов сложных ИС, состоящих из многих компонентов,
каждый из которых может иметь разновидности или версии, возникает проблема
учета их связей и функций, создания унифицированной структуры и обеспечения
развития всей системы. Управление конфигурацией позволяет организовать,
систематически учитывать и контролировать внесение изменений в ПО на всех
стадиях ЖЦ.
Конфигурация ПО - это совокупность его функциональных и физических
характеристик, установленных в технической документации и реализованных в ПО.
Процесс обеспечения качества (quality assurance process)
10. Он обеспечивает соответствующие гарантии того, что ПО и процессы его ЖЦ
соответствуют заданным требованиям и утвержденным планам.
Качество ПО - совокупность свойств, которые характеризуют способность ПО
удовлетворять заданным требованиям.
Для получения достоверных оценок создаваемого ПО процесс обеспечения его
качества должен происходить независимо от субъектов, непосредственно связанных
с разработкой ПО. При этом могут использоваться результаты других
вспомогательных процессов (верификация, аттестация, совместная оценка, аудит и
разрешение проблем).
Процесс верификации (verification process)
Верификация - процесс определения того, отвечает ли текущее состояние
разработки, достигнутое на данном этапе, требованиям этого этапа.
Верификация в узком смысле означает формальное доказательство
правильности ПО. Если процесс верификации осуществляется организацией, не
зависящей от поставщика, разработчика или службы сопровождения, то он
называется процессам независимой верификации.
Так как задание на создание ПО обычно создается неформально, а также из-за
того, что понятие ошибки в информационной системе не формализовано, то нельзя
доказать формальными методами (математически) правильность ПС.
Процесс аттестации (validation process)
Аттестация должна гарантировать полное соответствие заданных требований
и созданной системы или программного продукта их конкретному
функциональному назначению.
Под аттестацией ПО обычно понимается подтверждение и оценка
достоверности проведенного тестирования ПО.
Процесс совместной оценки (joint review process)
Он предназначен для оценки состояния работ по проекту и ПО, создаваемого
при выполнении данных работ (действий). Данный процесс может выполняться
двумя любыми сторонами, участвующими в договоре, при этом одна сторона
проверяет другую.
Процесс аудита (audit process).
Аудит — это ревизия (проверка), проводимая компетентным органом (лицом)
в целях обеспечения независимой оценки степени соответствия ПО или процессов
установленным требованиям.
Аудит служит для установления соответствия реальных работ и отчетов
требованиям, планам и контракту. Аудиторы (ревизоры) не должны иметь прямой
зависимости от разработчиков ПО. Они определяют состояние работ, использование
ресурсов, соответствие документации спецификациям и стандартам, корректность
тестирования. Аудит может выполняться двумя любыми сторонами, участвующими
в договоре, когда одна сторона проверяет другую.
Процесс разрешения проблем (problem resolution process)
Процесс предусматривает анализ и решение проблем (включая обнаруженные
несоответствия) независимо от их происхождения или источника, которые
обнаружены в ходе разработки, эксплуатации, сопровождения или других
процессов.
1.1.3 Организационные процессы ЖЦ ПО
11. Процесс управления (management process)
Менеджер отвечает за управление выпуском продукта, управление проектом и
управление задачами соответствующих процессов, таких как приобретение, постав-
ка, разработка, эксплуатация, сопровождение и др.
Процесс создания инфраструктуры (infrastructure process)
Он охватывает выбор и поддержку технологии, стандартов и
инструментальных средств, выбор и установку аппаратных и программных средств,
используемых для разработки, эксплуатации или сопровождения ПО.
Процесс усовершенствования (improvement process)
Усовершенствование процессов ЖЦ ПО направлено на повышение
производительности труда всех участвующих в них специалистов за счет
совершенствования используемой технологии, методов управления, выбора
инструментальных средств и обучения персонала.
Процесс обучения (training process)
Он охватывает первоначальное обучение и последующее постоянное
повышение квалификации персонала.
Приобретение, поставка, разработка, эксплуатация и сопровождение ПО в
значительной степени зависят от уровня знаний и квалификации персонала.
1.1.4 Модели жизненного цикла ПО
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы
разработки ПО. Его регламенты являются общими для любых моделей ЖЦ,
методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает
структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или
выполнить действия и задачи, включенные в эти процессы.
Под моделью ЖЦ понимается структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач, выполняемых на
протяжении ЖЦ.
Модель ЖЦ зависит от специфики информационной системы и специфики
условий, в которых последняя создается и функционирует.
Модель жизненного цикла любого конкретного ПО определяет характер
процесса его создания, который представляет собой совокупность упорядоченных
во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых
необходимо и достаточно для создания ПО, соответствующего заданным
требованиям.
Под стадией создания ПО понимается часть процесса создания ПО,
ограниченная некоторыми временными рамками и заканчивающаяся выпуском
конкретного продукта (моделей ПО, компонентов, документации).
Стадии создания ПО обычно выделяются в следующие группы:
• Формирование требований к ПО;
• Анализ;
• Проектирование;
• Реализация (Кодирование);
• Тестирование и отладка;
• Внедрение и сопровождение;
• Снятие с эксплуатации.
Формирование требований к ПО
12. На стадии формирования требований к ПО, являющейся одной из важнейших,
выполняются следующие работы:
планирование работ, предваряющее работы над проектом.
Основными задачами этапа являются: определение целей разработки,
предварительная экономическая оценка проекта, построение плана -
графика выполнения работ, создание и обучение рабочей группы;
проведение обследования деятельности объекта
организации, в рамках которого осуществляется: предварительно
выявление требований к будущей системе; выявление функциональных
взаимодействий и информационных потоков в объекте, анализ
существующих средств автоматизации Е организации;
построение моделей деятельности объекта/организации,
предусматривающее построение двух видов моделей: модели "AS-IS"
("как есть"), отражающей существующее положение дел в организации
и позволяющей понять, каким образом функционирует данная
организация/объект и модели "ТО-ВЕ" ("как должно быть"),
отражающей представление о новых технологиях работы
организации/объекта.
Анализ и проектирование
Стадии анализ и проектирование включают в себя:
Разработку системного проекта, основу которого составляют
модели проектируемой системы, которые строятся на основе модели
"ТО-ВЕ". На данном этапе дается ответ на вопрос: "Что должна делать
будущая система? ", а именно: определяются архитектура системы, ее
функции, интерфейсы и распределение функций между пользователями
и системой, требования к программным и информационным
компонентам, сроки разработки. Результатом данного этапа является
документ "Техническое задание".
Разработку технического проекта. На этом этапе на основе
системного проекта осуществляется собственно проектирование
системы, включающее проектирование архитектуры системы и
детальное проектирование.
Содержание последующих стадий совпадает в основном с соответствующими
процессами ЖЦ ПО. На каждой стадии могут выполняться несколько процессов, и,
наоборот, один и тот же процесс может выполняться на различных стадиях.
К настоящему времени наибольшее распространение получили следующие
две основные модели ЖЦ:
• каскадная модель (1970-1985 г.);
• спиральная модель (1986-1990 г.).
Каскадная модель
В изначально существовавших однородных информационных системах
каждое приложение представляло собой единое целое. Для разработки такого типа
приложений применялся каскадный подход (другое название «водопадная модель»).
Принципиальной особенностью данного подхода является то, что переход на
следующую стадию осуществляется только после того, как будет полностью
13. завершена работа на текущей стадии, и возврат на пройденные стадии не
предусматривается.
Каждая стадия заканчивается получением некоторых результатов, которые
служили в качестве исходных данных для следующей стадии (рис. 1.1).
Рисунок 1.1 - Каскадная модель разработки ПО
Положительные стороны каскадного подхода:
• на каждой стадии формируется законченный (отвечающий критериям
полноты и согласованности) набор проектной документации;
• выполняемые в логичной последовательности этапы работы позволяют
планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении систем, для
которых в самом начале разработки можно достаточно точно и полно
сформулировать все требования, с тем, чтобы предоставить разработчикам свободу
реализовать их как можно лучше с технической точки зрения. В эту категорию
попадают сложные расчетные системы, системы реального времени и другие
подобные задачи.
Однако в процессе использования этого подхода обнаружился ряд его
недостатков, вызванных прежде всего тем, что реальный процесс создания ПО
никогда полностью не укладывался в такую жесткую схему.
Недостатки каскадного подхода:
• отсутствие обратной связи - решение, принятое на стадии анализа, даже если
происходит его фактическая ревизия на последующих этапах, не пересматривается;
• опаздывание - согласование результатов с пользователем производится
только в точках, планируемых после завершения каждого этапа работы;
• устаревание - модели объекта устаревали вскоре после их утверждения (а
иногда и одновременно с ними).
Процесс создания ПО носит, как правило, итерационный характер: результаты
очередной стадии часто вызывают изменения в проектных решениях более ранних
Исправен
Неисправен
Формировани
е требований
Проектирование
Реализация
Тестирование
Внедрение
Анализ
14. стадий. Уточненную модель иногда называют моделью с промежуточным
контролем или с обратной связью (рис. 1.2). Это обеспечивает большую надежность
по сравнению с классической каскадной моделью, хотя и увеличивает весь период
разработки.
Рисунок 1.2- Каскадная модель с обратной связью
Спиральная модель
Для преодоления перечисленных проблем Боэм в 1986 предложил новую
модель ЖЦ - спиральную (рис. 1.З.).
Ее принципиальной особенностью является то, что разработка представляется
как итеративный процесс, состоящий из одних и тех же этапов, но повторяющихся
много раз.
Спиральная модель делает упор на начальные этапы ЖЦ - анализ и
проектирование. На этих этапах реализуемость технических решений проверяется
путем создания прототипов.
Под прототипом понимается действующий компонент, реализующий
отдельные функции и внешние интерфейсы разрабатываемого ПО.
Каждый виток спирали соответствует созданию фрагмента или версии ПО, на
нем уточняются цели и характеристики проекта, определяется его качество и плани-
руются работы следующей итерации. Таким образом, углубляются и
последовательно конкретизируются детали проекта и в результате выбирается
обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл
создания системы. Неполное завершение работ на каждом этапе позволяет пере-
ходить на следующий этап, не дожидаясь полного завершения работы на текущем.
При итеративном способе разработки недостающую работу можно будет выполнить
на следующей итерации. Главная же задача - как можно быстрее показать
пользователям системы работоспособный продукт, тем самым заново начиная
процесс уточнения и дополнения требований. Спиральная модель не исключает
Формировани
е требований
Проектирование
Реализация
Тестирование
Внедрение
Анализ
15. использования каскадного подхода на завершающих стадиях проекта в тех случаях,
когда требования к системе оказываются полностью определенными.
Рисунок 1.3 - Спиральная ЖЦ
Основная проблема спирального цикла - определение момента перехода на
следующий этап. Для ее решения необходимо ввести временные ограничения на
каждый из этапов жизненного цикла. Переход осуществляется в соответствии с
планом, даже если не вся запланированная работа закончена. План составляется на
основе статистических данных, полученных в предыдущих проектах, и личного
опыта разработчиков.
1.1.5 Методы и технологии проектирования ПО
Методологии, технологии и инструментальные средства проектирования
(CASE-средства) составляют основу проекта любой ПС. Методология реализуется
через конкретные технологии и поддерживающие их стандарты, методики и
инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех
составляющих:
• пошаговой процедуры, определяющей последовательность технологических
операций проектирования (рис. 1.4);
• критериев и правил, используемых для оценки результатов выполнения
технологических операций;
• нотаций (графических и текстовых средств), используемых для описания
проектируемой системы.
Методические материалы,
инструкции, нормативы и
стандарты, критерии оценки
результатов
16. Рисунок 1.4 - Представление технологической операции
Проектирования
Технологические инструкции, составляющие основное содержание
технологии, должны состоять из описания последовательности технологических
операций, условий, в зависимости от которых выполняется та или иная операция, и
описаний самих операций.
Технология проектирования, разработки и сопровождения ПС должна
удовлетворять следующим общим требованиям:
• технология должна поддерживать полный ЖЦ ПО;
• технология должна обеспечивать гарантированное достижение целей
разработки ИС с заданным качеством и в установленное время;
• технология должна обеспечивать возможность выполнения крупных
проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные
части, разрабатываемые группами исполнителей ограниченной численности с
последующей интеграцией составных частей). Опыт разработки крупных ИС
показывает, что для повышения эффективности работ необходимо разбить проект на
отдельные слабо связанные по данным и функциям подсистемы. Реализация
подсистем должна выполняться отдельными группами специалистов. При этом
необходимо обеспечить координацию ведения общего проекта и исключить
дублирование результатов работ каждой проектной группы, которое может
возникнуть в силу наличия общих данных и функций;
• технология должна обеспечивать возможность ведения работ по
проектированию отдельных подсистем небольшими группами (3-7 человек). Это
обусловлено принципами управляемости коллектива и повышения
производительности за счет минимизации числа внешних связей;
• технология должна обеспечивать минимальное время получения
работоспособной ПС. Речь идет не о сроках готовности всей ПС, а о сроках
реализации отдельных подсистем. Реализация ПС в целом в короткие сроки может
потребовать привлечения большого числа разработчиков, при этом эффект может
оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем
меньшим числом разработчиков. Практика показывает, что даже при наличии
17. полностью завершенного проекта внедрение идет последовательно по отдельным
подсистемам;
• технология должна предусматривать возможность управления
конфигурацией проекта, ведения версий проекта и его составляющих, возможность
автоматического выпуска проектной документации и синхронизацию ее версий с
версиями проекта;
• технология должна обеспечивать независимость выполняемых проектных
решений от средств реализации ПС (систем управления базами данных (СУБД),
операционных систем, языков и систем программирования);
• технология должна быть поддержана комплексом.
Реальное применение любой технологии проектирования, разработки и
сопровождения ПС в конкретной организации и конкретном проекте невозможно
без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться
всеми участниками проекта. К таким стандартам относятся следующие:
• стандарт проектирования;
• стандарт оформления проектной документации;
• стандарт пользовательского интерфейса. Стандарт проектирования должен
устанавливать:
• набор необходимых моделей (диаграмм) на каждой стадии проектирования и
степень их детализации;
• правила фиксации проектных решений на диаграммах, в том числе: правила
именования объектов (включая соглашения по терминологии), набор атрибутов для
всех объектов и правила их заполнения на каждой стадии, правила оформления
диаграмм, включая требования к форме и размерам объектов, и т. д.;
• требования к конфигурации рабочих мест разработчиков, включая настройки
операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
• механизм обеспечения совместной работы над проектом, в том числе:
правила интеграции подсистем проекта, правила поддержания проекта в одинаковом
для всех разработчиков состоянии (регламент обмена проектной информацией,
механизм фиксации общих объектов и т.д.), правила проверки проектных решений
на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
• комплектность, состав и структуру документации на каждой стадии
проектирования;
• требования к ее оформлению (включая требования к содержанию разделов,
подразделов, пунктов, таблиц и т.д.),
• правила подготовки, рассмотрения, согласования и утверждения
документации с указанием предельных сроков для каждой стадии;
• требования к настройке издательской системы, используемой в качестве
встроенного средства подготовки документации;
• требования к настройке GASE-средств для обеспечения подготовки
документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
• правила оформления экранов (шрифты и цветовая палитра), состав и
расположение окон и элементов управления;
• правила использования клавиатуры и мыши;
• правила оформления текстов помощи;
• перечень стандартных сообщений;
18. • правила обработки реакции пользователя.
1.1.6 Быстрый способ разработки ПО RAD
Одним из подходов к разработке прикладного ПО в рамках спиральной
модели является способ так называемой быстрой разработки приложений, или RAD
(Rapid Application Development). Данный подход предусматривает наличие трех
составляющих:
• небольшие группы разработчиков (от 3 до 7 человек), выполняющих работы
по проектированию отдельных подсистем;
• короткий, но тщательно проработанный производственный график (до 3
месяцев);
• повторяющийся цикл, при котором разработчики по мере того, как
приложение начинает обретать форму, запрашивают и реализуют требования
заказчика.
Жизненный цикл ПО в соответствии с данным подходом включает в себя 4
стадии:
• Анализ и планирование требований,
• Проектирование,
• Реализация (кодирование),
• Внедрение.
Стадия анализа и планирования требований
Действия: определение пользователем функций системы с выделением
наиболее приоритетных. Описание информационных потребностей и
формулирование (с помощью разработчиков) требований к системе.
Задачи: ограничение масштаба проекта; установление временных рамок для
каждой стадии. Определение возможности реализации проекта в заданных
условиях.
Результаты: приоритетный список функций будущего ПО. Предварительные
модели ПО.
Стадия проектирования
Действия: более детально рассматриваются процессы системы. При
необходимости для каждого элементарного процесса создается частичный прототип
(экранная форма, диалог, отчет). Устанавливаются требования разграничения
доступа; определяется состав необходимой документации.
Задачи: оценка количества функциональных точек разрабатываемой системы,
под которыми понимается любой из следующих компонентов:
• входной элемент приложения (входной документ или экранная форма);
• выходной элемент приложения (входной документ или экранная форма);
• запрос (пара "вопрос-ответ");
• логический файл (совокупность записей данных, используемая внутри
приложения);
• интерфейс приложения (совокупность записей данных, передаваемых
другому приложению или получаемых от него).
Далее проект распределяется между командами разработчиков, реализующих
отдельные подсистемы. Все модели и прототипы должны быть получены с примене-
нием тех CASE-средств, которые будут использоваться в дальнейшем при
19. построении системы. В отличие от других подходов, где прототипы выбрасываются
после устранения неясностей при проектировании, в подходе RAD каждый
прототип развивается в часть будущей системы.
Результаты: общая информационная модель системы. Функциональные
модели системы в целом и отдельных подсистем. Точно определенные интерфейсы
между автономно работающими подсистемами. Построенные прототипы экранных
форм, диалогов, отчетов.
Стадия реализации
На этой стадии выполняется непосредственно разработка приложения.
Действия: итеративное построение разработчиками реальной системы на
основе полученных моделей и требований по надежности и производительности.
Оценка заказчиком полученных результатов и внесение корректив.
Интегрированное тестирование, осуществляемое в процессе разработки. Физическое
проектирование базы данных; установление способов повышения производи-
тельности. Завершение разработки документации.
Результаты: готовая система, удовлетворяющая всем согласованным
требованиям.
Стадия внедрения
На данной стадии производится внедрение системы параллельно с
эксплуатацией существующей системы и обучение пользователей. Планирование и
подготовка к данной стадии должны осуществляться заранее, как правило, на стадии
проектирования системы.
Следует отметить, что подход RAD не претендует на универсальность.
Данный подход не применим для построения сложных расчетных программ или
программ управления сложными объектами в реальном масштабе времени; для
приложений, в которых отсутствует ярко выраженная интерфейсная часть и
приложения.
Основные принципы методологии RAD:
• разработка приложений итерациями;
• необязательность полного завершения работ на каждом из этапов
жизненного цикла;
• использование прототипирования, позволяющее полнее выяснить и
удовлетворить потребности конечного пользователя;
• обязательное вовлечение пользователей в процесс
разработки ИС;
• необходимое применение CASE-средств, обеспечивающих целостность
проекта;
• тестирование и развитие проекта, осуществляемые одновременно с
разработкой;
• ведение разработки немногочисленной, хорошо управляемой командой
профессионалов.
1.1.7 Модели качества процессов конструирования ПО
Подтверждение качества процесса конструирования ПО дает сертификат
качества процесса, подтверждающий, что процесс конструирования ПО
соответствует международным стандартам. Каждый из таких стандартов фиксирует
20. свою модель обеспечения качества. Наиболее авторитетные международные
стандарты:
l) ISO 9001:2000
2) ISO/IES 15504
3) Модель зрелости процесса конструирования ПО
(Capability Maturity Model - CMM) Института программной инженерии при
американском университете Карнеги-Меллон.
Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из
любых областей человеческой деятельности. Стандарт ISO/IES 15504
специализируется на процессах программной разработки и отличается высоким
уровнем детализации. Базовым понятием модели СММ является определение
зрелости компании, занимающейся конструированием ПО. И кроме этого, СММ
предлагает рекомендации по совершенствованию процессов проектирования в
данной компании.
Каждый уровень СММ характеризуется областью ключевых процессов,
причем каждый последующий уровень включает в себя характеристики
предыдущих уровней.
Уровни зрелости модели СММ:
Ввод новых
технологий
Количественная
оценка
Все задокументировано
Все зависит от личных
качеств сотрудников
)
Уровень 5. Оптимизирующий
планомерное улучшение и
повышение качества процесса
Уровень 3. Определяемый
Процесс полностью определен и
организован на основе единого
стандарта компании
Уровень 1. Начальный
самоорганизирующийся хаос Процесс
осуществляется случайным образом.
Уровень 4. Управляемый
количественное управление
процессом, его качеством
Уровень 2. Повторяемый процесс
планируется и отслеживается
21. 1.1.8 Руководство программным продуктом (ПП )
Руководство ПП - первый слой процесса конструирования ПО. Термин "слой"
подчеркивает, что руководство определяет сущность процесса разработки от его
начала до конца:
Руководство программным проектом
Этапы
Анализ Проектирование Кодирование Тестирование
Процесс руководства проектом
Для проведения успешного проекта нужно понять объем предстоящих работ,
возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи,
необходимые усилия (стоимость), план работ, которому желательно следовать. Оно
начинается перед технической работой, продолжается по мере развития ПО от идеи
к реальности и достигает наивысшего уровня к концу работы.
Начало проекта
Перед планированием проекта необходимо:
• Установить цели и проблемную область проекта
• Обсудить альтернативные решения
• Выявить технические и управленческие ограничения.
Измерения (меры и метрики)
Измерения помогают понять как процесс разработки продукта, так и сам
продукт. Измерения процесса разработки продукта производятся в целях его
улучшения. Измерение продукта - для повышения его качества. В результате
измерения определяется мера - количественная характеристика какого-либо
свойства объекта. Измеряются только опорные свойства объектов, все остальные
свойства оцениваются в результате вычисления функций от значений опорных
характеристик.
Эти функции называются метриками. В IEEE-стандарте метрика определена
как мера степени обладания свойством, имеющая числовое значение.
В программной инженерии понятия мера и метрика рассматриваются как
синонимы.
Процесс оценки
При планировании программного проекта оцениваются:
• Людские ресурсы (в человеко-месяцах).
• Продолжительность (в календарных датах).
• Стоимость (в тысячах долларах).
Анализ риска.
22. На этой стадии исследуется область неопределенности, имеющаяся в наличии
перед созданием программного продукта, нет ли невыполнимых технических про-
блем, нет ли чего, что помешает выполнить проект в срок. В результате
принимается решение - выполнить проект или нет.
Планирование
Определяется набор проектных задач. Устанавливаются связи между
задачами. Определяются людские и другие ресурсы. Создается сетевой график
задач, проводится его временная разметка.
Трассировка и контроль
Каждая задача, помеченная в плане, отслеживается руководителем проекта.
При отставании в решении задачи применяются утилиты (процедуры) повторного
планирования, в результате чего могут быть:
• Перераспределены ресурсы.
• Реорганизованы задачи.
• Пересмотрены выходные обязательства.
Планирование проектных задач
Основной задачей при планировании является определение WBS-Work
Breakdown Structure (структуры распределения работ), которая составляется с
помощью утилиты планирования проекта (рисунок 1.5)
Типовая структура распределения
проектных работ
Рисунок 1.5- Типовая структура распределения проектных работ
Системный анализ проводится с целью:
Системныйанализ
Анализтребований
Предварительное
проектирование
Детальное
проектирование
Копирование Тестирова
ние
Детальное
пректирование
Копирование Тестирова
ние
Планирование
тестов
Разработка
тестов
Проверка
тестов
Тестированиепрограммы
Проверкапрограммы
23. • Выяснения потребностей заказчика.
• Оценки выполняемости системы
• Выполнения экономического и технического анализа.
• Распределения функций по элементам компьютерной системы (аппаратуре,
программам, людям, базам данных и т.д.).
• Определения стоимости и ограничений планирования.
• Создания системной спецификации.
В системной спецификации описываются функции, характеристики системы,
ограничения разработки, входная, выходная информация.
Анализ требований дает возможность:
Определить функции и характеристики программного продукта.
• Обозначать интерфейс продукта с другими системными элементами.
• Определить проектные ограничения программного
продукта.
• Построить модели: процесса, данных, режимов функционирования продукта.
• Создать такие формы представления информации и функций системы,
которые можно использовать в ходе проектирования.
Результаты анализа сводятся в спецификацию требований к программному
продукту - вехи, процедуры контроля промежуточных результатов.
Основной рычаг в планирующих методах - вычисление границ времени
выполнения задачи.
Рекомендуемое правило распределения затрат проекта:
40% - анализ, проектирование (5% из них - на планирование и системный
анализ),
20% - кодирование,
40% — тестирование, отладка.
Требования к разбивке сложной системы на подсистемы:
• количество связей между отдельными подсистемами должно быть
минимальным;
• связность отдельных частей внутри каждой подсистемы должна быть
максимальна;
• каждая подсистема должна инкапсулировать (скрывать) свое содержимое от
других подсистем;
• каждая подсистема должна иметь четко определенный интерфейс с другими
подсистемами.
Декомпозиция означает, что систему необходимо разбить на небольшие
подсистемы, каждую из которых можно разрабатывать независимо от других.
Инкапсуляция позволяет рассматривать структуру каждой независимо от
других подсистем.
Интерфейсы позволяют строить систему более высокого уровня, рассматривая
каждую подсистему как единое целое и игнорируя ее внутреннее устройство.
В качестве дополнительных принципов, несоблюдение которых может
привести к провалу проекта, необходимо отметить следующие:
• Принцип абстрагирования — заключается в выделении существенных
аспектов системы и отвлечения от несущественных;
• Принцип непротиворечивости - заключается в обоснованности и
согласованности элементов;
24. • Принцип структурирования данных - заключается в том, что данные должны
быть структурированы и иерархически организованы.
Наиболее часто используемыми моделями в структурном подходе являются
следующие:
• SADT (Structured Analysis and Design Technique) -метод структурного
анализа и проектирования;
• DFD (Data Flow Diagrams) - диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь".
Метод SADT (и DFD) применяется на стадии анализа и формирования
требований для построения моделей
"AS-IS" и "TO-BE". ERD позволяет описать БД на концептуальном уровне. На
стадии проектирования применяется DFD для описания структуры системы и ERD
— для описания логического уровня БД.
1.2 Классические методы анализа Структурный подход к
проектированию
1.2.1 Метод функционального моделирования SADT
Методология SADT разработана Дугласом Россом в 1973 г. На ее основе
разработана, в частности, известная методология IDEFO (Icam DEFinition), которая
является основной частью программы ICAM (Интеграция компьютерных и
промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT может использоваться для моделирования широкого круга
систем и определения требований и функций, а затем для разработки системы,
которая удовлетворяет этим требованиям и реализует эти функции.
Методология SADT представляет собой совокупность методов, правил и
процедур, предназначенных для построения функциональной модели объекта какой-
либо предметной области. Функциональная модель SADT отображает
функциональную структуру объекта, т.е. производимые им действия и связи между
этими действиями.
Результатом применения методологии SADT является модель, которая состоит
из диаграмм, имеющих ссылки друг на друга.
Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на
них представлены как блоки и дуги.
Управление
Рисунок 1.6 - Функциональный блок и интерфейсные дуги
Место соединения дуги с блоком определяет тип интерфейса. Управляющая
информация входит в блок сверху ( рис1.6), в то время как входная информация
показана с левой стороны блока, а результаты (выход) показаны с правой стороны.
Механизм (человек или автоматизированная система), который осуществляет опера-
цию, представляется дугой, входящей в блок снизу.
Функция
А0
25. Иерархия диаграмм
Каждый компонент модели может быть декомпозирован на другой диаграмме.
Каждая диаграмма иллюстрирует внутреннее строение блока на родительской диаг-
рамме. Построение SADT-модели начинается с представления всей системы в виде
простейшего компонента - одного блока и дуг, изображающих интерфейсы с
функциями вне системы. Затем блок, который представляет систему в качестве
единого модуля, детализируется на другой диаграмме с помощью нескольких
блоков, соединенных интерфейсными дугами. Эти блоки представляют основные
подфункции исходной функции. Данная декомпозиция выявляет полный набор
подфункций, каждая из которых представлена как блок, границы которого
определены интерфейсными дугами. Каждая из этих подфункций может быть
декомпозирована подобным образом для более детального представления.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня,
являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня
и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть
системы.
На SADT-диаграммах не указаны явно ни последовательность, ни время.
Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по
времени) функции могут быть изображены с помощью дуг. Обратные связи могут
выступать в виде комментариев, замечаний, исправлений и т.д.
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может
быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может
быть далее детализирована с помощью необходимого числа диаграмм. Таким
образом формируется иерархия диаграмм.
Основные правила методологии SADT включают:
• Ограничение количества блоков на каждом уровне декомпозиции (правило
3-6 блоков);
• Связность диаграмм (номера блоков);
• Уникальность меток и наименований (отсутствие повторяющихся имен);
• Синтаксические правила для графики (блоков и дуг);
• Разделение входов и управлений (правило определения роли данных);
• Отделение организации от функции, т.е. исключение влияния
организационной структуры на функциональную модель;
• Типы связей между функциями.
Одним из важных моментов при проектировании ПС с помощью методологии
SADT является точная согласованность типов связей между функциями. Различают,
по крайней мере, семь типов связывания (номер указывает значимость связи).
Случайная-0. Случайная связность возникает, когда конкретная связь между
функциями мала или полностью отсутствует. Это относится к ситуации, когда имена
данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом.
В E
А С D
А1 A2
26. Рисунок 1.7 - Случайная связь
Логическая-1. Логическое связывание происходит тогда, когда данные и
функции собираются вместе вследствие того, что они попадают в общий класс или
набор элементов, но необходимых функциональных отношений между ними не
обнаруживается.
Временная-2. Связанные по времени элементы возникают вследствие того, что
они представляют функции, связанные во времени, когда данные используются
одновременно или функции включаются параллельно, а не последовательно.
Процедурная-3. Процедурно связанные элементы появляются
сгруппированными вместе вследствие того, что они выполняются в течение одной и
той же части цикла или процесса.
А
А и В
В
Рисунок 1.8 - Процедурная связь
Коммуникационная-4. Диаграммы демонстрируют коммуникационные связи,
когда блоки группируются вследствие того, что они используют одни и те же
входные данные и/или производят одни и те же выходные данные.
А
В
Рисунок 1.9 - Коммуникационная связь
Последовательная-5. На диаграммах, имеющих последовательные связи,
выход одной функции служит входными данными для следующей функции.
Согласовать А и В
А3
Планировать В
А2
Планировать А
А1
А1 А2
А2
А1
