Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (1015641), страница 32

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 32)

Может быть предусмотрено несколько неформальных процедур пересмотра плана, однако все они должныбыть успешно закончены официальным рассмотрением — фазовым обзором II. В результате фиксируется согласие или несогласие каждой функциональной группы с предложениями соглашения о требованиях.211Полученные в ходе фазового обзора II предложения относительно внесения изменений в соглашение о требованиях даютвозможность оценить недостатки проекта. Оценку проводят потрем переменным: технические характеристики, календарныесроки и стоимость (рис. 8.7).СсSсFсРис. 8.7 — Границы изменяемости проекта:Cc — увеличение стоимости; Sc — изменение времени;Fc — изменение технических характеристикТо есть внутри проекта выделяется некоторый диапазонизменения переменных; фактически это соответствует заданиюнебольшого запаса финансовых ресурсов, времени и свободывыбора технических характеристик системы.На рассмотрение, переработку и утверждение соглашенияо требованиях может уйти много времени, поэтому обычно этаработа совмещается с продолжением разработки в тех масштабах, которые позволяют ресурсы.Параллельно с процессом рассмотрения соглашения отребованиях составляются индивидуальные рабочие планы исводка трудозатрат, которые будут основой для определениябудущих финансовых затрат.2128.3.3 Организация разработки программного изделияв фазе конструирования (проектирования)Основная цель проектирования заключается в выработкеи анализе требований к программному изделию.

Процесс декомпозиции проекта, начатый при составлении соглашения отребованиях, продолжается путем разработки спецификаций иразбивки их на две части — внутренний и внешний проект.Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект —совокупность характеристик программного изделия, скрытых отпользователя. Это делается, в первую очередь, для того, чтобыпользователи могли критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия.

То есть внешний проект описывает, что делаетпрограммное изделие, а внутренние спецификации указывают,каким образом изделие сконструировано для достижения внешних спецификаций. Внешние спецификации передаются дляоткрытого и широкого обсуждения, в котором предпочтенияотдаются предложениям пользователей.Для того чтобы провести границу между внутренним ивнешним проектом, схему декомпозиции упорядочивают. Схема декомпозиции называется хорошо упорядоченной, если наней отмечен каждый случай вызова одной функции другой,вплоть до некоторого уровня абстракции, удобного с точки зрения управления проектом. Далее, каждый функциональный модуль рассматривается как черный ящик, для которого можноопределить внешнее поведение, однако ничего нельзя сказатьотносительно его внутреннего устройства.

Свойства черногоящика определяются полным описанием его характеристик, видимых извне, включая описание условий, при которых к немуможно обратиться, чтобы инициировать его функционирование.Те атрибуты модулей, которые играют существенную роль присоставлении описания программного изделия как единого целого, составляют внешний проект. Все остальные параметры модулей, полностью или частично скрытые внутри программногоизделия, составляют внутренний проект.213С учетом четкого различия между внешним и внутреннимпроектом, следует составлять внешние и внутренние спецификации программного изделия.

При этом необходимо избегатьобщих мест в разных документах. Формы спецификаций обычно строго стандартизированы (SADT, PDL, и др.).После того, как внешние спецификации приобретаютсравнительно стабильный характер, в рамках функции разработки производится их рассылка функциональным группам(с пометкой «проект»). Все замечания суммирует специальныйорган — технический комитет, который после анализа передаетих в группу разработки. Обязанность группы разработки —максимально учесть все замечания.Во время создания внутренних и внешних спецификацийдругие функциональные группы готовят планы выпуска документации, планы испытаний и др. Эти документы рассылаютсяна рассмотрение в конце фазы проектирования.

Руководительпроекта изучает и утверждает их. Фаза проектирования обычнозаканчивается утверждением внешних спецификаций.8.3.4 Организация разработки программного изделияв фазе программированияРабочая нагрузка при выполнении функции разработкидостигает наибольшей величины в фазе программирования.Основная задача организации разработки заключается в координации усилий большого числа сотрудников, занятых реализацией этой функции, а также в организации взаимодействия междуразличными функциональными группами. Метод — соблюдение принятых на данном предприятии стандартов программирования.Кодирование начинается на ранней стадии программирования. При этом используется так называемый «волновой эффект» (табл. 8.3), когда составление внешних и внутренних спецификаций, кодирование, отладка и компоновка программ выполняются одновременно на различных уровнях структуры программного изделия.

Например, в фазе программирования какого-то модуля внешние спецификации всего программного изделия уже могут быть утверждены, а внутренние спецификациисоставлены не до конца. И наоборот, хотя этапы кодирования,214отладки и компоновки некоторых модулей уже могут быть завершены, их разработка в рамках целого программного продукта еще может быть не закончена.Таблица 8.3 — Волновой эффект в разработке модулей изделияСоставлениевнешнихспецификаций завершеноСоставлениевнутренних спецификаций завершеноКодирование законченоОтладказаконченаКомпоновка законченаМодулиG H IABCDEFJKLM N–––––––––––––––––––––––––––Если желательно избрать более жесткий путь и если впрограмме нельзя выделить сравнительно слабо связанныекомпоненты, то целесообразно закончить не только внешнийпроект, но и внутренний и только после этого браться за программирование.Следует иметь в виду один серьезный недостаток волнового эффекта: задержка с утверждением внешних спецификаций может крайне неблагоприятно отразиться на выполнениимногих функций.

То есть нельзя утверждать спецификации испытаний, невозможно закончить рекламные материалы и т.д.215Помимо кодирования, отладки и компоновки деятельность группы разработки связана с демонстрацией работающегоизделия в конце фазы программирования и организацией взаимодействия группы с другими функциональными группами.Сначала на рассмотрение поступает план поддержки. В групперазработки должна, прежде всего, существовать уверенность вобоснованности плановых сроков и правильности предложенийгруппы поддержки, касающихся описания программного изделия.

Любые ошибки в описании характеристик программногоизделия или в определении сроков его готовности, которые могут дойти до пользователя через рекламные материалы, могутпородить недоразумения или, хуже того, штрафы за невыполнение обязательств.В фазе программирования группа выпуска документациипредставляет на рассмотрение ряд вариантов справочных материалов. В середине фазы программирования группой испытаний представляется на рассмотрение график испытаний. Группаразработки тщательно изучает варианты документации и спецификации испытаний с тем, чтобы в них не было ошибок, порожденных неверными исходными предложениями. Если группаразработки в свое время подготовила корректные внешние спецификации, то их анализ не вызывает больших затруднений изаймет немного времени. Если же некоторые положения внешних спецификаций пропущены или изложены недостаточнополно, то их проверка отнимет не только много времени, но ивызовет большие трудности.

В этом случае придется изменятьвнешние спецификации, что может свести на нет запас времени,имеющийся в календарном плане проектирования.Группа поддержки после утверждения изготовляет инаправляет на рассмотрение рекламные материалы. Группа разработки анализирует эти материалы, чтобы не допустить технических ошибок, порождающих недоразумения и соответствующие финансовые санкции. Обычно во время фазы программирования оказывается целесообразной демонстрация программногоизделия в действии, чтобы показать, что наиболее критическиеэксплутационные характеристики изделия реализованы в соответствии с требованиями, или чтобы установить, насколько далеко продвинулся проект.

Группа разработки стремится закон-216чить этот этап как можно раньше, чтобы учесть замечания тех,кому демонстрировалось программное изделие.8.3.5 Организация разработки программного изделияв фазе оценкиФаза оценки открывается началом испытаний класса A,проводимых группой разработки. Испытания класса A — этовсесторонняя проверка программного изделия, которая начинается после того, как все модули программ были подвергнутыиндивидуальной проверке и включены в работоспособную систему. Испытания класса A начинаются сразу же после того,как в систему включен последний модуль.Проводя испытания класса A, группа разработки прогоняет как можно больше контрольных примеров, предложенныхгруппой испытаний. Это ускоряет фактическое завершение независимых испытаний, которые проводит группа испытаний, ипомогает устранить ошибки в самих тестах, являющиеся частопричиной разногласий между этими двумя группами.

К концуиспытаний класса A группа разработки подготавливает спецификацию выпуска — документ, который связывает воедино составные части программного изделия. Форма спецификациистрого стандартизована. После того, как число ошибок, обнаруживаемых во время испытаний класса A, становится незначительным, группа разработки начинает приемочные испытанияпо программе, составленной группой испытаний.Приемочные испытания основываются на наборе тестов,выбранных из общей программы испытаний, и предназначеныдля выявления недостатков плохо продуманного программногоизделия. К сожалению, под впечатлением результатов испытаний группа разработки склонна к проведению поспешных изменений в модулях, которые могут разрушить целостность программного изделия.

Проведение приемочных испытаний убеждает всех, что для внесения дополнительных изменений в модули нет оснований.Испытания класса B представляют собой независимуюпроверку программного изделия на соответствие спецификациям. Программное изделие считается готовым к проведению испытаний класса B после успешного проведения приемочных ис-217пытаний. Группа разработки составляет отчет об испытанияхкласса A, подытоживая результаты этих испытаний, в том числеи приемочных, свидетельствующих о готовности программногоизделия к испытанию класса B.Группа испытаний подготавливает набор тестов.

Характеристики

Список файлов книги