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

Рис. 26.1.

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

На этом этапе также определяется среда, в которой будет выполняться программа: требования к аппаратуре, используемая ОС и другое программное обеспечение.

Постановка задачи завершается созданием технического задания, а затем внешней спецификации программы, включающей в себя:

■ описание исходных данных и результатов (типы, форматы, точность, способ передачи, ограничения) ;

■ описание задачи, реализуемой программой;

■ способ обращения к программе;

■ описание возможных аварийных ситуаций и ошибок пользователя.

Таким образом, программа рассматривается как "черный ящик", для которого определена функция и входные и выходные данные.

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

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

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

■ Какая точность представления данных необходима?

■ В каком диапазоне лежат значения данных?

■ Ограничено ли максимальное количество данных?

■ Обязательно ли хранить их в программе одновременно?

■ Какие действия потребуется выполнять над данными?

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

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

Проектирование. Под проектированием программы понимается определение общей структуры и взаимодействия модулей.

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

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

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

ВНИМАНИЕ

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

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

Процесс проектирования является итерационным, поскольку в программах реального размера невозможно продумать все детали с первого раза.

Структурное программирование. Программирование здесь рассматривается "в узком смысле", т.е. понимается как запись программы на языке программирования по готовому алгоритму. Этот процесс часто называют кодированием , чтобы отличить его от полного цикла разработки программы.

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

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

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

Во-вторых, для отладки каждого модуля, а затем более крупных фрагментов программы требуется каждый раз составлять свои тестовые примеры, и программист часто вынужден имитировать то окружение, в котором должен работать модуль. Нисходящая же технология программирования обеспечивает естественный порядок создания тестов – возможность нисходящей отладки, которая рассмотрена далее.

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

Нисходящее тестирование. Этот этап записан последним, но это не значит, что тестирование не должно проводиться на предыдущих этапах. И проектирование, и программирование обязательно должны сопровождаться написанием набора тестов – проверочных исходных данных и соответствующих им наборов эталонных реакций.

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

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

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

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

ВНИМАНИЕ

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

Естественно, полное тестирование программы, пока она представлена в виде скелета, невозможно, однако добавление каждого следующего уровня позволяет постепенно расширять область тестирования.

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

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

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

Рис. 26.2.

• Под типами и форматами не имеются в виду типы языка программирования.

В этой статье попробуем раскрыть основные этапы разработки программы, написанной на любом языке программирования.

Спецификация (определение требований к программе):

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

Разработка алгоритма:

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

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

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

Кодирование:

После проведения спецификации и составления алгоритма решения, используемый алгоритм в итоге будет записан на необходимом языке программирования (Pascal, Delphi, C++ и др.). Результатом этапа кодирования является готовая программа.

Этапы разработки программы. Отладка:

На данном этапе программист занимается отладкой программы, то есть поиском и устранением ошибок. Последние делятся на две группы: алгоритмические и синтаксические (ошибки в тексте исходной программы). Из этих двух групп ошибок наиболее легко устранить синтаксические ошибки, тогда как алгоритмические ошибки определить достаточно трудно.

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

Тестирование:

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

Создание справочной системы:

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

Кроме справочной информации справочная система содержит необходимые инструкции по инсталляции программы. Обычно их представляют в виде файла Readme разных форматов: *.doc, *.txt, *.htm. Более подробно рассматриваемый этап разработки программы будет описан позже.

Создание установочного диска (CD-ROM):

Инсталяционный диск (CD-ROM) разработчики создают для того, чтобы пользователи могли самостоятельно, без помощи программиста, проинсталировать данную программу на свой ПК.

Как правило, кроме самой программы установочный CD-ROM располагает файлами справочной информации и инструкциями по установке программы. Нужно заметить, что большинство современных программ, включая программы, разработанные в среде Delphi, во многих случаях, даже путем простого копирования файлов не могут быть проинсталированы на компьютер пользователя, поскольку для правильной работы этих программ необходимо присутствие специальных библиотек, а также компонентов, которые могут отсутствовать на ПК конкретного пользователя.

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

Процесс разработки программного обеспечения можно разбить на этапы (фазы), показанные на рис. 15.

Рис. 15. Этапы разработки программного обеспечения

Работа над программным обеспечением начинается с составления документа, называемого “Задание на разработку программного обеспечения (техническое задание)”.

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

Техническое задание

Техническое задание включает в себя три этапа: 1) обоснование необхо­димости разработки программы; 2) проведение научно-исследовательских работ; 3) разработка и утверждение технического задания.

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

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

Разработка и утверждение технического задания включает в себя:

Определение требований к программе;

Разработку технико-экономического обоснования разработки программы;

Определение стадий, этапов и сроков разработки программы и документации на нее;

Выбор языков программирования;

Определение необходимости проведения научно-исследовательских работ на последующих стадиях;

Согласование и утверждение технического задания.

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

Какими должны быть входные данные?

Какие данные являются корректными и какие ошибочными?

Кто будет использовать программное обеспечение, и каким должен быть интерфейс (средство общения с пользователем)?

Какие упрощения, предположения и допущения можно сделать по отношению к программам?

Какими должны быть выходные данные?

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

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

Проектирование

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

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

1) он имеет средства взаимодействия с внешней средой;

2) он является самостоятельной программной единицей, выполняющей определенные функции.

Частью интерфейса являются потоки данных. При описании их для каждого модуля необходимо дать ответы на следующие вопросы:

Какие данные можно передать в модуль до начала его выполнения?

Какие упрощения, предположения и допущения сделаны по отношению к модулю?

Что будет с данными после того, как модуль завершит свою работу?

На рис. 16 приведен пример описания модуля, используемого для сортировки целых чисел.

Рис. 16. Пример спецификации модуля

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

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

Рабочий проект

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

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

Кодирование должно быть простым. Должен соблюдаться так называемый KISS–принцип: Keep It Simple, Stupid (делай проще, глупец!). Изощренное программирование может обойтись слишком дорого при отладке и модификации программы. Необычное кодирование (например, использование скрытых возможностей машины) часто препятствует отладке программы и, конечно, затрудняет ее использование другими программистами.

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

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

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

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

Тестирование – это проверка программы на работоспособность. Отладка имеет место тогда, когда программа со всей очевидностью работает неправильно. Отладка начинается всегда в предвидении отказа программы. Если же оказывается, что программа работает верно, то она тестируется. Часто случается так, что после прогона тестов программа вновь должна быть подвергнута отладке. Таким образом, тестирование устанавливает факт наличия ошибки, а отладка выявляет ее причину.

Для несложного приложения тестирование может оказаться простым. Большие программы поддаются тестированию с трудом. Возможны устранения ошибок на этапе эксплуатации.

Можно привести примеры ошибок в программных комплексах, допущенных при разработке и не обнаруженных при тестировании.

В “Справочнике Microsoft Works” в интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как

ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина).

Однако, в действительности, работа данной функции должна иметь следующий вид: ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь). В “Руководстве пользователя Microsoft Works для Windows” пакета Works 3.0 эта ошибка исправлена.

Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего, из–за ошибки в программе – вместо требуемой в операторе точки программист поставил запятую. Оператор на языке Фортран был записан

Do 50 i = 12,525

На самом же деле он должен был выглядеть следующим образом:

Do 50 i = 12.525

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

В 1983 году произошло наводнение в юго–западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.

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

Таблица 2

Виды и причины ошибок

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

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

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

Внедрение

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

Примером добавления новых функций в программный комплекс является текстовый редактор Лексикон 1.3. Данная версия получена из текстового процессора 1.2 путем включения в него функций – импортирование графических файлов в формате PCX в текстовые файлы.

Документация

На рис. 15 прямоугольник, отражающий каждый этап разработки програм­мы, соединен с прямоугольником “Документ”. При этом стрелки направлены в обе стороны. Идеи и решения, используемые на каждом этапе, влияют на документацию, сопровождающую этап, так же, как и документация влияет на идеи и решения.

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

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

Техническое задание должно содержать следующие разделы:

Введение;

Основания для разработки;

Назначение разработки;

Требования к программе и программному изделию;

Требования к программной документации;

Технико-экономические показатели;

Стадии и этапы разработки;

Порядок контроля и приемки.

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

Спецификация является основным программным документом и составляется в соответствии с ГОСТ. Спецификация представляет собой таблицу, состоящую из граф: “Обозначение”, “Наименование”, “Примечание”. В графе “Обозначение” записывают обозначения перечисляемых документов и программ. В графе “Документация” указывают наименования и вид документа или программы. В графе “Примечание” – дополнительные сведения, относящиеся к записанным в спецификации программам.

Описание программы содержит:

– прокомментированные исходные тексты (листинги) модулей программы и управляющего модуля;

– схему разбиения программного комплекса на программные модули;

– схему потоков данных программного комплекса;

– схему взаимодействия программных модулей;

– планы и данные для тестирования программного комплекса;

– другие материалы, иллюстрирующие проект, например, схемы алгоритмов.

Второй вид документов содержит информацию, необходимую для работы с программным комплексом. Эти документы могут оформляться в печатном виде и (или) “встраиваться” в программный комплекс.

Дисциплина программирования – это важный фактор успеха разработки программных продуктов. Принципы разработки программ, приведенные в последней главе, справедливы для процедурных языков программирования и для объектно-ориентированных языков.

Версия 6.0 Турбо Паскаля, выпущенная в 1990 году, наглядно продемонстрировала преимущества объектно–ориентированной технологии программирования. В комплект поставки новой версии вошла библиотека Turbo Vision, на которой многие тысячи программистов осваивали принципы ООП. За короткий срок появилось множество коммерческих программ, построенных на базе Turbo Vision. Эта библиотека поистине революционизирует процесс разработки интерактивных программ, сокращая до минимума сроки и обеспечивая высочайшее качество программ.

Эволюция технических средств персональных компьютеров привела к повсеместному вытеснению старой “доброй” ОС MS–DOS значительно более мощными системами Windows, программирование для которых существенно сложнее, чем программирование для MS–DOS. С выпуском системы Borland Pascal with Objects корпорация Borland предоставила в распоряжение программистов весьма эффективные средства разработки и отладки программ, рассчитанные на работу под управлением операционной оболочки Windows. Но все же несколько лет назад о создании своих собственных программ под Windows рядовому программисту оставалось только мечтать.

Этапы разработки программного обеспечения

Профессиональное программирование подразумевает, что результатом труда, – программным продуктом, – будет пользоваться определенный круг людей, пользователей. На этапе разработки программы, в которой может участвовать группа людей, пользователей представляет Заказчик .

Для выполнения задачи создания и эксплуатации программного обеспечения ее разбивают на определенные этапы:

1. Постановка задачи.

2. Составление алгоритма.

3. Составление и ввод программы.

4. Отладка и тестирование программы.

5. Сопровождение программного продукта.

Создание любой программы начинается с постановки задачи . Изначально задача ставится в терминах некоторой предметной области, и необходимо перевести ее в понятия и выражения, более близкие к программированию. Поскольку программист первоначально редко досконально разбирается в предметной области, а Заказчик – в программировании, то постановка задачи может стать весьма непростым итерационным процессом.

Постановка задачи заканчивается созданием технического задания, а затем и внешней спецификации программы , которая включает в себя:

1. Описание исходных данных и результатов (виды, представление, точность, ограничения и т.п.).

2. Описание задачи, реализуемой программой.

3. Способ обращения к программе.

4. Описание возможных особых и аварийных ситуаций и ошибок пользователя.

На этом этапе программа рассматривается как «черный ящик», для которого определяется выполняемая им функция, входные и выходные данные. Каким образом достигается выполнение функций, здесь не указывается.

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

Третий этап как раз и является непосредственно программированием на языке, понятном ЭВМ. По своей сути третий этап является продолжением второго, так как программа тоже есть форма записи алгоритма с максимальной степенью детализации, – программная.

Изучению одного из языков программирования высокого уровня и посвящается данный курс.

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

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

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

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

Возможно и другое деление на этапы с приблизительным делением по времени реализации, как указано на рис. 1.1:

1. Анализ требований.

2. Определение спецификаций.

3. Проектирование.

4. Кодирование.

5. Автономное тестирование.

6. Комплексное тестирование.

Рис. 1.1. Временные затраты на реализацию этапов цикла разработки программного обеспечения (за исключением этапа эксплуатации и сопровождения)

На последний же этап эксплуатации и сопровождения объемных программных продуктов отводится более половины времени: до 67% от общего времени жизненного цикла.

Классическим называется следующий набор технологических этапов (процессов) :

1. Возникновение и исследование идеи

2. Управление

3. Анализ требований

4. Проектирование

5. Программирование

6. Тестирование и отладка

7. Ввод в действие

8. Эксплуатация и сопровождение

9. Завершение эксплуатации

Процессы жизненного цикла программного обеспечения определены международным стандартом ISO 12207 и делятся на три группы (без привязки ко времени) :

· Основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение.

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

· Организационные процессы: управление, создание инфраструктуры, усовершенствование, обучение.

программное обеспечение управление

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

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

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

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

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

Рисунок 1- Модифицированная каскадная модель разработки программного обеспечения

Модифицированная каскадная модель предусматривала возможность возвращения к предыдущим этапам.

Спустя непродолжительное время после своего появления на свет каскадная модель была доработана Уинстом Ройсом с учетом взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания . В таком «обратимом» виде каскадная модель просуществовала долгое время и явилась основой для многих проектов (рисунок 1).

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

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

Рисунок 2- V-образная модель разработки программного обеспечения

V-образная модель позволяет гораздо лучше контролировать результат на предмет его соответствия ожиданиям, поскольку сфокусирована на тестировании .

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

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

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

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

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

Предложенная Барри Боэмом в 1988 году спиральная модель стала существенным прорывом в понимании природы разработки программного обеспечения, хотя объединяет каскадный подход и итерационный процесс проектирования на основе создания прототипов (рисунок 3).

Рис. 3.

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

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

Впервые предложенная Филиппом Крачтеном в 1995 году, итеративная модель объединяет главные преимущества спиральной, инкрементной, каскадной моделей, а также методов разработки на основе создания прототипов и объектно-ориентированного подхода (рисунок 4). Она завоевала большую популярность и в том или ином виде используется во многих современных проектах .

Рисунок 4- Итеративная модель разработки программного обеспечения

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

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

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

Самым известным и авторитетным стандартом качества следует считать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 году, хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 голу. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания программного обеспечения. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (таблица 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA) .

Таблица 1-Модель СММ

Название уровня	Ключевые области процесса
1 - Начальный	Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено
2 - Повторяющийся	Управление программными конфигурациями. Обеспечение качества программных продуктов. Управление контрактами подрядчиков. Контроль за ходом проектов. Планирование программных проектов. Управление требованиями
3 - Определенный	Экспертные оценки. Координация взаимодействий проектных групп. Инженерия программного продукта. Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса
4 - Управляемый	Менеджмент качества ПО. Управление процессом на основе количественных методов
5 - Оптимизируемый	Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов, а он получил новое имя - SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI - Capability Maturity Model Integrated (CMMI) - интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления - классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA).

В таблице 2 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 2- Соответствие уровней зрелости стандартов CMM, CMMI

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO.

В современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания программного обеспечения. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI .

Модель зрелости процесса разработки программного обеспечения (CMM), разработанная Институтом программной инженерии в университете Carnegie Mellon, предлагает пять уровней зрелости (таблица 3). Она помогает организациям повысить зрелость своих процессов разработки программного обеспечения, и организации могут быть оценены и аккредитованы в соответствии с этими уровнями.

Таблица 3-Уровни зрелости разработки программного обеспечения

Уровень 1 - начальный уровень	Процесс разработки ПО спонтанен, и регламентированы лишь немногие процессы. Успех разработки может зависеть от отдельных сотрудников.
Уровень 2 - уровень повторяемости	Созданы основные процессы управления проектами для отслеживания затрат, календарного плана и функциональных возможностей.
Уровень 3 - уровень регламентируемости	Процесс разработки ПО документирован, стандартизирован и интегрирован со стандартным процессом разработки ПО организации как для операций управления, так и для операций разработки. Во всех проектах используется стандартизированный процесс.
Уровень 4 - уровень управляемости	Проводится сбор подробных показателей процесса разработки ПО и качества продукта, что позволяет понять процесс и продукты и управлять ими.
Уровень 5 - уровень оптимизируемости	Непрерывная оптимизация процесса обеспечивается количественной обратной связью от процесса и от пилотных инновационных идей и технологий.

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