Жизненный цикл ПО САПР

Носо

вая полость

^Д Сагиттальный разре

\^>'

 

 

Язык, вид спереди

Вид спереди

ПОЛОСТЬ РТА

Носо

вая полость

^Д Сагиттальный разре

\^>'

 

 

Язык, вид спереди

Вид спереди

Жизненный цикл ПО САПР

 

Программное обеспечение САПР представляет со­бой сложную программную систему, включающую в себя десятки и сотни компонентов. Создание ПО САПР – трудная научно-техническая задача, для реше­ния которой требуются большие материальные затраты. Так, известны САПР, ПО которых насчитывает более 500 тыс. операторов языка программирования. Разработ­ка такого ПО требует сотен и тысяч человеко-часов. Затраты на разработку и сопровождение ПО составляют подавляющую долю всех затрат на создание и эксплуа­тацию САПР.

Высокая стоимость ПО объясняется низкой скоростью роста производительности труда программистов по срав­нению с темпами роста производительности труда в дру­гих сферах производства. Средняя производительность труда программистов в организациях, занимающихся промышленной разработкой ПО, составляет 10000–20000 операторов в месяц.

В отли­чие от программ индивидуального пользования, предназ­наченных для обслуживания только их разработчика, законченный программный продукт:

1) имеет универсальное назначение, ориентирован на применение многими пользователями и в ряде органи­заций;

2) предназначен для работы в комплексе с другими компонентами ПО;

3) имеет специальные средства модификации и рас­ширения;

4) всесторонне отлажен;

5) описан в тщательно составленной документации.

Стоимость программного продукта приблизительно в 9 раз выше стоимости программы индивидуального наз­начения и с увеличением его сложности растет по квад­ратичному закону.

Для оценки сложности ПО используются два основ­ных показателя:

1) количество операторов;

2) количество и типы взаимосвязей компонентов ПО между собой. Этот показатель более важный, так как именно он определяет эффективность декомпозиции исходной задачи разработки на ряд вложен­ных подзадач разработки его компонентов. Поэтому, в частности, трудоемкость разработки управляющих прог­рамм выше (приблизительно в 4 раза) трудоемкости раз­работки прикладных программ.

С конца 60-х годов, когда очевидным стало противо­речие между потребностями общества в системах элек­тронной обработки информации и возможностями созда­ния ПО, началось становление новой научной дисципли­ны «Методы разработки программного обеспечения». В рамках этой дисциплины предлагается рассматривать цикл жизни (цикл разра­ботки) ПО состоящим из шести основных этапов: 1) ана­лиз требований, предъявляемых к системе; 2) разработ­ка спецификаций на систему; 3) проектирование; 4) кодирование; 5) тестирование; 6) сопровождение и экс­плуатация. На рис. 1.1 приведено соотношение времен­ных затрат по этапам цикла жизни ПО.

 

 

Этап 1. Анализ требований, предъявляемых к ПО САПР. Основу этих требований составляют требования, перечисленные выше (см. Введение). Они дополняются требованиями заказчика, включающими пространствен­но-временные ограничения, необходимые функции и воз­можности, режимы функционирования, требования точ­ности и надежности и т. д., т. е. вырабатывается описа­ние системы с точки зрения пользователя. Эта работа выполняется группой системных аналитиков, конечным результатом деятельности которых должно стать полное и непротиворечивое описание требований к проектируе­мой системе на языке, понятном разработчикам ПО.

На данном этапе выявляются проектные процедуры и операции, автоматизация которых возможна и целесооб­разна, изучаются особенности математических моделей проектируемых объектов, выбирается или разра­батывается математическое обеспечение. Принимается решение о типах используемых средств разработки, рассматривается возможность использования го­товых компонентов ПО. Здесь же решаются вопросы планирования работ, устанавливается их очередность, этапность сдачи подсистем САПР в эксплуатацию.

Этап 2. Определение спецификаций на ПО САПР. На этом этапе производится точное описание функций САПР, разрабатываются и утверждаются входные и про­межуточные языки, форма выходной информации для каждой из подсистем, описывается возможное взаимодей­ствие с другими программными комплексами, специфи­цируются средства расширения и модификации ПО, раз­рабатываются интерфейсы обслуживающих и проекти­рующих подсистем, решаются вопросы организации базы данных, утверждаются основные алгоритмы. Итогом выполнения данного этапа явля­ются эксплуатационные и функциональные специфика­ции, содержащие конкретное описание ПО. Разработка спецификаций требует тщательной работы системных аналитиков, постоянно контактирующих с пользователя­ми, в большинстве случаев не способными самостоятель­но сформулировать четкие требования к системе.

Эксплуатационные спецификации содержат сведения о быстродействии ПО, затратах памяти, требуемых тех­нических средствах, надежности и т. д. Функциональные спецификации определяют функции, которые должна выполнять САПР, т. е. в них опреде­ляется, что надо делать, но без указания, как.

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

Значение спецификаций при создании ПО определяет­ся тремя факторами:

1) спецификации являются заданием на разработку ПО, и строгое их выполнение – закон для разработчика;

2) спецификации используются для проверки готово­го ПО (выполняет ли оно требуемые функции и в какой степени);

3) спецификации, являясь неотъемлемой частью про­граммной документации, облегчают сопровождение и мо­дификацию ПО.

Завершается второй этап цикла жизни подготовкой тестов, на которых будут проводиться испытания при приемке САПР. На подготовленные тестовые данные в дальнейшем не будет оказывать влияние конкретная реализация системы.

Этап 3. Проектирование ПО САПР. На этом этапе формируется структура ПО и разрабатываются алгорит­мы. Устанавливается со­став модулей с разделением их на иерархические уровни на основе изучения схем алгоритмов для типовых задач проектирования. Выбирается структура информацион­ных массивов, составляющих базу данных. Фиксируются межмодульные интерфейсы.

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

Этап 4. Кодирование модулей. На данном этапе производится программирование модулей на каком-либо алгоритмическом языке, т. е. перевод разработанных алгоритмов на язык программирования. Этот этап менее сложен по сравнению со всеми остальными этапами цик­ла жизни ПО. Для его реализации широко используется метод структурного программирования. Одна из задач, которую необходимо решить на данном этапе, – обосно­ванный выбор языков программирования.

Этап 5. Тестирование. Тестированием называется процесс проверки ПО (или его компонентов), имеющий целью обнаружение ошибок в ПО. При этом использу­ются тестовые наборы, включающие в себя специально подобранные исходные данные и эталонные результа­ты. Тестирование включает в себя три шага: автоном­ное, комплексное и системное. При автономном тестиро­вании контролируется каждый компонент ПО изолиро­ванно от других на данных, подготовленных его разра­ботчиком.

В процессе комплексного тестирования всего ПО выяв­ляются ошибки, связанные с нарушением спецификаций на все ПО САПР, при этом используются тесты, подго­товленные на этапе 2. Системное тестирование – испы­тание ПО САПР на технических средствах и данных пользователя в производственных условиях. Тестирова­ние является составной частью отладки – процесса об­наружения ошибок, их локализации и устранения.

Необходимо отметить, что надежность ПО заклады­вается на более ранних этапах его цикла жизни, правиль­ное тестирование позволяет лишь выявить большинство из относительно немногочисленных вкравшихся ошибок. Повысить надежность плохо спроектированных программ никакое тестирование не способно.

Этап 6. Сопровождение. Как показано на диаграм­ме рис. 1.1, наибольшие затраты в цикле жизни ПО приходятся именно на этап сопровождения. Эти затраты для ПО САПР складываются в основном из затрат: 1) на устранение ошибок, не выявленных на этапе тести­рования; 2) на внесение изменений в первоначальную версию ПО, вызванных взаимным недопониманием заказ­чика и разработчика ПО на первых двух этапах создания ПО; 3) на адаптацию ПО к быстроизменяющимся требованиям к САПР.

 

 

Устранение ошибки во время эксплуатации ПО обхо­дится по крайней мере в два раза дороже, чем на этапе тестирования. На рис. 1.2 показана динамика измене­ния количества обнаруживаемых ошибок в ПО с мо­мента сдачи его в эксплуатацию. Первоначально об­наруживаются наиболее «простые» ошибки, затем неко­торое время все идет нормально, но с накоплением опыта и повышением квалификации пользователей САПР, с ее полной загрузкой начинают выявляться наиболее «тон­кие» ошибки. И если при проектировании ПО не были приняты соответствующие меры (такие, например, как использование принципа модульности), то оно со време­нем становится все менее упорядоченным и менее жизне­способным (верхняя часть заштрихованной области на рис. 1.2.). Одна из проблем сопровождения состоит в том, что даже для «правильно» спроектированного ПО исправление одной ошибки влечет за собой внесение но­вой ошибки с вероятностью 20–50%. Третья составляю­щая затрат на сопровождение для ПО САПР наиболее существенна и связана с задачей продления срока эффек­тивной эксплуатации САПР, поскольку изменение техно­логий промышленного производства и развитие матема­тического обеспечения АП происходят обычно более быст­рыми темпами, чем может создаваться ПО новых САПР. Для замедления морального старения ПО САПР пред­лагают три возможных способа:

1) разработка САПР совместно с разработкой новых промышленных технологий;

2) разработка САПР с учетом прогнозов на будущее;

3) создание САПР, открытых как к новым элементам математического обеспечения, так и по отношению к но­вым технологиям и предметным областям.

Наиболее перспективен третий способ, хотя он и наи­более сложен в реализации.

Особенно остро задача сопровождения ПО стоит для САПР, эксплуатируемых в нескольких организациях, по­скольку процесс исправления обнаруженных ошибок, включения новых программных компонентов различными пользователями очень скоро приводит к появлению стольких версий ПО, что их учет и контроль становится невозможным. Чтобы этого не происходило, все коррек­тивы и дополнения необходимо вносить только в версию разработчика ПО и передавать ее всем пользователям одновременно через достаточно крупные промежутки вре­мени, называемые периодом обновления.

Рассмотренная модель цикла жизни ПО весьма услов­на. Реальный процесс разработки носит итерационный характер, многие этапы перекрывают друг друга, выпол­няются параллельно.