У ДК 681.3

Мирошниченко Е.А. Технология программирования: Учебное пособие. — Томск: Изд. ТПУ, 1999. — 80 с.

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

Учебное пособие подготовлено на кафедре вычислительной техники ТПУ и предназначено для студентов специальности 220100 "Электронные вычислительные машины, системы, комплексы и сети" Центра дистанцион­ного образования ТПУ. Также пособие рекомендуется для студентов всех специальностей, связанных с созданием математического и программного обеспечения вычислительных систем.

Печатается по постановлению Редакционно-издательского Совета Том­ского политехнического университета.

Рецензенты:

Поддубная Т.Н., к.п.н., доцент кафедры прикладной информатики факульте­та информатики Томского государственного университета.

Ушаков А.В., к.ф.-м..н., зав. кафедрой прикладной математики Томского государственного архитекгурно-строительного университе­та.

Темплан 1999

Томский политехнический университет, 1999

ВВЕДЕНИЕ

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

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

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

Все происходящие в области развития вычислительной техники процессы оставляют неизменным одно: требование к высокой профессиональности программистов-разработчиков. Смещаются лишь акценты. Если на заре вы­числительной техники программист-эксперт должен был во всех тонкостях разбираться в устройстве вычислительной установки, владеть системой ко­манд процессора и изобретать “трюки”, позволяющие экономить память и время, то современный специалист должен владеть методами и средствами грамотной организации своей работы, уметь работать в коллективе и должен программировать не столько “эффективно”, сколько “надежно”.

Данное учебное пособие предназначено для студентов всех специально­стей, связанных с созданием математического и программного обеспечения ВС. В нем с системных позиций излагаются современные взгляды на разра­ботку ПО как промышленной продукции, включая проблемы оценки качест­ва программного продукта. Изложение материала в пособии в основном ве­дется на основе Единой системы программной документации (ЕСПД) — комплекса государственных стандартов (ГОСТов), устанавливающих взаи­моувязанные правила разработки, оформления и обращения программ и про­граммной документации. Эти стандарты продолжают действовать, вследст­вие чего необходимо знать и уметь применять их положения. С другой сто­роны, интеграция России в мировое сообщество и широкое внедрение зару­бежного ПО привело к “размыванию” использования отечественных стан­дартов и нередкому использованию “де-факто” зарубежных подходов. С учетом всех этих факторов, в данном пособии используются как принятая в мире терминология, так и терминология ЕСПД.

Раздел 1 является вводным. В нем рассматриваются основные понятия, используемые в области разработки ПО. Разделы 2—7 посвящены отдельным этапам разработки ПО. Раздел 8 содержит описание основных понятий и подходов в области оценки качества ПО.

1. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК ПРОМЫШЛЕННАЯ ПРОДУКЦИЯ

1.1. Общие положения

Принято выделять семь видов обеспечения ВС [11]:

• 
  математическое;
  
• 
  лингвистическое;
  
• 
  информационное;
  
• 
  программное;
  
• 
  техническое;
  
• 
  методическое;
  
• 
  организационное.
  

Из всех видов обеспечении программное обеспечение (ПО) занимает особое место, поскольку основная доля затрат на оснащение и эксплуатацию ВС приходится именно на ПО.

Определим такие основные понятия, как программа, программный ком­плекс, программная система, программный продукт и программное обеспе­чение.

Под программой будем понимать:

1) совокупность кода и данных, пригодных для исполнения процессорам (исполняемая программа);

2) самостоятельный компонент относительно небольшого размера, пред­назначенный для решения локальной задачи (программа как компонент сис­темы).

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

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

Программное обеспечение — наиболее общее понятие, под которым по­нимают программы, программные системы или продукты в совокупности или по отдельности, в зависимости от контекста использования этого терми­на.

Будем условно делить программные продукты на небольшие, средние и крупные. Объем исходного текста небольших программ составляет несколь­ко сот операторов языка высокого уровня, средних — до десятков тысяч и крупных — до миллиона.

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

Совершенно иным классом программ являются полновесные программ­ные средства, которые в настоящее время принято квалифицировать как про­дукцию производственно-технического назначения. В этом качестве про­граммные продукты являются непосредственной производительной силой и не отличаются от любой другой промышленной продукции [5].

Создание хорошего программного продукта является весьма трудоемкой задачей, решение которой, как правило, не под силу одному человеку. Про­граммисты-одиночки (“хакеры”) могут обладать гениальным даром к быст­рой алгоритмизации и кодированию нетривиальных задач, созданию новых методов и идей программирования, приобретая при этом значительную из­вестность. Однако не в их силах в одиночку решать весь комплекс проблем разработки средних и крупных программных продуктов за приемлемые сро­ки.

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

Программисту следует трезво оценивать свои возможности и руково­дствоваться известной фразой “гении встречаются крайне редко, и нет осно­вания полагать, что в среде программистов их число выше среднего” [1].

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

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

1.2. Характеристики программного обеспечения

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

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

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

Наиболее часто оценивают такие свойства ПО как:

• 
  надежность;
  
• 
  сопровождаемость;
  
• 
  удобство применения;
  
• 
  эффективность;
  
• 
  универсальность (гибкость);
  
• 
  корректность.
  

Указанные свойства являются свойствами “верхнего” уровня, то есть ка­ждое из них подразумевает наличие множества второстепенных свойств.

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

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

Свойства программ и методы их оценки подробно рассмотрены в разделе 8, посвященном оценке качества ПО.

1.3. Жизненный цикл программного обеспечения

Жизненный цикл программного продукта состоит из трех крупных фаз (рис. 1.1):

1) разработка;

2) использование (эксплуатация);

3) сопровождение и продолжающаяся разработка.



Рис. 1.1. Фазы жизненного цикла программного продукта
В фазе разработки программный продукт разрабатывается и выпускает­ся.

В фазе эксплуатации созданный продукт используется на практике кон­кретными потребителями.

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

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

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

Основой процесса сопровождения является, как правило, юридическая договоренность между разработчиками и пользователями (заказчиками), в которой может быть оговорен также срок, в течение которого принимаются

претензии. Модификации при сопровождении обычно инициируются пользо­вателями, обнаруживающими ошибки и недостатки продукта.

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

Фазу разработки обычно разделяют на следующие логические этапы [15, 11]:

1) системный анализ;

2) проектирование;

3) программирование (кодирование);

4) отладка и тестирование;

5) документирование;

6) выпуск.

В ЕСПД описываются следующие формальные этапы работ:

1) техническое задание;

2) эскизный проект",

3) технический проект;

4) рабочий проект;

5) внедрение.

Рассмотрим краткую характеристику логических этапов с указанием то­го, какие формальные этапы разработки им соответствуют в ЕСПД.

На этапе системного анализа происходит анализ необходимости самого программного продукта, выявляются наиболее общие требование к нему. В терминах ЕСПД это этап технического задания. Результатом системного ана­лиза является выработка спецификации требований на программный про­дукт, содержащая указанные требования в формальном виде. ЕСПД называет такую спецификацию техническим заданием (ТЗ).

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

Этап кодирования при наличии достаточно детального проекта (каковым является технический проект) является рутинным. Фактически, кодирование — это в некоторой степени механический процесс реализации спроектиро­ванных алгоритмов на конкретном языке программирования с использовани­ем конкретного инструментария. Результатом кодирования являются собст­венно программы как в исходном тексте, так и в бинарном виде, пригодном к исполнению.

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

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

На этапе выпуска продукт проходит испытания по утвержденной методи­ке, после чего поставляется, внедряется или продается.

Этапам кодирования, отладки и тестирования и документирования в ЕСПД соответствует этап рабочего проекта. Выпуск соответствует этапу внедрения.



Рис. 1.2. Итеративность процесса разработки ПО

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

Таким образом, процесс разработки является существенно итеративным (рис. 1.2). Только простейшие задачи проходят все шаги без итераций. Для больших проектов проектирование не кончается никогда. К сожалению, при­чины этого кроются в человеческом сознании, что характерно показано на рис. 1.3, заимствованном из [8].



Рис. 1.3. Ироническое изображение процесса разработки ПО

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

Трудно иногда провести четкую границу между этапом системного ана­лиза и этапом проектирования, вследствие чего эти этапы иногда объединяют в один.

Далее, программирование часто начинается до окончательного заверше­ния проектирования. Более того, существуют подходы к проектированию “снизу-вверх”, при которых создание программ в процессе проектирования предусматривается самой технологией.

Отладка и тестирование начинаются практически одновременно с про­граммированием, они, по сути, нерасторжимы.

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

По сути, все логические этапы перекрываются и, самое главное, не могут не перекрываться, особенно в случае коллективной разработки. Различные разработчики и даже группы разработчиков занимаются проектированием, кодированием и документированием одновременно. Рис. 1.4 в большей мере соответствует ситуации, которая возникает при разработке крупного про­граммного продукта [15].

Следует особо отметить, что любой процесс разработки, начавшись, практически никогда не “сходит на нет”, то есть выпуск продукта обычно прерывает его в некоторой точке. Причина здесь, скорее, философская: иде­ал, к сожалению, недостижим.

Рос. 1.4. Распределение ресурсов при разработке ПО:

1 — системный анализ, 2 — проектирование, 3 — кодирование и отладка, 4 — верификация, 5 — документирование

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

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

1.4. Вопросы для самоконтроля

1.Что понимается под терминами “программа”, “программный ком­плекс”, “программная система”, “программный продукт”, “программное средство”, “программное обеспечение”?

2. Отличается ли принципиально разработка ПО от разработки любой другой промышленной продукции?

3. Что понимается под грамотностью разработчика ПО?

4. Какие характеристики ПО являются наиболее важными?

5. Из каких фаз состоит жизненный цикл программного продукта?

6. Из каких логических этапов состоит разработка ПО?

7. Какие формальные этапы разработка ПО определяет ЕСПД? Какова их связь с логическими этапами?

8. В чем причина итеративности процесса разработки ПО?

9. Как обычно распределяются ресурсы по основным задачам разработки ПО во времени?

2. СИСТЕМНЫЙ АНАЛИЗ

2.1. Общие положения

Целью системного анализа в наиболее общем виде является описание и исследование систем. Под системой будем понимать совокупность элемен­тов (компонентов) системы и связей (отношений) между ними [14]. Система характеризуется структурой и поведением.

Структуру системы наиболее часто представляют с помощью понятия графа. Под графом G будем понимать пару G = (V, D), где V — множество вершин графа, графически изображаемых точками или окружностями; D — множество дуг графа, графически изображаемых стрелками, соединяющими вершины (рис. 2.1). При этом вершины, как правило, соответствуют элемен­там системы, а дуги — отношениям между элементами.

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

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

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

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

Эта внешняя сложность обычно возникает из-за “нестыковки” между пользователями системы и ее разработчиками: пользователи с трудом могут объяснить в форме, понятной разработчикам, что на самом деле нужно сде­лать. Бывают случаи, когда пользователь лишь смутно представляет, что ему нужно от будущей программной системы. Это в основном происходит не из-за ошибок с той или иной стороны; просто каждая из групп специализируется в своей области, и ей недостает знаний партнера. У пользователей и разра­ботчиков разные взгляды на сущность проблемы, и они делают различные выводы о возможных путях ее решения. На самом деле, даже если пользова­тель точно знает, что ему нужно, мы с трудом можем однозначно зафиксиро­вать все его требования. Обычно они отражены на многих страницах текста, “разбавленных” немногими рисунками. Такие документы трудно поддаются пониманию, они открыты для различных интерпретаций и часто содержат элементы, относящиеся скорее к дизайну, чем к необходимым требованиям разработки.

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

Этап системного анализа состоит из следующих стадий:

1) обоснование необходимости разработки программы;

2) научно-исследовательские работы (НИР);

3) разработка и утверждение технического задания.

Наиболее полно формализована последняя стадия, тогда как первые две во многом отдаются на волю исполнителей. В то же время, на стадии разра­ботки спецификации на программу (технического задания) фактически толь­ко обобщаются и утверждаются результаты, полученные на первых стадиях. • Рассмотрим стадии системного анализа подробней.

следующая страница>