Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007) (1095890), страница 2
Текст из файла (страница 2)
...............25571 ВВЕДЕНИЕ. ПРОБЛЕМЫ СОВРЕМЕННОГОПРОГРАММИРОВАНИЯПервый этап развития программирования в первую очередь был связан с накоплением опыта в приобретении технических (стандартных) навыков написания программ. Однако помере развития средств вычислительной техники и накопленияэтих навыков существенно изменилось положение.
Возниклиестественные вопросы — продолжаем ли мы делать ошибки?;является ли сам процесс написания программ правильным?; невозникла ли необходимость в создании новых методов разработки программного обеспечения?Ответом на эти вопросы и занимается научная дисциплина — методы (технология) разработки программного обеспечения. Круг вопросов, который рассматривает данная дисциплина,связан с классическими составляющими программирования: написанием спецификаций; проектированием; тестированием и функционированием программ.Практическую значимость данной дисциплины можнопроиллюстрировать путем сопоставления состояний дел по разработке технических систем и больших программных систем. В 1958 году в США приступили к строительству Веррацано-Нарроуского моста. По расчетам инженеров затраты на строительство определялись в размере 325 млн $,а работы планировалось завершить в 1965 году.
Этосамый большой подвесной мост в мире. Работы понему завершились в ноябре 1964 года в соответствии спроектной сметой. Приблизительно в это же самое время производиласьразработка операционной системы OS фирмы IBM. Попланам разработчиков длительность разработки составляла 5000 человеко-лет. Но несмотря на все возможные принятые фирмой меры, завершилась на 4года позже планируемого срока.Возникает вопрос, почему в технических системах возможен достаточно точный прогноз, тогда как при разработке программных систем он оказывается несостоятельным?8Частично на этот вопрос можно ответить следующим образом — инженеру проще предусмотреть возрастающую сложность строительства, вызванную увеличением размеров моста,чем разработчику программного обеспечения определить сложность программы большого размера.В настоящем курсе мы будем рассматривать методы итехнические приемы, введение которых позволит уменьшитьстоимость и повысить надежность программ.В общем случае методы разработки программного обеспечения не есть программирование, хотя программирование составляет важную ее часть.
Данный предмет также не сводится кпроблеме изучения компиляторов и операционных систем, хотяони также играют существенную роль в рассматриваемой технологии. Точно так же проблемы электронной техники, структуры ЭВМ не являются предметом исследований, хотя и их знание в данном предмете необходимо.Методы разработки программного обеспечения — этосинтезированная дисциплина, в которой для составления алгоритмов используются математические методы, для оценки затрат и выбора компромиссных решений — методы инженерныхрасчетов, для определения требований к системе, учета ситуаций, связанных с потерями, организации работы исполнителейи прогнозирования — методы управления. Все это и будет предметом наших исследований.92 ЭТАПЫ РАЗРАБОТКИ ПРОГРАММНОГООБЕСПЕЧЕНИЯЕстественно, что отдельный человек не в состоянии полностью осмыслить и построить программное обеспечениебольшой системы.
Для управления ходом разработки большихпрограммных систем выделяются шесть этапов, составляющихцикл разработки (цикл жизни) программного обеспечения:1) анализ требований, предъявляемых к системе;2) определение спецификаций;3) проектирование;4) кодирование;5) тестирование:а) автономное;б) комплексное;6) эксплуатация и сопровождение.Анализ требований (10%)Комплексноетестирование (20%)Определениеспецификаций (10%)Проектирование(15%)Автономноетестирование (25%)Кодирование (20%)Рис. 2.1 — Распределение затрат по этапам разработкиНа диаграмме (рис. 2.1) показано приблизительное распределение затрат на реализацию отдельных этапов разработки.Рассмотрим определение каждого из этих этапов.102.1 Анализ требований, предъявляемыхк системеНа первом этапе, часто неоправданно опускаемом, определяются требования, которые позволяют получить приемлемоерешение проблемы.
На этом этапе формулируются целевое назначение и основные свойства разрабатываемой программнойсистемы.Процесс выполнения работ и оформление результатов наэтом этапе проработаны гораздо в меньшей степени, чем надругих, и в общем случае не являются объектом деятельностипрофессиональных программистов.Если предметом разработки является не программная система, а более сложный объект (например, система управлениятехнологическим процессом), включающий программы только вкачестве составной части, требования формируются ко всемупредмету разработки.
В том случае, когда разработка программного обеспечения является самоцелью, обычно используютсяметоды составления исходных описаний. Одним из самых эффективных методов исходных описаний является метод структурного анализа, сущность которого сводится к декомпозицииисходного объекта на его составные части (рис. 2.2).AРис. 2.2 — Схема декомпозиции системы11Таким образом, создается иерархия связанных подсистем(обязательно непересекающихся).В общем случае, анализ требований, предъявляемых к системе, должен быть сосредоточен на интерфейсе между человеком (пользователем) и инструментом (ЭВМ).
При этом для программных систем можно выделить лишь базовые требования: время обработки (работы) программы; стоимость обработки; вероятность ошибки; реакция на непредсказуемые действия оператора (защита от дурака и др.).При декомпозиции требований следует делать различиямежду жесткими требованиями и требованиями, выполнениекоторых не является строго обязательным.Особое внимание следует уделять пространственно-временным ограничениям и средствам системы, которые в будущем могут претерпеть изменения.К важнейшим требованиям относятся ресурсные требования и затраты на реализацию системы.Фактически, анализ требований завершается составлением развернутого технического задания на систему, которое втерминологии классического САПР называется аван-проектом.2.2 Определение спецификацийНа этапе определения спецификаций осуществляетсяточное описание функций, реализуемых ЭВМ, а также задаютсяструктура входных и выходных данных, методы и средства ихразмещения.
Определяются алгоритмы обработки данных.Центральным вопросом определения спецификаций является проблема организации базы данных. При этом решаетсякомплекс вопросов, имеющих отношение к структуре файлов,организации доступа к ним, модификации и удалению.В случае, когда новая система создается на основе существующих, составной частью спецификаций является схема (алгоритм) приведения существующей базы данных к новому формату.
Такое преобразование может потребовать разработку специальной программы, которая становится ненужной после еепервого и единственного использования.12Все эти вопросы должны быть отражены в функциональных спецификациях, которые представляют собой документ, являющийся основополагающим в процессе разработки системы,так как содержит конкретное описание последней. Чем подробней составлены спецификации, тем меньше вероятность возникновения ошибок.В спецификациях должны быть представлены данные длятестирования элементов системы и системы в целом. Это требование является объективным и обязательным, т.к. на данномэтапе на параметры тестирования не будет оказывать влияниеконкретная реализация системы.Так как функциональные спецификации описывают принятые решения в целом, данный документ можно использоватьдля начальных оценок временных затрат, числа специалистов идругих ресурсов, необходимых для проведения работ.В общем случае, спецификации определяют те функции,которые должна выполнять система, не указывая, каким образом это достигается.
Составление подробных алгоритмов наэтом этапе преждевременно и может вызвать нежелательныеосложнения.2.3 ПроектированиеНа стадии проектирования разрабатываются алгоритмы,задаваемые спецификациями, и формируется общая структуравычислительной системы. При этом система разбивается (принеобходимости) на составные части таким образом, чтобы ответственность за реализацию каждой составной части можнобыло бы возложить на одного разработчика (или группу исполнителей). При этом для каждого определенного таким образоммодуля системы должны быть сформированы предъявляемые кнему требования: реализуемые функции; размеры; время выполнения и др.В целом соотношения «требования — спецификация —проектирование» можно проиллюстрировать следующей схемой(рис.
2.3).13Реальный мирАбстракция (формализация)Требования (1)Спецификация (2)Реализация (4)Проектирование (3)Рис. 2.3 — Схема проектирования программных системПрежде всего Заказчик анализирует и формулирует требования реальности, которые находят отображение в требованиях, предъявляемых к программной системе. Однако ЭВМ неспособна решить задачу непосредственно, реальные данныенеобходимо каким-то образом закодировать и ввести в ЭВМ.Подобная модель решаемой задачи представляет собой абстрактное выражение реального мира и отражается в спецификациях.Если спецификации программы определены, возникаетнеобходимость в описании процесса обработки информации,что относится к этапу проектирования.
Поскольку программадолжна использоваться для реальной задачи, то на этапе реализации проекта (кодирование, тестирование) осуществляетсяперевод формального проекта в выполняемую программу.И наконец, пользователь может сравнить планируемуюфункцию программы с реализованной функцией. Эти функцииочень редко совпадают полностью. Таким образом, сопровождение замыкает цикл проектирования и позволяет изменитьсистемные требования, спецификации, проекты программ и т.п.В процессе проектирования системы, по мере выполненияспецификаций на определенные подмодули, последние представляются в виде древовидной схемы, показывающей вхождение элементов системы (рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
