Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007) (1095890), страница 32
Текст из файла (страница 32)
Далее, каждый функциональный модуль рассматривается как черный ящик, для которого можноопределить внешнее поведение, однако ничего нельзя сказатьотносительно его внутреннего устройства. Свойства черногоящика определяются полным описанием его характеристик, видимых извне, включая описание условий, при которых к немуможно обратиться, чтобы инициировать его функционирование.Те атрибуты модулей, которые играют существенную роль присоставлении описания программного изделия как единого целого, составляют внешний проект. Все остальные параметры модулей, полностью или частично скрытые внутри программногоизделия, составляют внутренний проект.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.Группа испытаний подготавливает набор тестов. Испытания на основе этих тестов обычно проводятся циклами, начинаяс повторных приемочных испытаний. Цикл испытаний предполагает прогон как можно большего числа тестов в максимальносжатые сроки и завершается отчетом о результатах испытаний,который направляется в группу разработки.
Если после циклаиспытаний в программном изделии будут обнаружены недостатки, препятствующие его выпуску, группа разработки с максимальной быстротой реагирует на результаты цикла и предъявляет программное изделие в исправленном виде для новогоцикла испытаний. Группа разработки получит наивысшуюоценку, если испытания класса B пройдут за один цикл. Хотяэто иногда и случается, чаще всего приходится проводить околотрех циклов испытаний. Однако на практике известны случаи,когда количество циклов достигало 10.В то время как группа испытаний проводит испытаниякласса B, группа выпуска документации представляет нарассмотрение справочные материалы. Группа разработки имеетпоследнюю возможность исправить ошибки в этих материалах,и поэтому их рассмотрение должно проводиться наиболее тщательно.
Группа выпуска документации учитывает замечанияразработчиков и проводит последний просмотр материала передсдачей в печать.Фаза оценки заканчивается тогда, когда группа испытаний излагает свои замечания в отчете об испытаниях класса B.Отчет составляется после того, как группа испытаний приходитк выводу, что программное изделие удовлетворяет или неудовлетворяет критериям испытаний. Чаще всего при испытаниях выявляется ряд нерешенных проблем, к рассмотрению которых привлекаются разработчики.
Решение о выпуске программного изделия для широкого использования принимаетсяна основе отчета группы испытаний и пояснительной запискигруппы разработки, которая обычно предлагает план устранения недостатков. Поэтому группа разработки тщательно изучает отчет об испытаниях класса B и рекомендует меры для218устранения всех замеченных дефектов. При этом группа разработки может вступать во взаимодействие с группой сопровождения, если выявленные дефекты могут быть компенсированыкакими-либо средствами во время эксплуатации.8.3.6 Окончание проектаНезависимо от причин, вызвавших завершение проекта,группа разработки выпускает отчет, из которого могут почерпнуть опыт разработчики будущего проекта.
Заключительныйотчет составляется всеми участниками проекта и содержит, какминимум, следующую информацию: опыт преодоления наибольших трудностей, встретившихся при разработке проекта; рекомендации по разработке последующих проектов(включая различные варианты); сводку плановых и фактических сроков выполненияэтапов (включая все случаи изменения запланированных сроков); сводку запланированных и фактических расходов; сводку запланированных и фактических трудозатрат; сводку запланированных и фактически используемыхмашинных ресурсов; хронологию затруднений в работе с оборудованием ирекомендации по устранению недостатков в будущем; хронологию возникновения трудностей, связанных свзаимодействием функциональных подразделений; рекомендации по планированию в условиях неопределенности; хронологическую запись наиболее значимых событий.Если разработка программного изделия завершена полностью, то заключительный отчет включается в спецификациюсопровождения.Нормальное завершение проекта наступает на этапе фазового обзора V, когда принимается решение о выпуске программного продукта.